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

2019-05-22 Thread Michael Booth 
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:
typeptrptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes  1099931   203   8578   0  0 00   0
ways_linear 127899 24505 32096 3964 306970528   8
ways_area31652 19560 35729  265  15342   171   15  14
relations  818   614  31832   0 23120   1

US:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes70394   19   2420   0  0 00   0
ways_linear   1196 1023  1940  148  12361 20   0
ways_area  674 1303  2233   10   0 32 60   1
relations   10   11140   0  0 10   0

Germany:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   178981   15   1011   0  0 00   0
ways_linear  36427 1012  7143  663  41172 20   0
ways_area 7891  481  9823  184   1269485   9
relations  274   35  19681   0 16 40   1

France:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   1028218360   0  0 00   0
ways_linear  17179 1342  2609   46   3 29 00   0
ways_area 1173 1190  19415   1  2214   0
relations   12  104530   0  0 10   0

Great Britain:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes370789 20   0  0 00   0
ways_linear300 2412  1012   18   7 15 10   0
ways_area   59 2076  12430   2  0 30   2
relations3   31850   0  0 00   0

Poland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes22073   11 90   0  0 00   0
ways_linear   9294  996   783  615   7 25 20   0
ways_area10327 2612  2189   42   0 24 62   1
relations   37   14370   0  0 00   0

Switzerland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes 67273 00   0  0 00   0
ways_linear   5945  112   805  151   4  4 00   0
ways_area  376  114  18641   0  3 00   0
relations   119   2480   0  0 00   0

Italy:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes317375120   0  0 00   0
ways_linear   3902 1435   757   43   8  0 10   0
ways_area  190 1028   7141   0  0 30   0
relations9   21 70   0  0 00   0

Japan:
typeptr   ptr pt+f

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

2019-05-22 Thread Michael Booth 
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:
typeptrptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes  1099931   203   8578   0  0 00   0
ways_linear 127899 24505 32096 3964 306970528   8
ways_area31652 19560 35729  265  15342   171   15  14
relations  818   614  31832   0 23120   1

US:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes70394   19   2420   0  0 00   0
ways_linear   1196 1023  1940  148  12361 20   0
ways_area  674 1303  2233   10   0 32 60   1
relations   10   11140   0  0 10   0

Germany:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   178981   15   1011   0  0 00   0
ways_linear  36427 1012  7143  663  41172 20   0
ways_area 7891  481  9823  184   1269485   9
relations  274   35  19681   0 16 40   1

France:
typeptr  pt+r pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes   1028218360   0  0 00   0
ways_linear  17179 1342  2609   46   3 29 00   0
ways_area 1173 1190  19415   1  2214   0
relations   12  104530   0  0 10   0

Great Britain:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes370789 20   0  0 00   0
ways_linear300 2412  1012   18   7 15 10   0
ways_area   59 2076  12430   2  0 30   2
relations3   31850   0  0 00   0

Poland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes22073   11 90   0  0 00   0
ways_linear   9294  996   783  615   7 25 20   0
ways_area10327 2612  2189   42   0 24 62   1
relations   37   14370   0  0 00   0

Switzerland:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes 67273 00   0  0 00   0
ways_linear   5945  112   805  151   4  4 00   0
ways_area  376  114  18641   0  3 00   0
relations   119   2480   0  0 00   0

Italy:
typeptr   ptr pt+f r+f pt+r+f pt+pe r+pe pt+r+pe
nodes317375120   0  0 00   0
ways_linear   3902 1435   757   43   8  0 10   0
ways_area  190 1028   7141   0  0 30   0
relations9   21 70   0  0 00   0

Japan:
typeptr   ptr pt+f

Re: [Tagging] Trailhead tagging

2018-12-21 Thread Michael Booth 
I only know of the term trailhead as I've seen it used in the infobox on 
Wikipedia, e.g. https://en.wikipedia.org/wiki/West_Highland_Way


That route has trailheads at Milngavie (bonus points for pronouncing it 
correctly): https://www.geograph.org.uk/photo/5819237 and Fort William: 
https://www.geograph.org.uk/photo/3237567


Also in Scotland the Fife Coastal Path has an arch like this at each end 
of its route: 
http://fifecoastandcountrysidetrust.co.uk/userfiles/Fife%20Coastal%20Path%20Kincardine%20archway%20unveiled.jpg 
(don't know if there's information boards as well)


On 21/12/2018 13:29, Andy Townsend wrote:


Can you give a few examples of what trailheads are to you? There's a 
clearly defined American concept, it isn't not really used much in 
British English.  Also what do you mean by "official" below - is there 
some kind of VVV list or similar?


Best Regards,

Andy

On 21/12/2018 11:54, Peter Elderson wrote:
I would like to revive the trailhead proposal, 
https://wiki.openstreetmap.org/wiki/Proposed_features/trailhead


After discussions in the Dutch user community, a list of all Dutch 
trailheads was compiled and systematically entered as nodes tagged 
highway=trailhead, name=, 
tourism=information, information=board or map. Many trailheads were 
already present in OSM, there we just did some additional tagging.


In the US, trailheads are all maintained on OSM by a national 
operator. Japan has lots of trailheads, I don't know how they are 
maintained. In Europe, no systematical OSM-tagging appears to take 
place, except for the Dutch base.


I think it deserves a push.

Any thoughts on the matter?

--
Vr gr Peter Elderson

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway=*_link roads at Y-junctions and roundabouts?

2018-12-18 Thread Michael Booth 
Agreed, a short Y section before a roundabout because there is a small 
bit of painted or physical separation doesn't mean they are _link roads 
- it's still the same through road.


The wiki says "The _link tags are used to identify ... 'channelised' 
(physically separated) at-grade turning lanes connecting the through 
carriageways ... to other roadways"


So this way is correctly tagged as a _link road: 
https://www.openstreetmap.org/way/352297911 / 
https://www.mapillary.com/map/im/5jD0ksQCmHPt11DizKyztA - but the other 
ways connecting to the roundabout aren't, because they are through 
carriageways (you could argue the roundabout is the thing doing the 
linking here).


On 16/12/2018 15:51, Greg Troxel wrote:

Joseph Eisenberg  writes:


While checking the rendering of highway link roads (eg motorway_link,
primary_link, tertiary_link), I noticed that in some cases these tags
are used when a road splits in a Y-junction, for example before a
traffic circle / roundabout. In some areas these are the most common
forms of _link for less major roads, eg secondary_link and
tertiary_link.

On the wiki there was some debate about whether it was correct to tag
a Y-junction as leading into link roads, or if these should only be
used for slip lanes and on-ramps which merge off of or onto the
through-lanes of another road:
https://wiki.openstreetmap.org/wiki/Talk:Highway_link

It seems that the Y roads should not be link.  link is about a
connecting road used when changing roads, and the last few feet entering
a rotary, especially when there is no other choice, does not fit that.

In particular, if a road wouldn't be tagged differently at a rotary, but
happens to be divided (dual carriageway) the last 50m, then it's fine to
make two ways, but not to change the way type.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] issues with the list of deprecated features

2018-10-17 Thread Michael Booth 
Sorry, but bed_and_breakfast is not tagged in the "hundreds and 
thousands" - it is in fact used less than 700 times worldwide (about 300 
in the UK, including 10% of the total in one town alone!). And if you 
look at the tag history graph you'll see it has never been above 750 at 
any point.


This compares to guest_house which now has 114k uses (was 38k when B 
was deprecated four years ago). It looks like the guest_house definition 
includes B so there doesn't seem to be any point in having another 
top level tag value. Most of the objects I've looked at can easily be 
retagged as guest_house, plus quite a few are from the early days of OSM 
before this tag consensus appeared.


On 15/10/2018 09:57, Martin Koppenhoefer wrote:

10. tourism=bed_and_breakfast
The suggested alternative is 
"tourism=guest_house+guest_house=bed_and_breakfast"
Every time a deprecated tag should be replaced by a tag which is so 
unspecific that people have seen to need to add subtags in order to 
express what it is (on the same level of specificity as the tag that 
should be deprecated), there is some problem. People know what is a 
bed and breakfast, the tag it in the hundreds and thousands despite it 
being discouraged and flagged as deprecated. Wouldn't it be easier to 
accept tourism=bed_and_breakfast, or are there other issues with this tag?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] mast / tower / communication_tower (again)

2018-09-28 Thread Michael Booth 

Hi,

I opened an issue on the rendering of man_made=communications_tower on 
the standard layer over on OSM-carto: 
https://github.com/gravitystorm/openstreetmap-carto/issues/3414 and 
think there should be a discussion about the tagging as well.


The Wiki definition is: *"**a huge tower for transmitting radio 
applications It is often made from concrete and usually a far 
visible landmark."* 
https://wiki.openstreetmap.org/wiki/Tag:man%20made=communications%20tower


Looking at examples of this tag in OSM I would guess that out of the 
<4,000 objects worldwide most of them do not conform to that definition. 
Many of them are small mobile phone/cell site "masts", towers less than 
100m, or very tall guyed masts.


I'd like to retag the structures near me to something more suitable - 
however the wiki pages aren't very clear in distinguishing between the 
various constructions and sizes for masts and towers.


Hopefully people can agree that the following should be tagged as 
man_made=mast or tower + tower:type=communication + tower:construction + 
height? Using TV transmitters in the UK as examples:


 * mast - guyed lattice, 306m:
   https://en.wikipedia.org/wiki/Durris_transmitting_station
 * mast - guyed tube, 351m:
   https://en.wikipedia.org/wiki/Belmont_transmitting_station
 * tower - lattice, 219m:
   https://en.wikipedia.org/wiki/Crystal_Palace_transmitting_station
 * tower - freestanding, 330m:
   https://en.wikipedia.org/wiki/Emley_Moor_transmitting_station

But how should these examples be tagged in OSM? All of them are 
self-supporting structures, so in engineering terms they are not masts.


1. https://binged.it/2xILZO9
2. https://www.geograph.org.uk/photo/2361955
3. https://www.geograph.org.uk/photo/2337468
4. https://en.wikipedia.org/wiki/Charwelton_BT_Tower
5. https://www.geograph.org.uk/photo/2053885
6. https://binged.it/2xTxcQK
7. https://fr.wikipedia.org/wiki/Tour_hertzienne_de_Villeneuve-d%27Ascq
8. https://www.geograph.org.uk/photo/2162874

Fortunately all three of the tags are now all displayed on the standard 
layer so there shouldn't be any tagging for the renderer. But it would 
be good to fix the definitions and make the wiki much clearer, 
especially with more example photos. Then also ensuring the tags are 
well supported in each editor's presets.


Cheers

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging