De kleuren en de weergaven zullen er niet anders van worden. Zelfs de weg hoeft niet eens op de kaart getekend te worden. Alleen het fietspad kan ook. Een verschil in ondergrond kan ook aangegeven worden zoals nu gebruikelijk, mits dat natuurlijk in de database staat.
Des te ingewikkelder de database, des te meer kans op fouten, lijkt me.
En des te ingewikkelder het voor mij wordt om een openfietsmap kaart te maken.
Heeft ZMW ervaring met het maken van een kaart? Dacht het niet…
Michiel misschien?
Correct. En daarom stel ik juist een standaard en gedocumenteerd schema voor om de kans op fouten te minimaliseren. Zie ook een voorgaande post van richardbrinkman
Niet per se met het renderen van een osm kaart. Ik ken ook de achterliggende code niet, maar ik heb wel een globaal idee. Waar nu wordt geselecteerd op highway=cycleway moet bijkomen ‘of cycleway=track of cycleway=lane’. Het selecteren van de eigenschappen van die extra 2 wegelementen zou niet veel moeilijker moet zijn dan wat er nu al gebeurt. Als highway=cycleway zoek voor surface etc… Als cycleway=track, zoek naar cycleway:surface etc.
Het probleem zit 'm in het feit dat cycleway=lane of track en highway=secundairy dan in één lijntje zitten. Ik kan dat lijntje dan hooguit wat dikker maken met een rode rand (gestippeld voor lane, wat dikker voor track), zodat je kan zien dat er een fietspad naast de weg loopt. Dat is nog te doen en werkt prima. Het fietspad "verdwijnt"niet onder het wegdek bij uitzoomen. Maar als er nog meer kenmerken aan die cycleway worden gehangen wordt het al onmogelijk.
De richtingen bijv. zijn niet te renderen laat staan te routeren.
Dat is wel wat makkelijker als het om een highway=cycleway gaat die als apart lijntje wordt ingetekend. Hier kan ik nog een pijltje inzetten voor de richting en een andere arcering als het fietspad niet geasfalteerd is.
Kort samengevat, extra tags als cycleway=track of cycleway:left=track zijn prima bij eenvoudige situaties. Wanneer de eigenschappen van de verschillende wegen totaal anders worden teken dan aub een apart lijntje. Als de kaarten er niet mee om kunnen gaan, wat heb je dan aan OSM?
Heren,
De fietspaden worden toch niet apart getekend omdat het eenvoudiger is voor het maken van OFM?
Wat dacht je dan?
Heb je overigens Mapnik al benaderd voor het renderen van jouw ZMW tags?
Ik snap waar de moeilijkheid in zit. Maar als er dus een mogelijkheid komt om, wanneer er een track wordt omschreven, deze los te kunnen tekenen, is het probleem opgelost?
Ik denk dat er genoeg programeurs zijn die dat erg vlot kunnen programeren. Ik weet nu niet welke software daadwerkelijk het lijntje op de kaart tekent, maar een lijntje evenwijdig tekenen langs een weg kan niet heel moeilijk zijn. Daarna kun je dezelfde code gebruiken om die je ook gebruikt als highway=cycleway. Ook nu wordt er al gewerkt met :=waarde. Dat kan ook al geinterpreteerd worden.
Eigenlijk is het een goede opmerking die je maakt. Hieruit blijkt namelijk dat we juist wel taggen voor de renderer. En natuurlijk moeten de renderers en kaarten makers iets extra gaan programeren. Dat snap ik ook wel. Maar juist omdat we een standaard introduceren moet het makkelijker worden. Zie ook het idee van David Earl (Tag central, sotm 2010) over een duidelijke omschrijving van de key’s en hun waarden.
Ik heb in februari 2009 al eens lopen te experimenteren met cycleway:left=*. Dat was toen al aktueel, maar helaas wordt het nog steeds niet correct gerenderd. Inmiddels ben ik van mening veranderd, en teken ik wel aparte fietspaden. Dit omdat sommige situaties te complex worden, waardoor het z’n doel voorbijgaat.
Op zich is het helemaal niet erg dat iedereen fiets- en voetpaden op z’n eigen manier mapt. Nederland is groot genoeg om elkaar niet in het vaarwater te zitten. En er zal vanzelf wel blijken wat uiteindelijk het beste is. Wat mij betreft hoeven we dat nu nog niet te beslissen. We kunnen het ons veroorloven om de technische ontwikkelingen af te wachten.
Maar het is wel belangrijk dat tagging schema’s goed worden ondersteund. En niet alleen door de renderers en routers, maar ook door de tools die mappers gebruiken. Als een renderer een extra lijntje evenwijdig van een weg kan tekenen als er een track is, kan josm dat ook. Dan wil ik dat fietspad kunnen selecteren, en de surface veranderen, en dan moet josm dat op de correcte manier naar tags omzetten. Dus voor de mapper moet er geen verschil zijn of het een los getekend fietspad is of niet.
Vergeet niet dat het niet te complex mag worden voor nieuwelingen. Op wikipedia, maar ook op de osm-wiki kan door middel van sjablonen heel mooi en uniform de opmaak van pagina’s verzorgd worden. Maar als je niet weet hoe zo’n sjabloon werkt, ben je soms niet in staat iets triviaals te veranderen. In een bedrijf kun je het veroorloven de technisch beste oplossing te kiezen, nieuwe medewerkers kun je immers een opleiding geven. Bij openstreetmap zal de afweging iets anders moeten liggen.
Dus ik zou willen voorstellen deze discussie te pauzeren totdat mapnik, josm, ofm, etc aangepast zijn, zodat we de voor- en nadelen zelf kunnen zien.
Wimmel,
Je bent een wijs man.
Op dit moment zijn reeds verschillende initiatieven begonnen om de randvoorwaarden die jij noemt op te lossen.
Jij bent erg thuis is het techie wereld en loopt al jaren mee.
Wellicht dat we je regelmatig om advies kunnen vragen als we met een vraag op dat terrein zitten?
Dit vat het goed samen: het probleem is dus niet dat fietsers een probleem hebben met de kaart, maar dat jij het niet ‘mooi’ vindt. Fietsers zijn hier juist heel tevreden over. Het schijnt maar niet door te dringen dat het voor fietsers wel(!) belangrijk is of ze kunnen zien of zo’n fietspad een saaie rechte lijn is of juist een aantrekkelijk slingerend pad. Dat is de toegevoegde waarde die gaat verdwijnen.
Gebruiksgemak voor de mapper is niet echt een argument: het wordt er met al die neventags niet makkelijker of duidelijker op, en bovendien … ooit een fietser horen klagen dat het invoeren van fietspaden teveel werk is?
http://tinyurl.com/3a53tva … daar is niks mis mee. Het fietspad heeft immers geen node met de weg. Je kunt met de fiets niet de weg op en met de auto niet het fietspad. Het zijn gescheiden wegen zonder verbindingsmogelijkheid. Ik zou daar zelf zeker geen node zetten omdat ie daar simpelweg niet hoort.
Dat de ZMW methode fouten voorkomt is twijfelachtig: meer opties betekent in de praktijk meer fouten en niet minder.
Uiteindelijk blijft het me allemaal voorkomen alsof er een probleem wordt ‘opgelost’ wat er niet is. Fietsers hebben een manier gevonden om binnen OSM een mooie kaart te maken zonder dat ze daarbij andere weggebruikers in de weg zitten. Een kaart die voor fietsers relevante informatie laat zien zoals het slingeren langs een weg. En geschikt voor het routeren met de fiets ook nog.
Het doet me allemaal wat denken aan gemor lang geleden toen een groep klaagde dat ‘al die fietspaden toch niet in OSM hoorden want dan werd de kaart zo druk’.
In het begin had Hugo een link naar een mooie Powerpoint waarin nogal werd geijverd voor ‘machine-readable code’.
Ik ben geen machine. Ik wil human-readable code. Oftewel een kaart die me laat zien waar ik fiets.
Daar zou ik wel een node plaatsen. Er is immers een fysieke verbinding. De strooiwagen moet ergens op het fietspad komen.
Kijk eens naar de proposed features, dan zie je direct de problemen die men meldt. Een aantal daarvan worden door de zmv-manier opgelost.
Ook heb ik al verschillende malen sitauties geschetst waar de zmw-manier wel goed de situatie kan beschrijven. Met verschillende ways zou dat erg onoverzichtelijk worden en ook praktisch niet handig. Jouw kaart zou er niet mooier van worden.
En het sluit elkaar alle bij niet uit.
En nogmaals: Iedereen kan blijven taggen zoals hij wil. Daar verandert niets aan. Jij kan gewoon je fietspaden tekenen zoals je altijd deed. Je doet het dan op de zmw-manier. Ook ik blijf veel fietspaden als losse lijnen tekenen als dat evident is. Maar waar dat eigenlijk niet mogelijk is, kan men nu de situatie wel beschrijven door de zmw-manier te gebruiken.
Ook de kaart blijft gewoon gelijk.
Beste Michiel,
Noordfiets is een ultimo fietser. dat weten we nu wel.
Dit is uitstekend en dat moeten we zeker zo houden.
En dit is het punt waar:
a) Noordfiets de plank finaal mis slaat
b) hij bij enige tegenargumenten weigert om zich verder te verklaren.
Als deze bewering door ons door argumenten en voorbeelden wordt weerlegt en beweren dat al die (en nog maals NIET ALLEMAAL) losse fietspaden wel degelijk het mappen van andere weggebruikers in de weg zit. Het is geografisch gewoon niet te mappen.
Het lijkt mij daarom een goed idee dat we het advies van Wimmel gaan opvolgen en onze ideeen verder gaan uitwerken.
En verder lijkt het mij zaak voor Noordfiets om eens uit zijn fietswereldje te stappen en op zijn manier een oplossing te geven voor het voorbeeld zoals Ligfietsers heeft voorgelegd “Het kruispunt bij Diergaarde Amersfoort”.
Als deze er is kunnen we zien of ook dit goed weergeefbaar is in een willekeurige kaart en bruikbaar is voor routers. Wellicht dat ons voorstel dan helemaal niet meer nodig is.
Die situatie in Hengelo wat Noordfiets aanhaalt is een mooi voorbeeld om uit te werken: http://tinyurl.com/3a53tva
Daar waar fietspaden fysiek kruisen met wegen die niet toegankelijk zijn voor fietsers is het gebruikelijk wèl een node te tekenen. Dat je als fietsers dan die weg niet in kan slaan moet je dan duidelijk maken door op de secundaire weg de tag bicycle=no te zetten. Deze methode gebruikt de fietsersbond ook in haar planner.
Als je verder naar die Hasselerbaan kijkt, hier zie je zowel de google satellite als osm: http://sautter.com/map/?zoom=18&lon=6.82331&lat=52.27741&layers=00B000TFFFFFFF
Dan zie je een busbaan die duidelijk onderdeel vormt van de linker rijstrook (alleen gescheiden door een witte lijn). In dit geval zou ik methode ZMW kiezen. Eén lijn voor de linkerbaan (ipv 2 zoals nu op osm), maar dan wel een andere voor de rechter omdat hier een significant brede groenstrook tussen zit.
De strook met busbaan zou je dan aangeven als highway=secundairy lanes=2 psv=right secundairy=left?
De beide fietspaden volgen een eigen loop dus die teken ik apart in. Maar dan iets naar het noorden kom je over een viaduct:
http://maps.google.nl/maps?q=hengelo&oe=utf-8&client=firefox-a&ie=UTF8&hq=&hnear=Hengelo,+Overijssel&gl=nl&t=h&layer=c&cbll=52.27757,6.823047&panoid=HGtF0XpWctyT3eIdnC7skQ&cbp=11,13.28,0,6.85&ll=52.277572,6.823046&spn=0.001779,0.013078&z=17
Dat is er maar één. Dus hier teken je eigenlijk maar één lijntje met bridge=yes. En niet 3 bruggen zoals nu op osm staat.
Dit wordt al wat lastiger, maar gelukkig is er geen busbaan. highway=secundairy cycleway=track bridge=yes layer=1 zou hier dan de beste tagging zijn. Voor het gemak laat ik in het midden of die fietspaden links en rechts in beide richtingen toegankelijk zijn, dat moet gewoon blijken wanneer de wegen zich splitsen. Nar het noorden toe splitsen de fietspaden zich weer van de hoofdweg en volgen hun kronkelend verloop dus dan is methode noordfiets weer beter. Daar geef je dan aan of er sprake is van oneway=yes dus dan weet de router dat je als fietser alleen links dan wel rechts van het fietspad moet zijn.
In mijn voorbeeld bij de dierenpark ligt het voor de hand wèl gescheiden lijnen te trekken omdat de fietspaden duidelijk fysiek gescheiden zijn en er oversteekplaatsen zijn en eenrichtingverkeerssituaties zijn waarmee de huidige renderers en mappingtools (nog) niet met ingewikkelde tags kunnen omgaan. Waar ik wel mee eens ben is dat de tagging verder wordt ontwikkeld in situaties als bijv. een wegdeel bestaande uit 5 rijstroken waaronder een fietspad in het midden met links 2 banen voor autoverkeer en uiterst rechts een busbaan.
Het lijkt mij goed om dat kruispunt dan daadwerkelijk in zijn geheel te mappen. Live en wel.
2 voetpaden, 2 fietspaden, twee rijbanen en een afslag.
Ik zie het live voorbeeld met spanning tegemoet.
Hihihi, ik kan het niet laten 
Ik zou in dit geval zeggen: Een weg met 5 rijstroken waaronder links twee banen voor autoverkeer, uiterst rechts een busbaan en daartussen in een fietspad.
Dankzij de inspanningen van Ligfietser is de OFM één van de weinige praktische toepassingen van de OSM. Aangezien de OFK niet perfect is en updates op zich laten wachten, kan er al gauw een betere fietskaart komen in de vorm van de OFM.
Ik ben het met je eens dat er een goede manier van mappen moet zijn. Van mijn mentor Eggie heb ik het mappen geleerd. Als ik zie hoeveel basisfouten er op de kaart zijn, omdat (beginnende?) mappers de kunst niet beheersen, lijkt het me niet wenselijk om ingewikkelde systemen te bedenken die alleen professionele cartografen kunnen uitvoeren.
En het kan niet vaak genoeg zeggen dat ons twee doelen voor ogen staan (En dat hebben we de hele tijd geroepen, maar kennelijk tegen enkele dovemansoren):
- Alle bestaande inspanningen (op ieder gebied en OFM als een van de weinige uitstekende kaarten staat boven aan deze lijst) mag onder geen geval verloren gaan, niet kwantitatief en niet kwalitatief.
- Omdat OSM = OFM maar een deelverzameling (niets meer en niets minder) zullen er veranderingen/ (lees alternatieven) nodig zijn om ook andere data van weggebruikers een evenredige kans te geven.
Noordfiets en Ligfietser worden hierbij van harte uitgenodigd om op een POSITIEVE en CONSTRUCTIEVE manier binnen het project waakhond te spelen over de OFM belangen. Ik, en steeds meer met mij, zien dit niet gebeuren wanneer we blijven hangen bij alleen de huidige manier en mogelijkheden van Taggen.
The world of OSM is changing.
Hoezo?
Wiki fidlers waren er drie jaar geleden, toen ik OSM ontdekte, ook al.
De enige echt succesvolle manier om nieuwe taggingschema’s in te voeren is uitleggen + overtuigen + toegepaste applicatie. Als het vervolgens breed wordt gedragen kun je zeggen dat het een “norm” is.
Uitleggen: doe je momenteel op een te klein platform (OSM is groter dan het Nederlandstalige deel van het forum)
Overtuigen: lukt je momenteel niet echt met de fanatieke fietsers
Toegepaste applicatie: nog niets eens een belofte van gezien
Een nieuw schema verzinnen en het meteen tot norm verklaren zonder dat er ook maar iets is dat met de nieuwe “norm” kan werken is een redelijk zinloos en zorgt alleen maar voor frustratie.
a) Het schema is helemaal niet nieuw, maar een bundeling van allerlei uitstekende ideeen uit het verleden. Veel zijn reeds lang geaccepteerd en vervolgens ondermijnd door bv fietsende mappers. denk hierbij aan cycleway=lane/track. Vervolgens gaan deze mappers relaties maken en moeten moeilijk doen met forward/backward waar beginnende mappers geen snars van begrijpen.
b) Wij bepalen niet de norm. Wij zijn aan het begin om te trachten de norm die jullie ooit gesteld en nooit beschreven hebben te verbeteren en inpasbaar te maken in meer situaties. Maar wat jullie doen is alle ontwikkelingen op dat vlak treineren en afschieten.
Ik blijf jullie daarom uitdagen:
Nou, steek met de hele fietsersploeg de koppen nu eens bij elkaar en laat zien dat jullie norm werkt.