Re: [Tagging] Tagging scrap yards, junkyards

[Paul Johnson]

On Wed, Jan 20, 2016 at 3:16 AM, Martin Koppenhoefer  wrote:

>
> 2016-01-20 2:03 GMT+01:00 Dave Swarthout :
>
>> After consulting Taginfo I've come up with these two tags for now:
>> landuse=industrial
>> industrial=scrap_yard
>>
>> Opinions, suggestions?
>>
>
>
>
> I'd prefer a "feature" tag, rather than a refinement of the landus
> attribute.
> What about man_made=scrap_yard?
>
> Not sure if it could also be considered a kind of works, e.g. we might see
> it as kind of a recycling plant?
> Shall we distinguish places which only do cars? We could also add a tag
> combination of
> shop=car_parts and
> second_hand=only ?  --> http://wiki.openstreetmap.org/wiki/Key:second_hand
>

This is how I view junkyards.  I consider scrapyards a different critter,
though, more in the recycling tagging schemes than anything, as that tends
to be where cars that were once in the junkyard go when the junkyards
decide it's cheaper use the space for a more complete unit than keep the
existing one on the lot.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key:priority

[Lauri Kytömaa]

On Wed, Jan 20, 2016 at 7:12 PM, Paul Johnson wrote:
> http://wiki.openstreetmap.org/wiki/Key:priority
>
> Would there be any major objection to expanding the priority key to include
> two way, multilane situations?  Example would be a two way street that was
> formerly a one-way street, and has signal timings as if it were a one-way
> street (thus the green wave turns into the red crawl if you're going the
> direction opposite the de-facto priority).

I'd rather keep that key solely for cases of "legal" priority of one direction
on the road segment in question. Both might effectively slow you down, but
in the "legal" case driving there is a different from "just slow" red
light crawl.

There have been some proposals in the past in the wiki for various
approaches to recording the fact that the delays are higher than could
be normally expected, but I'm not aware of any of them ever having
gained any support.

-- 
alv

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

Re: [Tagging] key:priority

[Paul Johnson]

On Sat, Jan 23, 2016 at 8:29 AM, Lauri Kytömaa  wrote:

> On Wed, Jan 20, 2016 at 7:12 PM, Paul Johnson wrote:
> > http://wiki.openstreetmap.org/wiki/Key:priority
> >
> > Would there be any major objection to expanding the priority key to
> include
> > two way, multilane situations?  Example would be a two way street that
> was
> > formerly a one-way street, and has signal timings as if it were a one-way
> > street (thus the green wave turns into the red crawl if you're going the
> > direction opposite the de-facto priority).
>
> I'd rather keep that key solely for cases of "legal" priority of one
> direction
> on the road segment in question. Both might effectively slow you down, but
> in the "legal" case driving there is a different from "just slow" red
> light crawl.
>
> There have been some proposals in the past in the wiki for various
> approaches to recording the fact that the delays are higher than could
> be normally expected, but I'm not aware of any of them ever having
> gained any support.


OK, I wonder if anybody's got a strategy for dealing with this situation
then.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Lauri Kytömaa]

On Wed, Mike N wrote:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.
> Many of these are from the US TIGER import, and must not be automatically
> removed.  They would go into alt_name , etc based on local knowledge.

I believe this is a good point to make, the origin for many of those tags.
While the number of uses is reason to keep them as-is, if a major slice
of them comes from an import, the ratio isn't a good reason to *recommend*
entering more of them.

Browsing through this thread I didn't notice one point, the fact that with
alt_name=a;b;.. all the names are/should be in the semicolon separated
list, i.e. even without any processing that separates the parts/names into
distinct records, searching would indicate that the searched-for name is
within the list of alternative names (in most cases/some countries, not
doing some sort of wildcard matching gives a bad user experience, esp.
if the local word or abbreviation for "street" is always at the beginning).
With name_1 and name_2 and name_9 you'd never know how many tags
you have to look for when indexing the db dump and changes.

Also, with name_[n] the original mapper and the next mappers have to
order the names with reasoning or just how they like them (subjective),
whereas with name=The Name + alt_name=other names the alternative
names are then equal with each other (a collection of alternative names).
What should be in the plain name tag is easier to agree on (especially if
the operator behind the named entity can be asked), than it would be to
agree on the sorting of the other known names.

-- 
alv

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

[Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[David Marchal]

Hello, there.

I tagged some bogs today, and I wondered: why does the wiki restricts bogs to 
"depressions that receive their water and nutrients from rainfall"? AFAIK, bogs 
are not necessarily isolated from water streams or bodies. Wikipedia talls 
about sloping bogs where running water is intercepted in the soil by plants; at 
least one well-known example comes to my mind, the lac de Lispach, in France, 
which is crossed by a river and still hosts a bog, and I saw 2 more exeamples 
today on a hike in the French mountains Vosges. Shouldn't this restriction be 
lifted, as it does not seem to be justified?

Furthermore, how could rain bring nutrients? It only brings, at least directly, 
water, and can only bring nutrients indirectly, like with erosion or bringing 
leaves.

Awaiting your answers,

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

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[Christoph Hormann]

On Saturday 23 January 2016, David Marchal wrote:
>
> I tagged some bogs today, and I wondered: why does the wiki restricts
> bogs to "depressions that receive their water and nutrients from
> rainfall"? AFAIK, bogs are not necessarily isolated from water
> streams or bodies. Wikipedia talls about sloping bogs where running
> water is intercepted in the soil by plants; 

There are of course all kind of boundary cases but the typical bog as 
common in many parts of northern Europe is rain fed.  In German we have 
the more specific term 'Regenmoor' which indicates this.  Mires fed by 
groundwater or water inflow from the outside are usually not bogs.  
See:

https://en.wikipedia.org/wiki/Mire

Of course wetland=bog is currently widely used incorrectly in OSM in 
that regard.  But assessing the specifics of water chemistry and plant 
communities is not easy so this is somewhat understandable.

> at least one well-known 
> example comes to my mind, the lac de Lispach, in France, which is
> crossed by a river and still hosts a bog, and I saw 2 more exeamples
> today on a hike in the French mountains Vosges. Shouldn't this
> restriction be lifted, as it does not seem to be justified?

Note this is not a restriction of OSM, it is simply what bogs are.  If 
you'd lift it you could simply drop most of the wetland=* distinction 
alltogether.

There are true bogs in the Vosges - like around Le Tanet and Gazon du 
Faing but it seems unlikely that what you observe at the Lac de Lispach 
is a bog.

> Furthermore, how could rain bring nutrients? It only brings, at least
> directly, water, and can only bring nutrients indirectly, like with
> erosion or bringing leaves.

Nutrients can arrive via air and through rainfall.  Dust from the Sahara 
has been found to be an important source of nutrients for the Amazon 
rain forest for example.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel]

On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa"  
wrote:
>I believe this is a good point to make, the origin for many of those
>tags.
>While the number of uses is reason to keep them as-is, if a major slice
>of them comes from an import, the ratio isn't a good reason to
>*recommend*
>entering more of them.

It's a pity that the us taginfo site is defunct; it would have given an 
interesting approximation of how many name_1 come from tiger. But I'm tired of 
this "most name_1 tags are from an import, they should be ignored" argument :
* coming from an import doesn't make name_1 wrong. It's a valid (IMHO superior) 
way of expressing multiple values.
* the most you can claim is that this import sometimes incorrectly assigned 
multiple values when there should be only one.
* there are plenty of uses of name_1 outside of tiger. While the ratio is 
unknown, a glance at the taginfo map shows that it isn't negligible.
* while popularity of a tag can on its own be enough to justify documenting the 
tag, it's never a good enough reason on it own to justify recomending it. 
Accordingly, the calls to recomend name_1 usage are not just b

>
>Browsing through this thread I didn't notice one point, the fact that
>with
>alt_name=a;b;.. all the names are/should be in the semicolon separated
>list, i.e. even without any processing that separates the parts/names
>into
>distinct records, searching would indicate that the searched-for name
>is
>within the list of alternative names (in most cases/some countries, not
>doing some sort of wildcard matching gives a bad user experience, esp.
>if the local word or abbreviation for "street" is always at the
>beginning).
>With name_1 and name_2 and name_9 you'd never know how many tags
>you have to look for when indexing the db dump and changes.
>
>Also, with name_[n] the original mapper and the next mappers have to
>order the names with reasoning or just how they like them (subjective),
>whereas with name=The Name + alt_name=other names the alternative
>names are then equal with each other (a collection of alternative
>names).
>What should be in the plain name tag is easier to agree on (especially
>if
>the operator behind the named entity can be asked), than it would be to
>agree on the sorting of the other known names.
>
>-- 
>alv
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Vincent Dp

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[moltonel 3x Combo]

Taped "send" to early, here's the rest of my email:

On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa" 
 wrote:
>I believe this is a good point to make, the origin for many of those
>tags.
>While the number of uses is reason to keep them as-is, if a major slice
>of them comes from an import, the ratio isn't a good reason to
>*recommend*
>entering more of them.

 It's a pity that the us taginfo site is defunct; it would have given an
 interesting approximation of how many name_1 come from tiger. But I'm tired
 of this "most name_1 tags are from an import, they should be ignored"
 argument :
 * coming from an import doesn't make name_1 wrong. It's a valid (IMHO
superior) way of expressing multiple values.
 * the most you can claim is that this import sometimes incorrectly
assigned multiple values when there should be only one.
 * there are plenty of uses of name_1 outside of tiger. While the
ratio is unknown, a glance at the taginfo map shows that it isn't
negligible.
 * while popularity of a tag can on its own be enough to justify
documenting the tag, it's never a good enough reason on it own to
justify recomending it. Accordingly, the calls to recomend name_1
usage are not just based on the tag's popularity.

>Browsing through this thread I didn't notice one point, the fact that
>with
>alt_name=a;b;.. all the names are/should be in the semicolon separated
>list, i.e. even without any processing that separates the parts/names
>into
>distinct records, searching would indicate that the searched-for name
>is
>within the list of alternative names (in most cases/some countries, not
>doing some sort of wildcard matching gives a bad user experience, esp.
>if the local word or abbreviation for "street" is always at the
>beginning).

That's a good corner-case example where a multivalue-unaware consumer
still gets some benefit of the multivalue if it is encoded using
semicolons. Of course it goes haywire again when trying to display the
value, and could cause other subtle issues, with stemming for example.

>With name_1 and name_2 and name_9 you'd never know how many tags
>you have to look for when indexing the db dump and changes.

I don't get that, or rather I don't get how it's different from never
knowing how many values you're going to get in the semicolon case.
Maybe you're thinking of an implementation that'd look for "name_1",
"name_2", etc explicitly for each variation ? No programmer in his/her
right mind would do that, (s)he'll regexp-match for "name_[0-9]+"
instead or (like for example Nominatim does) just match the beginning
of the string agains "name_".

>Also, with name_[n] the original mapper and the next mappers have to
>order the names with reasoning or just how they like them (subjective),
>whereas with name=The Name + alt_name=other names the alternative
>names are then equal with each other (a collection of alternative
>names).

Firstly, there's nothing that says "the order in which the values are
entered are their order of importance in real life". Wether the order
of the values matters or not is something that should be discussed on
a per-tag basis. The only tag that I know where this matters is
lanes=*, but it has its own complicated and well-defined
special-purpose syntax.

Secondly, the ordered_or_not situation is exactly the same with the
semicolon scheme as with the suffix scheme, neither can claim
superiority here.

>What should be in the plain name tag is easier to agree on (especially
>if
>the operator behind the named entity can be asked), than it would be to
>agree on the sorting of the other known names.

Again, there's no difference between the two schemes regarding the
tagging of the "default" value. It goes, on its own, in the "name" tag
and that's it. How you encode the default value does not influence how
you choose the default value. And yes, we should really discourage the
omission of a default value, whether it's by ommiting the plain "name"
tag or by putting semicolon-separated values in it instead of in
alt_name.

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

Re: [Tagging] wetland=bog, why only "receive their water and nutrients from rainfall"?

[Dave Swarthout]

I've seen that same sentence and IMO the Wiki goes too far in specifying
that rainfall brings nutrients. While it may do that, the amount of
nutrients is surely tiny relative to what comes from the ground. Plus,
there is no way for a mapper to determine whether rainfall is an important
component of the overall nutrient picture. I believe the two words "and
nutrients" should be removed from the Wiki.

This
email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Jan 24, 2016 at 4:37 AM, Christoph Hormann 
wrote:

> On Saturday 23 January 2016, David Marchal wrote:
> >
> > I tagged some bogs today, and I wondered: why does the wiki restricts
> > bogs to "depressions that receive their water and nutrients from
> > rainfall"? AFAIK, bogs are not necessarily isolated from water
> > streams or bodies. Wikipedia talls about sloping bogs where running
> > water is intercepted in the soil by plants;
>
> There are of course all kind of boundary cases but the typical bog as
> common in many parts of northern Europe is rain fed.  In German we have
> the more specific term 'Regenmoor' which indicates this.  Mires fed by
> groundwater or water inflow from the outside are usually not bogs.
> See:
>
> https://en.wikipedia.org/wiki/Mire
>
> Of course wetland=bog is currently widely used incorrectly in OSM in
> that regard.  But assessing the specifics of water chemistry and plant
> communities is not easy so this is somewhat understandable.
>
> > at least one well-known
> > example comes to my mind, the lac de Lispach, in France, which is
> > crossed by a river and still hosts a bog, and I saw 2 more exeamples
> > today on a hike in the French mountains Vosges. Shouldn't this
> > restriction be lifted, as it does not seem to be justified?
>
> Note this is not a restriction of OSM, it is simply what bogs are.  If
> you'd lift it you could simply drop most of the wetland=* distinction
> alltogether.
>
> There are true bogs in the Vosges - like around Le Tanet and Gazon du
> Faing but it seems unlikely that what you observe at the Lac de Lispach
> is a bog.
>
> > Furthermore, how could rain bring nutrients? It only brings, at least
> > directly, water, and can only bring nutrients indirectly, like with
> > erosion or bringing leaves.
>
> Nutrients can arrive via air and through rainfall.  Dust from the Sahara
> has been found to be an important source of nutrients for the Amazon
> rain forest for example.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging