Buslijnen, halteinfo, OV-routes - overzicht en discussie

De oude route wissen en opnieuw intekenen lijkt mij wel zo makkelijk.

Die hoeft niet opnieuw ingetekend te worden, want die is per 15 december 4:00 afgelsoten en Schiphol kennende een week daarna al volledig omgetoverd tot bouwplaats.

Ben wel verrast door de veler suggesties om de ways van de oude weg om te toveren tot de nieuwe weg - zo wordt de historie namelijk niet bewaard en dat is waar juist vaak tegen geageerd wordt…

Ja, waar gaat het nu om?
Om op een handige manier een hele bak buslijnen om te zetten of om geschiedenisboeken te schrijven?
Ik let echt niet op het bewaren van historie, ik zoek gewoon de werkwijze, die het beste past op de situatie.
Lijkt me te zot voor woorden, dat je een omslachtige werkwijze moet gaan kiezen omdat een of andere joker nog eens in de historie wil pluizen.
We leven in het nu, niet in gisteren.
Leuk als je dingen terug kan kijken, maar als dat niet kan, pech.

Ik vind het prima! Al ga ik wel jout suggestie van de Moreplugins proberen!

Is er een edit-oorlog aan de gang ?
Of is er alleen sprake van een verschil van inzicht ?

A67-A67 voegt de plaatsnaam toe aan de stop_position.
Sint E7 verwijdert vervolgens bus=yes en name=* van de stop_position.

Dat laatste zorgt dan weer voor een foutmelding in OSM inspector.
Dus voel ik mij geroepen om bus=yes weer toe te voegen.

Verwijderen van bus=yes lijkt mij niet correct. De toevoeging lijkt noodzakelijk om aan te geven door welk Ov-systeem de stop_position wordt gebruikt.

Maar wat is de reden om de name=* te verwijderen van de stop_position ?

Ik heb niet gemerkt dat ik Sint E7 tegen aan het werken ben. Voor zover ik weet hanteer ik ook dezelfde tagging als hij in ieder geval een paar maanden geleden had.

Bus/tram/train=yes is nodig op zowel platform en stop_position. Ook de nametag hoort ingevuld te worden omdat een halte een naam heeft. Het is gebruikelijk om alleen de haltenaam op het platform te gebruiken en plaatsnaam, haltenaam op de stop_positions.

Wat betreft dat laatste: ik denk dat eigenlijk beter is om een aparte tag te gebruiken voor de plaatsnaam op zowel platform als stop_position. Dan wordt het bijvoorbeeld name=haltenaam en placename=plaatsnaam. Zo kan een datagebruiker gemakkelijker de plaatsnaam en haltenaam onderscheiden.

Edit: Als ik kijk naar recente wijzigingen van Sint E7 in Limburg lijkt het dat hij de stop_postions meestal gewoon intact laakt. Misschien was het verwijderen van bus=yes en de naam een fout.

Ik heb soms aan de stop_position gezeten; het valt me op dat stop_positions soms te pas en te onpas gebruikt worden in Nederland. Ook zitten ze de ene keer wel in een relatie en de andere keer helemaal niet en is de stop_position ook geen eindpunt, dan haal ik hem helemaal weg. Verder was het verwijderen van de stop_positions in Vaals een foutje van mij.

Maar wat is de reden dat je bus=yes, name=* verwijderd, terwijl de tag public_transport=stop_position wel blijft staan ?

Verder krijg ik allerlei foutmeldingen omdat je ergens een nieuw platform op de kaart zet en het oude platform van zijn tags ontdoet.
Deze lege node blijft dan in de routerelatie staan en het nieuwe platform wordt niet in de routerelatie opgenomen.
Het waarom van deze foutieve werkwijze ontgaat mij. Je kunt toch net zo makkelijk het bestaande platform zo nodig losmaken en verplaatsen naar de juiste positie. Dan blijven de routerelaties gewoon in tact
Nu ben ik weer ruim een half uur bezig geweest om de fouten in Z Limburg te corrigeren.

In principe mogen zowel stop_position als platform aan de routerelatie worden toegevoegd. Dus het weghalen lijkt me geen goed idee. Over het algemeen hebben belangrijkere lijnen vaak wel stop_positions en minder belangrijkere niet, omdat het een hoger detailniveau is.

zie ook deze discussie: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Refined_Public_Transport

Dat voorstel ‘Refined Public Transport’ ziet er uit als een terugkeer naar PTv1, maar dan met het PTv2-idee dat elke routevariant in een aparte relatie moet. Ze zeggen dat het compatibel is met PTv2, maar dat lijkt alleen te kunnen door zowel RPT en PTv2 tags te gebruiken. Ik denk dat er weinig verandert als je het invoert, omdat er nu ook dubbelgetagd moet worden om compatibel te zijn.

Nu tag je een bushalte met de volgende tags:

  • public_transport=platform (PTv2-tag om aan te geven dat het een perron is.)
  • bus=yes (PTv2-tag om aan te geven dat het een halte voor bussen is.)
  • highway=bus_stop (PTv1-tag voor compatibiliteit)

