Ik heb mijn controle script uitgevoerd op de regio Alkmaar. De meeste bevindingen betroffen foutjes in de ref:IFOPT tags. Bij een paar routes waar voor een halte zowel een platform lijn als een platform node waren opgenomen heb ik de node verwijderd uit de route relatie. Dit heb ik gedaan omdat het maar een paar keer voor kwam en het best lastig is om een efficiënte controle te schijven die er mee om kan gaan.
De nodes heb ik nog wel even laten staan in afwachting van een consensus.
Morgen draai ik de controle opnieuw over de aanpassingen om te kijken wat ik nog gemist heb.
Ondertussen heb ik al wat ideeën over hoe ik de controles in een Josm plugin zou kunnen inbouwen, zodat iedereen ze kan uitvoeren. Maar dat kost nog wel even tijd.
1 Like
Op een node de highway=bus_stop. Daar waar het RVV L3 bushalte verkeersbord staat. Die probeer ik precies neer te zetten op de goede locatie.
Ik geef de enkele wayline, alleen highway=platform, daar waar de tactile_paving lijn ligt, dit op het gebied van het gebied platform closedway, welke een public_transport=platform krijgt.
Naar mijn inziens is dit correct.
Ik heb in het verleden al eens een schematische schets in dit forum gepost.
Ik vindt het dan niet zo, als ik de closedway area heb ingetekend, dat men ook nog eens op die enkele wayline public_transport=platform zet. Dubbel op.
Public transport platvorm dubbel invoeren? Soms heb ik het idee ze bedoelen eigenlijk, public_transport_platform=yes.
Dat is niet hoe ik het lees in Tag:public_transport=platform - OpenStreetMap Wiki
Ik lees het als de plek waar mensen de bus in- en uitstappen, dus de way (of area) perronrand als er een perronrand is, óf een node de paal als er alleen een paal is.
De paal taggen als platform: Da’s wel een beetje vreemd: alleen een haltepaal, dan is er juist géén platform.
Een paal is ook geen highway 
De taalkunfige betekenis van key- en value-namen op OSM zijn niet altijd logisch. Zo hebben we een hele klasse van highways die unclassified is, en ook privé-wegen zijn highway (terwijl dat in Brits-Engels per definitie geen highways zijn)
Gewoon ter lering ende vermaeck: heb je hier voorbeelden van?
highway is een klasse van wegobjecten, waaronder bushaltes ooit geschaard zijn. Zo vallen onder water= ook allerlei objecten die geen water zijn, maar wel als waterobjecten gezien worden.
Ik zou highway=platform ook heel raar vinden voor een haltepaal. De value van de main key moet aangeven wat het object voorstelt. Af en toe moet je dan een beetje ruimer denken, maar een paal is geen platform en duidt het ook niet aan; bij de paal kan een platform zijn, een instaprandje (wat ik dan nog wel onder platform durf te scharen) of helemaal niks. Wiskundig kan je het ontbreken van een fysiek platform nog onder een “nulplatform” scharen, public_transport=platform + platform=null maar dat gaat me dan weer net ff te ver.
Het gaat dan om het niveau van detail, public_transport=platform op een area is het hoogste detail niveau, dan zet je het niet op die andere. Dat staat er niet met zoveel woorden in het schema, maar is een OSM logische praktijk.
Ik voeg zelf altijd tenminste een haltenode toe (dus de node met highway=bus_stop). Deze voeg ik ook toe aan bushaltes waar deze node ontbreekt.
Voor zover is overal in Nederland de standaard om haltesnodes toe te voegen. De enige haltes waar ze ontbreken, zijn de haltes die IIVQ heeft bewerkt/toegevoegd.
Er zijn meerdere interpretaties van PTv2. De haltenode is geen onderdeel van dat schema, maar wordt vaak gemist en is volgens mij een belangrijke reden voor het gebrek aan acceptatie van dat schema. Door de haltenodes wel toe te voegen en eventueel ook een perron, behoudt je compatibiliteit zonder dat je PTv2 in de weg zit.
1 Like
Voor de node zou je ook kunnen denken aan
highway=bus_stop
in combinatie met
traffic_sign=NL:L3
Dan is er op de halte (way of area) slechts 1x public_transport=platform, samen met alle andere tags.
highway=platform is dan nergens meer nodig
Voor de routerelatie weet ik niet wat ik ervan moet vinden:
alleen stop_positions
of
alleen platforms
of
beide tags in de volgorde stop_1,platform_1,stop_2,platform_2, etc (=wat PTv2 hanteert)
Heeft de combinatie stop,platform in een routerelatie enig nut?
Voor mij is het dubbel op.
1 Like
Volgens mij is er geen gebrek aan acceptatie van PTv2, er is vooral heel v3l chagrijn dat het niet correct gerenderd wordt door osm_carto én Andy Allen’s OV-laag, terwijl de meerderheid van de OV-relaties ptv2 is. Al heel lang.
En ik vindt PTv2 ook niey altijd even logisch, maar dat is wel het meestgebruikte schema. Als je daar allerlei variaties op gaat verzinnen dan kunnen dataconsumers daar niet zo veel mee.
Ik hou me daarom aan de strikte zin van het schema en vind het een beetje overbodig om per haltepaar zeven elementen neer te moeten zetten.
1 Like
Hier belangrijkste correctie die ik gedaan heb:
Lijn 2:
Foutje in ref:IFOPT vor halte Huiswaarderbrug. Aangepast.
Lijn 4:
Foutje in ref:IFOPT voor halte Vlietwaard. Aangepast.
Eindhalte Rietschoot wijkt af van Netex. De eindhalte volgens NeTex
(NL:Q:35110215) is verdwenen in OSM. Vandaag nog wel zichtbaar op Carto
kaart.
Lijn 8:
Haltes Noordwest ziekenhuisgroep stonden nog niet in CHB. Nu wel.
Aangepast.
Lijn 10:
Eindhalte Kerkplein wijkt af van Netex. (NL:Q:35120170)
Lijn 157:
Foutje in ref:IFOPT voor haltes Oude Slotstraat en Gerechtsgebouw.
Aangepast.
Eindhalte NL:Q:34600050 op station Schagen ontbrak. Toegevoegd en route
aangepast.
Volgens Netex stop de bus bij de Pastoor Meijdersstraat aan de andere
kant van de straat. Aangepast.
Diverse ref:IFOPT tags toegevoegd. Deze waren niet meegenomen bij de
vorige actie omdat de haltes toen nog niet aan een route lagen.
Halte Westerwerf en Melis Stokelaan: haltes ontbraken. Alle tags
stonden op de stop_position.
Lijn 163:
ref:IFOPT toegevoegd aan halte Kanaaldijk
Lijn 165:
In OSM is vertrek van perron J. In Netex van perron L en volgens
Connextion en 9292 van perron G. Het laatste lijkt me corect, maar ik
heb nog even niets aangepast.
Lijn 166:
In OSM is vertrek van perron E. In Netex van perron K en volgens
Connextion en 9292 van perron F. Het laatste lijkt me corect, maar ik
heb nog even niets aangepast.
Eindhalte Plein in Bergen is volgens Netex NL:Q:36141120 ipv
NL:Q:36141010
Lijn 129:
Eindhalte tramplein Purmerend aangepast.
1 Like
Om een vriendelijke ‘mapping-war’ te voorkomen lijkt het mij goed om te komen tot een consensus over platform nodes en/of ways in een route.
Op 19 juli heeft IIVQ in changeset 154145063 de laatste platform node (Station) in route “Bus 10: Sint Pancras Kerkplein => Alkmaar Station” verwijderd en een platform way opgenomen.
Op 27 juli heeft A67-A67 in changet 154463917 een nieuwe platform node gemaakt en opgenomen in de route. Daarnaast higway=platform toegevoegd aan de platform way.
Allemaal met goede bedoelingen volgens mij. IIVQ probeert zoveel mogelijk de ptV2 standaard aan te houden, ook al wordt het niet getoond op de Carto kaart en ziet het er niet naar uit dat dat op korte termijn gaat veranderen. A67-A67 hanteert de meer pragmatische insteek door een node met highway=busstop toe te voegen en de highway=platform tag aan de platform way.
Zelf ben ik geen voorstander van mappen voor de renderer, maar af en toe moet je pragmatisch zijn. Voor OSM-leken geldt min of meer “Carto=OSM”. Als daar geen bushaltes, perrons en buslijnen (bij highway=busway speelt het ook), is dat in mijn ogen geen reclame voor OpenStreetmap.
Daarnaast probeer ik controle tools te maken voor de buslijnen. Dat wordt er ook niet eenvoudiger op als we geen goede afspreken hebben en de tagging steeds wijzigt. Op de platform node van station Alkmaar ontbreken nu de ref:IFOPT tags.
Kortom, kunnen we samen op zijn minst in Nederland tot een consensus komen? Misschien met een stemming?
2 Likes
Thx, lijkt mij een goed idee.
Ik ben overigens nog steeds van mening dat bij PTv2 highway=bus_stop vervangen zou moeten worden door public_transport=platform, maar ik zie dat bij de haltes waar ik dat gedaan heb, dat door zó weinig applicaties goed gerenderd wordt, (ook als way), dat ik dat weer terug ga draaien.
Eigenlijk zijn de enige applicaties die een way public_transport=platform (+bus=yes, naam, en ref:IFOPT, maar zonder highway=bus_stop) goed renderen Osmand en Opvnkarte. Alle nu in openstreetmap staande lagen (standard, cycle map, Andy Allan’s Transport Map, tracetrack topo en humanitarian), renderen deze nu niet (cyclosm laadde niet).
Overigens zie ik dat ook Anna Gartlin9 aanpassingen heeft gedaan aan de routes, min of meer terugkerend naar de oude situatie. Ik zal Anna op deze discussie wijzen.
Ik moet vanaf morgen weer werken en heb nogal wat andere klusjes, ik heb nu even niet de tijd zo’n peiling/stemming op te zetten. Jij wel?
1 Like
Herstel, dat ga ik niet doen. Als @A67-A67 terwijl hij van deze discussie weet min of meer al mijn werk ongedaan gaat zitten maken zonder dat hier te melden, dan heb ik er niet zo’n zin in om nog iets te doen.
Dit is lang niet overal het geval, en er is geen duidelijke standaard waar dat op gebaseerd is. Dat is nou mijn hele issue. Het is niet volgens zoals ik PTv2 interpreteeer, waarbij ik moet toegeven dat dat niet een van de betere documentaties op OSM-wiki is.
1 Like
- Wat map je van minder naar meer gedetailleerd.
- Wat neem je in de route op.
Algemeen: highway tagging op lijn (highway=*) en vlak (area:highway=*) naast elkaar behouden, dus ook bij platform tagging.
topic met discussie
Tag je een vlak, dat is meer detail: area:highway=platform + public_transport=platform, dan haal van de highway=platfrom, public_tranport=platform af en ook bij de node highway=busstop (verkeersbord).
Het invoegen in de route kan 1 van deze drie zijn, net naar het gemapt is. public_transport=platform kan niet op alle drie staan. Vandaar dat ik eerder schreef, voor de minst gedetailleerde.
In het verleden heb ik al eens een plaatje gemaakt met een locatie intekening en in eerder topic geplaatst.
De post van toen.
Een reactie:
Route:
Wat daar in komt, ik hou me daar niet zo mee bezig, tags als ref:IFOPT
In mijn beleving is het op 1 van de drie.
Ik kan me wel voorstellen dat ze wisselen in de route komen. Dus het kan wisselend zijn al naar gelang de bushalte meer gedetailleerd is ingetekend.
1 Like
Ik volgde deze discussie met enige interesse, vanaf de zijlijn, nadat ik (na een conflict in een wijzigingenset) een bushalte zag verdwijnen in Zuid-Scharwoude. Ik was benieuwd of daar op het forum discussie over is geweest.
Hoewel ik van het nieuwe taggingschema niet van de hoed en de rand weet, ben ik wel voorstander van het doorbreken van de impasse hieromtrent. Als dingen in principe beter werken, zou ik zeggen: voer de veranderingen door en doe dit ook meteen voor het hele land. Zodra bepaalde systematieken op grotere schaal worden gebruikt, heeft het voor de eindgebruiker ook meer zin om deze actief te gaan gebruiken. Dat is ook waarom we highway=busway zijn gaan gebruiken (al worden die nog altijd weinig weergegeven op kaarten).
Ik ben dus op zich wel voorstander van het voorstel van IIVQ en blij met zijn initiatief. Wel zou ik ervoor pleiten om de haltebordjes ‘in te tekenen’ als highway=bus_stop met de naam van de halte, zodat de haltes wel als zodanig zichtbaar zijn (en helpen op zicht te oriënteren).
Ik kan wel een peiling/stemming opzetten. Wat is dan de voorliggende keuze?
1 Like
Het lijkt mij ook goed om hier eerst een consensus te bereiken over een nieuwe manier van categoriseren alvorens we overgaan tot het verbeteren van de situatie. Dit voorkomt dubbel werk.
1 Like
Dat herstel komt denk ik wel goed, zolang de neuzen de zelfde kant op staan. Volgens mij zitten we het in dit topic nu wel eens over deze punten:
- Minimaal een node met public_transport=platform, highway=bus_stop, name, bus=yes en ref:IFOPT.
- Optioneel ook een way met public_transport=platform, highway=platform, name, bus=yes en ref:IFOPT.
1 Like
Ik ben het dus niet eens met de combinatie van node en way. Het is m.i. een way (of area) als er een echt “perron” is (inmiddels de meerderheid van de haltes in Nederland) en een node alleen in een geval er geen halteperron is zoals hier.
En daarnaast nog een node voor de stop_position.