Wij gebruiken de AHN WCS om AHN data te ontsluiten. Nu ik recent aan het werk ging om een meer algmene AHN ontsluitingstool te maken in FME, vielen me twee items op;
- De AHN1 en AHN2 WCS services lijken geen noData waarden terug te geven, waar dat bij de AHN3 WCS wel het geval is.
- WCS versie 2.0.1 lijkt niet goed te werken voor AHN3, maar wel voor AHN1 en 2.
Nu zag ik vaker vragen over de AHN WCS services op dit forum voorbijkomen, dus wend ik me ook maar tot dit forum 
Om e.e.a. tastbaar te maken heb ik wat voorbeeldjes opgesteld n.a.v. de requests die ik op dit forum topic tegen kwam.
M.b.t. het eerste item.
Zie onderstaande 3 voorbeeldrequests, waarbij enkel de ahn versie in de BaseURL verschilt, alsmede de gekozen coverage:
AHN1 WCS request (v1.0.0):
https://geodata.nationaalgeoregister.nl/ahn1/wcs?Service=WCS&Version=1.0.0&Request=GetCoverage&Coverage=ahn1_5m&CRS=EPSG:28992&BBOX=237988,578508,238212,578726&Width=400&Height=400&Format=image/tiff
AHN2 WCS request (v1.0.0):
https://geodata.nationaalgeoregister.nl/ahn2/wcs?Service=WCS&Version=1.0.0&Request=GetCoverage&Coverage=ahn2_05m_non&CRS=EPSG:28992&BBOX=237988,578508,238212,578726&Width=400&Height=400&Format=image/tiff
AHN3 WCS request (v1.0.0):
https://geodata.nationaalgeoregister.nl/ahn3/wcs?Service=WCS&Version=1.0.0&Request=GetCoverage&Coverage=ahn3_05m_dtm&CRS=EPSG:28992&BBOX=237988,578508,238212,578726&Width=400&Height=400&Format=image/tiff
In het (binary) GeoTIFF respons die ik op deze requests terugkrijg, zie ik dus alleen bij de AHN3 request een noData value gedefinieerd zijn (‘3.4028235e+38’), maar bij de AHN1 en AHN2 lijkt er geen noData value gedefinieerd. In deze AHN1 en AHN2 GeoTIFFs hebben de pixels die bij de AHN3 als noData te boek staan een pixelwaarde van ‘0’. Nu zou ik zelf in dit geval de waarde ‘0’ wel als noData value kunnen definieëren, maar voor de AHN, en zeker in dit gebied, heeft dat niet mijn voorkeur, omdat dan alle pixels met waarde 0 als noData worden gezien, waar er ook terecht pixels op land kunnen zijn met NAP hoogte ‘0’ die niet als noData moeten worden gezien.
Nu zag ik dat onderin dit forum topic ook al gemeld worden dat destijds voor de AHN3 de noData value (tijdelijk) niet leek te werken, wat later was gerepareerd. Kan het zo zijn dat dit toen alleen voor de AHN3 is gedaan, en niet voor AHN1 en AHN2?
M.b.t. het tweede item.
De eerdere voorbeelden zijn opgesteld door gebruik te maken van WCS versie 1.0.0. Nu leek het me handiger om gebruik te maken van ‘the latest greatest’ WCS versie 2.0.1. De Query Parameters in het request worden daarmee ietsje anders. Zie opnieuw onderstaande 3 voorbeeldrequests, waarbij ook nu enkel de ahn versie in de BaseURL verschilt, alsmede de gekozen CoverageID:
AHN1 WCS request (v2.0.1):
https://geodata.nationaalgeoregister.nl/ahn1/wcs?Service=WCS&Version=2.0.1&Request=GetCoverage&CoverageID=ahn1_5m&Subset=x(237988,238212)&Subset=y(578508,578726)&SubsettingCRS=EPSG:28992&ScaleSize=x(400),y(400)&Format=image/tiff
AHN2 WCS request (v2.0.1):
https://geodata.nationaalgeoregister.nl/ahn2/wcs?Service=WCS&Version=2.0.1&Request=GetCoverage&CoverageID=ahn2_05m_non&Subset=x(237988,238212)&Subset=y(578508,578726)&SubsettingCRS=EPSG:28992&ScaleSize=x(400),y(400)&Format=image/tiff
AHN3 WCS request (v2.0.1):
https://geodata.nationaalgeoregister.nl/ahn3/wcs?Service=WCS&Version=2.0.1&Request=GetCoverage&CoverageID=ahn3_05m_dtm&Subset=x(237988,238212)&Subset=y(578508,578726)&SubsettingCRS=EPSG:28992&ScaleSize=x(400),y(400)&Format=image/tiff
Nu geven voor mij de AHN1 en AHN2 requests hetzelfde resultaat als wanneer gebruik wordt gemaakt van WCS versie 1.0.0 (ook bij deze bestanden speelt dezelfde situatie voor de noData value). Belangrijkste though, ze geven valide (binary) GeoTIFF bestanden terug.
De request met AHN3 levert in mijn geval geen valide (binary) GeoTIFF bestand op.
Als ik echter de GeoTIFFS wegschrijf (met Binaire bestands encoding), en vervolgens in een tekst editor open, dan lijk ik ook een probleem te zien m.b.t. de AHN3 WCS van versie 2.0.1. Het lijkt dat in dat bestand zowel voor (prefix), als na (suffix) de Binary GeoTIFF data nog tekstuele regels staan m.b.t. de response headers van het WCS bericht. In dit geval zie ik het volgende terugkomen in het GeoTIFF bestand verkregen met WCS versie 2.0.1:
--wcs
Content-Type: image/tiff
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: coverage/out.tif
Content-Disposition: INLINE; filename=out.tif
<Binary GeoTIFF Data (line 9 t/m 2714)>
--wcs
Content-Type: application/octet-stream
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: coverage/out.tif.aux.xml
Content-Disposition: INLINE; filename=out.tif.aux.xml
<PAMDataset>
<PAMRasterBand band="1">
<NoDataValue le_hex_equiv="010000E0FFFFEF47">3.40282346638529E+38</NoDataValue>
</PAMRasterBand>
</PAMDataset>
--wcs--
De prefix en suffix regels die je hierboven ziet, zie ik niet terugkomen in de GeoTIFF bestanden die ik heb verkregen met de AHN1 en AHN2 requests a.d.h.v. WCS versie 2.0.1.
Edit: Nu ik wat beter kijk, lijkt de responseBody een multiPart bericht te zijn, waarbij de beschreven regels de multipart headers zijn. Dus eigenlijk lijken er twee bestanden in een bericht geretourneerd te worden. Ten eerste (1e multipart) de AHN GeoTIFF zelf, als binair bestand, en ten tweede (2e multipart) een XML metadata bestand m.b.t. de gebruikte NoData waarde in de AHN3 GeoTIFF.
Nu heb ik niet eerder gewerkt met dit soort multiPart responseberichten. Ik zie echter in de HTTPCaller van FME een optie ‘Multipart Response Handling’, met daarbij de parameter ‘Multipart Responses’ die ik ipv de default ‘Output Single Feature’ heb gezet op ‘Split into Multiple Features’. Met die wijziging zie ik wel de multipart headers terugkomen als lijst, maar alsnog krijg ik maar 1 feature terug en niet twee. Dus misschien dat ik iets verkeerd doe (of deze optie niet goed werkt in FME), of misschien is er toch iets niet goed m.b.t. het bericht.
In ieder geval, als ik zelf het verkregen GeoTIFF responsebericht bewerk, en alleen het eerste multiPart bericht bewaar m.b.t. de Binary GeoTIFF Data (regel 9 tm/m 2714), dan levert me dat wel een GeoTIFF bestand op die ik kan inlezen. Dat bestand lijkt dan ook identiek aan het GeoTIFF bestand dat ik had verkegen toen ik gebruik maarkte an de WCS request met versie 1.0.0 (specifiek dus ook met de gewenste expliciete noData value definitie).
Groet,
Thijs
ps. Ik wou de beschreven GeoTIFFs ook al bijlage toevoegen, maar merk nu dat dat niet direct kan. Daarom maar even als wetransfer linkje (1 week geldig): WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
)
)
). Het is wel handig om de NoData waarde te kennen, want ik had in het verleden (via gedownloade bladen in QGis) ook al eens gemerkt dat de NoData waarde niet overal gelijk is…