Ik heb de AHN3 DSM kaart M_28CN2.tif gedownload. Bij het bekijken van de data blijken er tussen de reguliere waardes enorme waardes in de staan (3.4e38). Lijkt op een overflow van het dataveld. Kunnen jullie hier iets mee? Als er meer info van mijn kant nodig is hoor ik het graag.
Hoi Joris, die enorme waardes zijn correct. In de GeoTIFF files zijn de pixels waar geen hoogte voor bekend is gevuld met de zogeheten NoData waarde. Gebieden die geclassificeerd zijn als water hebben geen waardes in de AHN3 (zie de metadata in het NGR) en kaartbladen die gedeeltelijk buiten de landsgrens vallen hebben ook geen waardes buiten de landsgrens. Deze zijn dus gevuld met een NODATA waarde van 3.4028234663852886e+38.
QGIS maakt dit bijvoorbeeld inzichtelijk in het Layer Properties scherm:
De waarde 3.4028234663852886e+38 is overigens geen toeval, het is de grootste waarde die opgeslagen kan worden in een Float32 dataveld (raster - Is there an easy way to say -3.4028234663852886e+38? - Geographic Information Systems Stack Exchange) en zal nooit clashen met een geldige waarde in de AHN3 (hoogste punt Nederland 322m, overzeese gebieden niet meegerekend 
).
1 like
Bedankt voor de toelichting!
Beste Anton,
Die extreem hoge waarde zie je vaak bij oppervlaktewater ben ik inmiddels achter.
Maar ik kom ook vaak āhogeā waarden tegen, tot een aantal meters boven het terrein nivo.
Dit is volgens mij door bomen of andere begroeiing.
Bij gebruik van de DTM zouden die toch eruit gefilterd moeten zijn?
Bij het DSM zouden dit objecten kunnen zijn. In het DTM, wat gefilterd is, zouden deze waarden niet voor mogen komen. Het kan echter altijd gebeuren dat deze waarden voorkomen omdat bijvoorbeeld een groepje vogels niet goed uitgefilterd is. Dat zou echter niet āvaakā het geval mogen zijn. Omdat de data steeksproefsgewijs gecontroleerd wordt kan het dus nog wel voorkomen.
Had het niet een iets makkelijker hanteerbaar getal kunnen zijn. 1e+38 m was ruim voldoende out of space geweest denk ik. Daar vliegen ook geen vogeltjes 
We hebben het over Nederlandse hoogtedata voor Nederlands gebruik. De logica ontgaat mij nog steeds om dit ultiem-maxer-de-max tig cijfers achter de komma te plaatsen. Niet gebruiksvriendelijk
Dat is natuurlijk een kwestie van perspectief van de verschillende gebruikers.
Het gebruik van deze No-Data values is (ook zoals QGIS ze interpreteert) hoe de "rasterā(/wiskundige) wereld (in ieder geval in Nederland m.b.t. de AHN) werkt/is afgesproken.
Dat dit voor nieuwe āgebruikerā een drempel kan zijn is natuurlijk iets wat niet alleen van de aanbiedende/inwinnende kant hoeft te komen om deze te verlagen. Inlezen in de materie, vragen stellen, uitproberen, enzā¦ mag dan ook verwacht worden zodat deze aspecten uiteindelijk goed geĆÆnterpreteerd kunnen worden.
Stel dat we het zouden aanpassen (zover dat mogelijk is) naar iets als NIHIL/nil/null dan zouden nu tientallen applicaties ākapotā gaan en gebruikers hinder ondervinden. Dat lijkt mij toch ook niet wenselijk/gebruiksvriendelijkā¦
3 likes
Maakt niet uit Wouterā¦ je hebt helemaal gelijk. Ook maar gewoon een mening, een perspectief.
Beste Alkemade,
Tot nu toe heb ik elke set hoogte waarden die ik gedownload heb nog moeten corrigeren.
Even ter toelichting over mijn gebruikswijze: Ik stel een lijst van +/-200 XY coordinaten op, waar ik het Z coordinaat van nodig heb. De lijst stel ik op in .csv. Deze lees ik in in Rstudio met een code (AHN_hoogtes) van Jelle Stuurman. Daarop ontvang ik een .csv bestand retour waarin de Z coordinaten toegevoegd zijn.
De code geeft de keuzemogelijkheden, maar ik gebruik altijd de DTM en 0.5m resolutie.
De XY coordinaten liggen op een lijn op een vaste afstand van bijvoorbeeld 20 cm meter van elkaar. In de resultaten vind ik regelmatig hoogteverschillen van meer dan een meter tussen punten die dicht bij elkaar liggen (meestal 20 Ć 50 cm). Dit kan in de werkelijkheid natuurlijk ook wel eens voorkomen, maar ik ken meestal de situatie ter plaatse en ik weet zeker dat dit soort hoge waarden meestal āfoutā zijn. Zou jij dit kunnen verklaren.
Ik haal nu steeds de resultaten door een Excel lijstje, waarmee ik de āvreemdeā waarden opzoek en die handmatig aanpas naar een āreĆ«leā waarde en vind het heel jammer dat ik deze tussenstap moet maken.
Bij ons zijn dit soort afwijkingen niet bekend, en ik kan er dan ook geen verklaring voor geven. Aangezien je de data met tussenstappen verkrijgt, kan ik dat verder ook niet beoordelen. Als je verschillen ziet op korte afstanden van meer dan een meter is dat in ieder geval niet te verklaren door puntruis in de metingen.
Wat een mogelijke verklaring zou kunnen zijn, is dat de rasters een gemiddelde hoogtewaarde hebben die binnen die cel geldt. Als je punten hiertussen definieert, op een afstand van 20 cm, zal hierdoor ook een waarde worden toegekend die niet helemaal representatief is voor die lokatie. Of dat verschillen van een meter zijn, betwijfel ik wel. In die zin zou je misschien eens kunnen vergelijken met het LAZ bestand, omdat hier geen interpolatie op is toegepast.
Misschien hebben andere gebruikers een verklaring voor de vreemde waarden?
Dankje Alkemade,
Kun je de āgemiddelde hoogtewaarde van de rasterā verder toelichten? En wat daar wellicht mee samenhangt: Weet jij wat 0.5m resolutie van de AHN precies inhoud?
Ik stel mij daarbij voor 1 hoogte waarde per vierkant van 0,5x0,5 meter. Maar dan zou een talud er heel blokkerig uit moeten zien. Wanneer ik in de AHNviewer kijk, zie ik veel meer hoogtewaarden binnen een vierkant 0,5x0,5 m. Weet jij hoe dit zit?
Martien, kun je een voorbeeld van dit lijstje bijvoegen. Input en output. Ik wil dit graag even belijken en snappen hoe dat met Rstudio werkt.
Verder denk ik zelf dat de grafische kaart of sofwarematig een soort blending wordt verzorgt door viewers. Als ik geotiff converteer naar polylijnen van gelijke hoogte, dan kont het er geblokt uit op 0.5 m
Het 0,5m DTM raster heeft inderdaad 1 hoogte waarde voor iedere rastercel van 50x50 cm (dat is meteen de resolutie). Deze is verkregen door de laserpunten uit de LAS file te middelen met behulp van de Squared IDW methode, kort gezegd betekent dat dat een punt die dichter bij het middelpunt van de te berekenen cel ligt, zwaarder meetelt dan de punten die verder weg liggen.
Als je binnen die cel van 50x50cm twee coordinaten pakt die 20 cm uit elkaar liggen, hebben ze dezelfde hoogte. Afhankelijk van hoe steil een talud is, ziet het raster er inderdaad blokkerig uit.
In de viewer is het raster voor visuele doeleinden verbeterd, maar de onderliggende hoogtewaarden zijn niet gewijzigd. Voor professionele analyses raden we altijd aan om van de originele rasters gebruikt te maken in een geschikt GIS programma. Ik kan trouwens in de AHNviewer niet zover inzoomen dat ik individuele rastercellen zie, dus zeker niet of daar meerdere hoogtewaarden in getoond worden.
CoordinatenXY is input, Coordinate is output. Daar is weinig spannends aan, al is voor de input natuurlijk wel belangrijk dat het exact zo opgesteld is.
Ik gebruik trouwens nog steeds de versie van februari. De āverbeterdeā versie is mij nog steeds niet gelukt te gebruikenā¦
Het wordt trouwens pas echt interessant als je deze tool kunt activeren vanuit Bricscad. Ik bedoel dan een command bv āAHNā, waarop je een 2Dpolylijn van XYcoordinaten kunt aanklikken, waarop dan automatisch de tool wordt opgestart en de polylijn wordt omgezet in een 3D polylijn met de Z coordinaten van het maaiveld toegevoegd. Denk je dat dat haalbaar is?
In de viewer kun je maar op hele meters XY coordinaten āzienā. Dus zie je inderdaad niet welke cel van 50x50 je aanklikt.
Maar je kunt een lijn trekken en daarvan een .csv bestand van 200 punten op die lijn downloaden. Als je een lijn van 20 meter trekt, heb je dus 10 punten per meter.
De Z-waarden in de .csv bestand lopen bij een talud gelijkmatig op en geven dus geen blokkerig profiel. Ik begrijp nu dat hierop de Squared IDW methode door de viewer kennelijk al toegepast wordt.
Ik zal Jelle Stuurman vragen hoe de middeling werkt wanneer de genoemde code ahn_hoogte.R en of daar de fouten misschien uit voort kunnen komen.
Ik acht de kans groot dat het ligt aan de manier waarop de hoogte wordt berekend in de R script die ik heb gemaakt. Hoewel ik de bron bestanden gebruik via de PDOK, verwerkt hij de data waarschijnlijk op een andere manier via mijn script. Ik zal er dit weekend opnieuw naar kijken of ik het probleem kan reproduceren. Dit is niet eenvoudig want het gaat vaak wel goed, en soms niet als ik het goed begrijp.
Tot nu toe heeft elke dataset die ik met de code gedaan heb, wel een aantal āfouteā waarden gehad, die ik dus handmatig hebben moeten corrigeren naar een realistisch waarde.
Heb je misschien de mogelijkheid de Z waarden van de geraadpleegde 0,5x0,5 rastercellen mee te vermelden, bijvoorbeeld als een extra parameter (Z0) in het output bestand. Dan kunnen we in eerste instantie zien of de āfoutā misschien toch in de AHN data zit en zoniet kan het in tweede instantie helpen te vinden welke rekenfout de code maakt.
@mluijben Ik heb nog even nagevraagd hoe in de AHN viewer de CSV wordt gemaakt als je een profiel trekt over de data. Bij korte lijnstukken (tot 500 meter) wordt het ruwe bestand gebruikt. Bij langere stukken het maaiveld bestand. Achtergrond is dat de verwachting is dat de meeste gebruikers bij een kortere afstand meer details willen zien. De CSV die gegenereerd wordt bevat altijd 200 punten, ongeacht hoe lang je profiel is. Het spreekt voor zich dat bij een korter profiel punten worden getoond die niet rechtstreeks uit het DEM komen, aangezien daar maar 1 hoogtewaarde per 50x50cm in zit. Er wordt dan geĆÆnterpoleerd tussen de (reeds met SqIDW geĆÆnterpoleerde) punten. Deze waarden zijn geen āofficieleā AHN waarden, maar zouden geen grote fouten moeten bevatten. Als je tools gebruikt die door anderen ontwikkeld zijn (wat we overigens altijd toejuichen) spreekt het voor zich dat je je goed laat informeren hoe de tool werkt en of er evt. geinterpoleerd wordt. Dat betekent namelijk dat je met bewerkte data analyses gaat doen.
Dank voor de toelichting Ingrid. Ik heb zojuist ook even contact gehad met Jellest en de vreemde waarden zaten kennelijk in die code. Eigenlijk had hij het allang al opgelost, maar ik gebruikte nog steeds een oude versie van zijn codeā¦
Goed nieuws Jelle. Ik ga het ook rens proberen nu er meet duidelijkheid is. Ik zal het resulaat een langs qgis profile addon leggen.
Wat betreft āAls je tools van anderen gebruiktā¦ā ,volgens mij is het idee van dit forum om elkaar te helpen. De vraag was terrecht en als je tools beschikbaar STELT zul je dat goed moeten documenteren en testen. Prima werk @Jellest !