Ik heb even globaal naar de routes in netwerk Noord-Holland-Noord gekeken en daar zitten relatief veel haltes als lijn (osm-way) in, in plaats van als punt (node). Daar kan mijn controlescript nu nog niet mee om gaan. Staat nog op de to-do lijst.
Dit speelt in de hele randstad. Daarom was ik ook in de andere provincies begonnen. Toevallig viel dat mooi samen met de provincies van de maand.
Als ik het goed heb staat de node met public_transport=platform nog altijd naast de way.
Op de lijn of area staat dan ook nog eens public_transport=platform.
Dat leidt al tot verwarring bij SC gebruikers die twee keer dezelfde vraag krijgen bij Ă©Ă©n halte.
Naar mijn mening zou de lijn of area dus alleen de tag highway=platform moeten krijgen. Zie de halte Europaweg in Woudenberg:
OpenStreetMap
Dat is niet hoe ik PTv2 interpreteer.
Tag:public_transport=platform - OpenStreetMap Wiki en Proposal:Public Transport - OpenStreetMap Wiki hebben het over public_transport=platform dat een node/way/area mag zijn.
Er is vziw geen verplichte [quote=âLeo_Slager, post:102, topic:7050â]
de node met public_transport=platform
[/quote] naast een way.
Ze hebben het verder alleen over een node public_transport=stop_position op de weg (in de way) waar de bus (tram/trein/âŠ) stopt en een relatie die alle haltes samengroepeert.
Er zijn hier in de Nederlandstalige community eerdere mensen die pleiten voor een node op de plek van de haltepaal en/of de instaptegel, naast een way voor het (halte)perron, maar dat lees ik nergens in de documentatie voor PTv2.
Ik heb een tijd heel enthousiast OV bewerkt waarbij ik nieuwe haltes volgens PTv2 gemapt hebt (en alléén PTv2), wat neerkomt op 5 items per dubbele halte: 2 ways pt=platform, 2 nodes pt=stoppos en een relatie pt=stoparea. De laatste tijd heb ik het echter te druk met andere zaken (ik doe een vrij intensieve opleiding).
Groot probleem is dat OSM-carto en de publictransport-laag PTv2 niet rendert: Alleen highway=bus-stop als node of pt=platform als way of evt area, maar dat laatste toont geen naam en alleen zichtbaar op heel lage zoombiveaus. De ĂPNV-laag deed dat wel goed (net als bijv OSMAND), maar die is weer uit de standaardlagen op openstreetnap.org gezet (wegens niet updaten).
Ik ben het eens met IIVQ. Een aparte public_transport=platform node is volgens mij in PTv2 niet verplicht. Dat zou het voor mij wel gemakkelijker maken en misschien zouden de OSM-carto mensen dan ook bereid zijn om public_transport=platform nodes met bus=yes te renderen met een bushalte plaatje. (En een algemeen OV plaatje als er tevens tram=yes oid bij staat).
Ik vind het nog steeds jammer dat bij PTv2 gekozen is voor de term platform. Op een platform/perron kunnen er meerdere haltes zijn. Zowel bij bus, als bij tram en spoor. Daarom zou ik de voorkeur gegeven hebben aan de term quay (of bay, NL baai). Nu lopen de betekenissen van platform als perron en platform als halte door elkaar heen.
2 Likes
OV lijkt simpel maar kan heel complex zijn.
Op bijvoobeeld het busstation van Hilversum hebben we Ă©Ă©n groot eilandperron, met daaraan 4 perronwanden en halteborden (geletterd A t/m D), maar elk perron heeft meerdere buslijnen die daar halteren en het gebeurt ook regelmatig dat 2 lijnen tegelijk aan hetzelfde perron staan, waarbij de achterste iets eerder vertrekt dan de voorste
Dan is het ook nog eens erg anders per land of zelfs regio: in Nederland is een (trein)âperronâ qua nummering overeen met een spoornummer.
Maar in Duitsland vertrekt een trein van bijv âhet derde perron, spoor 6â, omdat aan Ă©Ă©n eilandperron 2 sporen liggen.
Het Nederlandse concept van gedeelde perrons (4, 4a, 4b) is in Frankrijk vrijwel onbekend, een paar maanden geleden is men de eerste test ermee begonnen.
De sporen op Amersfoort worden nogal ingrijpend veranderd. Heeft iemand (@JJJWegdam ?) wellicht een tekening van de nieuwe situatie?
Volgens mij is de situatie in Nederland niet anders dan wat je voor Duitsland beschrijft. Hooguit in het taalgebruik.
Utrecht CS heeft 8 perrons. Die heten bij ProRail en NS ook perron 1 t/m 8. Aan perron 1 grenzen spoor 1 t/m 4. Aan perron 2 spoor 5 en 7 etc. De intercityâs naar Amsterdam Centraal vertrekken van perron 2, spoor 5. In de praktijk wordt het perronnummer echter nooit gebruikt. De reiziger zegt âMijn trein vertrekt van perron 5â, maar dat zal je de omroeper nooit horen zeggen. Die zegt âDe intercity naar Amsterdam Centraal vertrekt van spoor 5â.
In Nederland kennen we daarom volgens mij ook geen âconcept van gedeelde perronsâ. Het zijn in jouw voorbeeld spoor 4, 4a en 4b die aan 1 en het zelfde perron grenzen. Waarom iemand in OSM ooit begonnen is om perrons in stukjes te knippen weet ik ook niet, maar als het aan mij ligt herstellen we dat zo snel mogelijk. Het is in strijd met het osm uitgangspunt One_feature,_one_OSM_element.
Voor spoor 4a en 4b zijn er de stop_position nodes op de rails. Dat dat wat karig is zal in niet ontkennen. Je zou daarom kunnen overwegen om een lijn-element langs het perron toe te voegen met de naam âSpoor 4aâ etc. En wat mij betreft zou je dat lijn-element dan taggen met public_transport=quay, maar dat is dan wel een aanpassing op PTv2.
âGenummerdeâ perrons (met 2 sporen eraan) is puur iets intern voor ProRail als perronbeheerder.
Voor de reiziger hebben we hier alleen âspoor xâ wat in de volksterminologie ook wel perron X heet. Je moet namelijk wachten op een perron. Als je heel perron 4 als Ă©Ă©n perron hebt, en de trein vertrekt van perron 4a, moet een reiziger potentieel nog een eind lopen als 'ie bij perron 4b staat.
In Duitsland wordt daadwerkelijk het vierde perrron gecommuniceerd als spoor 7/8 bedoeld wordt.
Het script kan nu ook omgaan met haltes die als lijn (osm-way) platform in OSM staat.
Ik heb de CHB en NeTeX data vernieuwd. De nieuwe lijn 130 in Noord-Holland Noord staat er al in. De wijziging van lijn 34 nog niet. Dus volgend weekend nog maar eens kijken.
De nieuwe lijn 130 staat als volgt in de NeTex data:
| route_id | sequence | quay_code | name | town |
|---|---|---|---|---|
| CXX:Route:H130-97440-1-1 | 2 | NL:Q:34200140 | Dorperweerth | Den Helder |
| CXX:Route:H130-97440-1-1 | 3 | NL:Q:34202300 | Zwanenbalg | Den Helder |
| CXX:Route:H130-97440-1-1 | 4 | NL:Q:34200040 | Wierbalg | Den Helder |
| CXX:Route:H130-97440-1-1 | 5 | NL:Q:34200020 | Kruiszwin | Den Helder |
| CXX:Route:H130-97440-1-1 | 6 | NL:Q:34201020 | De Slenk | Den Helder |
| CXX:Route:H130-97440-1-1 | 7 | NL:Q:34201040 | Zuiderhaaks | Den Helder |
| CXX:Route:H130-97440-1-1 | 8 | NL:Q:34203010 | Doorzwin | Den Helder |
| CXX:Route:H130-97440-1-1 | 9 | NL:Q:34203030 | Langevliet | Den Helder |
| CXX:Route:H130-97440-1-1 | 10 | NL:Q:34400050 | Vlotbrug | t Zand |
| CXX:Route:H130-97440-1-1 | 13 | NL:Q:34602120 | Hofstraat | Schagen |
| CXX:Route:H130-97440-1-1 | 14 | NL:Q:34600100 | Muggenburg | Schagen |
| CXX:Route:H130-97440-1-1 | 15 | NL:Q:34600050 | Station | Schagen |
| CXX:Route:H130-97440-2-1 | 2 | NL:Q:34601110 | Station | Schagen |
| CXX:Route:H130-97440-2-1 | 3 | NL:Q:34602010 | Oude Slotstraat | Schagen |
| CXX:Route:H130-97440-2-1 | 4 | NL:Q:34602030 | Hofstraat | Schagen |
| CXX:Route:H130-97440-2-1 | 5 | NL:Q:34400050 | Vlotbrug | t Zand |
| CXX:Route:H130-97440-2-1 | 6 | NL:Q:34202100 | Malzwin | Den Helder |
| CXX:Route:H130-97440-2-1 | 7 | NL:Q:34200140 | Dorperweerth | Den Helder |
1 Like
Hoi Gertjan, heb je die OSM-file van de lagen ergens? Dan kan ik de komende week het nieuwe netwerk van NHN bouwen.
Ik heb in Changeset: 154145063 | OpenStreetMap de wijzigingen in de regio Alkmaar gedaan, terwijl ik wachtte tot mijn net geoliede vloer droog zou zijn. Maar ik verwacht niet dat ik de komende dagen aan de regioâs Kop NH en Westfriesland toe kom.
Wat ik grofweg gedaan heb is voor alle nieuwe lijndelen:
- Alle haltes volledig volgens PT_V2: dus per richting een node:public_transport=stop_position op de weg en een way (als er een halteperron was):public_transport=platform met daarop de ref:IFOPT. De losse node pt=platform heb ik in dat geval verwijderd, evenals de highway=bus_stop tag hieruitâ .
- Beide nodes pt=stop_position en ways (of nodes) pt=platform opgenomen in een relatie pt=stop_area
- In alle routes (die nieuw zijn of grotendeels vernieuwd) de node pt=stop_position en way (of node) pt=platform opgenomen
De meeste haltes bestonden al met ref:IFOPT in openstreetmap, in dat geval heb ik dat niet gecontroleerd met het CHB, maar voor de paar nieuwe haltes was het bestand dat ik van @Gertjan_Idema heb gekregen erg waardevol!
â Voor iedereen die gaat zeuren dat zonder highway=bus_stop de halte niet meer rendert op OSM_carto: a) je hebt gelijk, b) een way highway=busstop rendert sowieso al niet met naam (terwijl public_transport=platform wel als een perron rendert)
1 Like
En nog een vraag waar ik niet echt een antwoord op heb:
Er zijn twee manieren om een haltenaam op te nemen:
- A: â«plaatsnaam», «haltenaam»â
- B: â«haltenaam»â
In Openstreetmap Nederland is manier B het meest gebruikelijk, maar ik zie A ook voorkomen en soms ook door elkaar. Ik kan daar niet echt duidelijk concensus in vinden. Wat doen we?
Edit: kennelijk worden zaken in enkele punthaken genegeerd, waarschijnlijk ter voorkoming van XSS.
Is er een mogelijkheid dat we bushaltes tijdelijk ook nog een bus_stop op een punt meegeven, al dan niet opgenomen in het âplatformâ? Ik mis ze (de bushaltes) heel erg, en ik vermoed dat we die straks ook bij 9292 gaan missen.
Ik weet dat dat in principe het probleem van de kaartenaanbieder (renderaar) is, maar we moeten ook niet vergeten dat sommige aanpassingen tijd nemen. Ik denk dat iedereen uiteindelijk zichtbaarheid wil van bushaltes op de kaart. Misschien is een overgangsperiode handig.
Hoe kijkt de @Reisinformatiegroep hier tegenaan?
Tsja. Het hele OV op Openstreetmap is zoân clusterfuck van 2 verschillende schemaâs en iedereen die maar op elkaar wacht⊠Ik heb nu maar eens vrij radicaal besloten allen PT_v2 toe te passen.
Jammer dat haltes niet gerenderd worden op OSM_carto. Dat worden ze wel in de app OSMAND en op OPNVkarte â zie bijv haltepaar Laren/Eemnes P+R dat ik vorige week toegevoegd heb.
Op basis van waarnemingen in OSM verkeer ik in de veronderstelling dat
âname=plaatsnaam,haltenaamâ werd toegevoegd aan de stop_position.
En âname=haltenaamâ aan het platform.
Maar dat is nergens beschreven.
Dat is ook was ook mijn indruk, maar âname=haltenaamâ zonder woonplaats komt vaker voor dan ik dacht. Onder anderen in de regio Utrecht en al sinds 2010. Ik wist niet eens dat PT_v2 al zo lang bestaat.
stop_position met â,â : 12535 keer
stop_postion zonder â,â : 4709 keer
Dit betreft alleen haltes zonder railway=* tag. Bij trein en tram wordt consequent op de stop_positie âname=haltenaamâ gebruikt, dus zonder woonplaats.
âname=plaatsnaam,haltenaamâ op het platform komt incidenteel (97 keer) voor in Nederland. Daar lijkt dus wel consensus en die 97 kunnen wel denk ik wel een keer âcorrigerenâ.
Het buitenland zit niet in mijn database. Ik heb een halte in Antwerpen bekeken en daar werd stop_position niet gebruikt. In Hamburg stond bij een de naam zonder woonplaats op de stop_position.
Als we eenmaal consensus hebben en de ref:IFOPT tags compleet zijn is het niet zo moeilijk om het semi-automatisch te corrigeren.
highway=busstop rendert wel met de naam op zoomlevel 19:
In my area around Munich and maybe elsewhere youâll find for instance, and mostly in big cities
- name=âstop nameâ
- ref_name=âcity name, stop nameâ
the http://www.openptmap.org (switched off, no longer maintained?) used âref_nameâ (if set) for a query to https://bahn.de because name=âstop nameâ is often ambiguous
highway=busstop rendert wel met de naam op zoomlevel 19:
Niet als way, alleen als node. Dus daarom heb ik van alle ways de perron-ways highway=bus_stop eraf gehaald, en op de nodes het (voorlopig) laten stan.
Voor wat betreft het «plaatsnaam», «haltenaam» op de stop_position: ik vind het een rare keuze, ik zou het liever op de relatie stop_area doen. Liever nog een apart attribuut, maar ja, dat moet dan wel OSM-wijd geaccepteerd worden. Maar als de meerderheid hier «plaatsnaam», «haltenaam» op de stop_position een goede keus vind dan ga ik me daar zeker aan houden. Liever dat er iets van een systeem in zit.
Ik heb trouwens ook de wijzigingen lijnen in AML (en GVB) vanwege de komst van de Amsteltram bijgewerkt op OSM. Vooral het busstation Uithoorn was even een klusje.
Ik ben hierbij iets minder aggressief geweest als in NHN, dus ik heb bij al bestaande bushaltes de node met highway=bus_stop/public_transport=platform niet verwijderd (alleen bij 3 haltes wel omdat OSM daar een conflict gaf bij het uploaden ⊠)