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

classic Classic list List threaded Threaded
96 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Michael Reichert-3
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)


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Mateusz Konieczny-3



23 May 2019, 00:23 by [hidden email]:
(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
I always though that platform should not interupt footways, but platform itself
has no need for footway tag on its area

See for example
https://www.openstreetmap.org/?mlat=50.06524&mlon=19.95230#map=19/50.06524/19.95230
https://www.openstreetmap.org/way/234100234#map=19/50.06524/19.95277

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

marc marc
In reply to this post by Michael Reichert-3
Le 23.05.19 à 00:23, Michael Reichert a écrit :
> What is your opinion on this issue?

Thanks for the so documented message.
I didn't read all numbers but indeed, some plateform aren't
a footway
some are a path
some of indoor feature (more like a room=corridor)
it could be a good idea to improve the routing in those case,
but not with an easy/wrong assertion "all plateform mean X access"
some may get a highway tag to avoid breaking the highway network
some have a highway through the plateform area (that the issue of having
a linear+area network)

I may have missed the last iD update announcement announcing this,
what this transparent or discovered by chance?
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Tagging mailing list
In reply to this post by Michael Reichert-3
They've (just quincylvania?) got their logic backwards. A platform is, by default, accessible by people. It's what they are designed for in the real world.

I find it strange/worrying he makes these far reaching decisions unilaterally (unless there's other hidden discussions not linked to in #6042 

On 22/05/2019 23:23, Michael Reichert wrote:
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.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Michael Booth
In reply to this post by Michael Reichert-3
That explains why I saw highway=footway being added to a platform in a changeset today...

If adding highway=footway is such a good idea then let's have a discussion and get it added to every platform, rather than this fake "upgrade" tag feature in iD.

Maybe routers should treat platforms as routable on foot by default?

Another issue is that any platform mapped as an area will now render as a footway area, see: https://www.openstreetmap.org/way/252199901

On 22/05/2019 23:23, Michael Reichert wrote:
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.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Michael Booth
In reply to this post by Michael Reichert-3
That explains why I saw highway=footway being added to a platform in a changeset today...

If adding highway=footway is such a good idea then let's have a discussion and get it added to every platform, rather than this fake "upgrade" tag feature in iD.

Maybe routers should treat platforms as routable on foot by default?

Another issue is that any platform mapped as an area will now render as a footway area, see: https://www.openstreetmap.org/way/252199901

On 22/05/2019 23:23, Michael Reichert wrote:
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.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Graeme Fitzpatrick
In reply to this post by marc marc


On Thu, 23 May 2019 at 09:10, marc marc <[hidden email]> wrote:

I may have missed the last iD update announcement announcing this,
what this transparent or discovered by chance?

This one, which includes heaps of changes!?

 
Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Mateusz Konieczny-3
This is a change on the OSM website that updates iD version so all changes are bundled as one.

For more gradual commits/issues see https://github.com/openstreetmap/iD


23 May 2019, 01:39 by [hidden email]:


On Thu, 23 May 2019 at 09:10, marc marc <[hidden email]> wrote:

I may have missed the last iD update announcement announcing this,
what this transparent or discovered by chance?

This one, which includes heaps of changes!?

 
Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Mateusz Konieczny-3
In reply to this post by Tagging mailing list
23 May 2019, 01:15 by [hidden email]:
I find it strange/worrying he makes these far reaching decisions unilaterally
Note that JOSM also is doing this but in cases of unwanted or broken validation
it gets fixed/changed/rolled back.

I think that main difference between JOSM validation (that is not causing repeated complaints,
at least on this mailing list) and iD validation is that JOSM devs have no trouble
with reverting or fixing changes that are not actually wanted (or are better on judging what
is wanted by community).

I think it is fine to make such changes without checking every single one with wider community,
as long as unwanted ones get rolled back.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

dieterdreist


sent from a phone

> On 23. May 2019, at 09:21, Mateusz Konieczny <[hidden email]> wrote:
>
> I think that main difference between JOSM validation (that is not causing repeated complaints,
> at least on this mailing list) and iD validation is that JOSM devs have no trouble
> with reverting or fixing changes that are not actually wanted (or are better on judging what
> is wanted by community).


a big difference is that in Josm there is a team, where different opinions can be discussed, while in iD it is Bryan who has the whole burden on his shoulders to decide alone about raised issues.

Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Markus-5
I agree that adding highway=footway to platforms is not only
redundant, but (as pointed out by Michael) is bad because platforms
often have different access restrictions than highway=footway. iD's
validation rule should be removed.

Regards

Markus

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Tobias Zwick
In reply to this post by dieterdreist
I like your wording. It is a burden. He also takes all the complaints for bugs and when iD steps on someone's shoes. This is a very stressful position to be in.

Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer <[hidden email]>:

>
>
>sent from a phone
>
>> On 23. May 2019, at 09:21, Mateusz Konieczny
><[hidden email]> wrote:
>>
>> I think that main difference between JOSM validation (that is not
>causing repeated complaints,
>> at least on this mailing list) and iD validation is that JOSM devs
>have no trouble
>> with reverting or fixing changes that are not actually wanted (or are
>better on judging what
>> is wanted by community).
>
>
>a big difference is that in Josm there is a team, where different
>opinions can be discussed, while in iD it is Bryan who has the whole
>burden on his shoulders to decide alone about raised issues.
>
>Cheers, Martin
>_______________________________________________
>Tagging mailing list
>[hidden email]
>https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

marc marc
In reply to this post by Mateusz Konieczny-3
I mean that previous updates were announced by email on osm-dev
with the change log, everyone can easily see the changes.
I missed this one and/or no announcement for this one.
after reading the modification log, other changes are strange,
I will reread them again before posting specific issue

Le 23.05.19 à 09:14, Mateusz Konieczny a écrit :

> This is a change on the OSM website that updates iD version so all
> changes are bundled as one.
>
> For more gradual commits/issues see https://github.com/openstreetmap/iD
>
>
> 23 May 2019, 01:39 by [hidden email]:
>
>
>
>     On Thu, 23 May 2019 at 09:10, marc marc <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>
>         I may have missed the last iD update announcement announcing this,
>         what this transparent or discovered by chance?
>
>
>     This one, which includes heaps of changes!?
>
>     https://github.com/openstreetmap/openstreetmap-website/pull/2231
>
>     Thanks
>
>     Graeme
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

Paul Allen
On Thu, 23 May 2019 at 09:46, marc marc <[hidden email]> wrote:
I mean that previous updates were announced by email on osm-dev
with the change log, everyone can easily see the changes.

On my browser, the version number at bottom right was replaced by a red icon.  Clicking on it
opens a browser window onto the changelog.  That's been standard with iD updates for as long
as I've been using it.
 
I missed this one and/or no announcement for this one.

Maybe your browser works differently to mine.

after reading the modification log, other changes are strange,
I will reread them again before posting specific issue

Many of them don't make a lot of sense unless you take a look at the issues they reference.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

marc marc
Le 23.05.19 à 11:46, Paul Allen a écrit :
> On Thu, 23 May 2019 at 09:46, marc marc wrote:
>
>     previous updates were announced by email
>     I missed this one and/or no announcement for this one.
>
> Maybe your browser works differently to mine.

it isn't my nor your browser that send the email
wrote by the iD team :)

last one [Tagging] iD news - 2.12.0 released
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041434.html
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

Paul Allen
On Thu, 23 May 2019 at 11:26, marc marc <[hidden email]> wrote:

it isn't my nor your browser that send the email
wrote by the iD team :)

I didn't get that email either.  I've never received an email from the iD team about upgrades.  Yet
I learn of the upgrades as soon as they happen.  Because iD tells me that there's been an
upgrade as soon as I start to use it.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Tagging mailing list
In reply to this post by Tobias Zwick
Don't you think, with his refusal to participate in discussions about
raised issues, that it's often self inflicted?

On a couple of occasions he's said he ignores these forums & note how
often github threads are instantaneously closed.

DaveF

On 23/05/2019 09:16, Tobias Zwick wrote:

> I like your wording. It is a burden. He also takes all the complaints for bugs and when iD steps on someone's shoes. This is a very stressful position to be in.
>
> Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer <[hidden email]>:
>>
>> sent from a phone
>>
>>> On 23. May 2019, at 09:21, Mateusz Konieczny
>> <[hidden email]> wrote:
>>> I think that main difference between JOSM validation (that is not
>> causing repeated complaints,
>>> at least on this mailing list) and iD validation is that JOSM devs
>> have no trouble
>>> with reverting or fixing changes that are not actually wanted (or are
>> better on judging what
>>> is wanted by community).
>>
>> a big difference is that in Josm there is a team, where different
>> opinions can be discussed, while in iD it is Bryan who has the whole
>> burden on his shoulders to decide alone about raised issues.
>>
>> Cheers, Martin
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

