Re: [Tagging] Feature Proposal - RFC - drinking_water

[Martin Koppenhoefer]

2014-04-02 22:18 GMT+02:00 Rudolf Martin :

> We can transfer "drinkable=" to "drinking_water=". The future tagging-
> scheme will have only one tag to indicate the existence and quality of
> drinking water.
>
> In the future the tag "drinkable=" can be deprecated.
>


sorry, if I come up a little late with this, and maybe it was already
mentioned by someone, actually, "drinking_water" and "drinkable" are not
exactly the same. If something is "drinking_water" I'd expect it to be
monitored and "certified" to be OK to drink (at least in Europe), while
water that is "drinkable" does more sound like "I (or someone else who has
told me) have drunk this and didn't get ill".

This doesn't invalid the "drinking_water=*" proposal of course, it just
might be a reason not to deprecate "drinkable", and it might also be a
reason not to perform automatic retagging.

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

Re: [Tagging] Feature Proposal - RFC - drinking_water

[Janko Mihelić]

2014-04-14 12:15 GMT+02:00 Martin Koppenhoefer :

>
> sorry, if I come up a little late with this, and maybe it was already
> mentioned by someone, actually, "drinking_water" and "drinkable" are not
> exactly the same. If something is "drinking_water" I'd expect it to be
> monitored and "certified" to be OK to drink (at least in Europe), while
> water that is "drinkable" does more sound like "I (or someone else who has
> told me) have drunk this and didn't get ill".
>
> This doesn't invalid the "drinking_water=*" proposal of course, it just
> might be a reason not to deprecate "drinkable", and it might also be a
> reason not to perform automatic retagging.
>

I think this is better resolved with a second tag like
"drinkable:source=official,sign,local_knowledge,London_Agency_For_Drinking_Water"...

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

Re: [Tagging] direction=forward/backward on nodes ?

[fly]

Am 14.04.2014 08:28, schrieb Peter Wendorff:
> Hi,
> 
> Am 13.04.2014 21:35, schrieb Steve Doerr:
>> I'm surprised that so many people are jumping to this conclusion. Let's
>> remember that a way is just a series of nodes in a particular order. So
>> a node is not necessarily an isolated object. 
> Agree
>> In many cases, it exists solely as part of a way. Thus the concept of 
>> direction is not
>> meaningless for a node which is part of a way. 
> Agree partly. It's not meaningless, but it get's ambiguous very often.

Exactly, it is not meaningless but ambiguous and can easily lead to
wrong results.

> Take traffic signals as one example where the direction might be used:
> Besides an intersection someone could add the traffic lights on the four
> individual ways (instead on the intersecting node itself).
> This matches the installation of the individual lights and the stop
> positions, but it produces wrong results without a direction tag.

> The drawback of that is, that someone crossing the intersection straight
> meets two traffic lights, which is wrong of course. The mapper therefore
> might decide to add direction-tags to them, as each traffic light node
> is relevant and applied only for one of the two directions.
> 
> Looks perfect now - all four traffic lights are mapped separately where
> they are, routing for cars works great (provided that the direction tag
> is known and supported by routers).
> 
> Enter of the next mapper: He want's to add the footways and cycleways
> that cross the streets using the pedestrian traffic lights integrated in
> the traffic lights mentioned above.
> As a result the nodes previously mapped with a direction are shared by
> two ways, and it's hard to determine what the direction tag refers to,
> as of course crossing for pedestrians is possible and meaningful for
> both directions.

Thanks for another example where cardinal coordinates work but
forward/backward fails.

>> I haven't examined any
>> uses of the tag on a node, but I can imagine, for instance, that a node
>> in a way with a direction attribute might be used to represent a
>> road-sign that applies only to traffic on the way passing that node in a
>> particular direction.
> For other traffic signs it's the same, and that's why we usually map the
> road signs meaning on the road that is affected by it. (The sign itself
> may be mapped as such, as an obstacle and a physical object next to the
> street), while maximum speed, maximum dimensions (width, height,
> weight), oneway access, access restrictions and so on are mapped on the
> where they hold.
> 
> Here the direction is useful (look at the oneway=yes tag), meaningful
> and not ambiguous; on nodes it is or get's very lightly without tagging
> mistakes.

Ok, we can take a split between unconnected nodes on the
left-/right-hand-side of the road and nodes being part of a way. The
first are less ambigious but you still need to know the driving
directions where as the latter ones just won't work properly with
forward/backward.

To make it less ambigious and easier I would deprecate forward/backward
completely for nodes and advice to use cardinal coordinates for all nodes.

