Heeeeeel lang geleden, toen Overpass nog niet bestond, had ik hier een eigen tileserver met een OSM-kopie van de provincie Groningen en een renderer waar fietspaden mooi rood werden. Alles wat ik daar voor nodig had kon ik gewoon downloaden. Het enige wat ik niet had was een krachtige server, dus de opbouw van de tiles was wel traag ( tijd-voor-koffie-traag zelfs ).
Die tiles dumpte ik dan weer op een oude nokia voor onderweg. Navigeren met een 1,2 inch schermpje , kom daar nu nog maar eens mee aan
Maar het is dus goed te doen, destijds 1 dag voor de basisopzet, en 2 dagen om de renderer aan te passen naar mijn smaak.
( nu ik dit bedenk: eigenlijk wel gek te bedenken dat ik in 2008 nog met een papieren kaart door Noord-Duitsland fietste en nu gewoon heel Duitsland digitaal op mijn telefoon dump en real-time render met eigen thema)
Ik heb inderdaad wat aanpassingen gedaan. Voor zover ik kon zien zou het nu wel goed moeten gaan met de busroutes. Mocht dat niet zo zijn, dan hoor ik het graag.
Ben het met jullie eens dat het niet de bedoeling is dat iedere gemeente of andere instantie OSM gaat aanpassen waar hij of zij het zelf voor nodig heeft. Dan is het einde zoek. De vraag is alleen of wij dat hier doen, ik denk van niet. We voegen knips toe op plekken waar wegen aansluiten op zijwegen. Dit zijn logische plekken, maar volgens mij past dat ook helemaal binnen het OSM beleid, toch? Op heel wat plekken zijn ze al wel logisch, maar op sommige ook niet. Daar passen we ze aan. Wat je nu bijvoorbeeld soms ziet is dat een fietslink doorloopt over een kruispunt heen, terwijl op het kruispunt fietsers ook af kunnen slaan. Daar voegen we dan een knip toe. Ik zou het dus meer zien als een verfijning om OSM nog beter te maken (en bruikbaarder). Moeten alleen wel voorkomen dat daar mee schade optreedt… en hopelijk gaat dat nu goed.
'k Vermoed dat de route-experts wel zullen kijken…Die hebben daar een tool voor… maar het zijn drukke dagen voor iedereen.
Op de fietspaden kunnen trouwens weer fietsroutes lopen… dus die ook weer checken.
Nee, dat is een misvatting. Er is geen beleid of conventie die voorschrijft dat wegen bij kruisingen met andere wegen opgesplitst moeten worden. Tools die deze splitsing intern nodig hebben, zoals navigatiesoftware, splitsen de segmenten zelf verder op.
In OpenStreetMap worden wegen noodzakelijkerwijs opgesplitst wanneer de tags verschillen per segment; bij wegen met verschillende namen is dat vanzelfsprekend het geval, waardoor bij veel kruisingen wegsegmenten eindigen. Wanneer de tags gelijk zijn, worden ze juist vaak verbonden om de kaart beter beheerbaar te maken. Jullie lopen dus het risico dat mappers die zich volledig aan de regels houden wegen weer met elkaar verbinden wanneer ze een stukje kaart aanpakken.
Ook zullen wegsegmenten soms hertekend worden wanneer de verkeerssituatie verandert; levert dit geen problemen op voor jullie?
Hoe gaan jullie trouwens om met segmenten die verder opgesplitst worden tussen kruisingen? De numerieke identifier die OSM toekent aan een segment gaat over op een van de nieuw gesplitste segmenten (niet beide), maar dat is niet perse het segment waar jullie gegevens aan koppelen; die kan een nieuwe identifier krijgen.
Da’s een goede opmerking. Het id is zelfs helemaal geen garantie, want als je een stuk weg verwijdert en dan opnieuw intekent ( bijvoorbeeld om de ligging te verbeteren ) krijgt ie ook ander id. Ook het samenvoegen van segmenten is gebruikelijk als een weg 1 geheel is, het is iets wat ik bijv doe als ik een lange weg met veel segmenten van een nieuwe/andere tag voorzie. De knopen/kruisingen blijven immers op dezelfde plaats. Het id is dus geen uniek kenmerk voor een wegsegment.
Het lijkt alsof Gemeente Utrecht denkt dat je alleen kan afslaan bij het einde van wegen in OSM en dus wegen moet opsplitsen bij kruisingen. Dat is echter niet zo. Als er een node (punt) gedeeld is tussen twee wegen, kun je afslaan, zelfs als dat halverwege een weg is. Een op OSM gebaseerd navigatiesysteem gebruikt dus delen van wegen om de route te maken.
Gemeente Utrecht, kunnen jullie ons uitleggen waarom jullie de OpenStreetMap database aanpassen, en niet een eigen interne dataset maken/gebruiken voor het doeleinde ‘verkeersintensiteiten’?
Want hier zit denk ik het knelpunt van deze community (waar ook Geo professionals in zitten).
Begrijp ik het goed dat er hier wegen worden opgeknipt waarbij de overblijvende wegen identieke key/value pairs hebben? Zo ja … dan lijkt me dat echt niet de bedoeling. Mappers die dit niet weten (maar wellicht ook mappers die het wel weten ;)) kunnen die wegen zo weer aan elkaar plakken en dan is er niemand iets mee opgeschoten. Als er wegen worden opgeknipt dan zou dat m.i. moeten alleen omdat de tagging van de overblijvende wegen afwijkt of omdat het ene deel wel en het andere deel geen deel uitmaakt van een relatie. Of … mis ik iets?
Het lijkt erop dat de tool die de gemeente gebruikt niet kan omgaan met de wegen die op elkaar aansluiten. De doorgaande weg willen ze vermoedelijk opgeknipt zien, waar door de tool wel werkt.
De oplossing zal niet in de OSM data gezocht moeten worden maar in de tool die de gemeente gebruikt.
Ik denk dat de Gemeente Utrecht beter kan stoppen met deze manier van werken. Voornaamste redenen:
Het is in OSM ongewenst wegen op te knippen die na het knippen identiek getagd zijn (ook qua relatie). Sterker nog … er is in OSM een wens om deze wegen juist weer te verbinden tot 1 weg.
Daarnaast is het voor de gemeente niet houdbaar omdat de wegen nadat zij het hebben geplitst weer zullen wijzigen (door verschillende redenen)
Dat de Gemeente het jammer vind dat er negatief gereageerd wordt is m.i. volledig aan hen zelf te wijten. Als je in OMS edits wilt uitoeren die zeer ongebruikelijk zijn dan zou het wel zo netjes zijn dat te bespreken voordat je tot actie overgaat.
Ik denk dat voldoende gezegd is wat aan de hand is. Ik heb wegens afwezigheid niet de gehele discussie nageplozen maar ik denk dat er voldoende argumenten zijn waarom de GU het enders moet doen:
. OSM is geen officiële instantie, moet dat ook nooit worden, en daarmee kan GU deze nooit naar haar richtlijnen aanpassen.
. Alles wat GU aanpast, om welke reden dan ook, kan en zal door anderen wederom gewijzigd worden met als resultaat dat GU niet betrouwbaar gebruik kan maken van haar wijzigingen en mogelijk zelfs een edit-war.
. als GU een nieuwe systematiek wil toepassen dient zij dat eerst de community voor te leggen, acceptatie te verkrijgen en dan pas iets structureel wijzigen; dat is niet gebeurd
. er zijn voldoende tools voor de GU beschikbaar om mogelijk te maken wat zij willen: een eigen mirror server of een eigen laag over OSM. Er is geen enkele reden om hiervoor OSM aan te passen
Mijn advies aan de GU: stop ogenblikkelijk hiermee en richt je eigen infrastructuur in.
Hallo allen. Reagerend op bovenstaande: We willen niet richtlijnen aanpassen of een nieuwe systematiek toepassen. We willen alleen OSM verbeteren (en vervolgens gebruiken als onderlegger in een database waardoor we vervolgens weer meer data openbaar beschikbaar kunnen stellen). De vraag is alleen als ik de reacties zo lees of dit “verbeteren” past binnen de werkwijze van OSM. Wij zijn/waren in de veronderstelling dat het splitsen van wegen op de plekken die wij uitvoeren past binnen de werkwijze van OSM. Op heel veel plekken zijn deze ook al door jullie uitgevoerd. Op die plekken waar wegen samen komen/uitwisseling van verkeer plaats vindt. Het is alleen niet overal consequent gedaan. In Utrecht zijn heel wat locaties te zien waar het knippen (of doorverbinden) de ene keer wel is gedaan en in vergelijkbare situatie niet, vooral ook bij fietspaden. Hangt dit van de gebruiker af? ik weet het niet…
Maar als de wijzigingen die wij aanbrengen niet passen binnen de werkwijze van OSM, dan gaan we daar uiteraard niet mee verder. Want nogmaals, we willen een bijdrage leveren aan het nauwkeuriger maken van OSM en niet het toepassen van eigen richtlijnen of iets dergelijks.
Lees even de berichten in deze thread door en je snapt het. Met name:
Dataconsumenten van de OSM database moeten er dus vanuit gaan dat wegen niet perse bij elk kruispunt stoppen. Waar dit wel gebeurt, is dit vaak omdat de tags aan beide kanten van het kruispunt anders zijn.
De splitsing van wegen in Nederland (vooral in Nederland) komt door de import van de AND data. Daar waren ways gesplitst tussen elk punt waar je een andere richting uit kon (krusing/zijstraat). Veel daarvan is alweer samengevoegd (want een echt praktisch nut heeft het niet), maar je ziet het nog wel, bijvoorbeeld de Biezenstraat in Oisterwijk.
Er is IMHO ook geen sterk argument tegen opsplitsen of tegen samenvoegen. Voor de kaart is dat tot op zekere hoogte hetzelfde, alleen mapnik zal één straatnaam per segment tonen, wat betekent dat je op gesplitste wegen meer straatnamen ziet (vergelijk de Bunderstraat die richting ZW gaat). Voor een router is het helemaal hetzelfde.
Als je gaat splitsen in OSM en er op gaat vertrouwen dat die splitsing zo blijft en daar externe data van afhankelijk maakt, dan zul je gauw genoeg zien dat dit mis gaat. Het gaat al vaak genoeg mis met relaties in OSM die van de gesplitste wegen afhankelijk zijn (weg wordt gesplitst zonder relatie geladen te hebben → afgesplitst deel mist, of wegen worden samen gevoegd en de relatie heeft een overtollig stukje weg waardoor die misschien niet meer doorlopend is terwijl dat wel moet zijn). Dat een way nu bestaat betekent niet dat die morgen ook bestaat.
Dus: de vraag blijft wat jullie doelstelling met de data is. Ik denk niet dat we te hard moeten gaan roepen “je MAG wegen niet splitsen”, maar wegen splitsen alleen vanwege het splitsen zou ik niet doen.
Ik weet niet wie hem dat geflikt heeft maar Combine Way (toets C) gaat ineens niet meer in JOSM als segmenten deel van een route zijn https://josm.openstreetmap.de/wiki/Changelog
Ze noemen het:
Edit: *** ik kan zelfs wegen zonder routes niet meer samenvoegen!
Ik heb die problemen niet? Ik heb net de laatste JOSM gedownload (15628) en zie hetzelfde gedrag als voorheen: wegen combineren gaat zonder problemen, als er verschillende tags of ze in verschillende relaties relaties zitten krijg je een venster om te kiezen wat er genomen moet worden.
@Maarten: Advanced Preferences > More > Reset Preferences en een paar keer het programma starten en stoppen en ook rebooten heeft het probleem opgelost.
