Hulp gevraagd bij opzetten server wandelroutes

OSM is een wegenkaart, zoals je eerste quote al aangeeft. Die is bedoeld om wegen en andere geografische features in te zetten. De keus om alles maar in die database te dumpen is ronduit fout. Natuurlijk is het leuk om de fietsroutes te laten zien, maar stop die aub niet in de wegendatabase. Zet voor die niet-geografische dingen een aparte database op en voeg het geheel dan samen bij het bekijken.
Alle data zelf willen ‘hebben’ is ook niet meer van deze tijd. Het internet is een grote gemeenschappelijke database en het is niet zinvol al die gegevens zelf op te gaan slaan. Bovendien moet je ze dan ook zelf bijhouden.

Neem nou het hier vaak besproken BAG, en zet dat eens naast de GBA. Niemand komt op het idee die op 1 hoop te gooien. Een gebouw en zijn bewoners zijn verschillende dingen. De koppeling is dat in de GBA staat in welk gebouw iemand woont, en je via die link uit de BAG weer informatie kunt halen over dat gebouw. En omgekeerd natuurlijk. Toch is dat bij elkaar gooien precies wat we in OSM nog steeds doen. Sterker: er is zelfs veel gepraat over het in de OSM database dumpen van BAG.

Of kijk eens naar Google. Die stopt echt zijn wegen en poi’s niet in dezelfde database. Die maakt layers die verwijzen naar verschillende databases en voegt het samen in zijn api.

Wat mij betreft heeft OSM hiet echt een afslag gemist door op ouderwetse ( jaren 80 ) voet alles bij elkaar te gooien. Wie met databases werkt weet allang dat dat niet hoort en uiteindelijk een oncontroleerbare gegevensset oplevert. Als daar geen fundamentele verandering in komt loopt OSM straks achter de feiten aan en verliest zijn positie.

En is een singletrack dan geen geografische features dan ? volgens mij is dit nog steeds zo…

Ben met je eens dat een afvalbak of een hondedrol niet in een stratendatabase horen, maar een database zonder relaties gaat niet werken, dat is een bak met gegevens waar je niets mee kunt.
Wat je met de relaties doet is m.i. niets anders dan ID’s aan elkaar koppelen, ik verander niets aan de database.
Door het toevoegen van deze kun je query’s uitvoeren, volgens mij doe je dit met zelf ook met je gemaakte Fiets/wandelkaart.

Ik zal zelf ook geen borden of huisnummers toevoegen omdat dat geen enkel nut heeft, maar om nu te zeggen dat een landelijke route wel kan en een lokale niet vindt ik vreemd.
Een verzameling lokale route kan een regionale zijn,en deze weer landelijk. en dat kun je dus doen door relaties vast te leggen.

Dat is nu precies waar het om gaat. DB1 > wegen. DB2 > routes. Relatie DB2 > DB1.
Daarmee haal je de functies wegen en routes uit elkaar.
MTBroutes.nl heeft bv een prachtige database met routes. Waarom dan precies hetzelfde in de OSM database stoppen? Wat is dan de meerwaarde?

Meerwaarde is dat MTBroutes.nl die routes nu voor zichzelf claimt, dwz ik mag er geen gebruik van maken voor mijn OFM.
Als alles in OSM staat kan ik daar wél een kaartje van maken. Zie ook de discussie over de wandelroutes, http://forum.openstreetmap.org/viewtopic.php?id=19167
Verder zijn de officiële fietsknooppuntroutes niet foutloos, op OSM kunnen ze worden gecontroleerd en verbeterd. Kan natuurlijk ook door de officiële instanties gebeuren maar dan ben je weer vele jaren verder. Of door de Fietsersbond maar die claimt de gegevens dan ook en wil die voor zichzelf houden. Kortom de theorie die Noordfiets schetst is wel mooi maar de praktijk blijkt nog niet zo ver te zijn.

En ik wil daar nog aan toevoegen dat OSM een wereldwijd project is. Als je dus iets wilt met MTB routes van Europa en ieder land heeft een eigen DB (ODBL?) in eigen formaat en die moet je allemaal aan elkaar knopen dan wordt je daar als data consumer niet vrolijk van. Daarnaast vind ik het juist handig dat je alle zaken bij elkaar met 1 editor kunt aanpassen/toevoegen. Als ik als fietser de wegen in OSM moet invoeren en de routes in een andere DB (met een eigen editor) dan vind ik dat ook niet handig.

Ik ben er overigens ook geen voorstander van om alles maar in OSM te dumpen maer realiseer me wel dat een ieder daar zijn eigen grenzen in heeft. (van mij hoeven oude bomen echt niet maar anderen denken daar anders over). De discussie over het wel of niet in OSM opnemen van andere ODBL databronnen (bv BAG) vind ik wel zinvol. Ik denk dat de best of both worlds is het opnemen van deze data met daaraan vastgeknoopt een mechanisme dat synchronisatie mogelijkheden biedt (sleutels in OSM) . Eigen zou ik wel eens een lijstje willen zien met alle pros en cons van het opnemen van databronnen in OSM (of niet) maar ben zelf te lui en niet kundig genoeg om dat op me te nemen :/. Pas daarna kunnen we een goede afweging maken mijnsinziens.

Ik wil OSM koppelen met mijn Mysql database met gereden routes zodat ik altijd een actuele kaart heb waar ik mijn routes op kan projecteren, ik heb niet de intentie al mijn gereden tracks te uploaden.
Het probleem met sites als gps.nl en mtbroutes.nl vindt ik ook dat ze meteen het eigendom claimen van de route als hem upload …

Verder zijn de routes op MTBroutes.nl hopeloos verouderd en zul je in het geval van de Enschede routes er niets aan hebben. Het mooie van OSM is dat wanneer je een fout vindt je deze “on the fly” kan aanpassen, en dat dus de volgende gebruiker de actuele gegevens heeft. Heeft TT ook niet zoiets ?

Dat OSM er niet over nagedacht heeft zoals je hier boven claimed, is niet “mijn” probleem, ik maak alleen gebruik van de mogelijkheden die ze bieden.

Wat is er mooier dan wanneer ik beslis om naar Limburg te gaan, OSM kan opstarten en een route uit te zoeken,deze downloaden op mijn gps en gaan met die banaan…

Mijn hele geknoei met GPX files is dus om lokale files te gebruiken icm met server data, alleen vinden de browsers dit nog geen goed idee…

Als illustratie: Route Enschede gedownload van MTBoutes (groen)met de overlay uit OSM: klik.
Op vier plaatsen is er verschil, Op 1 plaats is de route gebarricadeerd en krijg je de hond van de eigenaar achter je aan, weet ik uit eigen ervaring :confused:

MTBroutes was bij nader inzien slecht voorbeeld want die site lijkt overgenomen door geldbeluste malloten. Het publiek is ook veranderd zie ik, want ze klagen nu dat er plassen en modder op een route liggen … Laat ik nu denken dat dat nu juist het hele doel van off-road fietsen is! Ploeteren door de omstandigheden en na afloop 2 uur poetsen.
Maar evenzogoed blijft mijn voorkeur voor scheiden van data overeind.
Overigens: kijk ik op dit moment naar ncn/lcn/mtb in OSM dan is het nog voorzichtig uitgedrukt als ik zeg dat daar geen snars van klopt en het heel ver van compleet is. Voor zover ik zie is eigenlijk alleen het knooppunten gedoe op orde.

Dat zeg ik niet. Ik zeg alleen dat ze imo een foute route hebben gekozen. Maar daar zal best over nagedacht zijn…

gpx: Er zijn zat mini servertjes. Installeer die op je pc op een alternatieve poort en het werkt meestal prima.

NB lekker bezig in Haaksbergen … overpass kan het niet eens bijbenen

Klopt, die staan ook allemaal op rcn niveau…

Ja, klopt ook, maar is wel minder leuk dan iets nieuws leren :slight_smile:

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.