fly



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

Re: [Tagging] direction=forward/backward on nodes ?

[John Packer]

>
> To make it less ambiguous and easier I would deprecate forward/backward
> completely for nodes and advice to use cardinal coordinates for all nodes.

I think that would be ok for traffic_sign:direction=*,
but not for traffic_signals:direction=* or direction=* when used with
highway=stop/give_way, because it wouldn't be as easy to know to which
highway's direction the highway=traffic_signals/stop/giveway applies to.

IMHO we should use relations for cases like this (see turn restrictions,
> via nodes, for reference)

+1



2014-04-14 8:44 GMT-03:00 fly :

> Am 14.04.2014 08:28, schrieb Peter Wendorff:
> > Hi,
> >
> > Am 13.04.2014 21:35, schrieb Steve Doerr:
> >> I'm surprised that so many people are jumping to this conclusion. Let's
> >> remember that a way is just a series of nodes in a particular order. So
> >> a node is not necessarily an isolated object.
> > Agree
> >> In many cases, it exists solely as part of a way. Thus the concept of
> direction is not
> >> meaningless for a node which is part of a way.
> > Agree partly. It's not meaningless, but it get's ambiguous very often.
>
> Exactly, it is not meaningless but ambiguous and can easily lead to
> wrong results.
>
> > Take traffic signals as one example where the direction might be used:
> > Besides an intersection someone could add the traffic lights on the four
> > individual ways (instead on the intersecting node itself).
> > This matches the installation of the individual lights and the stop
> > positions, but it produces wrong results without a direction tag.
>
> > The drawback of that is, that someone crossing the intersection straight
> > meets two traffic lights, which is wrong of course. The mapper therefore
> > might decide to add direction-tags to them, as each traffic light node
> > is relevant and applied only for one of the two directions.
> >
> > Looks perfect now - all four traffic lights are mapped separately where
> > they are, routing for cars works great (provided that the direction tag
> > is known and supported by routers).
> >
> > Enter of the next mapper: He want's to add the footways and cycleways
> > that cross the streets using the pedestrian traffic lights integrated in
> > the traffic lights mentioned above.
> > As a result the nodes previously mapped with a direction are shared by
> > two ways, and it's hard to determine what the direction tag refers to,
> > as of course crossing for pedestrians is possible and meaningful for
> > both directions.
>
> Thanks for another example where cardinal coordinates work but
> forward/backward fails.
>
> >> I haven't examined any
> >> uses of the tag on a node, but I can imagine, for instance, that a node
> >> in a way with a direction attribute might be used to represent a
> >> road-sign that applies only to traffic on the way passing that node in a
> >> particular direction.
> > For other traffic signs it's the same, and that's why we usually map the
> > road signs meaning on the road that is affected by it. (The sign itself
> > may be mapped as such, as an obstacle and a physical object next to the
> > street), while maximum speed, maximum dimensions (width, height,
> > weight), oneway access, access restrictions and so on are mapped on the
> > where they hold.
> >
> > Here the direction is useful (look at the oneway=yes tag), meaningful
> > and not ambiguous; on nodes it is or get's very lightly without tagging
> > mistakes.
>
> Ok, we can take a split between unconnected nodes on the
> left-/right-hand-side of the road and nodes being part of a way. The
> first are less ambigious but you still need to know the driving
> directions where as the latter ones just won't work properly with
> forward/backward.
>
> To make it less ambigious and easier I would deprecate forward/backward
> completely for nodes and advice to use cardinal coordinates for all nodes.
>
> fly
>
>
>
> ___
> 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] noexit=yes on ways ? (a typical OSM story)

[fly]

Am 13.04.2014 22:36, schrieb Mike N:
> On 4/13/2014 4:21 PM, Pieren wrote:
>> It's just a long and onerous discussion to find dubious arguments
>> against this tag on ways.
> 
>   It's really an argument against needless clutter in the Wiki.  Why not
> add noexit to a relation to show some condition?  To trees to show that
> once entered, there's only one way out?   It's not wrong and the tools
> ignore it so why not?
> 
>  The best documentation is often the most brief - including just what is
> needed but nothing else to add confusion.

Everyone can still tag how she/he likes to despite what is written on
the wiki.

Anyway, we really want to encourage mappers to map noexit=yes on nodes
and not on ways and we need to make aware of the difference between the
traffic sign for a dead end road and the meaning of noexit=yes.

Noexit=yes tagged on ways might no be wrong but it makes it harder to
tell the difference. In certain situations it gets ambiguous and overall
makes it more complex.

Conclusion, I am still in favour of tagging it only on the end node and
to update the wiki accordingly.

cu fly


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

[Tagging] noexit=yes : the outcome

[André Pirard]

  
  
Hi,

Side note: Please note that I just found two versions of the "Use
the noexit=yes tag..." text. One ahead that says that it must be
used only on nodes and the former one inside that says that it can
be used on ways too.  I left the newcomer where it was: ahead but
stroked out at your disposal.  Fun, fun, fun.

So, Pieren added to that page that noexit=yes can be tagged on ways.
He did this because contributors do that tagging, "open-mindedly".
Friends pointed out quite rightly that what the specification
explains cannot possibly be tagged on a way.  It's inescapable.
Insistence to make the impossible come true generated an endless,
fruitless discussion.

As I find that understanding the meaning of a tag on the map is
important, I pointed out that no one had asked why the contributors
tagged noexit=yes that way and that the only clues came from those
who spoke up: "I had not consulted the specification [for a long
time]", "A friend recommended that", 'I thought that I was tagging a
No Exit sign", ...
Except for the last, they don't explain the meaning of their tags,
but one thing appears certain: the meaning is different from the
specification which (btw/because it) is vastly misunderstood.
And what else, if they don't have the subtleties of the
specification in mind, could it be that "the No Exit sign"?

So, to make this explanation short and kill two birds with one
stone, please
  read, I modified the wiki as follows:
The noexit=yes tag has two meanings
  according to whether it's on a node or on a way:
  
  On a node:  present text, but  "Use ... on a node"
  
  On a way:  Use the noexit=yes
  tag on a way  to indicate that the way is
  leading to a dead end.


Remarks (here):

  Please note that it would logically be necessary to indicate
which direction leads to the dead end.
  The second definition is not exactly complete. Some
contributors tag noexit=yes all over a small, meshed
neighborhood that contains a dead end road, but not necessarily
if there's only one entry road. Well, putting it short again, a
more appropriate description in that case (when the said
way/road crosses junctions) would be: "to indicate that one will
have to return to the road through which one came into this
place".
  

I'm leaving to the noexit-on-ways specialist(s) to decide of the
exact usage/definition and of the contents of its paragraph.

But please, no more or a minimum of discussion about noexit-on-nodes
which stands very logical in its shoes.
The only thing I have to say is that its new rendering shows at one
end of a road the road sign that's in reality at the other end and
that this doesn't help much the on-a-way-sister-spec to show that
direction, if used jointly.

Is everybody happy now?

Cheers,


  

  André.

  


  

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

Re: [Tagging] noexit=yes : the outcome

[fly]

Am 14.04.2014 14:07, schrieb André Pirard:
> Hi,
> 
> Side note: Please note that I just found two versions of the "Use the
> noexit=yes tag..." text. One ahead that says that it must be used only
> on nodes and the former one inside that says that it can be used on ways
> too.  I left the newcomer where it was: ahead but stroked out at your
> disposal.  Fun, fun, fun.
> 
> So, Pieren added to that page that noexit=yes can be tagged on ways.
> He did this because contributors do that tagging, "open-mindedly".
> Friends pointed out quite rightly that what the specification explains
> cannot possibly be tagged on a way.  It's inescapable.
> Insistence to make the impossible come true generated an endless,
> fruitless discussion.
> 
> As I find that understanding the meaning of a tag on the map is
> important, I pointed out that no one had asked why the contributors
> tagged noexit=yes that way and that the only clues came from those who
> spoke up: "I had not consulted the specification [for a long time]", "A
> friend recommended that", 'I thought that I was tagging a No Exit sign", ...
> Except for the last, they don't explain the meaning of their tags, but
> one thing appears certain: the meaning is different from the
> specification which (btw/because it) is vastly misunderstood.
> And what else, if they don't have the subtleties of the specification in
> mind, could it be that "the No Exit sign"?
> 
> So, to make this explanation short and kill two birds with one stone,
> please read , I modified
> the wiki as follows:
>> The noexit=yes tag has two meanings according to whether it's on a
>> node or on a way:
>>
>> On a node:  present text, but  "Use ... on a node"
>>
>> On a way:  Use the *noexit*=yes tag on a way Way
>>  to indicate that the
>> way is leading to a dead end.
> 
> Remarks (here):
> 
>   * Please note that it would logically be necessary to indicate which
> direction leads to the dead end.
>   * The second definition is not exactly complete. Some contributors tag
> noexit=yes all over a small, meshed neighborhood that contains a
> dead end road, but not necessarily if there's only one entry road.
> Well, putting it short again, a more appropriate description in that
> case (when the said way/road crosses junctions) would be: "to
> indicate that one will have to return to the road through which one
> came into this place".
> 
> I'm leaving to the noexit-on-ways specialist(s) to decide of the exact
> usage/definition and of the contents of its paragraph.
> 
> But please, no more or a minimum of discussion about noexit-on-nodes
> which stands very logical in its shoes.
> The only thing I have to say is that its new rendering shows at one end
> of a road the road sign that's in reality at the other end and that this
> doesn't help much the on-a-way-sister-spec to show that direction, if
> used jointly.
> 
> Is everybody happy now?

Thanks, for your work.
One minor issue is the paragraph about "When not to use", in particular
the advice to use highway=turning_circle instead. It is OK to mention
turning_cirles but noexit might still be useful and there should be no
exclusion for this situation.


Now, we have two different meanings but I still wonder if we need to tag
the second one on ways or if we should state that this meaning is not
really useful and regarded deprecated and only advice to tag noexit=yes
on nodes.

Another solution which came to my mind is to deprecate noexit completely
and use no_exit as replacement and make sure this one is only valid for
nodes.

Cheers fly

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

Re: [Tagging] direction=forward/backward on nodes ?

[Tod Fitch]

On Apr 13, 2014, at 11:28 PM, Peter Wendorff wrote:

> Agree partly. It's not meaningless, but it get's ambiguous very often.
> Take traffic signals as one example where the direction might be used:
> Besides an intersection someone could add the traffic lights on the four
> individual ways (instead on the intersecting node itself).
> This matches the installation of the individual lights and the stop
> positions, but it produces wrong results without a direction tag.
> 
> The drawback of that is, that someone crossing the intersection straight
> meets two traffic lights, which is wrong of course. The mapper therefore
> might decide to add direction-tags to them, as each traffic light node
> is relevant and applied only for one of the two directions.
> 
> Looks perfect now - all four traffic lights are mapped separately where
> they are, routing for cars works great (provided that the direction tag
> is known and supported by routers).
> 
> Enter of the next mapper: He want's to add the footways and cycleways
> that cross the streets using the pedestrian traffic lights integrated in
> the traffic lights mentioned above.
> As a result the nodes previously mapped with a direction are shared by
> two ways, and it's hard to determine what the direction tag refers to,
> as of course crossing for pedestrians is possible and meaningful for
> both directions.

Hmmm. The examples I've seen on the map and as I recall the traffic_signals 
portion of the wiki for "complex intersections" the traffic signal node is not 
placed where the signal is but rather where a vehicle must stop for the signal.

That is prior to the crosswalk. So if a second mapper comes along and adds 
footways then those footways should not go through the vehicle traffic signal 
nodes. I haven't seen an example but it seems to me that the pedestrian signal 
should be on the new footway where a pedestrian should wait. So there should be 
no confusion as to the meaning of a traffic_signals:direction=forward/backward 
tag.

On Apr 14, 2014, at 4:44 AM, fly wrote:

> Ok, we can take a split between unconnected nodes on the
> left-/right-hand-side of the road and nodes being part of a way. The
> first are less ambigious but you still need to know the driving
> directions where as the latter ones just won't work properly with
> forward/backward.
> 
> To make it less ambigious and easier I would deprecate forward/backward
> completely for nodes and advice to use cardinal coordinates for all nodes.
> 
At least for the case of traffic_signals:direction=forward/backward, the use 
should be unambiguous as they are currently defined.

Cardinal directions could work but I wonder about errors and ambiguity that 
might crop up in the consumers of this data. I suppose that there might be some 
very detailed map renderers that wish to show all signals, signs, etc. But I've 
assumed that this information was primarily intended to make routing more 
accurate. Forward/backward along the direction of a way is information any 
routing algorithm has immediately at hand. But what about a road that makes an 
sharp bend just before the intersection? We sometimes have these here where two 
roads come in at an angle and the traffic engineers decided to make the 
intersection as close to a right angle as possible for safety reasons. I can 
see a human mapper assuming the tangent the road has before and after the 
intersection as the cardinal direction but routing software might not easily 
figure that out.

Is there anyone following this thread that is doing work that consumes these 
tags? If so what is easier and less error prone to process?

Regarding using relations, given the multitude of human errors introduced into 
existing relations by people making changes, I'd argue that very good support 
for traffic signal relations be built into all editors if this is the direction 
people wish to take. That does not seem to be the case currently for many types 
of relations, even simple ones like route relations.

-Tod





smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging