[Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Michael Reichert]

Hi,

I discovered today that iD suggests to add highway=footway to
railway/public_transport=platform objects as part of its new validation
rules. On a GitHub ticket I found, Quincy Morgan explained it that way [1]:
> Features with these tags are expected to be part of the pedestrian network, but without highway tags it is more difficult for routers (and iD's validation) to support them. iD should add highway=footway automatically and recommend upgrading features lacking this tag.

I disagree with that.

(1) Calling it difficult for routers is a weak reason. Currently, a
router can decided to include platforms in the graph or to exclude them.
Some do support or intentionally not support platforms. Platforms are
something special. There are subtle but relevant differences to normal
footways, e.g. the requirement to have a ticket (even without barriers
present) or a cycling ban [2]). These differences are hidden by adding
highway=footway.

Instead of making life easier, life stays as difficult for the developer
of routing engines but they have to change their code just for the sake
of changing. If iD starts adding highway=* to any platform, all routers
supporting the current tagging schema have to change their behaviour.

(2) The following numbers (data from 2019-05-21T22:58:37Z) show that the
change should be treated as the redefinition of a existing tag.
highway=footway is rarely used on platforms now – currently 0.4% only.

(Typewriter font recommened for optimal display of the following tables)

pt: public_transport=platform
r: railway=platform
f: highway=footway
pe: highway=pedestrian
ways_linear: non-closed ways and ways without area=yes
ways_area: closed ways with area=yes

Planet:
type            pt    r    ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes      1099931   203   857    8   0      0     0    0       0
ways_linear 127899 24505 32096 3964 306    970    52    8       8
ways_area    31652 19560 35729  265  15    342   171   15      14
relations      818   614  3183    2   0     23    12    0       1

US:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes        70394   19   242    0   0      0     0    0       0
ways_linear   1196 1023  1940  148  12    361     2    0       0
ways_area      674 1303  2233   10   0     32     6    0       1
relations       10   11    14    0   0      0     1    0       0

Germany:
type            pt    r  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes       178981   15   101    1   0      0     0    0       0
ways_linear  36427 1012  7143  663  41    172     2    0       0
ways_area     7891  481  9823  184   1    269    48    5       9
relations      274   35  1968    1   0     16     4    0       1

France:
type            pt    r  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes       102821    8    36    0   0      0     0    0       0
ways_linear  17179 1342  2609   46   3     29     0    0       0
ways_area     1173 1190  1941    5   1      2    21    4       0
relations       12  104    53    0   0      0     1    0       0

Great Britain:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes        37078    9     2    0   0      0     0    0       0
ways_linear    300 2412  1012   18   7     15     1    0       0
ways_area       59 2076  1243    0   2      0     3    0       2
relations        3   31    85    0   0      0     0    0       0

Poland:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes        22073   11     9    0   0      0     0    0       0
ways_linear   9294  996   783  615   7     25     2    0       0
ways_area    10327 2612  2189   42   0     24     6    2       1
relations       37   14    37    0   0      0     0    0       0

Switzerland:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes         6727    3     0    0   0      0     0    0       0
ways_linear   5945  112   805  151   4      4     0    0       0
ways_area      376  114  1864    1   0      3     0    0       0
relations       11    9   248    0   0      0     0    0       0

Italy:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes        31737    5    12    0   0      0     0    0       0
ways_linear   3902 1435   757   43   8      0     1    0       0
ways_area      190 1028   714    1   0      0     3    0       0
relations        9   21     7    0   0      0     0    0       0

Japan:
type            pt    r   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes        37185    7    13    0   0      0     0    0       0
ways_linear    910  785  1110    9   1      1     0    0       0
ways_area      342 1295  2207    0   0      0     2    0       0
relations       24   38    85    0   0      0     0    0       0

It is quite obvious that highway=footway on platforms is exotic.

(3) highway=footway is added to ways which are clearly tagged as area
using area=yes. Many routers route along the edges of areas but that's
more a bug and workaround than a good feature. A highway=footway area is
mapped as either area:highway=footway, not as highway=footway +
area=yes. iD recommends bad tagging. highway=service and
highway=pedestrian are the only tags where area=yes is widely accepted,
isn't it? There is no linear footway along the edge of an platform but
the whole platform polygon is the feature.

I pointed out these reasons (not the numbers – I run my counting
programme while preparing this email) today but my request rejected.

What is your opinion on this issue? Feel free to reply to this email or
comment at https://github.com/openstreetmap/iD/issues/6409

Best regards

Michael



[1] https://github.com/openstreetmap/iD/issues/6042
[2] highway=footway implies bicycle=no more or less strict but the
distinction footway vs. cycleway vs. path is – let's call it – difficult
in OSM. I tend to say that treating footways as slow and not to prefer
cycleways is a good idea if no explicit tag is present.


-- 
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: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190523/0acfcd3c/attachment-0001.sig>