Re: [Tagging] Best practices regarding implied tags

[Paul Johnson]

On Sun, Sep 20, 2020 at 11:58 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> The previous responses are focusing on the benefit of adding explicit tags
> in situations where the current tagging is ambiguous.
>
> Certainly there is a benefit of adding "oneway=no" on all two-way roads
> and "oneway=yes" on motorways to make the situation explicit.
>
> But the original question was about whether or not we should add
> "man_made=utility_pole" + "utility=power" to current power poles.
>

Well, does narrow it down from a neighborhood pole that might have cable
television or carry the PSTN.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Best practices regarding implied tags

[Martin Koppenhoefer]

sent from a phone

> On 20. Sep 2020, at 18:59, Joseph Eisenberg  
> wrote:
> 
> Does anyone think that it is a good idea to add those two new tags in this 
> particular situation?


utility=power seems to be a redundant concept in general (you can see which 
kind of lines are attached - if they are mapped), here all the more.

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

Re: [Tagging] Best practices regarding implied tags

[Martin Koppenhoefer]

sent from a phone

> On 20. Sep 2020, at 18:59, Joseph Eisenberg  
> wrote:
> 
> Does anyone think that it is a good idea to add those two new tags in this 
> particular situation?


while I am personally not unsatisfied with power=pole I could understand that 
people who want to deprecate this tag in favor of man_made=utility_pole (17200 
as of yesterday)
would want to add it.

I could see some benefit from such a switch (better supports multiple utilities 
on the same pole, no need to decide on kind of utility if you don’t know it).

Cheers Martin 



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

Re: [Tagging] Best practices regarding implied tags

[Joseph Eisenberg]

The previous responses are focusing on the benefit of adding explicit tags
in situations where the current tagging is ambiguous.

Certainly there is a benefit of adding "oneway=no" on all two-way roads and
"oneway=yes" on motorways to make the situation explicit.

But the original question was about whether or not we should add
"man_made=utility_pole" + "utility=power" to current power poles.

These are currently tagged "power=pole" which is clearly defined as a power
utility pole, so adding the two other tags does not provide any information.

Does anyone think that it is a good idea to add those two new tags in this
particular situation?

-Joseph Eisenberg

On Sun, Sep 20, 2020 at 9:46 AM François Lacombe 
wrote:

> Thank you all for replies
>
> Then the current proposal sounds to be ok regarding what is said upside.
> I admit to automatically adding implied tags when importing data covered
> by the proposal, so no apparent problem is mappers add them explicitly.
>
> All the best
>
> François
>
> Le jeu. 17 sept. 2020 à 15:11, Kevin Broderick  a
> écrit :
>
>> +1.
>>
>> Explicit tagging indicates a level of confidence not generally associated
>> with implicit tagging. While there's certainly an 'ad nauseum' level of
>> doing so (e.g. adding surface=paved, motor_vehicle=yes to highway=motorway
>> in the U.S. would be kinda silly, IMO), there are plenty of cases where a
>> primary tag generally implies something about the tagged object but doesn't
>> guarantee it. I'd point to the recent discussion of access= on driveways as
>> an example; while most driveways allow for certain types of access by
>> default, it's far from guaranteed—there may be a no-trespassing sign or a
>> locked gate, and explicitly indicating the lack of such in the access
>> tagging is helpful. (Adding the implied value without survey or other
>> definitive knowledge is not, as then you express a higher degree of
>> confidence than actually exists in the data).
>>
>> On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson  wrote:
>>
>>> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe <
>>> fl.infosrese...@gmail.com> wrote:
>>>
 Is that completely wrong or mappers could eventually add implied tags
 if they want to?
 The proposal currently states they are optional and it won't raise an
 error if mappers add them beside mandatory tags.

>>>
>>> No, it's not wrong to add implied tags explicitly.  It's actually
>>> encouraged in some cases where the implicit tag is not consumable by
>>> automated system (such as the "none" default for turn:lanes tends to be
>>> ambiguous between "you can't turn from this lane" and "you can't use this
>>> lane" and "there's an implicit but unspecified implication that isn't
>>> painted on the ground"), or access defaults (such as in the US where
>>> bicycle=* and foot=* varies a lot on highway=motorway)
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> Kevin Broderick
>> k...@kevinbroderick.com
>> ___
>> 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] Best practices regarding implied tags

[François Lacombe]

Thank you all for replies

Then the current proposal sounds to be ok regarding what is said upside.
I admit to automatically adding implied tags when importing data covered by
the proposal, so no apparent problem is mappers add them explicitly.

All the best

François

Le jeu. 17 sept. 2020 à 15:11, Kevin Broderick  a
écrit :

