[Tagging] Feature Proposal - draft - Traffic Signal Timings

[Gabe Appleton]

Hi all,

I just posted a draft proposal to document the relative timing of traffic 
lights. The aim is to provide a way for navigation apps to better estimate the 
delay caused by a given traffic signal.

In the most basic example, if there are two lights in a row that are locked in 
sync, you dont get two lights of delay from that, you would actually get 1 + 
epsilon.

The full proposal can be found here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signal_Timings

Constructive criticism is both welcomed and encouraged.

Thanks,
Gabe (gappleto97)

signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Jo]

I, for one, prefer to have the platform node/way and its corresponding
stop_position in 1 stop_area relation per direction of travel or per
platform (in bus stations).

I don't mind adding the shelter, waste_basket, bench,
ticket_vending_device, announcement_board to such a relation.

Then these stop_area relations can be grouped. I started doing this in
stop_area_group, but later on simply started creating a hierarchy of
stop_area relations, as JOSM's  validator complained about the
stop_area_group relations.

Having said that, I'm not always creating these stop_area relations. I'm
mostly mapping bus stops and routes and if there is no ambiguity with
resolving the correspondance between platform and stop_position/[highway to
be added ot the route relation], then spatial is good enough for me.

For underground features I would probably map all of the stop_area
relations, so it's clear what belongs together. For grouping 2 platforms /
2 stop_positions with the same name that are near to each other, there is
no real benefit in having them all together in stop_area relations either,
what's the functionality of that?

Polyglot

2017-11-10 19:43 GMT+01:00 marc marc :

> Le 10. 11. 17 à 17:45, Ilya Zverev a écrit :
>
> > Your "why change" argument looks weird with this sentence, by the way.
>
> I will rephrase my question. What are the benefits of your proposal ?
> What is the problem with the current situation and how does your
> proposal improve it ? the main change seems to be to cut a relationship
> in 2 without my understanding of the benefit.
> a proposal usually said "problem, current situation, solution".
> yours said "clarification (=change)".
> But in the talk page, problem are after your changes, not before :)
>
> >> - On the other hand, the section "What This Affects" is incomplete.
> >> -- it lacks the incomprehensible prohibition to map a station a an area.
> > Did you read https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway ?
>
> yes (but no link to the approved proposal)
> either your proposal does not change the previous proposal on this and
> then it is not a proposal since it is already the case. either your
> proposal wishes to make an existing situation "deprecated" but without
> saying so.
> often going from a node to an area is an improvement in the accuracy of
> information, so I do not really understand the point of wanting to
> depreciated the most accurate way of describing a station. Saying that a
> station is not visible on a satellite image or that a laser is necessary
> is a strange argument (road tunnels are also absent from satellite view,
> that does not stop anyone from describing them in osm without needing a
> laser)
>
> >> -- many other details are incomprehensible as "Platform Layer should be
> >> at least -3". what should be "mandatory" between layer and -3 ?
> > I chose -3 from the practical standpoint: -1 is usually used for highway
> tunnels, and -2 might be used on complex junctions, so having a layer -3
> and less would be a safe option.
>
> you misunderstand the layer tag.
> it should not be a value for tunnel, a value for junction, and a value
> for a station. it depends on the reality of site.
> Starting from the ground, first could have -1, next -2 and so.
> for ex https://www.openstreetmap.org/way/474210035
> what is the benefit of having to change it to layer -3 ?
> for me it's a useless constraint.
> how to map this https://www.openstreetmap.org/way/485683927 ?
> with a change to layer -3 and the other platform to -4
> and the highway tunnel to -5 ? what is the benefit of not using
> the (often) first free layer value like it's currently done ?
> a lot of change without advantage over the existing situation.
> if I'm wrong, feel free to explain WHY change.
>
> >> -- no explanation why the new shchema is better than the current one.
> >> for ex why a stop_area should be duplicated stop_area containing only
> >> part + a stop_area_group that groups them.
> > How is that worse than the current schema?
>
> your proposal makes it mandatory to do 3 relationships for every small
> station (2 stop_area + 1 stop_area_group).
> exemple https://www.openstreetmap.org/relation/7151720
> it 'll need to be splited in 3... without reading the benefit of these
> additional relationships.
>
> >> At the same time, on the mailing transport, there is already the case
> >> that a contributor who "cleanup" sncf station to apply the new scheme
> >> without any discussion with the local community concerned with app
> >> problems that do not work anymore . The phrase "More than fifty metro
> >> networks" has to be read as "no matter what your vote is, we have
> >> already begun to impose it". it is obviously not very positive.
> > I intended to resolve this privately and to wait a couple weeks before
> making the issue public
> Wanting to solve this privately is contradictory to calling to vote
> after you have been warned of the problem.
> Either you 

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[marc marc]

