Bugs m.b.t. AHN WCS Service/Data?

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;

  1. De AHN1 en AHN2 WCS services lijken geen noData waarden terug te geven, waar dat bij de AHN3 WCS wel het geval is.
  2. 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 :slight_smile:
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

1 like

Het kan zijn dat vanwege vakantie er minder of geen reacties komen, wat jammer zou zijn. Misschien kan @Alkemade er iets van zeggen?

Volgens mij wordt er niets meer gewijzigd aan AHN1 en 2, maar ik kan me vergissen. Ik meen overigens ook ergens gelezen te hebben dat alle AHN datasets dit jaar ergens anders gehost gaan worden:

Wie weet verandert er dan nog van alles.

Ik heb zelf gemerkt dat in bijvoorbeeld QGIS niet alle functies (sommige weer wel) de NoData waarde respecteren, soms wordt daar dan 0 ingevuld zonder dat je dit ergens kunt instellen. Het blijft altijd een controledingetje om te zien of het resultaat klopt.

1 like

Ik kan er wel iets over zeggen (al heb ik van WCR requests geen kaas gegeten…).
De AHN1 en AHN2 bestanden worden inderdaad sindskort elders gehost (tot juli zouden ze nog wel bij PDOK moeten staan). De omzetting is nog niet helemaal in orde omdat de WCS (maar ook de andere formaten) leeg lijken als je ze bevraagt. Ik durf ook niet met zekerheid te zeggen of de links via het nationale georegister je al naar de nieuwe lokatie sturen. Dat zou dus een onderdeel van het probleem kunnen zijn.

De twee gecorrigeerde kaartbladen van het AHN3 waar naar verwezen wordt is een ander issue. Het betrof hier twee kaartbladen die niet de juiste no-data waarde hadden in de GeoTIFF’s waardoor deze in de WCS problemen opleverden. Deze zijn inmiddels gecorrigeerd en worden nu (of zijn) verwerkt door PDOK.

Voor het AHN1 en het AHN2 geldt, dat de oorspronkelijk geleverde bestanden in een ander formaat waren dan in GeoTIFF. Deze bestanden zijn omstreeks 2014 omgezet in GeoTIFFs met dezelfde no-data waarden als het AHN3 en verder (3.4028235e+38). Een no-data waarde van 0 is niet handig omdat er wel degelijk een hoogtewaarde van 0 voor zou kunnen komen. Dat is in ieder geval niet iets wat wij als no-data waarde meegeven in de bronbestanden. Waarom er soms dan toch iets anders wordt toegekend, weet ik niet. Blijven opletten dus, zoals Anton zegt.

2 likes

Hoi Anton en Alkemade,

Bedankt voor de reacties. Het topic over de wijziging van opslag en het beschikbaar stellen van oudere AHN data had ik ook al gezien.

Op basis van de opmerking daar

Indien u in uw GIS pakket of viewer links hebt opgenomen naar de AHN data is het noodzakelijk deze (voordat deze verwijderd worden op PDOK medio 2022) te vervangen door de nieuwe services

Hoopte ik dat het alleen een verandering van de host zou zijn, en dat de dat nog steeds via dezelfde type web services (ihb een WCS service) beschikbaar zou blijven, maar dan mogelijk net via een andere endpoint/URL.
Op basis van de reactie van @Alkemade voel ik me gesterkt in die hoop/verwachting :slight_smile:
Misschien is het dan even afwachten dat de omzetting naar nieuwe host locatie helemaal is afgerond of met de AHN1 en AHN2 data nog steeds speelt. Zeker ook gezien de opmerking dat er in 2014 kennelijk AHN1 en AHN2 data is omgezet. Misschien dat die oude AHN1 en AHN2 datasets bij PDOK niet zijn bijgewerkt, en straks op de nieuwe hosting locatie wel?

@Anton Ik ben zelf niet bekend met QGIS, maar als ik zo je reactie lees

Ik heb zelf gemerkt dat in bijvoorbeeld QGIS niet alle functies (sommige weer wel) de NoData waarde respecteren, soms wordt daar dan 0 ingevuld zonder dat je dit ergens kunt instellen.

Dan vraag ik me dan af of dat misschien eenzelfde oorzaak heeft als mijn eerste bevinding. Is het misschien zo dat ‘de functies’ een raster teruggaven waarin ook geen noData value gedefinieerd was? (was dat toevallig expliciet voor AHN1 en AHN2 data?) Misschien dat QGIS in dat soort gevallen by default van een noData value van ‘0’ uitgaat? Aan de andere kant neem ik aan dat QGIS ook wel om zou moeten kunnen gaan met rasters waar geen noData value voor gedefinieerd is.

@Alkemade Ik begrijp je opmerking van

De twee gecorrigeerde kaartbladen van het AHN3 waar naar verwezen wordt is een ander issue.

helaas niet goed. Bedoel je dat er een probleem was voor het gebied waar ik mijn voorbeeld requests had gebasseerd? (RDNew (EPSG:28992) coordinaten: Xmin=237988, Ymin=578508, Xmax=238212, Ymax=578726)

Zelf lijkt mij dat ik dezelfde situatie ook tegenkom voor andere gebieden dan dat voorbeeld. Neem bijvoorbeeld het gebied met Xmin=208000, Ymin=474100, Xmax=208500, Ymax=474600. Als ik daarvoor een gebied van 1000 x 1000 pixels opvraag (overeenkomstig met 0.5m resolutie), dan kom ik in anologie op mijn eerdere AHN WCS 1.0 voorbeelden op de volgende aangepaste voorbeeld requests:

Dan kom ik ook hier uit op een AHN1 en AHN2 dataset waar geen noData value is gedefinieerd (gebouwen en water die uitgeknipt zijn en dus een noData value dienen te hebben, hebben expliciete pixel waarde 0). Overigens valt me nu ook op dat bij de AHN1 dataset de pixelwaardes in een andere eenheid lijken te zijn. De weg die langs het TAUW kantoor loopt heeft bv in deze AHN 1 dataset pixelwaardes van ongeveer 764.438 terwijl dit in de AHN2 dataset bijvoorbeeld ‘7.715’ is. Kan het zijn dat de AHN1 pixelwaarden in cm t.o.v. NAP zijn, en de AHN2 en later in m t.o.v. NAP is?

Ben verder benieuwd of iemand me wat kan vertellen over de ogenschijnlijke multipart responsebody n.a.v. mijn (voorbeeld) AHN3 WCS request (v2.0.1). Ik vermoed dat ik nu wel redelijk snap wat het idee/de bedoeling is hiervan (twee bestanden uitleveren, de GeoTiff zelf en een metadata bestand, in een multipart bericht), maar ik betwijfel of de gebruikte implementatie helemaal juist/kloppend is.
Ik vermoed dat normaliter een applicatie ervan uitgaat dat bij een multipart responsbericht de ~‘scheidingstekst’ van bericht (de tekst die de scheiding tussen de parts aangeeft), als platte tekst voorkomt (hier iets van ‘wcs’ of ‘–wcs’). Maar in dit geval wordt er geen platte (utf-8) tekst uitgeleverd, maar bytes. Ik denk dat daarom misschien de optie ‘Split into Multiple Features’ van de HTTPCaller van FME het bericht niet goed weet te parsen.
Aan de andere kant, dit is maar een hypothese, en ik weet het zelf ook niet zo goed. Ben benieuwd of iemand hier meer weet van hoe dit nou eigenlijk zou moeten werken met zo’n multipart responsebody (of de huidige situatie wel/niet goed is). Evt zou ik deze cases ook voor kunnen leggen bij de FME Community.

Groet,

Thijs

QGIS bevat een verzameling functies die iets kunnen doen met rasterdata. Maar de functies hoeven onderling niet hetzelfde resultaat te leveren of dezelfde werking hebben. Misschien dat de programmeur van de betreffende functie daar een eigen mening over heeft of niet over nagedacht heeft. Alle functies maken onder water gebruik van dezelfde libraries dus het zou geen probleem moeten zijn.

Maar een Merge functie bijvoorbeeld vult 0 als NoData value als je die niet specificeert, maar de minimale of maximale waarde die je kunt ingeven is 1e+09 en niet 3.40282e+38 die de oorspronkelijke GeoTiff zelf heeft:

In mijn blog staan een voorbeeld hiervan. Andere functies in QGIS gaan hier netter mee om, door de oorspronkelijke waarde weer toe te passen als je niets invult.

Het hoeft dus niet hetzelfde probleem te zijn als waar jij tegenaan loopt maar het was als voorbeeld dat elke conversie mogelijkerwijs data kan verliezen, zelfs als het onlogisch is dat het zou kunnen gebeuren.

Welke versie van FME gebruik je, en hoe roep je die url aan? als ik jouw v2.0.1 url GET met de HTTPCaller van FME 2021.1, krijg ik een tiff terug, en niets anders dan dat. Daar zit bij mij geen tekst bij.
Heb de WCS Reader niet geprobeerd, maar je zegt zelf de HTTPCaller te gebruiken.

Edit: Oh wacht even. Als je de HTTPCaller de response laat wegschijven als een file, dan krijg je inderdaad die tekst er bij… da’s apart.

Na nog wat te hebben lopen spelen, lijkt het me duidelijk dat de HTTPCaller niet met met het MimeType

Content-Type: multipart/related; boundary=wcs

weet om te gaan. Dit is de response-header die mee komt vanuit de server, en de HTTPCaller parsed dat niet. Ik zie zo gauw ook geen mogelijkheid om dat wel te doen, tenzij je het zelf doet met StringSearchers en zo (en de responsebody encoding op UTF-8 zet of zoiets).

Overigens zie ik Split into Multiple Features nergens terug?

Overigens levert de WCS Reader wel keurig netjes een Tifje op, dus die doet het wel goed. Afhankelijk van wat je wil bereiken, is dat natuurlijk ook een oplossing (tenzij je een workbench maakt die eerst berekeningen moet uitvoeren voor de bounding box - maar dat zou je kunnen afvangen door een workspacecaller te gebruiken).

Hoi @sbjager ,

Bedankt voor het meedenken. Ik gebruik momenteel een net iets nieuwere versie van FME, namelijk FME 2021.2.2.0 (b21806 - win64). In die versie is er ook een nieuwe versie van de HTTPCaller (Version 5), met een aantal prettige toevoegingen t.o.v. versie 4 van de HTTPCaller als je het mij vraagt (Retry Failed Requests, Rate Limiting, en volgens mij is de Multipart Response Handling sectie ook nieuw in deze versie).

Voor debugging van ‘het probleem met versie 2.0.1 van de AHN3 WCS’ is het misschien nog wel het makkelijkst om simpelweg het linkje hier in je browser aan te klikken (om de GET Request vanuit je browser uit te voeren). Dan zul je ook zien dat het linkje van AHN1 en AHN2 je vragen een out.tif bestand te openen of op te slaan, maar het AHN3 WCS 2.0.1. linkje je vraagt een bestand ‘wcs’ op te slaan. Als je dat bestand dan vervolgens in een tekst editer (bv Notepad++) opent, zie je daar dan de mix van utf-8 text (mbt de multipart headers), en binary data c.q. XML data (m.b.t. de twee parts).

Ik zag inderdaad ook die response header ‘Content-Type: multipart/related; boundary=wcs’ terugkomen. Ik denk dat normaliter daarmee een applicatie inderdaad weet hoe de responseBody opgesplitst zou kunnen worden. Echter ik vermoed dus dat hier het probleem zit. De responseBody is niet in (utf-8) tekst, maar in bytes.
Hier dan bv:
_response_body (bytes): 0D0A2D2D77…732D2D0D0A

Je kunt daaruit dus niet direct de aangegeven ‘wcs’ boundary terugvinden, dat zie je pas nadat je het weer decoded naar een tekstuele encoding (bv utf-8, of windows-1252). In FME kan dat bv met een TextDecoder, met dan Encoding Type = HEX, string to decode = ‘_response_body’, en ‘character encoding for binary data’ = ‘Unicode 8-bit (utf-8)’, maar ik had zelf ook voor de route gekozen van een AttributeFileWriter om het als bestand op te slaan en vervolgens verder te bekijken.

Ik zat inderdaad ook te denken dat je via deze route inderdaad wel weer met StringSearchers of StringReplacers zou kunnen werken, om zo alsnog de data van de twee files op te splitsen en apart aan te maken. Echter, het valt me op dat als ik het bestand in FME weer inlees, dat ik dan weer tegen een ander probleem aanloop. Het inlezen naar UTF-8 of windows-1252 text encoding lijkt te stoppen zodra er een ‘NUL’ waarde wordt gevonden in het bestand. Zie bijvoorbeeld dit stackoverflow item.

Oftwel, als ik in FME het weggeschreven bestand weer inlees, krijg ik als tekst bestand terug:

–wcs
Content-Type: image/tiff
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: coverage/out.tif
Content-Disposition: INLINE; filename=out.tif

II*

Oftewel, alleen de eerste 8 regels volledig, en maar een klein stukje van de 9e regel, omdat op regel 9, column 4 een ‘NUL’ byte/character staat :frowning:

Je hebt verder gelijk dat de WCS Reader van FME ook gebruik kan worden, dat was ook de manier hoe ik het initieel had gedaan. Maar ik zag dat die niet de nieuwste WCS versie ondersteunde.
Ook zat ik daar een beetje te prutsen hoe ik de BBOX voor mijn request het beste kon opgeven. Ik probeerde eerst een FeatureReader, met dan de ‘Spatial Filter’ = ‘Initiator OGC-Intersects Result’, maar dat leek niet te werken (waar dat bijvoorbeeld wel bij een WMS service werkt). Ik zag verder bij de parameters van de WCS reader destijds ook niet zo snel hoe ik het dan daar zou moeten instellen. Uiteindelijk was ik toen gesettled voor WCS versie 1.0.0, en had ik de BBOX als aparte Query parameter toegevoegd aan de WCS URL.

Dus ja, na een beetje zoeken/prutsen kwam ik er zelf initieel ook wel uit om met een WCS reader van FME (obv WCS v1.0.0) een GeoTIFF in te lezen.

Waarom dan het gebruik van de HTTPCaller - RasterReplacer systematiek?
Nou, in het gebruik merktten we dat de WCS service van PDOK niet al te stabiel bleek te zijn, en we liepen best wel vaak tegen timeouts op. De workaround die we hadden gebruikt was om dan na de Rejected poort een decelerator te hangen, en vervolgens weer opnieuw een FeatureReader, om op die manier een soort van handmatige retry-requests in te bouwen. Ik vond dat er alleen nogal slordig uitzien. Verder is ook het inbouwen van looping in FME een beetje omslachtig (stel dat je n retries wil, dan wil je dat niet realiseren door n keer de Decelerator-FeatureReader te herhalen.). Ik vind de nieuwe optie van versie 5 van de HTTPCaller van ‘Retry Failed Requests’ hier super handig werken, Daar kun je direct instellen van… probeer igv ‘deze en deze http errors’, het nog ‘x’ keer, na een initiele backoff time.
Oftewel, de Retry functionaliteit die ik zocht/nodig had is nu al ingebouwd in de HTTPCaller transformer :slight_smile:

Waarom het gebruik van WCS v2.0.1?
Tjah, dat is niet perse een vereiste. Het is meer dat ik graag probeer het principe van ‘latest = greatest’ probeer te volgen. Het biedt ook gewoon weer extra opties die je met de oudere WCS versies niet kunt gebruiken. Zie bijv ook deze link. Maar goed, voor m’n huidige usecases kan ik dus inderdaad ook met de oudere WCS v1.0.0 uit de voeten.

Waarom kaart ik hier het ogenschijnlijke issue met de AHN3 WCS v2.0.1. dan aan?
Dat is denk ik een combinatie van nieuwsgierigheid van hoe/wat/waarom, en ik denk dat voor anderen en/of andere toepassingen dit misschien wel van pas zou kunnen komen. Dus het lijkt me goed om na te gaan of er in de huidige WCS service iets verkeerd gaat, of dat dat er bij het verwerken van het bericht niet goed gaat. Het feit dat er een alternatief is die ook gebruikt kan worden, doet m.i. niet af aan de vraag waarom er mogelijk iets mis gaat bij het gebruiken van de AHN3 WCS v2.0.1.

Hoi @ThijsKnapen om iets toe te lichten m.b.t. de bug. Dit heeft meende ik te maken met het grootste verschil tussen de AHN1/2 en AHN3, en dat is dat de AHN3 een INSPIRE aangemerkte WCS is. Zoals ook in de Capabilities terug te zien/lezen is. (om eerlijk te zijn zou ik m.b.t. deze materie me er wel weer helemaal in voor moeten lezen… :expressionless: )

Maar dat de output dus ‘afwijkt’ heeft ermee te maken dat er vanuit INSPIRE regels zijn hoe data terug gegeven moet worden. In dit geval een multipart response met de geotiff en een metadata xml file. @antonbakker heeft hier eerder al een scriptje voor gemaakt om het uit te pakken.

Ik zal morgen verder navraag doen bij de rest van de collega’s (of dit ook de daadwerkelijke reden is :grinning: )

Heb je trouwens tijdstippen van deze timeouts? (zodat we in onze logging kunnen kijken, wat er mogelijk gaande was)

Aha. Ik dacht dat ik redelijk bij was, maar dus niet :smiley:

Da’s een vrij irritant dingetje van FME (vind ik - er zijn er wel meer, ondanks dat het hele mooie software is…). Als je de Reader de eerste keer toevoegt, kun je de Search Envelope opgeven (minx en miny en maxx en maxy). In die dialoogbox kun je daarbij niet kiezen voor een parameter, maar als ie er eenmaal staat wel (dmv rechtermuisklik). Ik vind het nog steeds onhandig dat dat op meerdere plekken zo is. Ik zet er dan meestal een paar bogus-waarden in, die ik daarna vervang door een User Parameter. En dan kun je dus bij de aanroep de bounding box meegeven, en ik krijg daarmee keurig netjes het vierkant terug waar ik in geinteresseerd ben.

Via een Custom Transformer? Vind ik nog wel meevallen. Die route gebruik ik op diverse plekken om een gepagineerde WFS leeg te trekken. Super handig, je kunt gewoon de waardes uit het vorige request invullen en doorloopen totdat je het einde bereikt. en daar kun je, als er een maximum aan het aantal requests op zit per tijdseenheid, dan ook makkelijk een Decelerator inbouwen. En het versimpelt je Main workspace nogal, dus ik stop vaak dingen in custom transformers om de zaak overzichtelijk te houden.

Ik ga toch nog eens kijken naar het parsen van die response (puur uit nieuwsgierigheid :wink: ). 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…

Hoi @sbjager

Die route gebruik ik op diverse plekken om een gepagineerde WFS leeg te trekken.

Volgens mij is paging een ding in WFS vanaf v2.0.0. Onderschrijft maar weer het principe van ‘latest = greatest’ :wink:
Naar mijn ervaring kan je in in een WFS (Feature)Reader van FME direct paging toe laten passen zonder zelf een CT te schrijven met looping. Dat is, mits je de parameters op juiste wijze invult (ihb ‘Start Index’ en ‘Count’). Ik gebruik het zelf bijvoorbeeld ook voor de BAG. Ik kwam eerder nog wel een keer de situatie tegen dat de WFS implementatie van PDOK het wel nodig was om sorting toe te passen op een id (bv bag:gid) om geen dubbele (of te weinig) features terug te krijgen, maar dat is dan iets dat je eenmalig instelt en dan heb je in mijn optiek een erg fijne en cleane oplossing.
Mocht je eens een voorbeeld oid daarvan nodig hebben/willen zien moet je het maar zeggen. Wil je best een voorbeeldje sturen van hoe dat bijvoorbeeld direct in de (Feature)Reader geregeld kan worden.

En het versimpelt je Main workspace nogal, dus ik stop vaak dingen in custom transformers om de zaak overzichtelijk te houden.

Ik ben het helemaal met je eens dat CT in FME wel heel handig zijn. Deze bevindingen/vragen van mij komen voort uit dat ik zelf bezig was met een CT te maken om AHN data te kunnen ontsluiten. Inmiddels best goed gelukt al zeg ik het zelf :slight_smile:
Maar al doende kwamen er dus wel wat vragen in me op, en m’n nieuwsgierigheid bracht me dus hier.

Bedankt voor de toelichting. Ik ben het helemaal met je eens dat je altijd goed op moet letten op wat voor functies/translatie je toepast en hoe dat je data beïnvloed.

Naar mijn idee praten we in dit geval alleen niet over een conversie oid, maar zit het al puur bij de bron. Als ik bijvoorbeeld simpelweg de linkjes die ik deelde aanklik, het (geotiff) bestand opsla, en vervolgens in FME het bestand inspecteer, dan geldt voor de AHN1 en AHN2 datasets dat er geen noData waarde gedefinieerd is, en dat er bij de AHN3 dataset wel een noData waarde gedefinieerd is.

Ik snap nu ook wat beter wat je bedoelt met die functies voor Rasterdata. Er zijn natuurlijk altijd meerdere platforms en toolings waarmee je hetzelfde kan bereiken. Ik werk zelf het meest met FME. Zo’n merge actie zou in FME met een RasterMosaicker gedaan kunnen worden, en een noData waarde zetten/overrulen met een RasterBandNodataSetter. Het is maar net wat je het prettigst vind werken :slight_smile:

1 like

Hoi @wouter.visscher ,

Bedankt voor je reactie. Goed te weten dat het vermoedelijk gaat om een bewust verschil tussen de AHN1 en AHN2 datasets. Bedankt voor het wijzen van het bestaan van zo’n .bash scriptje. Het lijkt me dat er ook wel mogelijkheden zijn om die geotiff en metadata xml file in het responsbericht uit elkaar te trekken. In de basis is het natuurlijk vrij duidelijk hoe/wat er moet gebeuren, maar gezien dat probleem met die ‘NUL’ byte/character die zorgt dat bij inlezen naar utf-8 of windows-1252 het bestand niet helemaal wordt ingelezen, zal er misschien wel iets met een PythonCaller en wat specifieke binary/bytes conversion nodig zijn om dat op te lossen. Ik parkeer het even als een uitzoekprojectje voor een andere keer (ik ben zelf geen Python held, maar vind het wel interessant om er meer in de praktijk mee te doen en van te leren).

M.b.t. de tijdstippen van de timeouts op de WCS service…
Ik heb het niet bijgehouden, maar we kwamen het echt veelvuldig tegen. Vaak via scripts die we met FME Desktop runden, maar ook wel op FME Server.
Ik kan even kijken of ik wat in de logging zie, maar ik kan je ook wel even doorsturen als we het in het vervolg weer zien (al denk ik dat we het mogelijk minder in de logging gaan zien als we met de HTTPCaller zelf al retries gebruiken. Ik vermoed dat de retries dan al inwendig worden afgehandeld en er niet over gelogd zou worden).

Edit, op FME Server kwam ik deze in ieder geval tegen (oudere logs zijn helaas alweer verwijderd):
|1182|2022-4-19 14:19:57 | [2]: Received HTTP response header: ‘HTTP/1.1 502 Bad Gateway’ from 'https://geodata.nationaalgeoregister.nl/ahn3/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=1.0.0&COVERAGE=ahn3_05m_dsm’|
|1183|2022-4-19 14:19:57 | HTTP/1.1 502 Bad Gateway- Unable to fetch the download: 'https://geodata.nationaalgeoregister.nl/ahn3/wcs?SERVICE=WCS&REQUEST=DescribeCoverage&VERSION=1.0.0&COVERAGE=ahn3_05m_dsm’|

Kennelijk geen timeout, maar een bad gateway error.

Hoi Anton, ik dacht dat zal ik even fixen maar dan krijg je dus dit:

Komt doordat die spinbox widget standaard wordt gebruikt voor alle getallen-invoer bij processing algoritmes.

1 like