Buslijnen, halteinfo, OV-routes - overzicht en discussie

Daar sluit ik mij graag bij aan.

Of de keuze van


Waar ik dus niet schipper is dat ik de node plaats, waar het haltebord staat, dat kan ook naast het platform zijn. Waar het werkelijk staat. Dan hoort het daar ook te staan.

Node naast het platform, is het dan terecht dat daar dan ook public_transport=platform op komt?

Net zoals met bench=yes, wil je eigenlijk zeggen er is ergens een bench aanwezig, terwijl je ergens anders de amenity=bench inteken.
Eigenlijk wil je dan zeggen public_transport_platform=yes

Laatst heb ik in Tilburg bijna alle bushaltes als platform geĂŻmporteerd. In ieder geval als ze een beetje in de BGT opgenomen zijn. Ik vraag me alleen nog af of ik ze wel juist getagd heb.

Ik heb alle platformen deze tags gegeven:


public_transport=platform
highway=platform
area=yes
name=naam van bushalte

Verder heb ik gezien dat ze vaak ook onderdeel kunnen zijn van de halterelatie. Hoe zit het eigenlijk daarmee?

Dat lijkt mij helemaal correct.

Het aanmaken van een halterelatie houdt ik voor volkomen zinloos.
Het is nergens voor nodig en ook de wiki geeft niet aan wat het doel of het nut of de functie daar van is.

Moet daar niet nog een tag bij om duidelijk te maken dat om een bushalte gaat?

bus=yes

Heb die tag er nu bij gezet. :slight_smile:

Moet eerlijk zeggen dat hoe meer ik op de wiki kijk, des te minder ik de OV tagging begrijp. Ben heel blij dat je het gewoon hier op het forum kan vragen.

Wanneer er wel of geen platform is. Staat er altijd een node, de highway=bus_stop (op of naast platform), die ook een naam heeft.
Hoort dan de naam op beide, platform en node. Lijkt mij dat 1 keer de naam voldoende is.

Zo zag ik dat ook een platform, bijvoorbeeld een A B C etc heeft, dan lijkt het mij dat deze naam A op het platform hoort. Of moet dat met een ref?

In vrijwel alle gevallen tref ik 2 nodes aan:
stop_position en het platform.
Beide dragen de naam van de halte.
Soms heeft de stop_position plaatsnaam+haltenaam.

Als er een way of area wordt toegevoegd, ontbreekt vrijwel altijd de naam van de halte.
Daarom is het ook zinloos om de way of area toe te voegen aan de routerelatie.

Dit is maar 1 van de vele mogelijke interpretaties van PTv2.

Het lijkt mij dat de stop en platform dezélfde naam moeten krijgen.
Ik heb wel voorstellen gezien om de “plaatsnaam, haltenaam” in een alt_name te zetten, ik zou daar zelf het liefst placename voor gebruiken (maar heb dat nog niet gedaan). Zie ook mijn oorspronkelijke post.

Je schrijft “lijkt me logisch en overbodig”, dat is toch een tegenstrijdigheid?
Ik vind het wel handig, zo kan je bij een eilandplatform zien aan welke kant je moet staan, ook als de weg zich om het platform heen draait. Ik voeg ze dan ook altijd beiden toe, maar volgens PT_V2 is het niet verplicht.

Ik snap niet waar het idee (van meerderen hier en elders) vandaan komt om voor het platform per sé een node moet komen, als er ook al een platform way of area is.
Even ter herhaling: de platform-tag geeft volgens PT_v2 aan plaatsen waar passagiers op het openbaar vervoer wachten. Dat is niet per sé op de plek van het haltebord.

Zoals Allroads eerder schreef zou je het haltebord wel kunnen taggen met het juiste verkeersbord, traffic_sign=NL:L3b.

Het “schipperen tussen wat zou moeten en gerenderd wordt”. Tsja, dit blijft een lastige, voor allerlei andere zaken zeggen we “don’t tag for the renderer” maar hier dan weer niet
 Feit is dat OSM_Carto het public_transport=platform (zonder highway=bus_stop) niet goed rendert Al zijn er wel mensen langzaam maar zeker mee bezig. Anderer renderers gaan er echter prima mee om (zoals OSMand, Openbusmap en zelfs in beperkte mate de Transport-layer van Openstreetmap.org).

de note waar het haltebord staat is prima. Maar als je gaat micromappen is dat niet het platform. Wel het traffic_sign.

Ik denk dat als je gaat micromappen dat je al die zaken los kan zetten (en dan evt in de halterelatie opnemen), maar je kan ze ook als tags meegeven aan de platform-node/way/area.

