Algemeen Openbaar Vervoer (NL)-topic

Hoi, ik heb een drukke week gehad, geen tijd om te reageren, dus in één keer op alles.

Er is een verschil tussen andermans werk van 5 jaar geleden veranderen omdat er inmiddels andere inzichten zijn, en iemands werk van een paar dagen geleden, waarvan je weet dat er een lopende discussie over is.
Ik reageerde een beetje gepikeerd (en heb geen zin meer om die highway=bus_stops terug te zetten waar ik ze verwijderd heb) door dat door jouw (en andermans’) bewerkingen dat héél veel werk zou zijn, terwijl als er niemand iets aan gedaan had het één search obv mijn .osm-bestand was geweest. Maar ik begrijp dat je het niet kwaad bedoeld hebt. Wat mij betreft zand erover, de gepikeerde toon was niet zo naar jou bedoeld.

Dat is dus niet zo, zie reactie hierboven.

Dat is zeker waar. Ik merk dat veel mensen op de Nederlandse OSM heel erg verkeersbord-georiënteerd zijn, iets waar ik helemaal niets mee heb. Ik zal nooit een verkeersbord mappen, maar ik map de gevolgen op de weg, bijv. maxspeed.
Ik had er niet bij stil gestaan dat mensen daarom het haltebord zo belangrijk vinden. Dat levert wel problemen op, gezien dit bij veel haltes veel minder en soms helemaal niet meer toegepast wordt, gezien de rechterlijke uitspraak dat alleen het “busicoon” voldoende is om iets een bushalte te maken. In bijv. Amsterdam ontbreekt het klassieke haltebord bij alle moderne haltes waar een abri is, en is er dus (als je micromapt) geen halte"paal" meer.

Afhankelijk van hoe strikt je aan PTv2 vasthoudt, nog zeker niet. Veruit de meeste halteparen hebben nog geen stop_position en geen stop_area-relatie, maar ik kom ook nog af en toe een highway=bus_stop (of zelfs pt=platform) óp de weg of juist stop_position náást de weg tegen.

Als we daartoe besluiten: prima, al ligt die haltenode nu vaak in de platform-way, en als je die van elkaar loskoppelt heb je sowieso al een breuk in je geschiedenis.

Mijns insziens is een public_transport=platform de verhoogde stoeprand (een way dus), tenzij je het echt hebt over een speciaal voor het OV gemaakt deel, dus bijv Zuidtangent (Noord-Holland) - Wikipedia of Google Maps , dan zou je er voor kunnen kiezen om er een area van te maken (wat ik wel in het eerste en niet in het laatste geval zou doen).
Maar bij een groot eilandperron als bijvoorbeld Den Oever zou ik alleen de stoepranden van de individuele tot public_transport=platform maken, waarbij het hele eiland dan een highway=pedestrian+area=yes wordt. En bij een visgraatperron als Alkmaar hetzelfde, omdat dan duidelijker is aan welke kant van het eilandje je moet instappen.
Sterker nog, nu ik erover nadenk zou dat ook voor spoorplatforms logischer zijn om alleen een way (de perronrand langs het spoor) te doen, zodat je niet de arbitraire splitsing halverwege het perron tussen spoor 1 en 2 krijgt.

en

Volgens is de meerderheid het toch redelijk eens:
Per halte een:

  • node highway=bus_stiop op de plek van de haltepaal (of bij afwezigheid: op de abri), voor de renderer, zonder public_transport=platform (tenzij het een halte is die alleen bestaat uit een paal), met verder als enige tags de naam en evt de ref= en
  • way public_transport=platform op de stoeprand of evt area op het hele vlak van de halte, met hieraan alle informatie van de halte zoals ref=ifopt
  • node public_transport=stop_position (met verder alleen bus=yes en name=x en evt bus_bay=left/right) op de weg, op de plek waar de bus stopt.

Laten we dan in de routerelatie alle 3 elementen opnemen, voor nu.
Volgens mij hebben we dan als netjes compromis dat we ons helemaal houden we ons dan aan PT_v2, en toegevoegd een node highway=bus_stop hebben voor de renderer

Als de meerderheid het daarmee eens is, zal ik dan een Nederlandstalig wiki-artikel schrijven zodat we deze discussie vastleggen?

Wat losse eindjes, die los staan van de hoofddiscussie:

Wat mij betreft is dan de route en de halte niet helemaal goed getagd, maar in dat geval zou ik het dubbeltaggen als public_transport=platform en highway=footway. Heb je hier voorbeelden van?

Wat mij betreft halen we highway=platform helemaal weg — volgens de wiki is public_tranport=platform het populairdere alternatief.

=====

Dan nog even vwb de naam:

Dit staat inderdaad nergens beschreven, maar ik vind het wel zo duidelijk om het zo te doen; dat kan Gertjan idd makkelijk

Is vooral handig voor een lijn als 320, die 5 haltes P+R heeft, waarvan 2x 2 achter elkaar (al zit daar de naam van de plaats wel in de haltenaam), dus Muiden, P+R terrein / Naarden, Gooimeer P+R / Huizen, Crailo P+R / Blaricum, Blaricum P+R / Eemnes, Eemnes/Laren P+R

Edit: per halte een node een highway=bus_stop, thx allroads!

1 Like

Hier bedoel je denk ik highway=bus_stop.

De highway=platform teken ik op een lijn, daar waar tactile_paving ligt.
De public_transport=platform teken ik in als area. Omdat dat het meeste detail geeft.
En sinds kort overweeg ik de verhoogde rand, verbinding van twee nodes van public_transport=platform area te taggen met kerb.

highway=platform zou ik altijd blijven mappen op een lijn.

1 Like

Thx voor de opmerkzaamheid: foutje is gecorrigeerd.

Tsja, volgens de blinden en slechtzienden mag je op een tactile_paving juist niet wachten!

(Grappige anekdote: Ik heb eens twee blinden erg boos op elkaar zien worden omdat de ander op de blindegeleidelijn stond. Het duurde even voordat ze inzagen (pun intended) dat ze allebei blind waren.)

Ik snap het nut van highway=platform nog niet helemaal, naast de public_transport=platform.
En ik wist niet eens dat de tag barrier=kerb bestond. Ik vind het micromappen maar ieder z’n ding, al is het natuurlijk wel een specifieke vorm van kerb. Bij de meeste haltes is het hier niet de bedoeling om af te stappen, de weg op.

kerb is naar mijn idee, geen micromapping. Meer mappen voor oa mensen met beperking. Daarvoor kan het belangrijk zijn of je stoep op of af kan komen. Bij een rolstoel lukt dat niet zo makkelijk met een rechte stoeprand.
En bijv. hier in Deventer is een fietspad dat met een rechte stoeprand eindigt op de dwarsweg. Dan toch maar met kerb aangeven, mogelijk komt er ooit een routeplanner, die er rekening mee houdt.

Ik bedoel: de bushalte mappen als barrier=kerb vind ik micromapping. Maar het maakt mij verder niet uit. Ik zal het niet weghalen.

kerb:height=0.18 , cm en de aansluiting op treeplanken.

1 Like

Dat heeft niet mijn voorkeur.
In de routerelatie heeft het 3e element geen functie.
Volgens PTv2 dus alleen het platform en de stop_position.

1 Like

Ik ben het een paar keer tegenkomen, maar ik weet niet meer waar. Ik ben ook bang dat ik het niet heemaal conform de huidige inzichten opgelost heb. Mogelijk heb ik een footway getagd, over het perron (area) heen of bijgetagd op het perron (way), of ik heb me helemaal niets aangetrokken van PT.

Ik ben niet goed genoeg in overpass-turbo om het even op te vragen… en goeie kans dat anderen het inmiddels veranderd hebben.

1 Like

Overpass loopt vast als ik het voor heel Nederland opvraag. In mij database vind ik 198 ways met plublic_transport=platform en highway=footway. Onder anderen in Rijswijk:

Ik heb weer een stapje verder met mijn controles. Vooral de presentatie van de bevindingen heb ik geprobeerd te verbeteren. Het is nog wel in het Engels omdat ik nog steeds moet uitzoeken hoe vertalingen in Josm werken. Iemand ervaring daar mee?

Hier onder een paar voorbeelden van bevindingen:


De melding over de kleurcode is net nieuw. Daar komt straks natuurlijk bij welke kleur het moet zijn.

1 Like

Geweldig dat je dit doet!

Die melding over lijn 10 is een lastige. Vanwege een onhebbelijkheid van onze boordcomputers is het in sommige situaties nodig dat de eindhalte van een lijn een andere haltecode nodig heeft dan de beginhalte, ook al os het fysiek dezelfde halte en zou dat volgens de Nederlandse implementatiehandleiding (ik weet niet of die openbaar toegankelijk zijn) één halte moeten zijn (één halte=één code, met de uitzondering van “dijkhaltes”).

Een heel andere vraag: Hoe gaan we om met lijnen die niet altijd van dezelfde halte vertrekken?
De Amsterdamse metrolijn 53 vertrekt op Gaasperplas om-en-om van spoor 1 of 2, en komt om-en-om aan op spoor 1 of 2 op CS, terwijl de tussenliggende stations steeds hetzelfde perron (zeg 1) gebruiken. Je zou eigenlijk 4 routevarianten moeten maken maar dat is een beetje onzin.
Op busstation Bijlmer ArenA gebeurt hetzelfde met lijn 300: er zijn daar 2 perrons voor fysieke halte A (en die 2 haltes zijn in praktijk ook nog eens uitstaphalte van alle andere lijnen)

Lijn 594 heb ik even aangepast vwb route en haltes.

Die melding over lijn 10 is een lastige. Vanwege een onhebbelijkheid van onze boordcomputers is het in sommige situaties nodig dat de eindhalte van een lijn een andere haltecode nodig heeft dan de beginhalte.

Voor dit soort zaken moeten we waarschijnlijk een of meer lijstjes met uitzonderingen maken, om te voorkomen dat lijn continu in het foutenlijstje komt. Zgn ‘False positives’. Er zit al iets degelijks voor enkele virtuele haltes die nodig zijn voor de OV maatschappij, maar waar geen fysieke halte is.

De Amsterdamse metrolijn 53 vertrekt op Gaasperplas om-en-om van spoor 1 of 2, en komt om-en-om aan op spoor 1 of 2 op CS

Nog niet gecontroleerd, maar waarschijnlijk zitten in NeTex wel alle routevarianten. Die wil je niet allemaal in OSM, dus ook hier is een lijstje met uitzonderingen wenselijk.

Top! Ik had hem bewust zelf niet aangepast om te kijken of iemand het op zou pakken, maar zo snel had ik niet verwacht :slight_smile:

Brengt gelijk de vraag met zich welke wijzigingen in deze concessie zijn nog niet verwerkt ?
Dat zijn 55 lijnen nog te controleren !

Uit nieuwsgierigheid: hoe doe je dit nou op bushaltes/busstations met meerdere perrons en met last-minute perrontoekenning via een elektronisch vertrekbord?

1 Like

Dit zij de statistieken voor netwerk Twente, met jouw aanpassing voor lijn 594 nog niet verwerkt:

9 lijnen komen voor 100% overeen met det Netex data. Op dit moment kan ik nog niet eenvoudig voor de ander lijnen een overzichtje maken met de bevindingen. Omdat ik de losse puzzelstukjes al wel heb, moet dat niet al te moeilijk te maken zijn. Ik denk daarbij aan 1 PDF document per network. Dat zal in het begin nog even een groot bestand zijn, maar na een inhaalslagje zal het hopelijk snel kleiner worden.

Met dynamische/last-minute perontoekenning kan ik niets.
Bij meerdere perrons (1 punt en 1 lijn/vlak) neem ik deze samen en behandel ze als een geheel.