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

[Michael Reichert]

Hi Ilya,

Am 2017-12-09 um 23:18 schrieb Ilya Zverev:
> You may remember the "Metro Mapping" proposal, which was too complex for
> some, and tried to explain the rapid transit mapping in its entirety.
> That was not a regular proposal, which put off a lot of people. So I am
> doing the second take, now only with parts that actually change things.
> 
> Please read and review the "PTv2 Improvements" proposal:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/PTv2_Improvements_wrt_Rapid_Transit
> 
> 
> Eight short points, no pictures. I really hope there will be no "Too
> difficult for most mappers" comments when voting. Most of the points
> were discussed previously, but I am of course ready to answer questions.
> Preferably on the wiki Talk page.
I read your proposal. It is much easier to read. Nevertheless I have a
few minor remarks and questions:

> Subway Entrances and Exits
>
> No subway entrance should be outside a stop area.

I don't understand this. Do you mean the relation with
type=public_transport + public_transport=stop_area? Or do you mean the
station mapped as a closed way or multipolygon relation?

> Restricting Stop Areas
> 
> For a subway station, a stop area relation should have only objects that are directly related to the station. Rule of thumb is, only objects with these tags (roles are optional, except for oneway subway entrances): 

Why are the roles optional?

> Railway Tracks Direction
>
> When you map directions with separate ways, do not use oneway=yes on these. Instead, look at railway:preferred_direction or designated_direction=* keys.
> 
>     Reason: "oneway" tag marks a legal restriction, and trains do not have these. An engineer won't be fined if he drives a train in an opposing direction. There are very few railway tracks that even have signs forbidding the reverse movement.

Nitpicking (and not a reason to vote against the proposal): I would
write it like this:

> Optional Route Members
>
> Tracks are optional for a route relation.
>
> Reason: on the ground, splitting roads and tracing a route is hard.
> Underground, tracing tracks is virtually impossible. One should not be
> penalized for wishing to add a route with a requirement to draw proper
> tracks. By experience, many currently mapped subway networks do not
> have tracks in them.

I gave this question a serious consideration and am not against it
anymore. However, I would like to ask you to invent a separate type=*
tag for these "routes", i.e. type=trackless_route. They should follow
the same rules as other PTv2 route relations but without having tracks.
But if the tracks exist, type=trackless_route should be replaced by a
normal type=route with route_completeness:tracks=no.

Could you please replace "is virtually impossible" by "is difficult"? It
is impossible if you edit from a foreign country but as I wrote a few
weeks ago it is achieveable if you have enough time and a day pass for
the network.

> Platforms are also optional, but only if they are not mapped, or there
> is a single "island" platform for a stop_area relation. When there are
> two or more platforms (e.g. side platforms for each direction), adding
> a platform for each stop to a route relation is mandatory.
>
> Reason: because mapping an underground platform is also hard (you
> don't expect a mapper to visit and measure every station in a city),
> and in case of a single platform, it is easily deducible from a
> stop_area relation it should be in.

Why should platforms be optional members of a route relation if there is
only one platform for this station? On the one hand you complain that
the existing scheme is difficult but on the other hand you add new
exceptions.

> Mandatory Route Tags
>
> […]

I would not make any of these tags mandatory. ref=* should be mandatory
if there is a reference number. The same applies to colour=* and
colour:infill=*.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20171213/be7f92ef/attachment.sig>