[Tagging] Feature Proposal - RFC - Public Transport v3
joseph.eisenberg at gmail.com
Sun Mar 8 04:17:32 UTC 2020
> 2. People with a preference for the old tags see that as an excuse to keep using them
It's openstreetmap, "any tags you like" etc. - you have to reach local
consensus to change tags. Voting on a proposal does not avoid this
step, you will have to convince people that the new way is better.
I personally agree that it's better to just map the bus stops or train
stations in many cases, just not in every case.
> 4. People who want to use the new tags have to use _both_ sets of tags
That was a problem with the introduction of the public_transport=*
tags because they often partially duplicated existing tags, and never
become more popular.
But you proposal isn't introducing new tags, is it? I don't think this
will be a problem now.
> the manifestation of #4 here would be that ways would be included, whereas I'm trying to avoid mappers dealing with them at al
Yes, that's a good point, and I certainly support changing the
documentation to let mappers know that including just nodes is totally
fine and sufficient.
In fact, if this method of mapping is already somewhat common, we can
update the wiki pages right now, to mention that it is an option.
Then it's a matter of asking editors to make it easy to add the route
relations with just the nodes, if this isn't already the case.
If it's not really done yet it is still a good idea to go through the
whole proposal process, but I think it will have more success to focus
on adding this simpler and easier option, rather than removing other,
more complicated options.
- Joseph Eisenberg
On 3/8/20, John Doe <music.kashish at gmail.com> wrote:
> 08-Mar-2020 03:56:45 Joseph Eisenberg :
>> > routes without fixed stops can easily be represented using only via
>> > points and stop positions
>> I think you mean "bus stops" (or railway platforms), not
>> "public_transport=stop_position", since those nodes are usually
>> unnecessary, and are not added by most mappers for bus routes. Routing
>> apps can easily calculate the location where the bus stops based on
>> the location of the "highway=bus_stop" next to the way.
>> Creating "via points" seems more cumbersome than adding the highway
>> ways to the relation when the route is "hail-and-ride", especially
>> since a via point would not represent a real-world feature in that
> For such relations, I already have to create stop positions at the start and
> end of the route. Indeed, the PT Assistant validator pesters me to 🙂 From
> there, it's just a question of adding a few via points - still less work and
> more maintainable than adding all the ways of the route.
>> I understand why user Stereo would like a clean, simple solution. But
>> realistically, both mapping methods are going to co-exist (this is
>> already the case).
>> It is most likely to be accepted if the proposal does not attempt to
>> call anything "deprecated" or force anyone to use the new mapping
> That would be tempting, because it would mean a lot less work for us in the
> short term. However, I'm afraid of ending up like PTv2 -
> 1. It 'does not deprecate the old tags', use of the new tags is 'recommended
> but not mandatory'...whatever that means.
> 2. People with a preference for the old tags see that as an excuse to keep
> using them
> 3. Consumers see that as an excuse to not support the new schema, even after
> 8 years of people requesting it -
> 4. People who want to use the new tags have to use _both_ sets of tags 🤦♀️
> 5. Both sets of tags have to be documented, making the documentation more
> verbose than it might be.
> They should coexist...for a transitional phase. But it has to be just that -
> a _transition_, not a permanent inconsistent mess.
> Note that the manifestation of #4 here would be that ways would be included,
> whereas I'm trying to avoid mappers dealing with them at all - to deal with
> them would mean losing important maintainability benefits.
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging