Bus_stop aggiunta di bus=yes

Ciao a tutta la communità (o community)!
Mi hanno mandato qua a chiedere se posso aggiungere bus=yes a tutte le bus_stop, io avevo già fatto:

  • Valle d’Aosta
  • Verbano-Cusio-Ossola
  • Como
  • Lecco
  • Sondrio
  • Biella
  • Vercelli
  • Novara
  • (Città) Torino NW
  • (Provincia) Torino NW

Mi hanno mandato qua per avere una conferma che posso di nuovo a iniziare a taggare le bus stop con bus=yes, magari anche senza un timeout e richieste xtra large!, poi appena finita l’italia vorrei iniziare a mappare altri tag, o fuori dall’italia.

Faccio tutto manualmente con overpass.eu, faccio la query, clicco su run, controllo se funziona, faccio esporta, clicco JOSM, e me la carica su JOSM semplice, faccio CTRL+A, aggiungi, metto come “chiave” bus, metto come “valore” yes, quindi non serve neanche un bot che probabilmente farà più lentamente.

Ciao. Qual è il valore aggiunto di questa modifica? AFAIK bus=yes è richiesto solo se si mappano le fermate dei bus con public_transport=stop_position invece che con highway=bus_stop.

Ho visto che ad alcuna gente su youtube, vanno sulle bus_stop e praticamente gli esce “… has outdated tags” e praticamente poi un menu per tipo “Insert it!”, e vorrei mano mano togliere tutte queste outdated tags in tutto il mondo, non solo in Italia.

Un utente alla prima esperienza su OSM non dovrebbe iniziare con degli edit semiautomatici perché è molto probabile che non abbia la necessaria esperienza.

In particolare, accennare ad alcune persone su youtube che fanno questo tipo di modifica (senza fornire link), che ci sono delle etichette obsolete (senza dire quali e senza fornire i necessari rimandi alla wiki) e che un programma (quale?) fornisce questo tipo di warning (in quali contesti?), non è il massimo per spiegare quello stavi facendo.

4 Likes

TL;DR:

highway=bus_stop (without bus=yes, as that was considered implied) is a legacy approach. public_transport=platform + bus=yes is the new standard. These may be combined for backwards compatibility, but the new standard takes priority. So:

If the stop is represented by a single node:
- Node: highway=bus_stop + public_transport=platform + bus=yes

If the stop is represented by a closed way (area):
- Way: public_transport=platform + bus=yes
- Node (optional): highway=bus_stop (NOT public_transport=platform +/ bus=yes)

The (optional) public_transport=stop_position node on the parent highway=* way on which the vehicle travels gets a bus=yes tag to define the type of public transport vehicle that services that stop, regardless of how the platform is mapped.


Rationale:

The highway=bus_stop node does not need the bus=yes tag, as this is unambiguously implied by the highway=bus_stop tag. However, simple highway=bus_stop nodes are considered a “legacy” approach.

A bus stop that is mapped as a single highway=bus_stop node is often updated with the public_transport=platform tag in line with the PTv2 schema. Because public_transport=platform does not imply a vehicle type, it is suggested to add bus=yes. Yes, this is implied by the highway=bus_stop tag, but the redundancy is not harmful - the old approach (just highway=bus_stop tag on a node) and the new approach when used at the “node” level of detail (public_transport=platform tag + bus=yes tag on a node) can coexist.

When the platform is mapped at the “area” level of detail, the public_transport=platform way is tagged with bus=yes to specify the vehicle type. In this case, the public_transport=platform tag and bus=yes tag should be removed from the highway=bus_stop node, which now essentially serves as a simple role:label for the stop placed at the location of the pole.


Deeper dive:

There is an additional complication, which is that bus=yes is used two different ways: First, as a type of access=* tag for that specific vehicle type; and second, as an indication of which vehicle type serves a stop. Validators will flag warnings when, for example, an area-mapped stop is also tagged with highway=platform, because now it is not entirely clear whether bus=yes means “Busses are allowed to travel here” (bus=yes as an access tag) vs “People wait for busses here” (bus=yes as a specifier tag). :woman_shrugging:

where do you get this from? The “new” standard did not make it, hence the actual standard prevails, highway=bus_stop, and adding bus=yes does not add anything meaningful.

Possibilmente ID o Osmose promuovono questo ‘tagging’ ereditato. A volte vedo un mappatore locale che utilizza commenti CS come ‘automatic tagging’ o simile, ovvero quando ad esempio ID appare con questa linea arancione o gialla che indica che i tag devono essere corretti… aggiornare o ignorare. Osmose ha a che fare con il tagging dei bus, ma per le gap nei percorsi ho disabilitato i loro pin che inondano la mappa."

“bus=yes” is only requested for “public_transport=stop_position”

Deleting the tag “highway=bus_stop” means deleting information from the database which is discouraged even if some YouTubers claim this is a legacy tag. “legacy” is not equal to “deprecated” (aka “to be deleted”, “to be replaced by a better tag”).

Some tools still support or even depend on this “highway=bus_stop”, e.g. “Carto” the standard style does not consider “public_transport=stop_position” and “=platform” but only “highway=bus_stop”.

1 Like

@dieterdreist @ToniE

Ah, maybe I didn’t communicate clearly - I definitely agree that the highway=bus_stop tag should not be removed, and it should be added to any newly-created node for a bus stop.

That’s what I meant to convey by using the words “legacy” (instead of “deprecated”) and “takes priority” (instead of “replaces”) :slight_smile: Thank you both for helping clarify.


I’m not sure on what what you base the idea that the PTv2 standard “didn’t make it” - it was approved in the proposal process and the tagging trends are clear.

(No, the propsal process is not perfect, and yes, this graph is somewhat misleading as it is also containing the other vehicle types and thus over-counting in favor of PTv2)


From Taginfo (link), it seems like ~2/3rds (~3 million cases) of public_transport=platform have bus=yes, but you are correct that the PTv2 proposal and the relevant OSM Wiki pages I can find don’t suggest vehicle type tags on the platform.

(And, for what it’s worth, I expect you have a much, much deeper understanding of public transport tagging than I do, so I would defer to your judgment anyway :smiley:)


Well, let’s check! Both iD and Rapid add all three tags when applying the “Bus Stop” preset to a node:


and add these, for the “Bus Platform” preset on an area:

and their validators prompt to add bus=yes:

Ciao, graziae a tutti per le risposte, mi son arreso a modificare allora bus=yes etc. Vorrei continuare/iniziare a modificare gli oggetti aggiungendo +39 (es: alcuni luoghi hanno il contact:phone=3123456789, quindi diventa contact:phone=+393123456789) solo in italia ovviamente

Va bene come tipo di modifica? oppure non è conforme? Vorrei iniziare da Valle d’Aosta (provincia) fino arrivare a Siracusa (Provincia)

Secondo me rimane valido il consiglio precedente:

Perché non iniziare mappando la tua città? Indirizzi, defibrillatori, idranti, negozi, alberi, edifici, strade ecc.ecc. Ce n’é per tutti i gusti. Conosci StreetComplete? Potrebbe essere un buon punto di partenza. Se hai domande o altro esiste anche un gruppo Telegram italiano.

fontane, fontanelle, fontanili, sorgenti, … :slight_smile:

A riguardo dei numeri telefonici, il tag usuale è “phone”, la variante di “contact:phone” è meno usata e i numeri crescono più lentamente, dal 2010 (15 anni), quindi sarebbe ora di abbandonare questa idea.

https://taghistory.raifer.tech/#/phone/&/contact%3Aphone/

Suggerisco di aggiungere spazi dopo il “+39” e dopo il prefisso, es. “+39 312 3456789”

Grazie per i consigli!

Capito tutto su phone= e sul formato corretto, cercherò di seguire quelle linee guida.

Intanto magari proverò a migliorare qualche altro tag semplice (non legato alla mia zona), tipo created_by=* o brand=Agip Eni, sempre una provincia alla volta, in modo tranquillo e manuale (Overpass, JOSM, Ctrl+A, aggiungi/rimuovi tag).

Se avete altri suggerimenti su tag da sistemare che non richiedano dati locali, li accetto volentieri!

I like using JOSM’s “TODO List” plugin (linky) for this type of thing - it adds a little bit more of a human element when you have to look at each element vs the more mechanical workflow you outlined.