Hulp gevraagd bij opzetten server wandelroutes

En deze kwam ik vanavond tegen… is toch wel heel mooi hoor !!!

Ja, maar deze website stuurt kant en klare tiles naar de client. Daar hebben ze dus een eigen server voor nodig. En dan ben ik weer terug bij mijn oorspronkelijke vraag: hulp bij het bouwen van een server.

Eerlijk gezegd vind ik de aangedragen oplossingen van het Forum - XML data uit de database halen dmv overpass api en verwerken in de client - ook erg mooi. Maar de hoeveelheid data is een beperking. Zoals gezegd: de Via Alpina levert al 5 MB op. En het Marskramerpad (Den Haag - Enschede) is altijd nog 700 MB. Daar komt bij dat de browser duizenden / tienduizenden punten moet verstouwen. Dat houdt natuurlijk een keertje op.

Dus wie heeft er suggesties om de client load te verminderen? Kan ik de XML niet zippen vanaf de OSM server en unzippen bij de client? Ik noem maar iets.

Hoe kom je nou bij die 700 MB? De hele OFM Benelux is 700 Mb, als je alleen de hiking routes ophaalt van de hele Benelux heb je het pakweg over minder dan 10 MB aan data.

Oeps: 700 KB … :D.
Maar die 10 MB van jou kunnen ook niet kloppen. Als ik alleen de relaties hiking|foot download, gestript van overbodige data, tel ik 12 MB voor de hele wereld. Maar wil ik deze relaties zichtbaar maken, dan moet ik de ways en nodes downloaden: da’s heel veel meer…

Probeer deze maar uit (Marskramerpad, 703 KB):

overpass-api.de/api/interpreter?data=(relation[route~'hiking|foot'][name='Marskramerpad'];>>;);(way(r);>;);out+skel;

Ik heb geen kijk op de wandelroutes, maar van het Marskramerpad lijkt niet veel meer over:
http://ra.osmsurround.org/analyzeRelation?relationId=1992618

Ik denk dat het met die data wel meevalt. Probeer deze eens. Kies als routetype nwn en slecteer dan het Marskramerpad. Paar seconden hooguit toch?
En euh, bij Oldenzaal zijn allemaal nodes aan de relatie toegevoegd. Heeft dat een speciale reden?

Nee. Wandelroutes zijn in OSM heel divers opgebouwd. Ieder land heeft zijn eigen gewoonten. En iedere mapper doet het weer anders. Ondanks pogingen om er lijn in te brengen: http://wiki.openstreetmap.org/wiki/Walking_Routes

Echt heel mooi gedaan! Maar het zijn 703 KB, ook bij jou.
Hoe heb je dat trouwens gedaan? Heb je de hele OSM database op je eigen server gezet? Ik zie dat de overpass api naar je eigen netwerk verwijst: http://server.mijneigen.net/api/interpreter/?

Kortom, hoe mooi je het ook geprogrammeerd hebt, mijn probleem blijft: wandelroutes genereren veel XML data die client side moeten worden verwerkt. Wat dat betreft is het wandelnetwerk anders dan het mtb netwerk.

Ik was er vanuit gegaan dat nodes die als node aan een relatie zijn toegevoegd startpunten zijn.

De database staat gewoon op de overpass server. Is een proxy. Die grootte ga je niet snel kleiner krijgen. Het enige wat je daar op kunt verzinnen is beneden een bepaald zoomnivo niets meer op te halen en alleen als je inzoomt meer te tonen. Maar dat is niet echt practisch voor lange tochten.

Welke policy zou de website dan moeten volgen? (Ik vraag het omdat GPX upload straks ook beschikbaar is op Traildino):

  • Iedereen mag vrij de GPX track gebruiken
  • De GPX track is alleen te gebruiken voor particulier gebruik, en niet door andere websites
  • De GPX track blijf eigendom van de maker, en deze bepaalt wie hem mag gebruiken (lijkt me lastig)
  • ODbL - net als OSM
  • Anders …

Daar komt geen ‘echte’ tileserver aan te pas. M.b.v. TileMill zijn offline tiles gegenereerd (t/m zoomlevel 14) en op de website gezet; een simpel php-script zorgt voor het aanleveren van de tiles. Boven zoomlevel 14 worden de tracks uit de database gelezen (alleen voor het zichtbare deel van de kaart) en geserveerd in JSON-formaat.
Voor een complete set routes/tracks is dit prima te doen, maar niet voor individuele routes.

Dit is te ondervangen door een database aan te leggen, waarbij je voor het overzicht een lage-resolutie versie van de routes opneemt. Als je wat verder uitgezoomd bent heeft het geen enkele zin een route tot op de meter nauwkeurig te tekenn…
Vereenvoudigen van de routes zou je kunnen doen m.b.v. het Douglas-Peucker algoritme. Kan eventueel real-time aan de serverkant (is vast wel een php-script voor te vinden), maar het is qua server load verstandiger om dat vooraf te doen.
Voor de gedetailleerde weergave zou ik dan de originele route in stukjes hakken en in de database opnemen, en alleen de stukjes oversturen die op het beeldscherm getoond kunnen worden (dat moet dan wel elke keer als de gebruiker in/uitzoomt of de kaart verschuift opnieuw gebeuren).
Door de data een beetje slim over te sturen heb je maar weinig bandbreedte nodig. Dus geen XML met nodes, ways en relations, maar JSON met naam (en evt. andere kenmerken) en een array met lat/lon waardes.
Eventueel nog on-the-fly comprimeren met gzip, dan wordt 't nog kleiner. Moderne browsers kunnen daar wel mee overweg; oude versies van IE niet (da’s dan pech, of je houdt er rekening mee door in die gevallen geen gzip te gebruiken).

Knap gedaan. Dank voor de uitleg. Erg mooie website, het fietsroutenetwerk. Zo ver kan je dus komen met GPX in html! Ik vermoed dat heel veel websites op dit gebied het nakijken hebben.
Misschien heb je ook het begin van deze discussie gelezen: hulp bij het bouwen van een server voor Traildino. De discussie ging eigenlijk voornamelijk over het niet-gebruiken van een server, en in plaats daarvan de gegevens uit OSM halen met de overpass api. Heb je daar ook ervaring mee? Deze aanpak heeft als beperking dat ik een dik pak XML terug krijg, en ik zou niet weten hoe ik dit kan zippen of in stukjes kan knippen of te vereenvoudigen, aangezien de data rechtstreeks van de api naar de client gaan. Maar misschien is daar ook een mouw aan te passen.

JaVaWa, als eerste complimenten voor de site, ziet er strak uit en een kind kan de was doen (of een route maken :smiley: ). Zeer sobere layout (lees duidelijk)maar wel verschikkelijk veel functies onder de rechterknop…

Ben een beginner in websites maar heb wel het e.e.a. gemaakt in VB
Ik zat ook al een beetje naar JSON te kijken, aangezien XML en browsers kennelijk geen goede combinatie is.
Ook GPX files oploaden naar een server vinden veel providers geen goed idee.

Ik ben aan het kijken of ik een drag en drop functie kan maken om een GPX op een openlayers map te projecten aan de client side.
Nu zul je de GPX uit elkaar moeten trekken en de lat/lon waarden om moeten zetten om ze op de map te tekenen, en wat ik begrijp zijn JSON en Java een goede combinatie in verband met de snelheid.
Wat heb jij gebruikt ? jij zult ook de track van de kaart moeten omzetten naar een track of koers, doe je dit met JSON ?
ik zie namelijk JSON en GEO-JOSN voorbij komen op de verschillende forums.

Ik heb even de documentatie van Overpass bekeken, maar er zijn geen mogelijkheden voor zippen, knippen en vereenvoudigen. Overpass is een systeem om ruwe data uit de OSM database te halen; verdere bewerkingen zijn voor zover ik zie niet mogelijk. Ik denk dat je er niet onderuit komt om zelf wat te maken als je een soepelwerkend en schaalbaar resultaat wilt bewerkstelligen…

Dank voor het compliment (Traildino ook trouwens). De rechterknop-functies zijn overigens de minst spannende onderdelen hoor…

Tijd om je te gaan verdiepen in Javascript… onmisbaar als je iets wilt gaan maken dat aangepast is op het doel wat je wilt bereiken. Met Openlayers is veel mogelijk, maar niet alles; daarnaast zorgt het ook voor veel overhead. JSON is een stuk ‘lichter’ qua dataoverdracht dan XML, en omdat JSON heel goed combineert met Javascript (de afkorting staat dan ook voor JavaScript Object Notation), werkt het ook een stuk soepeler aan de gebruikerskant.

