Hoogtedata in Openfietsmap

@Ligfietser. Is het een idee om, nu de AHN2 data openbaar is, op basis daarvan de contourlijnen te maken? Vooral in Nederland, vanwege de geringe verschillen, valt het nogal op dat de SRTM gebasseerde soms wel erg grof zijn.

Zie bijvoorbeeld het plaatje op de openfietsmap website voor de omgeving van de Italiaanseweg. De stuwwal aan de zuidkant van de Veluwe is erg steil maar door de onderliggende 90m SRTM data komen veel contourlijnen nog in de zo goed als vlakke uiterwaarden te liggen.

Ik wil als het nodig is wel helpen om de data te processen.

Beste Rutje, als je mij daarbij kan helpen zou dat heel mooi zijn want van het omzetten van AHN2 data naar osm formaat heb ik geen verstand. En een ander groter bezwaar is wat je dan met de grensstreek doet, houden die hoogtelijnen op bij de grens, wat doe je bv met België/Luxemburg en Duitsland?

Mooi dat je het in elk geval ziet zitten, dat lijkt me het belangrijkste. Omzetten naar osm formaat heb ik ook nog nooit gedaan, maar voor zulke technische punten is er vast genoeg kennis beschikbaar op het forum. Ik heb wel wat ervaring met GIS/Remote sensing data, dus wellicht kom ik zelf al een heel eind. In feite zal de procedure identiek zijn als voor srtm → osm. Je zet het raster met hoogtewaardes om naar contourlijnen (vector) en die converteer je naar het formaat wat OSM snapt.

Omgaan met de grensstreek is wel een zorg waar naar gekeken moet worden. Ongetwijfeld zullen de hoogtelijnen daar niet naadloos op elkaar aansluiten. Volgens mij wordt er meestal wel een buffer aangehouden die nog even doorloopt in het buitenland. Dus misschien is het mogelijk om tot de grens de hoge kwaliteit Nederlandse data te gebruiken, en daarna binnen die bufferzone de data langzaam te interpoleren naar de originele contourlijnen.

Hier een voorbeeldje ter indicatie met het verschil tussen SRTM en Top10NL hoogtelijnen (AHN gebasseerd) voor de Westbergweg in Wageningen:

SRTM:

Top10NL (AHN):

Vooral de resolutie van de Top10NL hoogtelijnen zijn een stuk beter. Maar ook de absolute waardes (denk ik), SRTM is vanuit de Space Shuttle gemeten en meet puur de hoogte van het oppervlak, dus ook de bovenkant van bomen/gebouwen etc. De gegevens van het kadaster zijn voor dat soort effecten gecorrigeerd en geven de hoogte van het maaiveld.

Het zal in Mapsource ook een stuk mooiere hoogte profielen geven. Kijk je bijvoorbeeld naar de Italiaanseweg (zie plaatje op openfietsmap.nl) dan zie je een kleine afdaling en de top ligt evenhoog als de hoogte in de eerste haarspeld. In werkelijkheid zit er geen afdaling in (vlakt daar wel iets af) en de top ligt ongeveer 20m hoger dan de hoogte in de eerste haarspeld.

Ik heb er even een apart draadje van gemaakt. Ziet er goed uit Rutje.
Ook de correctie van hoogtes van het maaiveld ipv hoogtes waarbij ook bomen en hoge gebouwen een storing van het actuele hoogtebeeld geven is natuurlijk veel beter.
In welk formaat is dat bestand beschikbaar? Om hoogtedata om te zetten naar OSM gebruikte ik ooit Srtm2Osm maar dat is vervangen door Phyghtmap. Heb ik geen ervaring mee.
Voor een voorbeeld zie http://osm.thkukuk.de/srtm.html, misschien kan je hier al wat mee?

Voor de andere landen zou je wellicht deze dataset kunnen gebruiken: http://www.eea.europa.eu/data-and-maps/data/eu-dem
Is niet zo nauwkeurig als de ahn, maar wel een stuk beter dan SRTM (EU-DEM: 1 punt per 1 boogseconde, SRTM 1 punt per 3 boogseconden)

Op de Nederlandstalige OSGeo-mailinglijst zijn we al aan het discussiëren om onze inspanningen te combineren m.b.t. het gebruik van de AHN2. Ik heb daar al geopperd om ondermeer een set met (semi-transparante) tiles met hillshading in World Mercator formaat beschikbaar te stellen die dan over andere data heen gelegd kan worden. Het genereren van hoogtelijnen is ook een goed idee. Ik durf niet te zeggen wat de nauwkeurigheid zal zijn t.o.v. de hoogtelijnen in top10nl, die nu ook te hergebruiken zijn (want CC-BY).

De europese data is mede gebaseerd op de Aster-data. Misschien is de situatie onderhand verbeterd, maar ik zou hier voorzichtig mee zijn. Toen de eerste set met Aster 30m-bestanden vrijkwam lag bijv. een groot gebied ten oosten van Arnhem onder zeeniveau! Lees ook dit eens: http://www.viewfinderpanoramas.org/reviews.html#aster

Groeten,

Frank

@ligfietser, dat tooltje ken ik niet, net zoals de rest van de osm gerelateerde software. Ik zag al dat er een aantal versies van een ogr2osm tooltje waren, dat spreekt mij in eerste instantie wel aan omdat ik zelf ook graag werk met Python + OGR/GDAL. Het zal een kwestie van uitproberen worden zodra er een goede set contourlijnen is gemaakt.

@JaVaWa, goede tip. Ik had de EU-DEM al bekeken toen die net uit was, en die vond ik er wel goed uitzien, weinig artefacten (waar originele ASTER DEM vol mee zit, geen goede ervaringen mee).

Volgens mij is de origineel verzamelde data voor SRTM wel geschikt voor een 1 boogseconde resolutie, die is namelijk ook op die resolutie beschikbaar voor de VS. Maar NASA heeft dat voor de rest van de wereld nooit vrijgegeven, of ze moeten boven de VS anders gemeten hebben.

@Frank, het zou me niet verbazen als de hoogtelijnen in de Top10 van de eerste AHN versie afkomen, maar dat is speculeren. Voor wat betreft je vraag in de mailinglist mbt de hillshading. Ik denk dat het zou moeten werken als je de WCS in een VRT bestand verpakt, dan heb je een formaat wat de GDAL utilities als invoer kunnen gebruiken, en het DEM gedeelte in QGIS is slechts een grafische schil om ‘gdaldem’. Je kan de xml definitie van de WCS als bronbestand in een VRT gebruiken. Maar ik zou het zelf even moeten proberen om het zeker te weten, ik doe veel met GDAL maar weinig met de webservices, en die werken soms net even anders.

Ik vond het in eerste instantie verleidelijk om voor het gemak die Top10 hoogtelijnen te kiezen, het scheelt de stap om zelf de rasters naar contourlijnen om te zetten. Het maakt het echter wel lastig in de grensstreek. Twee hoogte-rasters (subtiel) in elkaar over laten gaan lijkt me veel eenvoudiger dan twee sets, niet aansluitende, contourlijnen.

Los van alle data processing vraagstukken, waarvan ik binnenkort wel wat punten op een rij zal zetten, zijn er nog wat Garmin gerelateerde punten. Zouden we bijvoorbeeld de Top10 hoogtelijnen 1op1 overnemen, dan neemt het aantal datapunten (vertices) enorm toe ten opzichte van de huidige. Dat betekent meer opslag, grotere bestanden, maar ongetwijfeld heeft het ook impact op de performance op een Garmin apparaat. Het is dus de vraag wat wenselijk is, dat zal een compromis worden tussen kwaliteit en performance/bestandgrootte.

Opzich maakt dat in eerste instante niet zoveel uit wat mij betreft, het streven is om zo goed mogelijke contourlijnen te krijgen en die om te kunnen zetten naar osm-formaat. Als het nodig is kunnen de contourlijnen daarna net zolang versimpeld worden tot het gewenste detailniveau berijkt is. En zelfs bij versimpelen tot een gelijk aantal punten aan het huidige zal de kwaliteit nog verbeteren.

Mocht het lukken met die EU contour data dan zou dat ook gebruikt kunnen worden voor mijn Europakaart (die bevat 25-100-250m lijnen van viewfinderpanoramas.org) en ook voor Lambertus kaarten is dit interessant.