Zie public_transport=stop_area op de wiki voor uitleg. Ik zie het een aantal grote voordelen hebben:

  1. Je zou eigenlijk zo veel mogelijk informatie van de onderliggende nodes/ways/areas kunnen “offloaden” naar deze stop_area (dus de naam etc)
  2. Bij haltes die verder uiteen liggen weet je gelijk dat er een logische relatie is. Denk aan kruisende wegen met op elke weg een halte(paar), of bij een groot station , zelfs met een hierarchie erin (dat mag van PT_v2). In feite kan dit vergeleken worden met de IFOPT:S-tags (al heeft die nog een verschil tussen bus- en treinhaltes, tram en metro weet ik niet)
  3. Bijeenbrengen van alle “overige” informatie, zoals shelters, prullenbakken, entrees (van metrohaltes) etc die niet in een routerelatie hoort.

Ik voeg bij de platform-area altijd de naam toe (maar dat is voor mij dan ook de Ă©nige platform, ik plaats er geen platform-node bij).

Voor verschillende platforms die met letters zijn aangegeven gebruik ik de ref-tag.

Dat is natuurlijk een enorme drogreden: Omdat de naam er niet bij staat, hoort die niet in de routerelatie:D. Voeg de naam dan toe!:wink:

Anyway, hoe moeten we nu verder om dit uniform te krijgen. Moeten we met de NL-community een stemming hebben over verscheidene zaken? Moeten we internationaal te rade gaan?

  1. Ik heb je bestand gekregen, heel gaaf.
    Als ik het in JOSM open (in een aparte laag), is er dan een makkelijke manier om de gegevens “door te drukken” naar de onderliggende platform-nodes/ways/areas?

2.Voor iedereen die er mee werkt, let er op dat er een groot aantal haltes in staan die al niet meer door een buslijn aangedaan worden. Soms is daar nog wel “halteinfrastructuur” (verhoogde stoeprand) aanwezig, maar het fysieke haltebord wordt meestal door de busmaatschappij (die is eigenaar van het bord) vrij snel weggehaald.

De enige manier om momenteel op de standaard kaart ergens een busicoontje te krijgen, is highway=bus_stop te gebruiken. Dit is helaas iets waar al jaren over gesproken wordt, maar nog steeds een feit.

Om een platform op de standaard kaart (grijs) zichtbaar te maken (way of area) moet highway=platform gebruikt worden (of bij een treinperron railway=platform); enkel public_transport=platform werkt niet.

Aangezien je slechts Ă©Ă©n keer highway=xxxx tegelijk kunt gebruiken, is en blijft het voorlopig schipperen. Vandaar dat ik in de praktijk naast platforms als way of area daarbij nog steeds aparte nodes als halte gebruik, en alleen die in een route-relatie opneem.

Verder:
Het haltebestand van NDOV bevat inderdaad niet meer gebruikte haltes, maar kent ook vaak nieuwere haltes nog niet, en het ontbreekt soms aan precisie. Zij zijn afhankelijk van informatie van gemeentes, provincies, beheerders van OV-netwerken. Ik heb in de praktijk gemerkt dat ze het erg op prijs stellen bericht te krijgen over aanvullingen/onjuistheden (Meldpunt@crow-ndov.nl).

Aaaah, nu snap ik het. Taggen voor de renderer, al is dit natuurlijk wel “geldig” (PT_v1 is niet officieel “deprecated”) en dus te begrijpen.

Maar dan is het onlogisch om je routerelatie die je helemaal PT_v2 opbouwt, alsnog de PT_v1 highway=bus_stop mee te nemen - ik zou zeggen zet dan de way/area public_transport=platform in de routerelatie en zet in de halterelatie beiden.

Ter info (ik werk bij Connexxion): De vervoerders zijn verantwoordelijk voor het doorgeven van de juiste posities. Bij Connexxion is onze boordapparatuur ook afhankelijk van de juiste positie, daarom zal die i.h.a. redelijk kloppen. Bij andere maatschappijen is dat veel minder het geval.
Overige info (is er een bankje, is het voor blinden toegankelijk, in welke windrichting ligt het perron) is eenmalig grootschalig opgepakt door alle vervoerders; ik weet niet hoe het onderhoud daarvan gaat.

Dat zou een geweldige stap voorwaarts zijn.
De stop_position niet meer in de routerelatie opnemen
en alleen de node, way of area met public_transport=platform opnemen in de routerelatie.
en voor de renderer nog highway=bus_stop toevoegen aan een node van de way of area.

Ik ben normaal geen voorstander van ‘taggen voor de renderer’, maar het lijkt me toch wel zinvol dat een bushalte ook duidelijk zichtbaar is op de standaard kaart.

Verder: niet alleen halteposities in het haltebestand van NDOV kloppen soms niet, ook de routes die vervoerders aangeven in hun KV1 bestanden op NDOV-site lopen vaak achter bij de werkelijkheid. Zo heeft Connexxion de nieuwe situatie van de N331 bij Hasselt (toch al enige tijd realiteit) nog niet verwerkt. Merk op: dit is niet bedoeld als kritiek op Ă©Ă©n bepaalde vervoerder; ik kom dit tegen bij veel situaties waar (min of meer) recentelijk wijzigingen in wegen zijn gerealiseerd.

+1

Gezien de reactie van Leo zal ik dan ook stoppen met het toevoegen van de stop_position als ik routerelaties in OSM aanpas.

Hier gaat het dan fout, die paal/bord, staat waar hij staat, dat is veelal niet de hierboven omschreven plaats.
Je doet dit niet voor de render, maar omdat het zo is in Nederland.
Gevolg is dat andere deze node gaan loskoppelen en op zijn plaats zetten.

De stop_position is belangrijker dan je in eerste instantie zou denken en is niet voor niets opgenomen in PT_v2. Bijvoorbeeld om softwarematig de volgorde van de haltes in een route te kunnen controleren, of zelfs automatisch de haltes in de goede volgorde te kunnen. Zonder stop_position wordt dit een stuk bewerkelijker en daardoor trager. Dit omdat je eerst geografisch moet uitzoeken welke stukjes weg uit een route in de buurt van een halte liggen. De stop_positions zijn rechtstreeks verbonden met de stukjes weg uit de route. Met stop_positions is het dus een stuk simpeler om softwarematig de route van het beginpunt tot het eindpunt door te lopen en te kijken of de volgorde waarin je stops tegen komt overeen komt met de volgorde in de route relatie.
Als je haltes in de juiste volgorde staan en de REF:IFOPT codes van de haltes overeenkomen met de codes in een NDOV route bestand, kan er redelijk op vertrouwen dat je route klopt en actueel is.

  1. Ik ben hier mee bezig geweest, maar het is nog best een uitdaging. Vooral omdat het niet eenvoudig te bepalen is welke NDOV halte bij welke OSM halte hoort. De NDOV lokatie is te onbetrouwbaar. De windrichting klopt wel vaak ongeveer, maar dan moet je nog de windrichting van de osm halte bepalen. Niet onmogelijk, maar best wat uitzoekwerk.
  2. Mij gaat het er in eerste instantie om, om de REF:IFOPT tags toe te voegen aan bestaande haltes in osm. Als je die hebt, kan je osm routes vergelijken met NDOV routes en kom je er vanzelf achter of er haltes in OSM ontbreken, of in geen enkele route voor komen.

Ik zie steeds een soort ‘primaire node’ waarop in PTv1 de highway=bus_stop op stond en een ‘secundaire node’. In PTv2 is dan de primaire node het platform en de secundaire node de stop_position. De primaire node krijgt voor compatibiliteit nog steeds de highway=bus_stop en hier worden ook de belangrijke haltetags, zoals ref:ifopt aan toegevoegd. Bij het idee om het platform alleen als area te taggen, zit je dus met het probleem waar je die haltetags laat.

Bij trams werken de primaire en secundaire node juist andersom. Daar is de primaire node de stop_position i.p.v. het platform en heeft deze node de railway=tram_stop. Dit lijkt me een onhandig verschil. Waarom zou je dit bij trams omdraaien t.o.v. bussen?

Verder valt me ook de ‘name=plaatsnaam, haltenaam’ vs ‘name=haltenaam’ op. Ik zag dat SintE7 dat in zijn grote opschoonactie (goed werk overigens :)) zo toepast:

  • platform: name=haltenaam (‘primaire node’, die wordt gerenderd)
  • stop_position: name=plaatsnaam, haltenaam (‘secundaire node’)
    Op deze manier zie je dus alleen de haltenaam op de standaardkaart. Ik heb dat overgenomen, maar ik begin er nu toch over te twijfelen. Ten eerste hebben zo de platform en stop_position zo verschillende namen en zijn ze lastig automatisch als onderdeel van dezelfde halte te zien. Ten tweede is dit niet toepasbaar op tramhaltes, waar juist de stop_position de primaire node is. De plaatsnaam, haltenaam die niet overeenkomt met het haltebord, wordt dan gerenderd. De rendering van de tramhaltes is dan ook niet consistent met die van de bushaltes.

Een taggingschema placename=plaatsnaam en name=haltenaam voor zowel platform als stop_position lijkt me een betere tagging. Dat placename=* niet in PTv2 voorkomt, hoeft geen probleem te zijn. We kunnen afspreken dat we de placename-tag op deze manier in Nederland gebruiken.

Wat eventueel ook kan is de stop_position geen naam meer mee te geven en dan verder zoals hierboven genoemd. Dan ben je meteen ook af, van de ongelijkheid tussen haltenaam en stop_position.