[Tagging] Feature Proposal - RFC - PTv2 Improvements wrt Rapid Transit

Ilya Zverev ilya at zverev.info
Sun Dec 10 12:11:25 UTC 2017


Hi Muramoto-san,

>>Subway Entrances and Exits
> If I can walk into subway station through an underground shopping mall,
> where could be a subway entrance?

Most likely on the doors of a shopping mall. This is out of scope for 
the proposal and should be described on the "railway=subway_entrance" page.

>>Restricting Stop Areas
> I think `public_transport=*` is used here, not `railway=*`.

While there is a schema that describes public_transport=* tags for 
everything, I've yet to see a rapid transit system that is mapped 
without their legacy counterparts, or a renderer / router that support 
these without hints.

>>Mandatory Route Tags
> Why `ref`, `colour` and `network` are mandatory?
> I think these are optional tag. There could be a route without these
> information.
> At least `network` is too vague to translate into Japanese lines.

You can create a route without any tags except "type=route + 
route=subway", but why stop at that, when you can add extra useful 
information in a few moments? I have added a reasoning for each tag to 
the wiki page.

Hi Martin,

> subway entrances and elevators: you suggest to add both tags to the same object, but subway entrances are defined as nodes only while elevators can be mapped as well with a way.

Well, you could add a subway_entrance node on a contour in that case. In 
practice, I've yet to see an subway entrance elevator mapped not as a 
node, and I've seen all the metro systems in Germany, Austria, Helsinki 
and some other cities that allow entering a station via elevators.

> linking stop positions and platforms via relation with a station: if the station is mapped as an area, this shouldn’t be needed, as there’s already a spatial link

Oh come on, we're talking about underground stations. A spatial link 
will get you all the bus platforms overground.

Also, imposing using a spatial link for a distributed number of objects 
instead of a small relation is not thinking about data consumers. Which 
PT mappers have been doing for 9 years now, but should it stop somewhere?

> “restricting stop_area”: first you say only the following objects and present a list, in the first paragraph below, you also name additional optional objects (turnstiles, ticket purchase), this is not clear.

I agree, the criteria is not clear. I have added some explanations.

> why are tracks optional for route relations? Isn’t that in contradiction with the generic route relation definition? Shouldn’t this become a different type of relation if it isn’t about an explicit route anymore?

In my opinion, tracks should be optional for all public transport route 
relations, but let's start with rapid transit routes, when most of the 
time you don't see tracks, because they are underground. Mapping what 
you don't see and cannot check on the ground is questionable. Requiring 
to do that mapping from people who just want to mark a route with stops 
is plain bad.

Regarding the first responses to the proposal, I was even angry for a 
few minutes. I say "please discuss at the wiki" — there are no comments 
yet. I spend few more hours to polish a proposal — nobody cares. And had 
I not been a senseless drone, I'd be angry still, writing disappointed 
posts in every media about the community. Because starting your replies 
on a positive tone should be simple and would frame responses much more 
polite and caring. For now it looks like everyone here wants to maintain 
a status quo, because... I don't know why, 50 of 60 rapid transit 
networks in Europe already adheres to the proposed changes.

Thanks,
Ilya



More information about the Tagging mailing list