> +1.
>
> Explicit tagging indicates a level of confidence not generally associated
> with implicit tagging. While there's certainly an 'ad nauseum' level of
> doing so (e.g. adding surface=paved, motor_vehicle=yes to highway=motorway
> in the U.S. would be kinda silly, IMO), there are plenty of cases where a
> primary tag generally implies something about the tagged object but doesn't
> guarantee it. I'd point to the recent discussion of access= on driveways as
> an example; while most driveways allow for certain types of access by
> default, it's far from guaranteed—there may be a no-trespassing sign or a
> locked gate, and explicitly indicating the lack of such in the access
> tagging is helpful. (Adding the implied value without survey or other
> definitive knowledge is not, as then you express a higher degree of
> confidence than actually exists in the data).
>
> On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson  wrote:
>
>> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Is that completely wrong or mappers could eventually add implied tags if
>>> they want to?
>>> The proposal currently states they are optional and it won't raise an
>>> error if mappers add them beside mandatory tags.
>>>
>>
>> No, it's not wrong to add implied tags explicitly.  It's actually
>> encouraged in some cases where the implicit tag is not consumable by
>> automated system (such as the "none" default for turn:lanes tends to be
>> ambiguous between "you can't turn from this lane" and "you can't use this
>> lane" and "there's an implicit but unspecified implication that isn't
>> painted on the ground"), or access defaults (such as in the US where
>> bicycle=* and foot=* varies a lot on highway=motorway)
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Kevin Broderick
> k...@kevinbroderick.com
> ___
> 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] "width" on streets: Time for a recommendation

[Tobias Zwick]

>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. 

I don't think this is true anymore. Did you try out "Measure" or any other 
ARCore/ARKit-based measuring app? Example:

https://m.youtube.com/watch?v=qz0YJ0s4JLM

Am 20. September 2020 00:01:00 MESZ schrieb Volker Schmidt :
>Some thoughts that trouble me...
>
>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. I guess that most width
>values in the database are reality estimates (I don't think that this
>is an
>unjustified extrapolation from my own mapping - 99.9% of my width
>tagging
>based on estimates). Estimates are relatively easy for narrow roads if
>you
>have street-level photographs. They become much more unreliable for
>wider
>roads. I solve this by using only lanes count for wider roads. Precise
>width measurements are difficult to impossible, but fortunately they
>are
>also less important than the lanes count for the end user.
>
>The discussion about including/excluding sidepaths/sidewalks becomes
>also
>irrelevant if we were only to use the lanes count as that counts only
>motor
>traffic lanes.
>
>Would also overcome another aspect of the width definition: If we use
>width
>for the entire road, i.e motor-traffic lanes, shoulders, sidewalks,
>cycle
>lanes/tracks/paths, tree rows between foot and cycleway, ... we do in
>the
>end not know enough about the the actual widths of the different
>component
>"lanes".
>
>Width values are useful and easy to estimate from street-level
>photographs
>for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m
>precision.
>
>We need in any case a good system for regrouping parallel ways that
>belong
>to the same street.
>A relation seems to me the better option, but in any case, whatever
>approach we pick now, we will face an nearly impossible amount of
>retrofitting work. Anything we do on this from now will not make the
>problem go away with the existing stock of data.
>
>Volker
>
>
>
>
>
>
>
>
>
>Virus-free.
>www.avast.com
>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>On Fri, 18 Sep 2020 at 22:35, Tobias Knerr  wrote:
>
>> On 17.09.20 02:35, Taskar Center wrote:
>> > This is yet another example why "sticking" the sidewalks onto the
>> > highway (as a tag) rather than mapping them as separate ways is
>> > appearing to be less and less practical. Please see our sidewalk
>schema
>> > proposal
>> >
>
>> > from several years ago.
>>
>> Your sidewalk proposal unfortunately doesn't really address the
>crucial
>> shortcoming of separately mapped sidewalks: The lack of a reliable
>> mechanism for figuring out which section of road a given sidewalk way
>> belongs to.
>>
>> I agree that we should be able to give sidewalks their own geometry,
>but
>> we _also_ need the relationship between sidewalk and road. So far,
>all
>> the proposals attempting to support the former end up sacrificing the
>> latter.
>>
>> There have been some promising discussions recently around the
>> sidepath_of idea, but that's still just brainstorming. Until a
>practical
>> solution is found and actually used in the database, sidewalk mapping
>> will remain a choice between two options that are broken in different
>ways.
>>
>> As for the main issue of the thread: I would welcome a clear
>definition
>> for the meaning of width. In my own mapping and when writing the
>> relevant code in OSM2World, I have counted sidewalks etc. as part of
>the
>> road's width if they are mapped as tags on the main way. But I would
>of
>> course change that if there finally was a documented and widely
>> agreed-upon recommendation. I don't care so much which one it is -
>but
>> we need one.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

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