Le 10. 11. 17 à 17:45, Ilya Zverev a écrit :

> Your "why change" argument looks weird with this sentence, by the way.

I will rephrase my question. What are the benefits of your proposal ? 
What is the problem with the current situation and how does your 
proposal improve it ? the main change seems to be to cut a relationship 
in 2 without my understanding of the benefit.
a proposal usually said "problem, current situation, solution".
yours said "clarification (=change)".
But in the talk page, problem are after your changes, not before :)

>> - On the other hand, the section "What This Affects" is incomplete.
>> -- it lacks the incomprehensible prohibition to map a station a an area. 
> Did you read https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway ?

yes (but no link to the approved proposal)
either your proposal does not change the previous proposal on this and 
then it is not a proposal since it is already the case. either your 
proposal wishes to make an existing situation "deprecated" but without 
saying so.
often going from a node to an area is an improvement in the accuracy of 
information, so I do not really understand the point of wanting to 
depreciated the most accurate way of describing a station. Saying that a 
station is not visible on a satellite image or that a laser is necessary 
is a strange argument (road tunnels are also absent from satellite view, 
that does not stop anyone from describing them in osm without needing a 
laser)

>> -- many other details are incomprehensible as "Platform Layer should be
>> at least -3". what should be "mandatory" between layer and -3 ?
> I chose -3 from the practical standpoint: -1 is usually used for highway 
> tunnels, and -2 might be used on complex junctions, so having a layer -3 and 
> less would be a safe option.

you misunderstand the layer tag.
it should not be a value for tunnel, a value for junction, and a value 
for a station. it depends on the reality of site.
Starting from the ground, first could have -1, next -2 and so.
for ex https://www.openstreetmap.org/way/474210035
what is the benefit of having to change it to layer -3 ?
for me it's a useless constraint.
how to map this https://www.openstreetmap.org/way/485683927 ?
with a change to layer -3 and the other platform to -4
and the highway tunnel to -5 ? what is the benefit of not using
the (often) first free layer value like it's currently done ?
a lot of change without advantage over the existing situation.
if I'm wrong, feel free to explain WHY change.

>> -- no explanation why the new shchema is better than the current one.
>> for ex why a stop_area should be duplicated stop_area containing only
>> part + a stop_area_group that groups them.
> How is that worse than the current schema?

your proposal makes it mandatory to do 3 relationships for every small 
station (2 stop_area + 1 stop_area_group).
exemple https://www.openstreetmap.org/relation/7151720
it 'll need to be splited in 3... without reading the benefit of these 
additional relationships.

>> At the same time, on the mailing transport, there is already the case
>> that a contributor who "cleanup" sncf station to apply the new scheme
>> without any discussion with the local community concerned with app
>> problems that do not work anymore . The phrase "More than fifty metro
>> networks" has to be read as "no matter what your vote is, we have
>> already begun to impose it". it is obviously not very positive.
> I intended to resolve this privately and to wait a couple weeks before making 
> the issue public
Wanting to solve this privately is contradictory to calling to vote 
after you have been warned of the problem.
Either you want to find a solution either you start voting.
Opening the voting period assumes that the detected problems
have been resolved.
Voting a proposal that is already known to have problems is a mistake.

> http://www.openstreetmap.org/changeset/53267689
> Turns out some agency in France misuses stop_area relations to contain 
> _everything_ in the vicinity of a railway station.

