Ontbrekende hoogte in DTB

De DTB databron die via PDOK wordt geserveerd, lijkt wijzigingen te hebben ondergaan (en niet hier vermeld helaas).

In ieder geval 2 wijzigingen: aantal geretourneerde objecten in de WFS en het ontbreken van hoogtegegevens.

Het lijkt erop dat het aantal objecten in een aanroep sterk is teruggebracht, tot 1000 stuks. Andere databronnen hanteren 10.000 dacht ik. Is dat met een reden gedaan?

Het tweede vind ik problematischer, het lijkt of er door een fout geen hoogten meer worden geleverd:

De Z-waarde is nu overal 0.000000

Bij de verwerking naar AutoCAD ontbreken ook de hoogten bij de hoogtepunten:

Wat natuurlijk erg raar staat.

Iemand die hier iets over kan zeggen?

1 like

@Anton Bedankt voor je signaleringen. Ik heb contact gehad met Rijkswaterstaat over de foutieve Z-waardes. Door een fout in de levering zijn de juiste Z-waardes niet meegekomen in de aanlevering aan PDOK. Ze gaan bezig om dit te herstellen.
Voor wat betreft het aantal op te vragen objecten per WFS request heb ik nog geen antwoord, daar kom ik op terug zodra ik meer weet.

3 likes

@Anton We hebben het even uitgezocht en het limiet voor het aantal op te vragen objecten van deze WFS staat sinds zijn release (februari dit jaar) op 1000. Dit is een standaard limiet die we voor onze WFS’en hanteren. Wel is het zo dat de DTB services die op onze oude omgeving draaiden (https://geodata.nationaalgeoregister.nl/digitaaltopografischbestand/wfs) een limiet van 15.000 objecten hadden. Met de migratie naar de cloud is dit teruggezet naar een standaard limiet van 1000. Loop je tegen problemen aan door de limiet van 1000 objecten?

1 like

Bedankt voor het uitzoeken! Is geen probleem, kan door paginering alles gewoon ophalen maar dan klopt mijn herinnering dus wel dat het vroeger meer was :slight_smile:

Als de hoogte waarden weer terug zijn dan ben ik (en alle andere gebruikers) weer tevreden!

:+1:

Tijd gaat snel, intussen een half jaar verder. De hoogtegegevens zijn nog steeds niet beschikbaar:

Is er een inschatting wanneer dit hersteld wordt?

Hallo Anton,
Ik heb het doorgegeven aan Rijkswaterstaat. Zij gaan over de inhoud. Volgens
Digitaal Topografisch Bestand is het bewust.

Hm vreemd, vroeger was het 3D data.

Hallo Anton,
Ik heb zojuist antwoord gekregen van RWS. Zij geven aan dat er wel degelijk hoogte informatie beschikbaar is in het puntenbestand. Maar niet elk punt heeft hoogtewaardes. Als ik jouw voorbeeld erbij pak en in QGIS de vlakken en punten toevoeg waarbij de labels van het puntenbestand de waarde ‘z’ weergeven krijg ik dit:

Mogelijk gaat de omzetting/inlezen in CAD niet helemaal soepel (komma vs. punt?).

Bedankt voor de reactie! De punten die een hoogte voorstellen (dus geen andere geometrie) hebben wel een tekstlabel met de hoogte als alfanumerieke waarde. Wat ik nu mis in de dataset is de hoogte op elk object, deze was namelijk vroeger wel beschikbaar. Alle objecten in de DTB hadden een daadwerkelijke hoogte. Ergens voor oktober vorig jaar is dit gewijzigd in de databron, en nu heeft geen enkel object nog een daadwerkelijke hoogte.

Iemand heeft op een gegeven moment dus besloten om de databron van 3D naar 2D te brengen. Helaas, en zo te zien zal dit ook niet meer worden teruggedraaid.

Overigens dat in mijn software de labels 0.00 aangeven, komt omdat ik de hoogte toonde vanuit de hoogtedata (en dus grip heb op het aantal decimalen en de presentatie van een + of - teken). Ik had er ook voor kunnen kiezen om de labelwaarde te tonen, maar dan kun je geen ander aantal decimalen toepassen zonder tussentijdse conversies.