Specifiek type water binnen een specifiek gebied uit BRT API ophalen

Datasets BRT
#1

Mijn vraag lijkt sterk op deze vraag: Specifiek type gebouw uit BRT API ophalen - BRT - Geoforum op dit forum.

Ik probeer alle meren en plassen in een specifieke provincie te downloaden vanaf de BRT API (waterdeel). Het lukt me om te zoeken op geografisch gebied, maar ik zie geen mogelijkheid om daarnaast verdere specificaties op te geven. Liefst zou ik selecteren op typeWater (dit attribuut is niet beschikbaar via de API, wel via handmatige download) of anders tdnCode. Zie ik ergens iets over het hoofd, of is deze verdere specificatie op dit moment niet mogelijk via de API?

#2

In de REST API is dit filter inderdaad op dit moment niet beschikbaar. We hebben een story aangemaakt op dit op te pakken, als het meezit kan dit mee in onze komende sprint en dan zou het over ongeveer 3 weken beschikbaar moeten zijn.

#3

Zojuist is een nieuwe versie van de BRT Top10NL API uitgerold. Hierin bestaat nu een filter op typeWater op de /waterdelen endpoints (GET & POST). typeWater is ook toegevoegd als eigenschap van een waterdeel in de respons van de waterdelen endpoints.

Let op: typeWater is een optionele eigenschap van een waterdeel. Dus niet ieder waterdeel zal te vinden zijn met één van de opties van het nieuwe filter.

#4

Fantastisch, en super snel! Bedankt.

#5

Ik heb het idee dat er sinds die nieuwe uitrol iets is met de precisie (en projectie?) hoewel de kans natuurlijk groot is dat het aan mij ligt. kijk bijvoorbeeld naar:

p = request(
‘Get’,
‘https://brt.basisregistraties.overheid.nl/api/v2/waterdelen/110949124’,
headers={
‘X-api-key’:X_API_KEY,
‘Accept-Charset’: ‘UTF-8’,
‘Cache-Control’: ‘no-cache’,
‘Content-type’: ‘application/json’
},
)

Als voorbeeld de eerste coordinaten van de request:

[3.313602275, 47.975230171],
[3.313602276, 47.975230171],
[3.313602278, 47.975230171],
[3.313602285, 47.975230172],
[3.313602286, 47.975230172],
[3.313602287, 47.975230171],
[3.313602283, 47.97523017],
[3.313602278, 47.97523017],
[3.313602276, 47.97523017],
[3.313602275, 47.97523017],
[3.313602274, 47.97523017],
[3.313602272, 47.975230171],
[3.313602269, 47.975230172]

ter vergelijking coordinaten van een overlappende kadaster feature:
[4.763341508422365, 51.58595341365112]
1: (2) [4.763453450554716, 51.585695151083414]
2: (2) [4.763454985692882, 51.58569159071465]
3: (2) [4.763423830532635, 51.58567707840568]
4: (2) [4.763390449037446, 51.58561248655532]
5: (2) [4.76339036251009, 51.5856009354762]
6: (2) [4.763383032171039, 51.58560095929665]
7: (2) [4.763385906458291, 51.58553146418018]
8: (2) [4.763408330189764, 51.585454765440794]

Groet Jan W.

#6

Het zou niet met de uitrol te maken moeten hebben, maar het is zeker een fout. Het is gelukkig eenvoudig te fixen. Ik geef een seintje als de API is bijgewerkt.

#7

API is bijgewerkt. Er worden weer standaard correcte ETRS89 coordinaten geleverd.