Kan je dit nader uitleggen?
Wat is het verschil tussen enerzijds “de combinatie van node en way” en anderzijds “een way (of area) als er een echt ‘perron’ is” met “daarnaast nog een node voor de stop_position”?
Jij zegt in bovendstaande quote: Minimaal een node, en optioneel een way.
Ik zeg: óf een way óf een node. En dat laatste alleen als er geen verhoogd halteperron is.
Kortom: in jouw geval krijg je per halve halte 2 of 3 items (naast de relatie), in mijn geval exact 2.
Mag ik een domme vraag stellen? Zijn we het erover eens dat als er alleen een haltepaal ergens op een stoep staat, verder niks, dat je dat dan als “platform” kan aanduiden in OSM? Ik vind dat zelf wel vreemd. Een platform stel ik me toch iets meer herkenbaars bij voor.
Domme vragen mogen ook, maar dit is zeker geen domme vraag.
In ptv2 (public transport versie 2) wordt de tag public_transport=platform inderdaad gebruikt voor zowel een bus perron als een haltepaal. Die, in mijn ogen ongelukkige, keuze is de oorzaak van veel verwarring en discussie.
1 Like
Ik heb je werk nergens ongedaan gemaakt. Ik heb alleen haltenodes toegevoegd waar deze ontbraken.
Daarentegen verwijder jij de haltenodes die anderen hebben toegevoegd. Dat is toch ook andermans werk ongedaan maken?
Dit lijkt me een goed idee. Ik zou er de stop-positie nog aan toevoegen:
- Optioneel ook een node met public_transport=stop_position, name, bus=yes en ref:IFOPT.
Op deze manier heb je compatibiliteit met zowel het eenvoudige en ruim ondersteunde klassieke systeem, als het complexere maar slecht ondersteunde PTv2-systeem.
Het klassieke systeem houdt in:
- Een node met highway=bus_stop, die de halte aanduidt.
- Eventueel een way met highway=platform, die het perron aanduidt.
Het PTv2-systeem houdt in:
- Een node en/of way met public_transport=platform, die het perron aanduidt.
- Een node met public_transport=stop-position, die de stop-positie op de weg aanduidt.
Mijn excuses. Ik had jouw post niet goed gelezen en “een node voor de stop_position” aangezien voor de platform node. Dat betekent dat er ook een stuk minder consensus is dan ik dacht. Jouw insteek is dan niet in lijn met het herstelwerk dat A67-A67 en Anna Gartlin9 gedaan hebben.
De reden van dit herstelwerk is om de bushaltes weer zichtbaar op de kaart te krijgen. Eerder schreef je zelf ook:
Dat je het zelf zou terug draaien, daar ben je in de daar op volgende (135) op terug gekomen. Maar nu lijkt het er op dat je er ook op tegen bent als iemand anders dat doet.
@Lachgast Dit lijkt me een goede vraag voor een peiling/stemming. Wat lastig om de vraag neutraal te formuleren, maar het zou neer komen op de keuze tussen 2 opties:
- Als er een way public_transport=platform bestaat voor een bushalte verwijderen we de node public_transport=platform/highway=bus_stop. Dit om te voorkomen dat we 2 public_transport=platform objecten hebben voor de zelfde halte. De consequentie is wel dat de bushalte op de meeste kaarten niet als zodanig herkenbaar is.
- Als er een way public_transport=platform bestaat voor een bushalte behouden we de node public_transport=platform/highway=bus_stop. Dit om de halte zichtbaar te houden op de kaarten die public_transport=platform niet ondersteunen. De consequentie is wel dat we ‘taggen voor de renderer’ en dat er 2 public_transport=platform objecten zijn voor de zelfde halte.
Als ik de haltepaal tag met highway=bus_stop en de plek waar mensen staan totdat ze instappen met public_transport=platform, dan tag ik toch twee objecten?
Precies dat is ook mijn insteek:
node (taggen voor de renderer)
highway=bus_stop
name=
en een way of aerea
highway=platform
public_transport=platform
name=
node
public_transport=stop_position
name=plaatsnaam.haltenaam
Helemaal mee eens. Maar niet iedereen lijkt deze menig te delen. Ik heb geprobeerd om mijn voorstel voor een peiling zo neutraal mogelijk te formuleren.
Geen van de twee opties.
node is niet taggen voor de render, dat is het R.V.V. bushalte icoon, highway=bus_stop
way lijn, highway=platform, gebruikelijk binnen OSM way lijn met highway taggen, met tactile paving=yes op de juiste plaats, op het platform kunnen er meerdere knippen zijn, want niet overal op het platform ligt de tactile_paving, daarom is de volgende stap ook gewenst.
vlak area. public transport=platform, om het hele platform aan te geven eventueel met area:highway=platform.
Wil je geen vlak, dan zet je public_transport=platform op way lijn is er geen waylijn dan op de node.
Dan nog de public_transport=stop_position
Eventueel 18cm kerb rand taggen aan een kant het platform.
Ik zag net een locatie, waar de node highway=bus_stop en de way lijn highway=platform was weggehaald. Vlak bleef over, alles op het vlak.
Dat kan niet de bedoeling zijn.
Ik kreeg vannacht een vlaag van inzicht: bij “bushalte” denk ik aan de haltepaal met informatiebord; maar anderen (en de wiki van bus_stop) denken aan de halteplaats, waarop de mensen staan, en dat is platform. Weer anderen denken in de eerste plaats aan de plek waar de bus gaat staan, en dat is dan stop_position.
Bij micromapping van de situatie ter plekke wil je al die dingen wel onderscheiden, maar voor weergave van bus stops op een kaart of in een toepassing boeien de details niet, het moet vooral duidelijk zijn als bushalte met naam en wat info bv in de tooltip of popup, en in een OV-planner.
Vanwege dat laatste (denk ik) blijft highway=bus_stop enorm populair: snel mappen als node op de plek van de haltepaal, kanten van de weg goed onderscheiden ook als er maar 1 rijbaan is, en renderers hebben maar 1 superduidelijke node weer te geven op basis van 1 tag. OV-routers vinden het wsch wat minder fijn, want die hebben connectiviteit nodig. Een verbonden platform geeft dat beter dan een losse node.
Als ik dat dan afweeg, gaat bij mij de pragmatiek overheersen, en het de facto gebruik/gemakkelijke bruikbaarheid. Ik denk ook dat de snelle highway=busstop ervoor zorgt dat je op zijn OSM’s behoorlijke kaartvolledigheid kan bereiken, waarbij ook niet-PTv* kenners bushaltes kunnen mappen, gewoon wat ze op straat zien. Ik zeg: behouden!
Daarnaast zie ik de waarde van het PTv*-systeem: gelijke behandeling van de verschillende OV-soorten, precisie in de onderdelen naar functie en positie, aansluiting (in principe dan) op de systematiek van OV-feeds. Maar dat is wel specialistenwerk, en veel onderhoudsgevoeliger/foutgevoeliger.
Vraag: is er uberhaupt een puur OSM-gebaseerde OV-planner-toepassing?
Het is goed om enige consensus te laten bestaan over hoe om te gaan met bushaltes op Nederlandse buslijnen. Laten we even peilen wat de bevindingen zijn. Ik heb het voorstel van Gertjan Idema gebruikt voor de formulering van de twee keuzes en Peters voorstel toegevoegd als tussenoptie.
De basis is in ieder geval overstappen naar het nieuwe schema Public Transport version 2. De teneur is toch wel dat het goed is om over te stappen naar dit systeem. Het euvel is echter dat (nog) niet alle kaarten/applicaties rekening houden met deze systematiek.
Vandaar de kleine peiling onder geïnteresseerden!
- Als er een way public_transport=platform bestaat voor een bushalte verwijderen we de node public_transport=platform/highway=bus_stop. Dit om te voorkomen dat we 2 public_transport=platform objecten hebben voor de zelfde halte. De consequentie is wel dat de bushalte op de meeste kaarten niet als zodanig herkenbaar is.
- Als er een way public_transport=platform bestaat voor een bushalte verwijderen we de node public_transport=platform. Dit om te voorkomen dat we 2 public_transport=platform objecten hebben voor de zelfde halte. Om de bushalte op alle kaarten zichtbaar te laten zijn karteren we de haltepaal als highway=bus_stop+haltenaam.
- Als er een way public_transport=platform bestaat voor een bushalte behouden we de node public_transport=platform/highway=bus_stop. Dit om de halte zichtbaar te houden op de kaarten die public_transport=platform niet ondersteunen. De consequentie is wel dat we ‘taggen voor de renderer’ en dat er 2 public_transport=platform objecten zijn voor de zelfde halte.
0
voters
Volgens mij is ongeveer heel Nederland al getagd volgens PTv2, dus overstappen is niet meer nodig. Het gaat er vooral om of we nog compatibel zijn met het wijd ondersteunde klassieke systeem met highway=bus_stop en highway=platform.
Een van de opties nu is om de haltenode eerst te verwijderen en dan opnieuw te karteren op de exacte locatie van de haltepaal. Waarom kan de oorspronkelijke haltenode niet verschoven worden naar de haltepaal? Dan blijft de geschiedenis behouden.
1 Like
Dat klinkt goed.
Een zorg die ik heb: sommige wandelroutes lopen via een platform. Daarvoor heb ik dus een way nodig, bij voorkeur een highway. In principe zouden platforms routeerbare ways moeten zijn, denk ik, ook met het oog op multimodale routing, of er moet alsnog een routeerbare way bijgemaakt worden op het platform.
Ik dacht dat highway=platform die functie had.
Ik heb moeite met bovenstaande keuzestelling.
De motivatie omschrijving, rendering, terwijl voor mij bijvoorbeeld, het bord is de haltepaal bus_stop, platform het vlak.
“Als er een way …” wordt hier nu een vlak, een lijn bedoeld of beide. wordt er een closed way aangegeven.
Wat de meeste voorkeur heeft om public_transport op te zetten, vlak, lijn punt en de volgorde als dit er dan wel/niet is.
“dat er 2 public_transport=platform objecten zijn” of 3.
Ik zet het op de closedway(vlak) en highway=platform op de way(lijn)
Daar ga ik ook van uit.
Zodoende had ik al eens een issue aangemaakt bij OSRM omdat foot niet routeerde over het platform.
Andere zijn het met me eens.
Dit is het zelfde als de plein discussie.
Ook op het platform vlak, de looplijn intekenen, het liefst over de tactile_paving tegels.
Ja en nee. In mijn optiek is een platform langwerpig, wegvormig. Een oppervlak vergelijkbaar met area:highway dus, waar de routeerbare footway in de lengte overheenloopt. Anders gezegd, een footway ingericht voor OV-toepassing, waar je als bonus ook nog de geometrie van het perronvlak aan kan toevoegen.
Terwijl de pleindiskussie gaat over virtuele paden over een oppervlak dat allerlei vormen kan hebben.
Inderdaad, maar een highway=platform kan prima gecombineerd worden met het pt=platform.
Zelfs als een highway over een vlak als pt=platform.
Even voor de duidelijkheid: als we highway=bus_stop gebruiken voor de haltepaal, dan wijken we bewust af van de definitie op de wikipagina van highway=bus_stop. Want die definieert het als de plaats waar mensen uitstappen en instappen. Ik heb daar geen moeite mee, ik wou het alleen even opmerken. En als we dat nu besluiten, of herbevestigen, dan is een landspecifieke opmerking op de wikipagina wel op zijn plaats. Dan weten anderen dat ook.