Dat blijft exact hetzelfde:

  • highway=bus_stop (RPT-tag voor bushalte)
  • public_transport=platform (PTv2-tag voor compatibiliteit.)
  • bus=yes (PTv2-tag voor compatibiliteit.)

Ik moet zeggen dat ik het eerder had gezien en even snel doorgevlooid heb.
Ik vind het verschrikkelijk. Het probeert V1 en V2 te verenigen maar laat juist veel open (zelf of highway=bus_stop nou op of naast de weg moet) en daardoor is het het slechte uit twee werelden.

Ik moet zeggen dat ik me er niet echt meer in wil mengen - ik ben behoorlijk gedesillusioneerd door de gemeenschap om tot een gezamenlijke standaard te komen, en dan specifiek door de onderhouders van de renderer die járen voorgehouden te wachten met PTv2 te ondersteunen totdat de database het aankon, en toen dat eenmaal zo was, botweg “ik vind het geen goed voorstel, ik doe het niet” een gemeenschap die er al jaren op zit te wachten kalltstelt.

Ik ben zelf nogal een opponent van PTv2, maar als de gemeenschap als geheel zou besluiten PTv1 te omarmen (of zelfs alle OV-routes van de kaart te verwijderen, waar ook wat voor te zeggen zou zijn) kan ik me daarbij neerleggen. Maar dit is belachelijk.

Ik mis wikipedia wel eens, waarvan ik het idee had dat het besluitvormingsproces procedureel veel helderder en strikter was. En dat op een wiki, waar data-uniformiteit veel minder belangrijk zou moeten zijn dan op een geografische database…

Bij het nalopen van de concessie Regio Utrecht kwam ik tot de ontdekking dat lijn 50 twee route_hoofden heeft. Eén voor de relatie in de provincie-concessie, die door Syntus wordt gereden (lange ritten naar Wageningen en Veenendaal) en één in de regio-concessie die door Qbuzz wordt gereden (korte ritten tot Driebergen/Doorn). Echter heeft lijn 50 geen routevariant tussen beide concessies in en mijn inziens zou de hoofdroute dus ook aan de regioconcessie gehangen mogen worden en kan één route_hoofd aldus verwijderd worden.

Dat zie ik dan heel anders:

De 2 korte routerelaties hangen in 1 route_hoofd en die hangt in netwerk Regio Utrecht.
De 4 lange routerelaties hangen in 1 route_hoofd en die hangt in netwerk Provincie Utrecht

Het samenvoegen van de 6 routerelaties in 1 route_hoofd in het netwerk Regio Utrecht heeft dus tot resultaat dat het verband met de Provincie wordt verbroken. Dat lijkt mij niet juist.

Overigens valt mij op dat er wel veel overeenkomst zit tussen beide netwerken.
Is de concessie Provincie Utrecht anders als de concessie Regio Utrecht ?
Dan zouden er geen overeenkomsten moeten zijn.

Wie weet hoe het echt zit ?

De provincie-concessie wordt gereden door Syntus en is voortgekomen uit de vorige concessie Provincie Utrecht van Connexxion uit 2016.
De regio-concessie wordt gereden door Qbuzz en is voortgekomen uit het voormalige BRU en werd tot deceber 2013 gereden GVU en Connexxion.

Lijn 50 kent daarnaast een gedeelde exploitatie. Syntus rijdt de lange ritten naar Wageningen en Veenendaal en Qbuzz rijdt de korte ritten tussen Utrecht en Driebergen en in de spits verder naar Doorn. Tussen beide vervoerders zit geen routeverschil en zelfs geen huisstijl-verschil, alle ritten worden als U-link gereden in een licht-grijze kleurstelling.

Ik bedoelde met de eerste reactie dat het route_hoofd en de beide routes die daar onder hangen ook in de relatie van de concessie Regio Utrecht horen, gezien de gedeelde exploitatie hierboven genoemd.

Oké, daar kan ik nauwelijks bezwaar tegen hebben.

Een vraagje voor de kenners wellicht.

Naast het updaten van de buslijnen in OSM in Nederland, doe ik dat tegenwoordig ook in Duitsland. Zeker in het voormalige oostblok is daar nog veel werk te verzetten, maar daar loop ik ook tegen een probleempje aan. Aldaar heeft men het schijnbaar ooit een goed idee gevonden om de landuse-vlakken aan de wegen vast te koppelen en dan ook van beide kanten, waardoor ik de weg zelf in JOSM niet goed aangeklikt krijg voor de route-relatie.

Is er een manier om die landuse-vlakken uit te zetten, zodat ik alleen de weg nog maar zie?

Je kunt in JOSM toch gewoon filteren op landuse=* en dan alle landuse “uit” zetten?
Of omgekeerd, alle highways filteren en dan al het andere “uit” zetten?
Kwestie van de juiste vinkjes aanklikken als je het filter hebt geactiveerd.

Je kunt bij het downloaden een overpass query gebruiken. Maar dan moet je heel voorzichtig zijn met edits, omdat je niet alle elementen hebt kun je conflicts veroorzaken.

ik vind het koppelen van landuse aan wegen (in het algemeen areas aan lineaire features) heel erg vervelend. Meestal koppel ik het ook direkt los.
Want een bos, grasveld, akkerland loopt per definitie niet tot het midden van de weg.