maybe it's wrong to have soo many items to this relation.
but when reading
http://wiki.openstreetmap.org/wiki/Tag:public transport=stop area
you 'll see : "shelter, bench, bicycle_parking, taxi.   Recommended, if 
available."
So removing all those POI (and prior to the voting) is wrong.
If dev of existing applications need some time to think about
the issue, it does not seem to be excessive.

> I suggested retagging the original type=public_transport to type=site

this is in contraction with the page
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
that says "not to be used in cases where the elements are inside one or 
more areas where the perimeter can be tagged with an appropriate Area" 
and propose the opposite modification.
a station is not a dispersed facilities power plants like wind.
Also you claim that a relationship containing hundreds of objects is a 
mistake but your solution is to create another 

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Ilya Zverev]

marc marc wrote:
> with so many modifications, it would have been useful in my opinion to 
> call for comments a second time before the vote. I even think that a 
> 15-day vote to make the current mapping of the majority of the big 
> stations INVALID is a bit short.


I posted news about the proposal every two weeks in different channels. The 
discussion page being 44 kilobytes, I think, shows that many people who were 
actually interested in the proposal, did comment it (and helped improve it — 
thanks!). To suggest to continue this would mean you don't value time of others.

> For my part, I have the same criticism as at the beginning :
> - 90% of the proposal is not a proposal. it's a mix of current mapping 
> that doesn't change and extra details.

Yes, and this is clearly stated on the page, along with an explanation of what 
are we voting for. Your "why change" argument looks weird with this sentence, 
by the way.

> - On the other hand, the section "What This Affects" is incomplete.
> -- it lacks the incomprehensible prohibition to map a station a an area.

Did you read https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway ?

> -- the same for entries (you claim that this affects the routing, this 
> is not necessarily true)

I suggest people do mark subway entrances, as that helps with routing. Is that 
not so? As for nodes vs polygons, again, see 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dsubway_entrance

> -- many other details are incomprehensible as "Platform Layer should be 
> at least -3". what should be "mandatory" between layer and -3 ?

I chose -3 from the practical standpoint: -1 is usually used for highway 
tunnels, and -2 might be used on complex junctions, so having a layer -3 and 
less would be a safe option.

> -- no explanation why the new shchema is better than the current one.
> for ex why a stop_area should be duplicated stop_area containing only 
> part + a stop_area_group that groups them.

Instead of a single collection of every object on many transfer stations you 
get separate collections for each and a grouping that shows whether you can go 
from one to another. How is that worse than the current schema? Stop area 
groups were proposed initially in the Oxomoa schema, but were somehow lost on 
the way — probably because overground stations rarely need it.

> At the same time, on the mailing transport, there is already the case 
> that a contributor who "cleanup" sncf station to apply the new scheme 
> without any discussion with the local community concerned with app 
> problems that do not work anymore . The phrase "More than fifty metro 
> networks" has to be read as "no matter what your vote is, we have 
> already begun to impose it". it is obviously not very positive.

Ah. I intended to resolve this privately and to wait a couple weeks before 
making the issue public, but well, if you insist. Marc refers to this changeset 
discussion:

http://www.openstreetmap.org/changeset/53267689

Turns out some agency in France misuses stop_area relations to contain 
_everything_ in the vicinity of a railway station. Which results in a series of 
gigantic relations of 500-2500 members. They have everything: shops, cafes, 
signposts, trashcans, benches, footways, steps, railway tracks etc. Even 
untagged nodes. See for yourself:

http://www.openstreetmap.org/relation/6093537

In my proposal I specifically suggest to put in stop_areas only objects that 
are directly related to public transport stations. Which means, no tracks, no 
shops, no footways. So I was tidying up french metro systems and cleaned up 
these stop_areas. Then I was contacted by a person from SNCF. As a temporary 
solution I suggested retagging the original type=public_transport to type=site 
while creating smaller stop_areas. Turned out, that isn't enough and they want 
to have a few weeks to reprogram their system.

