AHN2 data ophalen via API (WCS) geeft integers ipv float voor hoogte, AHN3 geeft wel gewenste float getallen

[yasminekeehnen]

Hi allemaal,

Ik heb een python script ontwikkeld waarmee ik via WCS middels een API AHN2 en AHN3 data binnenhaal. Deze wil ik in hoogte van elkaar gaan aftrekken om zo hoogteverschillen te kunnen onderzoeken. Nu is het ineens zo dat de hoogtes bij AHN2 afgeronde hele getallen zijn. AHN3 geeft geen problemen en de payload is voor beide hetzelfde op het AHN stukje na. Voor mijn gevoel ging het eerder wel goed, dus er lijkt iets veranderd te zijn.

De volgende payload wordt gebruikt:
http://geodata.nationaalgeoregister.nl/ahn2/wcs?bbox=5.265666,51.792069,5.266666,51.793069&width=20&height=20&SERVICE=WCS&REQUEST=GetCoverage&coverage=ahn2_05m_non&VERSION=1.0.0&FORMAT=image/tiff&crs=EPSG:4326&response_crs=EPSG:4326

Als ik deze url direct benader via mn browser en de dan gedownloade tiff file inlees als numpy array krijg ik ook alleen integers/hele getallen. Er lijkt dus echt iets mis te gaan met het querien via de API en niet later in de code.

Ik heb verschillende contact geprobeerd (‘ahn2_05m_int’, ‘ahn2_05m_non’, ‘ahn2_05m_ruw’, ‘ahn2_5m’), maar dit geeft telkens hetzelfde resultaat namelijk; hele getallen.

VB: voor bepaalde x en y coordinaten (GPS) vind ik voor AHN3 een hoogte van 1.737405m en voor AHN2 een hoogte van 2m.

Heeft iemand enig idee of er iets veranderd is of hoe ik dit kan oplossen, wellicht door te specificeren dat ik floats willen binnenhalen oid?

Alvast bedankt!

NB: als ik los een AHN2 raster handmatig download als TIF bestand en dit als een array beschouw, zie ik wel floats met meerdere cijfers achter de komma. Er lijkt iets mis te gaan dus met het binnenhalen via de API.

[ivorbosloper]

Heb je ook format=GEOTIFF_FLOAT32 geprobeerd? Daar liep ik eerder tegenaan, zie post:

AHN WCS is afgelopen week kapot gegaan

Kijk ook even naar de vergelijking die @geotiles maakte op Vraag Vergelijking AHN2 Met AHN3 - #6 door geotiles - AHN - Geoforum bij het interpreteren van de verschil-data. De patronen op de plaatjes daar lijken me meer met de meet-methode of het seizoen te maken hebben dan met structurele bodemdaling. De AHNs zijn prachtige datasets (scherp, actueel, gratis/open, hulde aan de financiers RWS/waterschappen/provincies) maar bij het interpreteren van data en verschillen moet je scherp zijn op alle details.

Een paar jaar terug is https://bodemdalingskaart.nl/ gepresenteerd. Ik begreep uit hun presentatie op Geobuzz dat ze maken van continue satelliet-metingen ipv Lidar. Wellicht kun je hen benaderen om wat meer te leren over de hoogteverschil-vraag en hebben ze interessante data voor je…

[antonbakker]

De oplossing van @ivorbosloper hierboven is inderdaad juist. Om te weten welke outputformaten aangeboden worden in een WCS service kan je een describeCoverage request uitvoeren (N.B. dit geldt voor WCS versie 1.0.0, versie 2.X werkt net wat anders):

https://geodata.nationaalgeoregister.nl/ahn2/wcs?request=describecoverage&service=WCS&version=1.0.0&coverage=ahn2_05m_int

In de response zit dan een XLM element supportedFormats met de ondersteunde outputformaten

Overigens zou de service alleen het outputformaat GEOTIFF_FLOAT32 aan moeten bieden. Bijna alle gebruikers zullen decimale hoogtewaardes willen. Dit is voor de AHN3 al zo ingericht. We gaan dit gelijk trekken.

[kad-schipr]

Bij deze de mededeling dat de configuratie voor de WCS services van AHN1 en AHN2 nu meer gelijk getrokken is met die van de AHN3. We zijn benieuwd naar de bevindingen.