Bedoel je soms dat GPX vaak als XML behandeld wordt door de browser (op zich niet zo vreemd, aangezien het dat ook is), en een GPX-bestand zich daardoor niet makkelijk laat downloaden? Dat is een kwestie van de juiste headers meesturen (configuratie van Apache).

Ik doe niets met GPX, behalve als de gebruiker opdracht geeft om de track te downloaden. Daarvoor heb ik een PHP-script die een GPX-bestand genereert (of een TCX-bestand in het geval van een koers; in dat geval worden er optioneel ook koerspunten toegevoegd).
De tracks zitten in een MySQL database, met de geometrie in een ‘spatial’ veld. Als de gebruiker een track aanklikt op de pagina dan geeft Javascript het ID door, waarna een PHP-script de data uit de database haalt en als JSON naar de browser verstuurt (dit gaat asynchroon via AJAX). De browser tekent dan de track op de kaart.
De brondata krijg ik van Jan Kelder in de vorm van een GDB-bestand; ik heb een programma specifiek voor dit doel gemaakt waarmee ik de gegevens daaruit converteer naar GeoJSON (daar maak ik dan met TileMill een kaart van aan welke ik upload naar de server), en naar een SQL-bestand wat ik dan inlees in MySQL op de server. GeoJSON is een uitbreiding op JSON, specifiek voor geo-data. Ik gebruik het op de webserver overigens niet.

Wat GPX-bestanden betreft: ik gebruik het Leaflet-framework voor de kaartweergave; is lekker snel en een stuk lichter dan Openlayers, en ook een stuk makkelijker om onder de knie te krijgen. Er is ook een extensie beschikbaar voor het werken met GPX-bestanden.

Iedere query naar overpass levert idd xml op. Maar dat is vrij gemakkelijk om te zetten.
Het hele punt volgens mij is dat het knooppunten netwerk statisch is. De data van overpass is dynamisch. Wijzigingen is OSM zijn vrij vlot op te vragen via overpass. De routes worden door de community gewijzigd en aangepast, dus je wilt juist die informatie ophalen.
Tenzij je je eigen database regelmatig bijwerkt en het ok vindt niet altijd de meest recente data te laten zien.
Dus Traildino: zware keus … toch eigen server en regelmatig bijwerken of de grotere (clientside) dataload van overpass voor lief nemen.

Browsers zetten standaard het lezen van XML uit als ze lokaal worden aangesproken, je moet ze dan opstarten met bv een command line optie of bepaalde opties uit zetten.

Aha, zat me al af te vragen hoe je het hoogteprofiel maakte.

Zal ik daar ook eens na kijken, kortom veel te leren :slight_smile:

Bedankt voor je uitleg, is me veel duidelijk geworden.

Hoeft niet, je kunt Overpass de data ook als JSON laten serveren. (maar het blijft een hoop data)

Niet echt… er wordt constant aan gesleuteld. Niet in zo’n hoog tempo als de OSM, maar toch…

Daar komt het inderdaad op neer.

Serieus? Altijd gedacht dat het een statisch netwerk is met maar af en toe een uitbreiding als de provincie ergens wat geld gevonden heeft.

Oh, op die manier. Dat probleem heb je ook met javascript in een lokaal html-bestand. Ik heb een ontwikkel-webserver draaien op mijn computer, dan heb je dat probleem niet.

Dat staat daar los van. Bij MySQL is ‘spatial’ beperkt tot het platte vlak; geen z-coördinaat dus. De hoogtegegevens haal ik met een PHP-script uit SRTM-bestanden.

Ja en nee. De knooppunten zullen wel redelijk statisch zijn (al kan ik me voorstellen dat er wel eens eentje verplaatst wordt vanwege wijzigingen aan de weg), maar de tracks ertussen heeft Jan Kelder in z’n eentje uitgezet op basis van de Topo NL kaart van Garmin. Deze kaart is enigszins gedateerd en hij zal ze niet allemaal nagefietst hebben, dus zitten er ongetwijfeld fouten in. Als hij een melding krijgt dat een track niet klopt dan past hij z’n netwerk aan; ik moet dat dan weer verwerken in de online tool.