Mateusz Konieczny-3
In reply to this post by Tobias Zwick
Though repeated attempts by @bhousel and @quincylvania to declare themselves as
final arbiters of OSM tagging and dismissing everybody else is certainly not helping.

That is really not going to work, and it is a pity because plenty of work done of him is really great
but it is tainted by ignoring arguments of critics. No one is right all the time.

To directly quote part of

"Some things that don't really factor at all into our decision:

    how long a tag with implicit semantics has been in use
    how many softwares (renderers / routers or whatever) already support the implicit rule
    how frequently the tag is used
    what a handful of people on a mostly dormant mailing list think
    what one person has written on the osm wiki
    how many downvotes you encourage people to put on our issue list
    what they are saying about us in the weekly osm tabloid"

So someone is dismissing what everybody else thinks and at the same time expects everybody
to accept his own opinions?

Some ideas from tagging mailing list and OSM wiki (even after limiting to popular ones
or "approved") are pointless/harmful but that is not a valid reason to simply ignore all of them.

23 May 2019, 10:16 by [hidden email]:
I like your wording. It is a burden. He also takes all the complaints for bugs and when iD steps on someone's shoes. This is a very stressful position to be in.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: iD adding highway=footway to all railway/public_transport=platform ways and relations

Nick Bolten
In reply to this post by Markus-5
I'm confused, because these two statements seem incompatible. If it's redundant, how can it also have a conflict like different address restrictions? I'd like to know how, as a data consumer, I should reliably interpret existing platforms without the tag added by iD.

Taking a step back, can anyone name an instance where a linear transit platform is not a footway?

On Thu, May 23, 2019, 12:49 AM Markus <[hidden email]> wrote:
I agree that adding highway=footway to platforms is not only
redundant, but (as pointed out by Michael) is bad because platforms
often have different access restrictions than highway=footway. iD's
validation rule should be removed.

Regards

Markus

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

Tobias Zwick
In reply to this post by Mateusz Konieczny-3
I simply have the feeling that we are heading straight for an escalation course here. I already see it looming that some day the plug might be pulled on iD (being hosted on openstreetmap.org) and I really really don't want this to happen, lest even to think about it makes me sick.

Undoubtedly, the developers behavior is not helping there. I have the impression that they have almost given up on the OSM community. But this doesn't come out of nowhere.  I think it is important to understand their side of the story if we were to reverse this development.

I had to rewrite this last paragraph several times, but, well, I hope this does not come across the wrong way...
it can certainly not continue like this, so ... why not interview him, honestly and with open outcome, how should the collaboration and communication in OSM happen in the future from his point of view? Would he rather feel relieved or rather feel betrayed if the gatekeeping (~deployment) is done by other people? Does he really feel alienated (because I assumed it) from the community and if yes, why? And most importantly, what would it take to reverse this?

Tobias

On 23/05/2019 17:15, Mateusz Konieczny wrote:

> Though repeated attempts by @bhousel and @quincylvania to declare themselves as
> final arbiters of OSM tagging and dismissing everybody else is certainly not helping.
>
> That is really not going to work, and it is a pity because plenty of work done of him is really great
> but it is tainted by ignoring arguments of critics. No one is right all the time.
>
> To directly quote part of
> https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649
>
> "Some things that don't really factor at all into our decision:
>
>     how long a tag with implicit semantics has been in use
>     how many softwares (renderers / routers or whatever) already support the implicit rule
>     how frequently the tag is used
>     what a handful of people on a mostly dormant mailing list think
>     what one person has written on the osm wiki
>     how many downvotes you encourage people to put on our issue list
>     what they are saying about us in the weekly osm tabloid"
>
> So someone is dismissing what everybody else thinks and at the same time expects everybody
> to accept his own opinions?
>
> Some ideas from tagging mailing list and OSM wiki (even after limiting to popular ones
> or "approved") are pointless/harmful but that is not a valid reason to simply ignore all of them.
>
> 23 May 2019, 10:16 by [hidden email]:
>
>     I like your wording. It is a burden. He also takes all the complaints for bugs and when iD steps on someone's shoes. This is a very stressful position to be in.
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12345