My opinion is that is an abuse of OpenStreetMap database and a disregard for 
any current or potential users of map data. If Marc wishes for it to be 
resolved publicly, I welcome your opinions on this.

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

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Ilya Zverev]

José G Moya Y. wrote:
> How do you map this situation:
> You can enter with wheelchair to Pacifico Metro Station metro line 1.
> You can enter with wheelchair to Pacifico Metro Station line 6.
> You can't go with wheelchair from line 6 to line 1 (or vice versa) without
> paying
> your metro fee again. To do so, you have to go by foot.
> (This is a common accesibility problem on old metro stations in Madrid).


Thanks for the question. The short answer is, you could not before and won't be 
able if the proposal is accepted :) Of course you should put wheelchair=yes on 
all subway_entrances. You should map obstacles on the way from platform to 
platform, preventing people with wheelchairs from transferring, if you can.

But currently there is no way to mark two stations (or separate platforms 
inside a station) as being in an interchange. The proposal offers a way, by 
grouping all interchange stations in a stop_area_group relation. But that is a 
collection, not a route: having a wheelchair=no on the relation would not make 
sense.

I doubt we can invent a way to map individual routes between transfer stations 
that is easy to map (not a pair of relations on every two stations), easy to 
use (unlike footway and steps ways) and does not interfere with current mapping 
practices.

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

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Ilya Zverev]

Martin Koppenhoefer wrote:
> sorry for asking so late, but why should we deprecate mapping subway stations 
> with a relation or a way and insist on nodes? There are already a significant 
> number of stations mapped like this. I would also not write: "The location of 
> the node is irrelevant." or "There is nothing wrong with putting the node 
> near its entrance: it does not affect routing or anything else." but explain 
> more careful where the node should be put, and what it's meant to know (if it 
> wouldn't affect anything we could also not put it, no?).

Subway stations are mostly underground and, unlike overground stations, are a 
set of disjoint facilities joined by tunnels, invisible on satellite imagery. 
Nobody except the architect or a security employee can draw a polygon for 
underground station properly: you don't usually see service rooms or know how 
wide the tunnel is, and very few people, maybe less than ten in the whole 
world, would actually go with a laser ruler to measure angles and distances 
required for mapping an underground facility.

Then, having stations as polygons or multipolygons makes managing a stop_area 
and route relations much harder to manage. I don't know about iD, but in JOSM 
it takes several clicks to select a multipolygon. And with sparse editing 
techniques, you can't be sure whether a station exists if it's drawn with a 
multipolygon.

536 subway stations in the world are mapped with polygons, which makes for 4,5% 
of all metro stations. 421 of these (78%) also have building=* tags. I consider 
tagging a building a station a bad practice, for the building can have e.g. a 
different name or a different operator. Sharing an object between features is 
frowned upon, and I don't want to encourage this practice by allowing station 
tags on a polygon.

https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

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

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[José G Moya Y .]

Hi!
How do you map this situation:
You can enter with wheelchair to Pacifico Metro Station metro line 1.
You can enter with wheelchair to Pacifico Metro Station line 6.
You can't go with wheelchair from line 6 to line 1 (or vice versa) without
paying
your metro fee again. To do so, you have to go by foot.
(This is a common accesibility problem on old metro stations in Madrid).

El 10/11/2017 15:44, "Martin Koppenhoefer" 
escribió:

>
>
> 2017-11-10 15:38 GMT+01:00 Martin Koppenhoefer :
>
>> sorry for asking so late, but why should we deprecate mapping subway
>> stations with a relation or a way and insist on nodes? There are already a
>> significant number of stations mapped like this. I would also not write:
>> "The location of the node is irrelevant." or "There is nothing wrong with
>> putting the node near its entrance: it does not affect routing or anything
>> else." but explain more careful where the node should be put, and what it's
>> meant to know (if it wouldn't affect anything we could also not put it,
>> no?).
>>
>
>
> I've seen there is this paragraph: https://wiki.openstreetmap.
> org/wiki/Proposed_features/Metro_Mapping#What_This_Affects
> but it doesn't mention deprecating station areas. Can you please make a
> complete summary of all things (tags and their intended meaning) that your
> proposal
>
> a) introduces (new)
>
> b) changes
>
> c) removes
>
> Thank you,
> Martin
>
> ___
> 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] Feature Proposal - Voting - Metro Mapping

