LAW’s, LF’s en knooppuntroutes zijn allemaal twee richtingen en hebben niet echt speciale startpunten (je kunt overal opstappen). Die hebben dus ook allemaal geen speciale tags voor richting en startpunt(en). Deze routes maken echter wel de bulk uit van alle gemapte routes in Nederland. Blijven over de lokale routes.
Bij de paar lokale rondjes die ik heb gemapped heb ik de relaties zoveel mogelijk voorzien van:
Een tag: oneway=yes (maar geen oneway=no voor tweerichtingsroutes)
Een tag: direction=clockwise|counterclockwise (natuurlijk weer niet voor tweerichtingsroutes)
Nodes met de role start
Nu ik dit zo teruglees zou het waarschijnlijk handig zijn om voor de tweerichtingsroutes de tag direction=both te gebruiken.
Ik heb ooit een discussie gehad met Eimai. Die vond de direction tag niet goed genoeg, omdat je er niet alle rare uitzonderingen als rondjes in de vorm van een 8 of 9 mee kon taggen. Hij vond dat voor een éénrichtingsroute (maakt niet uit hoe lang) alle wegen van een role=forward|backward voorzien moesten worden.
IMHO zijn tags die beginnen met dingen als mtb:route: erg fout. Dat moet duidelijk zijn uit de context, als je de tags op de juiste plaats zet, namelijk in de relatie zelf.
Dat zag ik … de examenroute als lcn
Lokale wandelroutes/fietsrondjes/mtb routes hebben vaak meerdere opstappunten, gunstig gelegen bij een parkeerplaats of nog liever cafe. Nou vallen die routes zobiezo een beetje buiten de OSM doelstelling, en voel ik me ook niet geroepen daar in te gaan roeren. Maar om mijn idee te geven: ik zou het liefst bij een relatie de start als tag geven met als waarde een node-id ipv een tag start op de node zelf. En dan kun je ook meerdere tags start geven met meerder nodes. En liefst lengte en richting ook op de relatie.
Dat ik mtb:route:start als voorbeeld gebruikte is omdat als je op de node zelf tagt die node deel uit kan maken van meerdere relaties. Tag je de node op de relatie dan vervalt die onduidelijkheid.
Maar ook voor bv Pieterpad kun je Pieterburen/Maastricht als begin/eind taggen. Daar hoef je niet te beginnen natuurlijk maar het zou wel duidelijk maken of een route compleet is, vooral als het geen rondje is.
Blijft de vraag of dat allemaal wel in OSM thuishoort. Ik denk eigenlijk van niet, of althans niet in de hoofd database. Ik heb geloof ik al vaker een pleidooi gehouden voor meer gelaagdheid in de database ipv 1 gigantische brij. Omdat ik uit ervaring weet dat dat op den duur altijd problemen geeft. Maar goed, OSM is zoals het is, en het zal wel goed doordacht zijn …
Dat is toch precies wat er gebeurt as je één of meerdere node(s) aan de relatie toevoegt en de role “start” geeft. De mapper hoeft zo niet dat nummer over te typen, maar het zit wel in de relatie. Bovendien waarschuwt een goede editor als je dingen weggooit die onderdeel zijn van een relatie.
Zou wel eens willen weten wat dan precies de doelstelling is… en wat is het verschil tussen een regionaal knooppuntenroutenetwerk en een regionaal MTB netwerk dan ?
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
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
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…
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?
