Buslijnen, halteinfo, OV-routes - overzicht en discussie

Er zijn nu drie “platform”-elementen:
*de way met alleen bus=yes en public_transport=platform, die wél lid is van lijn 74.

  • de node van dvdhoven met allerlei relevante tags, waaronder ref:IFOPT = NL:Q:44800250
  • de node van Sint E7 met allerlei relevante tags, waaronder ref:IFOPT NL:Q:44800260
  1. Zouden deze drie niet vereenvoudigd moeten worden tot één element, namelijk het daadwerkelijke perronrand (als die er is)?
    Daarbij blijft ik niet houden van highway=bus_stop: verouderd, maar tot nu toe het enige dat rendert op OSM_carto. Maar niet als je het op een way plaatst, dus dan kan je het net zo goed helemaal weghalen.
  2. Sint E7: je schrijft: bushaltenode. Maar een bushalte moet(mag) bestaan uit een stop_position en een platform. Platform is daarbij een misnomer, het is namelijk gedefinieerd als “de plek waar je instapt” - een perron of een haltepaal. Dus niet beiden.
  3. Welke ref:IFOPT is nu de juiste?

Ik vind het streven van Sint E7 heel nobel om tot een eenduidige Nederlandse tagging te komen, maar volgens mij is die er niet. Ik heb mijn eigen manier, Polyglot (België) heeft weer een iets andere manier en jij kennelijk ook weer, en ondanks alle discussie in deze thread zijn we het volgens mij nog niet eens over wát de juiste “standaard”-manier van taggen dan is. Of heb ik wat gemist?

(Daarbij geloof ik overigens niet dat ik de waarheid in pacht heb qua manier van taggen)

Ik snap eigenlijk niet waarom Dvdhoven nog een node toegevoegd heeft. De node die ik op die plaats toevoegde bevat precies dezelfde tagging en het énige juist ref:IFPOT, d.w.z. NL:Q:44800250. Het nummer 260 ligt aan de overkant van de weg voor de bushalte richting Enschede.

Om nog even te reageren op het geen IIVQ schrijft:

  1. Alles samenvoegen op het perron ben ik niet zo’n voorstander van. In landelijke gebieden is het haltebord bijvoorbeeld bevestigd aan een lantaarnpaal en is er geen enkele sprake van enig platform en in Nieuwpoort (ZH) is dit bord zelfs bevestigd aan een huis. Daarom is voor mij een bushaltenode toch de beste optie om alles in kwijt te kunnen. Daarnaast valt me op dat op busstations (en in mindere mate onderweg) de platforms vaak ook een naam hebben, mijn inziens niet nodig als er ook een node aanwezig is met de naam vanuit het CHB en alle tags die aanwezig zijn.
  2. In elk geval in de Randstad en de concessie waarin ik woonachtig ben waren nog veel verouderde bushaltes aanwezig en vaak ook alleen in de vorm van een stop_position. Daar heb ik dus veelal de stop_position aangepast naar hetgeen (naar mijn idee) correct is en vervolgens ook een bushaltenode aangebracht. De relaties moeten in veel gevallen nog aangepast worden, daar ben ik inmiddels ook mee bezig.
  3. Staat in de eerste alinea van deze post.

Om überhaupt tot een eenduidige tagging te komen, gaat er nog wel heel wat tijd overheen. Ik heb er zelf dan ook niet echt een idee van, dat dit ooit gaat lukken en daarom ga ik ze gewoon allemaal langs en pas de nodes aan waar nodig.

Ik weet niets van een extra node of wat je daarmee bedoeld.
Voor mij is dat hele busgebeuren nog steeds een uiterst mistige zaak, waar het me niet duidelijk is wat er nu wel en niet moet.
Ik heb perrons ingetekend, een stop positie op de weg gelegd en een node voor de abri ingetekend en ook perron en stoppositie in de relatie opgenomen.
Daarna heb ik het hier gemeld, zodat iemand het in overeenstemming kan brengen met wat momenteel gebruikelijk is in OSM NL voor bussen.
Dus pas het naar believen aan, gooi weg wat je niet wilt hebben.

Helemaal goed Dick.
De officier belast met het optrekken van de mist is helaas met verlof gestuurd.

De wiki geeft iedereeen de gelegenheid om het anders te doen.
De stop_position mag worden opgenomen in de routerelatie.
Maar als je dat niet doet, is het ook goed.
Het platform kan als node of als way of als area worden ingetekend.
Way en area zijn dan niet de dragers van de gegevens van de bushalte en dus is toevoegen aan de routerelatie tamelijk zinloos.
De node met alle gegevens van de bushalte hoort eigenlijk deel uit te maken van de way of area.
Maar sommigen zetten die op de plaats van de haltepaal en dus los van de way of area.
En dan zijn er nog vele platforms die in de routerelatie de role stop krijgen toebedeeld.

En dan worden er, onbedoeld, bijna dagelijks, routerelaties beschadigd (zelfs door ervaren mappers).

De dag beginnen met een rondje Nederland en het repareren van beschadigde routerelaties is best leuk werk.
Je komt overal en ziet van alles.

m vr gr
Leo

Als ik de wiki lees, is dat niet helemaal de bedoeling:

[Tag:public_transport=platform](https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform#How to map)

Kortom: het platform zou gemapt moeten worden als:

Dus ik zet da halte-informatie gewoon op de area als het een area is, zoals Toolenburg.

Bij Bornholm is nog dubbelgetagd, volgens mij heb ik wél de platforms ingetekend maar niet de highway=bus-stop/public_transport=platform-nodes weggehaald (daarvoor moet nog wat informatie overgezet worden).

Zoals ik het interpreteer:
Per “richting”
*0 of 1 nodes stop_position op de weg
*0 of 1 node/way/area platform met de halteinfo náást de weg (maar kan onderdeel van de stoep zijn)
Die beiden opgenomen in de route-relatie
En dan eventueel nog allerlei randzaken, zoals shelter, bin, metro-ingang etc, samen met de stop_position en platform van beide (of alle) richtingen opgenomen in de stop_area.

Tja, dat is nu net het probleem. Het is één van de vele interpretaties die gebruikt worden.

Met als gevolg dat de halte Toolenburg Noord nu helemaal niet meer op de kaart wordt getoond.
Zelfs de area als platform worden niet meer gerenderd. En ook de naam van de halte verschijnt niet meer in beeld.
Misschien moet ik toch maar wat correcties aanbrengen :sunglasses:

Maar een Nederlandse kaart zonder bushaltes is natuurlijk wel heel rustgevend ;):wink:

public_transport=platform wordt volgens mij niet gerenderd. Wel bijvoorbeeld railway=platform.
Ik vind het zelf het prettigste om haltes alleen als nodes in busrelaties te hebben. Ik heb dan ook voor deze halte twee haltenodes toegevoegd met de noodzakelijke tags dat ze gerenderd worden en deze toegevoegd aan de buslijnen 300 en N30. De platform area’s heb ik uit de lijnen gehaald.
Dit is zoals ik het altijd map, ik wil daarmee niet zeggen dat dat het laatste woord in buslijnmappen is. :wink:

https://www.openstreetmap.org/changeset/66928315

Ik zie trouwens dat volgens de NDOV dataset deze halte gewoon Toolenburg heet. IFOPT refs ook even toegevoegd.

Al wat ik hierboven heb gelezen brengt me nu aan het twijfelen. Ik heb afgelopen maand de concessie DMG grotendeels aangepast hoe het lijnennet momenteel is. Hierbij heb ik voor de haltes overal een node geplaatst met de noodzakelijke tags en voorts ook een stop_position geplaatst. Als ik bijvoorbeeld de wiki lees, maakt het niet heel veel uit wat er komt (het mag allebei), maar dit zit me toch niet helemaal lekker, omdat ik toch alles een beetje op een lijn probeer te krijgen in NL. Als ik bijvoorbeeld de lijnschema’s van een buslijn raadpleeg wordt deze wel erg lelijk als zowel de stop_position als platform opgenomen zijn.

Nu ben ik aan de concessie Zuid-Holland Noord begonnen, waar een flinke achterstand bleek te liggen. Dit ga op dezelfde manier doen. Graag hoor ik toch een mening hierover.

#367
Volgens mij is het de/een goede manier om het openbaar vervoer te noteren.
Wat mij niet duidelijk is wat je bedoelt met

, kun een voorbeeld of verwijzing geven van die schemas?

Als er naast de platform node ook een stopposition op de kaart wordt gezet geeft de wiki aan dat het de bedoeling is om deze ook in de routerelatie op te nemen.
Dus zoals al eerder in deze discussie voorbij kwam:

platform 1
stop_position 1
platform 2
stop_position 2
etc
etc
Highway 1
t/m
highway(laatste)

In NL komen we echter alle varianten tegen
met alleen platform(nodes)
met alleen stop_positions
en iedere mengvorm die je maar kunt bedenken.

De standaard van Sint E7 lijkt mij dus correct in overeenstemming met het schema in de wiki.

En als het platform is ingevoerd als way of area, moet er volgens de wiki nog altijd een node zijn met de haltegegevens.
Dat is voor mij dus reden om een way of area niet op te nemen in een routerelatie.

Ook, vanuit welke invalshoek wordt de tagging benadert, je kan dat bekijken als openbaar vervoerder, maar ook als andere gebruikers van de omgeving.

Het feit, dat een bushalte mede wordt bepaald door een verkeersbord, bij wet RVV, dit verkeersbord heeft een plaats, een node, het lijkt mij dan logisch deze node als basis te gebruiken in Nederland, highway=bus_stop, eigenlijk zouden we op die node ook traffic_sign=NL:L3b kunnen zetten/horen te zetten.

Die node is deels bepalend, waar andere gebruikers mogen stilstaan.

Conclusie van mij is, die node highway=bus_stop is correct, zowel bij geen of wel een platform.

Al eens eerder naar een uittekening gevraagd.
Hier was ik een tijd terug al eens mee begonnen.

Voor de discussie:

Voorbeeld bushaltekom.
De werkelijke plaats van de stop_position.

Bij inrichting halteplaats in rechtstand (zijde weg) ligt the stoppositie op de rijbaan, residential way.

lanes gebruiken of aparte service way.
naar de toekomst toe het gebruik van area:highway
de looproute, over de tactile-paving

Eergisteren heb ik bijvoorbeeld buurtbus 725 in Zuid-Holland Noord aangepast volgens de tagging die gebruikelijk is. En in het lijnschema komt dat er dus zo uit te zien.

Dat is deels ook erfenis uit het verleden. Heel vroeger werden alleen de haltepalen gemapt, zonder public_transport tag en die kregen dan een stop role. In PTv2 zijn stops alleen de nodes die met de weg verbonden zijn en als stop_position gemapt zijn.
Je komt overal nog mengvormen tegen. Ik was gisteren lijnen van de concessie Veluwe aan het verbeteren en daar kwam dat nog veel voor. Bijvoorbeeld een haltenode als deze.
Dan weet ik nog dat toen PTv2 uit kwam ik een paar routes heb gemaakt met alleen stop_positions terwijl ik nu de opvatting heb dat je dat niet moet doen (of alleen platform, of platform en stop_position).
En omdat ik in het verleden op heel systematisch vrijwel alle busroutes ben nagegaan zit er veel van mijn “prutswerk” in :confused:

Voel je niet geremd om het te verbeteren.

De PT line diagrams kunnen inderdaad niet overweg met alle lijnen die volgens PTv2 gemapt zijn. Bij lijnen met een stop_position en platform worden beide getoond. Hiervoor moet de tool aangepast worden, maar er is niemand die dat nog opgepakt heeft.
Extra probleem is ook nog eens de 3 verschillende routes voor lijn 725 die de tool als één lijn probeert te zien. Daar is de tool helemaal niet geschikt voor. Extreem voorbeeld, dit is een bus in Venlo, een in Weert, een in Maastricht en een in Roermond.

Wat volgens mij echt verkeerd is is dat de platform en stop nodes niet dezelfde naam hebben. Of allebei plaats, haltenaam (niet mijn keuze) of allebei haltenaam. Maar niet de stop als plaats, haltenaam mappen en de platform als haltenaam.

Het oplossen van de chaos is dus een kwestie van lange adem en doorzettingsvermogen.
Zo langzamerhand begin ik echter ook te neigen naar een voorkeur om alleen de platform-(node) op te nemen in de routerelatie.
Dan ben je wel de plaatsnaam kwijt, maar in de meeste gevallen staat die er toch al niet.

De role in de relatie omzetten van stop naar platform voor alle haltes in een relatie, kan in drie klikken, dus als ik dat tegen kom, zal ik het wijzigen :sunglasses:

@371 Een hele mooie tekening van Allroads. Wat ik mij afvraag: loopt dat vooruit op toekomstige mogelijkheden binnen OSM ?

Ik voeg ook geen nieuwe stop nodes meer toe aan de kaart, behalve de eerste en de laatste van een route, omdat de validator van de PT plugin van JOSM daar over zeurt.
En als ik situaties tegenkom waar alleen een stop node en geen platform node is unglue ik vaker de stop node van de weg en hergebruik die dan als platform node.

Offtopic, over toekomstige mogelijkheden: Hikar, http://www.free-map.org.uk/common/hikar.html

Ik wil ook nog even reclame maken voor mijn extract van de NDOV data: http://maasluip.nl/osm/NDOV.html
Ik heb een tijdje geleden de platform letters (bij busstations) erbij gezet. Samen met de locatie en de richting van de halte (die niet altijd correct zijn!) geeft dat een stuk meer duidelijkheid.
En steeds meer vervoerders laten ook de IFOPT ref zien in hun informatiesystemen. Als 9292ov dat nu ook nog eens ging doen…

Ja en nee. Vragen, gedachtes, die bij mij naar boven komen.

Kijkend naar de toekomst is altijd goed, niet dat het gelijk moet gebeuren.
Zie ook wat, zelfs beginnende mappers, logisch achten, bijvoorbeeld intekenen highway=footway naast de rijbaan voor het trottoir.
Dat mensen zeggen, moeten we niet doen, is niet noodzakelijk, mijn conclusie is dan, is al een gepasseerd station, kan je beter mee denken, hoe het vorm te geven.

Ja, het gebruik van area:highway vlak, is nog niet zo gebruikelijk (toekomst), maar eigenlijk gebruiken wel al varianten, vlak public_transport=platform, ingetekend niet gerendeerd, is een onderdeel van landuse=highway, pleinen pedestrian.
De BGT geeft de mogelijkheid om het sneller te gaan gebruiken. Veelal, best wel correct.

Nee,
lanes, dat is een vraag van nu, wanneer er lanes zijn getagd, op de rijbaan (way) gezet, is er dan bij een haltekom sprake van een extra lane? Hoe dat vlak bekijken, vormgeven.
de stop_position, waar ligt die, haltekom, ik ben geneigd die op de werkelijk plaats te leggen, niet op de rijbaan, maar hoe kan dan deze node een onderdeel zijn van de way, hoor je dan extra way te tekenen, de highway=service.

Dan zijn er vragen is die haltekom nu area:highway=residential of area:highway=service?

Vele vraagstellingen zijn gerelateerd aan elkaar, die problematiek speelt ook bij parkeervakken langs op de weg, geen parkeergelegenheden, hoe ga je die parkeer vak benoemen, die geen P heeft, area:highway=service service=parking/plot of is dat area:highway=residential residential=parking/plot, dit is dan wel off topic, maar raakt elkaar, wat betreft de methodiek, overeenkomende methodieken zijn gewenst.

Waar vroeger alles aan de rijbaan (way) (lijn) werdt gehangen zien we een verschuiving, naar op de plaats, nieuwe intekening, vlak, sommige noemen dat al micro mapping, andere zien dat niet zo.
Ik zie wel die verschuiving.

Hoe gaan de meer openbaar vervoer gerelateerde, daar op inspelen.

Die pijtjes zijn erg duidelijk. Voor de liefhebbers heb ik de NDOV data ook als .osm bestand beschikbaar. Online beschikbaar stellen vind ik alleen een beetje tricky, omdat de NDOV coördinaten vaak nog te wensen over laten. We zitten denk ik niet te wachten op iemand die de nodes klakkeloos in osm plakt.