[marc marc]

Hello,

Le 10. 11. 17 à 15:30, Ilya Zverev a écrit :
> After six weeks of discussion and improvements, I am happy to start the 
> voting on my proposal about mapping metro stations and lines:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping

with so many modifications, it would have been useful in my opinion to 
call for comments a second time before the vote. I even think that a 
15-day vote to make the current mapping of the majority of the big 
stations INVALID is a bit short.

At the same time, on the mailing transport, there is already the case 
that a contributor who "cleanup" sncf station to apply the new scheme 
without any discussion with the local community concerned with app 
problems that do not work anymore . The phrase "More than fifty metro 
networks" has to be read as "no matter what your vote is, we have 
already begun to impose it". it is obviously not very positive.

For my part, I have the same criticism as at the beginning :
- 90% of the proposal is not a proposal. it's a mix of current mapping 
that doesn't change and extra details.
- On the other hand, the section "What This Affects" is incomplete.
-- it lacks the incomprehensible prohibition to map a station a an area.
-- the same for entries (you claim that this affects the routing, this 
is not necessarily true)
-- many other details are incomprehensible as "Platform Layer should be 
at least -3". what should be "mandatory" between layer and -3 ?
-- no explanation why the new shchema is better than the current one.
for ex why a stop_area should be duplicated stop_area containing only 
part + a stop_area_group that groups them. what is the benefit of this 
change ? it is especially that which remains for me understandable : 
change everything without understanding what this added complexity 
brings to the existing situation.

I'll read the 40k discussion page... but the proposal would have a a 
least one argument of "why change"

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

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Martin Koppenhoefer]

2017-11-10 15:38 GMT+01:00 Martin Koppenhoefer :

> sorry for asking so late, but why should we deprecate mapping subway
> stations with a relation or a way and insist on nodes? There are already a
> significant number of stations mapped like this. I would also not write:
> "The location of the node is irrelevant." or "There is nothing wrong with
> putting the node near its entrance: it does not affect routing or anything
> else." but explain more careful where the node should be put, and what it's
> meant to know (if it wouldn't affect anything we could also not put it,
> no?).
>


I've seen there is this paragraph:
https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping#What_This_Affects
but it doesn't mention deprecating station areas. Can you please make a
complete summary of all things (tags and their intended meaning) that your
proposal

a) introduces (new)

b) changes

c) removes

Thank you,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Metro Mapping

[Martin Koppenhoefer]

sorry for asking so late, but why should we deprecate mapping subway
stations with a relation or a way and insist on nodes? There are already a
significant number of stations mapped like this. I would also not write:
"The location of the node is irrelevant." or "There is nothing wrong with
putting the node near its entrance: it does not affect routing or anything
else." but explain more careful where the node should be put, and what it's
meant to know (if it wouldn't affect anything we could also not put it,
no?).

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

[Tagging] Feature Proposal - Voting - Metro Mapping

[Ilya Zverev]

Hi everyone,

After six weeks of discussion and improvements, I am happy to start the voting 
on my proposal about mapping metro stations and lines:

https://wiki.openstreetmap.org/wiki/Proposed_features/Metro_Mapping

Note that the proposal mostly compiles mapping practices already in use and 
packs these into an easy to understand format with lists and illustrations. But 
it also introduces a few restrictions on stop_area relations, allows routes to 
not contain any tracks, and re-introduces stop_area_group relations, although 
these have been in use in some countries. Do read at least the "What This 
Affects" section.

I am pretty sure everyone who had questions had them answered on the discussion 
page, now 44 kilobytes long. But if you are in doubt, I'm ready to answer yours 
— in the mail or on the wiki discussion page.

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

Re: [Tagging] [Proposal] Boundary=marker

[henkevdb]

"The tag historic =* 
indicates historic significance. It has no implications for the current 
condition or use of the structure."


http://wiki.openstreetmap.org/wiki/Historic

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