Mega-alles-in-één-reactie:

Public_transport=platform wordt sowieso niet gerenderd, tenminste niet op OSM_carto, of het nou area, node of way is.
De node wordt ook geen busicoon aan gegeven behalve als highway=bus_stop. Dit wordt wel beloofd.

Ergens is het taggen voor de renderer, want andere renderers (bijvoorbeeld OsmAnd) doen het prima!

Tsja, jammer, want ik heb juist de hele R-NET-serie in Amstelland-Meerlanden alle haltes van area’s voorzien en deze in de relatie gezet. Over het algemeen de nodes verwijderd, behalve waar ik dat omdat er ook niet-R·NET-lijnen langskwamen nog niet aan toe gekomen was.
Tof trouwens van de IFOPT’s.

Ik denk dat (ook gezien Sint E7’s en AdVerbrug’s opmerkingen) we juist met zijn allen een gezamelijke manier van mappen, juist in Nederland, moeten overeenkomen.
Daarbij hou ik het liefst vast aan het PT_V2-schema, maar dat is juist zo open voor interpretatie.

Waar vind je dat? Dat heb ik nooit gevonden, zowel niet op Public Transport noch in Tag:route=bus, maar ik leer graag iets nieuws.

Highway=bus_stop is mijns insziens géén onderdeel meer van PT_v2 (behalve dat zonder deze tag er niets meer op OSM_carto gerenderd wordt)
Ik hou mij absoluut niet bezig met verkeersbord-tagging, maar wat dat betreft heb je zeker een punt. Al is het verkeersbord soms op beide zijden van een Abri geplakt (het “bushalte”-icoon is bepalend tegenwoordig).
We hebben het in de RVV-context echter over de verkeersconsequenties van dat bord. (parkeerverbod)

Puur qua route-relatie kan het bord ook wel eens ergens in de modder staan, waar je niet meer in kan stappen (dan heb je het wel over micromappen)
Bijvoorbeeld hier staat het haltebord zo’n 2m in lengte van de verhoogde stoeprand af. Als een blinde dáár gaat staan komt 'ie niet de bus in.
In feite zou je als je dan een node als “instapplaats” wil hebben, de instaptegel (in dit geval de onderbreking in de geleidelijn) als plek moeten hebben.

Gaaf! Ik ben het hier eigenlijk helemaal mee eens, al heb ik nog nergens een zij-weg getekend voor een haltekom (maar op Utrecht CS Centrumzijde, wat nu niet meer bestaat, had iemand het wel gedaan, dat zag er duidelijk uit) - het is wat micromapping.
De discussie is volgens mij: moet/mag je dan de highway=bus_stop (haltepaal) of de public_transport=platform (lijn/area) opnemen in de routerelatie, of allebei?

Gaaf, die kende ik niet. Hij gaat inderdaad wel vreemd om met een aantal relaties.

Extreem gaaf!

Daar zul je bij mij niet bang voor hoeven zijn :-P. Kan ik dat krijgen? Kan je me misschien een PB sturen met een dropbox-link o.i.d.?

Even voor de duidelijkheid, als ik mijzelf teruglees vind ik me wat drammerig overkomen; het gaat mij niet om het doorpushen van míjn* interpretatie, maar veel meer om een uniform gebruik. Het liefst wereldwijd.

  • Hoe schrijf je in hemelsnaam een ij/ij met nadruk?

Nog een vraag: wat bedoel je met “dan ben je wel de plaatsnaam kwijt”?
Als je die in de naam zet, dan zet je hem toch hoop ik ook in de platform?
En als niet, dan heeft toch zowel platform als stop_position wel de halte- maar niet de plaatsnaam?

Ik heb ooit voorgesteld om in het PT_v2-schema een toevoeging op te nemen met placename, waarbij in bijvoorbeeld
Lijn 120 onderscheid gemaakt kon worden tussen de 5 haltes “Dorp”, zonder de Belgische praktijd om elke halte “plaatsnaam, haltenaam” te noemen.
Er waren wel wat mensen voor, maar er was geen duidelijke concensus en heb het toen niet op de transport-mailinlist besproken.