Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

There's historic precident outside Kansas as well.  What is now the Arroyo
Seco Freeway in LA originally opened as a pinewood, limited access,
elevated bicycle tollway under the name of California Cycleway sometime
around 1890.

On Mon, Sep 22, 2014 at 9:32 AM, John F. Eldredge 
wrote:

> I am American, and the concept of a toll cycleway is not one I have
> encountered either.
>
>
>
>
> On September 22, 2014 3:55:03 AM p...@trigpoint.me.uk wrote:
>
>  Toll? I assume that means the same in US English as in UK English?
>>
>> You really have to pay to use cycleways? How is the toll collected and
>> enforced?
>>
>> Phil (trigpoint )
>>
>> On Sun Sep 21 2014 23:36:04 GMT+0100 (BST), Paul Johnson wrote:
>> > Along with this, I really hope renderers start computing surface=* and
>> > toll=* values for ALL ways.  I say this since "surface=asphalt,
>> > highway=cyclway" is an exceptionally rare combination in the midwestern
>> US,
>> > but "highway=cycleway, surface=gravel, toll=yes" is not.
>> >
>> > On Sun, Sep 21, 2014 at 2:29 AM, Pee Wee  wrote:
>> >
>> > > -1
>> > >
>> > > A renderer/router is perfectly capable of deciding what he thinks is
>> > > paved/unpaved. He can decide whether he calls gravel / fine_gravel
>> paved or
>> > > unpaved. Do not leave the decision paved/unpaved  up to the mapper.
>> Map
>> > > what you see. As you may have guessed I prefer surface=asphalt over
>> > > surface=paved since the last one could mean that it is gravel.
>> > >
>> > > Cheers
>> > > PeeWee32
>> > >
>> > > 2014-09-21 2:49 GMT+02:00 David Bannon :
>> > >
>> > >>
>> > >> yes, agree strongly. Surface= is a good tag, provides important info
>> but
>> > >> it is far too fine grained. Someone setting up a route cannot be
>> > >> expected to sift through all the possible values.
>> > >>
>> > >> Similarly, we may well have a chance to get the renderers to respect
>> a
>> > >> clear, on/off tag like the proposed and show it on the maps too.
>> > >>
>> > >> I see no problem with both tags being used.
>> > >>
>> > >> I think sometimes we put too much detail in the database and risk
>> making
>> > >> the data unusable because of that. Mention making the data usable, we
>> > >> see charges of "tagging for the renderer". But this is important, I
>> have
>> > >> detailed life threatening issues resulting from unclear maps. This
>> > >> proposal will provide valuable, dare I say "usable" info for
>> consumers !
>> > >>
>> > >> David
>> > >>
>> > >> On Sat, 2014-09-20 at 23:42 +0200, Tomasz Kaźmierczak wrote:
>> > >> > Hello all,
>> > >> >
>> > >> > I've posted the below message on the forum, and have been directed
>> > >> > from there to this mailing list, thus re-posting it.
>> > >> >
>> > >> > Idea
>> > >> >
>> > >> > I would like to suggest making the paved key for highways (and
>> > >> > probably other types of elements) official. Taginfo for paved:
>> > >> > http://taginfo.openstreetmap.org/keys/paved#values
>> > >> >
>> > >> > The above shows that the key is already being used, but the Wiki
>> > >> > doesn't describe this key, instead redirecting Key:paved to the
>> > >> > article about Key:surface.
>> > >> >
>> > >> > Rationale
>> > >> >
>> > >> > Currently, the surface key is being used as a way of saying that a
>> > >> > given highway is paved or unpaved, but often the value for the
>> surface
>> > >> > key is not a generic paved or unpaved, but a specific surface type
>> is
>> > >> > given.This is of course very useful for describing the particular
>> > >> > surface type a given highway has. However, in some cases, a simple
>> > >> > information on just whether a highway is paved or not, would be
>> very
>> > >> > useful. One such case would be navigation software – if a user
>> chooses
>> > >> > to avoid unpaved roads, the software can check the value of the
>> > >> > surface key, but in practice most (all?) of the navigation software
>> > >> > only checks for a subset of all the possible values the surface key
>> > >> > can have. This leads to incorrect (in terms of what the user
>> expects)
>> > >> > navigation when, for example, the surface is set to some value that
>> > >> > describes an unpaved road, not recognized by the navigation
>> software –
>> > >> > if the software assumes that all highways are paved, unless
>> explicitly
>> > >> > stated otherwise (by recognized values of known keys), then, in
>> > >> > consequence, it assumes that the road in question is paved.
>> > >> >
>> > >> > If the paved key was widely used, then the navigation software
>> would
>> > >> > have a simple and clear way of checking whether a given road is
>> paved
>> > >> > or not. The default value of the paved key for highways could be
>> yes,
>> > >> > so that it would be consistent with the assumption that highways in
>> > >> > general are paved.
>> > >> >
>> > >> > I don't mean that we should stop using the paved and unpaved values
>> > >> > for the surface key – I'm sure those generic values are useful in
>> some
>> > >> > cases. Howev

Re: [Tagging] New key proposal - paved=yes/no

[Paul Johnson]

On Mon, Sep 22, 2014 at 3:54 AM,  wrote:

> Toll? I assume that means the same in US English as in UK English?
>

Yes, as in you need to pay a fee to travel on it to use it.


> You really have to pay to use cycleways? How is the toll collected and
> enforced?
>

I've encountered them in a couple places.  In Oregon, these are as far as
I'm aware, exclusively on ferries, in which you hand off your quarter (or
is it a half dollar now?) to the ferry operator.  In Kansas, it's a receipt
system and you have unlimited travel for the X number of days you prepaid
for.  It's not uncommon (possibly preferred?) for people to tape their
receipt to the bars.  Fares are checked by local and county police along
the route as well as regular patrols by the KHP, and I think you're allowed
to camp short-term along the right of way in designated spots.

Basically, in the Kansas case, the cycleways are long distance, largely
extremely rural, and the fares pay for a) safety patrols to ensure the ways
are clear, not washed out, not flooded, nobody died or got stranded along
the way, and b) toll collection.

Not to say that the Kansas model would scale or is particularly well
enforced, I'm just saying Kansas has a lot of toll cycleway mileage and
it's something to be aware of.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] name and brand tags

[Paul Johnson]

I'm pretty sure operator=Batman wouldn't work for name=Batman's Good Food,
which is brand=Phillips 66...

On Wed, Sep 24, 2014 at 9:24 AM, Richard Welty 
wrote:

>
> On 09/24/2014 10:22 AM, Philip Barnes wrote:
>
>> Besides in my experience petrol stations do have a name, it may not be
>> obvious until you are close to the shop. Other than supermarket petrol
>> stations, the name of the petrol station will appear on your receipt, not
>> the name of the oil company. Phil (trigpoint)
>>
>
> true, but are we better off with that in operator= than in
> name= ?
>
> richard
>
>
>
> ___
> 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] Forest vs Wood

[johnw]

Or make Highway=trunk a little brighter green, so it stands out against the 
wood even more.


On Sep 25, 2014, at 8:59 AM, johnw  wrote:

> If we are going to use landcover=forest/wood/ to unify the meaning of "trees 
> on the ground",  then the current implementation of forest - the bright green 
> with tree markers - should probably use the same color of "wood" green, as 
> they are all just a large amount of trees.  The forest still uses the the 
> tree icon overlay, to show usage, just like Nature Reserve has the NR 
> overlay, or Zoo with the Z overlay. 
> 
> If we're gonna seperate conditions on the ground from usage, then it seems 
> that having a single color that means "trees" is a good idea. 
> 
> That would also free up a more visible green for another use on the map, 
> maybe something distinctly manmade, like crop=rice, crop=corn, 
> crop=vegetable, etc. (and leave the brown for wheat). Just an idea.
> 
> 
> There are large sections of cleared and replanted cedars here in Japan, and 
> it is actively logged - so it has a different land use - but it is al just 
> hills covered with trees. The only time most people notice or care about the 
> difference is in winter, when the cedars stay dark green and the native mixed 
> maple forest loses it's leaves - the mountains become grey and black striped. 
> 
> Javbw
> 
> On Sep 25, 2014, at 4:18 AM, Andrew Guertin  wrote:
> 
>> On 09/24/2014 01:10 PM, Martin Koppenhoefer wrote:
>>> 2014-09-24 18:22 GMT+02:00 John Sturdy :
>>> 
 On Thu, Aug 21, 2014 at 9:29 PM, Andrew Guertin
  wrote:
 
> landcover=forest anywhere there's trees on the ground
 
>>> there is already a proposal in the wiki and the key is in use:
>>> http://taginfo.openstreetmap.org/keys/landcover#values
>>> 
>>> please not ~10k trees vs. 11 forest (i.e. factor 1000)
>> 
>> Sure, landcover=trees does seem better.
>> 
>> I wrote that out because it had been bouncing around in my head for a while, 
>> but I hadn't put much research into it. I'm not surprised people have 
>> pointed out problems with it (though I still think it's a good starting 
>> point and an improved version would be a good way to fix our problems).
>> 
>> --Andrew
>> 
>> ___
>> 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] Forest vs Wood

[johnw]

If we are going to use landcover=forest/wood/ to unify the meaning of "trees on 
the ground",  then the current implementation of forest - the bright green with 
tree markers - should probably use the same color of "wood" green, as they are 
all just a large amount of trees.  The forest still uses the the tree icon 
overlay, to show usage, just like Nature Reserve has the NR overlay, or Zoo 
with the Z overlay. 

If we're gonna seperate conditions on the ground from usage, then it seems that 
having a single color that means "trees" is a good idea. 

That would also free up a more visible green for another use on the map, maybe 
something distinctly manmade, like crop=rice, crop=corn, crop=vegetable, etc. 
(and leave the brown for wheat). Just an idea.


There are large sections of cleared and replanted cedars here in Japan, and it 
is actively logged - so it has a different land use - but it is al just hills 
covered with trees. The only time most people notice or care about the 
difference is in winter, when the cedars stay dark green and the native mixed 
maple forest loses it's leaves - the mountains become grey and black striped. 

Javbw

On Sep 25, 2014, at 4:18 AM, Andrew Guertin  wrote:

> On 09/24/2014 01:10 PM, Martin Koppenhoefer wrote:
>> 2014-09-24 18:22 GMT+02:00 John Sturdy :
>> 
>>> On Thu, Aug 21, 2014 at 9:29 PM, Andrew Guertin
>>>  wrote:
>>> 
 landcover=forest anywhere there's trees on the ground
>>> 
>> there is already a proposal in the wiki and the key is in use:
>> http://taginfo.openstreetmap.org/keys/landcover#values
>> 
>> please not ~10k trees vs. 11 forest (i.e. factor 1000)
> 
> Sure, landcover=trees does seem better.
> 
> I wrote that out because it had been bouncing around in my head for a while, 
> but I hadn't put much research into it. I'm not surprised people have pointed 
> out problems with it (though I still think it's a good starting point and an 
> improved version would be a good way to fix our problems).
> 
> --Andrew
> 
> ___
> 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] Forest vs Wood

[Andrew Guertin]

On 09/24/2014 01:10 PM, Martin Koppenhoefer wrote:

2014-09-24 18:22 GMT+02:00 John Sturdy :


On Thu, Aug 21, 2014 at 9:29 PM, Andrew Guertin
 wrote:


landcover=forest anywhere there's trees on the ground



there is already a proposal in the wiki and the key is in use:
http://taginfo.openstreetmap.org/keys/landcover#values

please not ~10k trees vs. 11 forest (i.e. factor 1000)


Sure, landcover=trees does seem better.

I wrote that out because it had been bouncing around in my head for a 
while, but I hadn't put much research into it. I'm not surprised people 
have pointed out problems with it (though I still think it's a good 
starting point and an improved version would be a good way to fix our 
problems).


--Andrew

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

Re: [Tagging] (Soapy) Massage Parlour

[John F. Eldredge]

It is my understanding that Britain also uses the "true statements that 
harm a reputation are libel", but that it is mainly used against the news 
media.


--
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness; only light can do that.  Hate cannot 
drive out hate; only love can do that." -- Dr. Martin Luther King, Jr.




On September 23, 2014 10:28:31 AM Mateusz Konieczny  
wrote:



2014-09-23 16:56 GMT+02:00 Mishari Muqbil :

> Even if it's the truth, it's criminal libel if you state it as a
> brothel. There's an interesting saying which you can Google that goes
> "the greater the truth, the greater the libel".
>

Libel is defined as "false statement that harms the reputation of
somebody/something".
Are you serious that in Thailand they have something like "criminal libel"
defined as
"any statement that harms the reputation of somebody/something"?



--
___
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] New key proposal - paved=yes/no

[Pee Wee]

No it not a language problem  or a dictionary issue. It's about an OSM data
consumer (openfietmap)  that thinks it is important to for cyclist to know
what type of paving can be expected.  Paved, unpaved and semi-paved to keep
it simple. I think this is OK and it works for me.

Cheers
Peewee32

2014-09-24 19:03 GMT+02:00 Martin Koppenhoefer :

>
> 2014-09-24 18:40 GMT+02:00 Pee Wee :
>
>> I would not call sand "paved" but when we look at e.g.gravel /
>> fine_gravel the opinions will vary. The OSM based Openfietsmap
>> (cycling map for Garmin
>> devices) has yet another value called "semi-paved".  All based on current
>> OSM tags. (surface, tracktype, smoothness etc. ) In my experience this
>> works pretty well.
>>
>
>
> "semi-paved" does not make any sense to me (besides maybe something
> divided in two along its direction, (that would probably be half-paved)) .
> I've looked the word "paved" up in an online dictionary and it seems to
> confirm what I thought it would mean.
> http://www.merriam-webster.com/dictionary/pave
>
> 1
> *:*  to lay or cover with material (as asphalt or concrete) that forms a
> firm level surface for travel
> 2
> *:*  to cover firmly and solidly as if with paving material
> 3
> *:*  to serve as a covering or pavement
>  of
>
>
> 1 is dealing with asphalt or concrete (firm level surface)
> 2 is dealing with different stuff (as if it was paved), i.e. comparing to
> 3 is not useful for us here
>
>
> gravel does not seem to fit into any of these categories. Maybe this is a
> language problem? E.g. in German you could translate "paved" as either
> "gepflastert"/"asphaltiert"/"betoniert" or as "befestigt", where the latter
> would indeed include gravel, fine gravel etc. (but in these cases "paved"
> would not be a suitable translation of "befestigt").
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Verbeter de wereld. Word mapper voor Openstreetmap
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest vs Wood

[Martin Koppenhoefer]

2014-09-24 18:22 GMT+02:00 John Sturdy :

> On Thu, Aug 21, 2014 at 9:29 PM, Andrew Guertin 
> wrote:
>
> > landcover=forest
> > anywhere there's trees on the ground
>
> This doesn't agree with my (British English) understanding of the
> terms; a wood can be small, but a forest is always large.



+1
a wood can be relatively small (but also has a minimum size, just a row of
trees will most likely not be a wood), but a forest has to be big in order
to develop the ecosystem it is.
I'd also like to point out that we aren't operating in a void when speaking
about landcover, there is already a proposal in the wiki and the key is in
use:
http://taginfo.openstreetmap.org/keys/landcover#values

please not ~10k trees vs. 11 forest (i.e. factor 1000)

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

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-24 18:40 GMT+02:00 Pee Wee :

> I would not call sand "paved" but when we look at e.g.gravel / fine_gravel
> the opinions will vary. The OSM based Openfietsmap
> (cycling map for Garmin devices)
> has yet another value called "semi-paved".  All based on current OSM tags.
> (surface, tracktype, smoothness etc. ) In my experience this works pretty
> well.
>


"semi-paved" does not make any sense to me (besides maybe something divided
in two along its direction, (that would probably be half-paved)) . I've
looked the word "paved" up in an online dictionary and it seems to confirm
what I thought it would mean.
http://www.merriam-webster.com/dictionary/pave

1
*:*  to lay or cover with material (as asphalt or concrete) that forms a
firm level surface for travel
2
*:*  to cover firmly and solidly as if with paving material
3
*:*  to serve as a covering or pavement
 of


1 is dealing with asphalt or concrete (firm level surface)
2 is dealing with different stuff (as if it was paved), i.e. comparing to
3 is not useful for us here


gravel does not seem to fit into any of these categories. Maybe this is a
language problem? E.g. in German you could translate "paved" as either
"gepflastert"/"asphaltiert"/"betoniert" or as "befestigt", where the latter
would indeed include gravel, fine gravel etc. (but in these cases "paved"
would not be a suitable translation of "befestigt").

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

Re: [Tagging] New key proposal - paved=yes/no

[Pee Wee]

>
> As per Peewee post - the definition of 'paved' vs 'unpaved' is open to
> interpretation. But I don't think anyone would accept 'sand' as being
> 'paved'?
>
I would not call sand "paved" but when we look at e.g.gravel / fine_gravel
the opinions will vary. The OSM based Openfietsmap
(cycling map for Garmin devices)
has yet another value called "semi-paved".  All based on current OSM tags.
(surface, tracktype, smoothness etc. ) In my experience this works pretty
well.

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

Re: [Tagging] Forest vs Wood

[John Sturdy]

On Thu, Aug 21, 2014 at 9:29 PM, Andrew Guertin  wrote:

> landcover=forest
> anywhere there's trees on the ground

This doesn't agree with my (British English) understanding of the
terms; a wood can be small, but a forest is always large.  "Small" and
"large" being loosely defined, but for something to be called "forest"
I'd expect it to be many times larger than a typical farm field.
Trying to pin down my intuition on it: a forest would be big enough to
have one or more villages within its boundaries.   However, the term
"woodland" can be used at any scale, I think.

__John

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

Re: [Tagging] name and brand tags

[Mateusz Konieczny]

2014-09-24 17:46 GMT+02:00 Pieren :

> On Wed, Sep 24, 2014 at 5:07 PM, Martin Koppenhoefer
>  wrote:
>
> > -1, if the name tag has values that aren't actually the name of the
> tagged
> > instance it should be removed. This is not about compatibility, but
> cleaning
> > up "tagging for the *-data-consumer".
>
> It's not tagging the data-consumer/renderer. Most of the contributors
> don't care about the real oil station (or hotel or bank)
> name/brand/operator refinements. We should consider the tag "name" as
> the main key and tolerate that name duplicates brand/operator until
> someone updates it with the real station name.
>

In Poland typical branded petrol station has no name (it may have some
internal ref code).
Name tag is frequently used instead correct brand tag as it is rendered.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] name and brand tags

[Pieren]

On Wed, Sep 24, 2014 at 5:07 PM, Martin Koppenhoefer
 wrote:

> -1, if the name tag has values that aren't actually the name of the tagged
> instance it should be removed. This is not about compatibility, but cleaning
> up "tagging for the *-data-consumer".

It's not tagging the data-consumer/renderer. Most of the contributors
don't care about the real oil station (or hotel or bank)
name/brand/operator refinements. We should consider the tag "name" as
the main key and tolerate that name duplicates brand/operator until
someone updates it with the real station name.

Pieren

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

Re: [Tagging] name and brand tags

[Martin Koppenhoefer]

2014-09-24 16:32 GMT+02:00 Matthijs Melissen :

> > Nameless object, with brand (for example petrol station).
> > IMHO it should be tagged brand=*, without name.
>
> That would cause backwards-compatibility problems for all data
> consumers



-1, if the name tag has values that aren't actually the name of the tagged
instance it should be removed. This is not about compatibility, but
cleaning up "tagging for the *-data-consumer".

If someone had added "name=beachvolleyball pitch" and natural=beach to
beach volleyball pitches it would also cause "backwards-compatibility
problems for all data consumers" if we changed the tagging to leisure=pitch
and removed the name tag (i.e. those pitches would vanish from products of
dataconsumers that don't render pitches but beaches).

IMHO the data consumers (and editors etc.) will update their projects
(btw.: if they haven't already, not that the brand tag was supernew, or
that this kind of tagging isn't advocated in the wiki since 4 years:
http://wiki.openstreetmap.org/w/index.php?title=Key:brand&oldid=538574 ).

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

Re: [Tagging] name and brand tags

[Martin Koppenhoefer]

2014-09-24 16:22 GMT+02:00 Philip Barnes :

> Other than supermarket petrol stations, the name of the petrol station
> will appear on your receipt, not the name of the oil company.
>



typically there are 3 entities that can appear on your receipt / be used in
osm tagging:

operator - this is required on the receipt, it is the company that issues
the receipt
brand - this might additionally appear on the receipt, in case of a petrol
station this is usually an oil company
name - this might also appear on the receipt, it is the name of the single
instance

in some cases the Oil company does operate the petrol station itself, in
these cases Operator and Brand might be similar (I'm usually adding the
corporate form to the operator value, but won't typically do it for brand
(i.e. unless it is part of the well known brand name)).

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

Re: [Tagging] name and brand tags

[Matthijs Melissen]

On 24 September 2014 14:12, Mateusz Konieczny  wrote:
> Nameless object, with brand (for example petrol station).
> IMHO it should be tagged brand=*, without name.

That would cause backwards-compatibility problems for all data
consumers, so I think Andy will probably not accept a rendering based
on this principle for openstreetmap-carto.

-- Matthijs

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

Re: [Tagging] name and brand tags

[SomeoneElse]

On 24/09/2014 15:24, Richard Welty wrote:



true, but are we better off with that in operator= than in
name= ?

richard



Not if they're different.  As an example, here's a hotel:

http://www.royaloakhotel.com/

The brand is "Best Western".  The name is something like "Royal Oak 
Hotel".  The operator isn't actually mentioned on the website, but 
there's a sign in reception that says "owned and operated by XYZ" or 
similar.


Cheers,

Andy


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

Re: [Tagging] name and brand tags

[Richard Welty]

On 09/24/2014 10:22 AM, Philip Barnes wrote:
Besides in my experience petrol stations do have a name, it may not be 
obvious until you are close to the shop. Other than supermarket petrol 
stations, the name of the petrol station will appear on your receipt, 
not the name of the oil company. Phil (trigpoint)


true, but are we better off with that in operator= than in
name= ?

richard


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

Re: [Tagging] name and brand tags

[Philip Barnes]

On Wed, 2014-09-24 at 15:12 +0200, Mateusz Konieczny wrote:
> How these tags should be used?
> 
> 
> Nameless object, with brand (for example petrol station).
> 
> IMHO it should be tagged brand=*, without name.

-1

Besides in my experience petrol stations do have a name, it may not be
obvious until you are close to the shop.

Other than supermarket petrol stations, the name of the petrol station
will appear on your receipt, not the name of the oil company.

Phil (trigpoint)




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

Re: [Tagging] name and brand tags

[Martin Koppenhoefer]

2014-09-24 15:35 GMT+02:00 Mateusz Konieczny :

> maybe "Independent" is a brand name somewhere? If not this tagging is bad.
>>
>
> http://overpass-turbo.eu/s/59O indicates that it is frequently used as
> equivalent of
> http://wiki.openstreetmap.org/wiki/Proposed_features/Noname for brand.
>



that's obviously a very bad idea, also because there are indeed brands with
this name, e.g. a skateboard parts company:
http://www.independenttrucks.com/ and clothing company
http://www.skatesonhaight.com/Independent-Clothing-s/274.htm
There is also "the Independent" (newspaper).

A quick research on the german register for brands (also international
brands) has revealed 232 brands with "Independent" in their name.
https://register.dpma.de/DPMAregister/marke/trefferliste

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

Re: [Tagging] name and brand tags

[Mateusz Konieczny]

2014-09-24 15:16 GMT+02:00 Martin Koppenhoefer :

> 2014-09-24 15:12 GMT+02:00 Mateusz Konieczny :
>
>> Objects without brand, in class where brand is typical.
>> brand=Independent is popular, what IMHO is a poor idea.
>>
> maybe "Independent" is a brand name somewhere? If not this tagging is bad.
>

http://overpass-turbo.eu/s/59O indicates that it is frequently used as
equivalent of
http://wiki.openstreetmap.org/wiki/Proposed_features/Noname for brand.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] name and brand tags

[Martin Koppenhoefer]

2014-09-24 15:12 GMT+02:00 Mateusz Konieczny :

>
> http://wiki.openstreetmap.org/wiki/Key:brand currently encourages
> setting brand and name to the same value. Is it really a good idea?
>


-1, I agree with you that we shouldn't encourage duplicating values into
several keys.




>
> Objects without brand, in class where brand is typical.
> brand=Independent is popular, what IMHO is a poor idea.
>


maybe "Independent" is a brand name somewhere? If not this tagging is bad.

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

[Tagging] name and brand tags

[Mateusz Konieczny]

How these tags should be used?

Nameless object, with brand (for example petrol station).
IMHO it should be tagged brand=*, without name.

http://wiki.openstreetmap.org/wiki/Key:brand currently encourages
setting brand and name to the same value. Is it really a good idea?

Objects without brand, in class where brand is typical.
brand=Independent is popular, what IMHO is a poor idea.

Post promted by https://github.com/gravitystorm/openstreetmap-carto/pull/972
that proposes rendering brand in default style.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New key proposal - paved=yes/no

[Martin Koppenhoefer]

2014-09-24 1:40 GMT+02:00 Warin <61sundow...@gmail.com>:

> One more point against that I have not seen (yet)  ..  with this
> additional tag you can get conflicts e.g.
>
> Paved=yes
> Surface=Unpaved
>
> Oh .. you want to exclude paved/unpaved from surface? Ok, then we get
>
> Paved=yes
> Surface=sand
>



I think these conflicts are not worse than wrong data, actually they are
better, because you can see an obvious inconsistency and can resurvey,
while otherwise you would only have a wrong tag in the db and could not
find it easily.

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

Re: [Tagging] Forest vs Wood

[Martin Koppenhoefer]

2014-09-24 1:21 GMT+02:00 Greg Troxel :

> I think the right thing to do is to look to professional geography.
> There, there are two separate concepts
>
>   land use: what humans do with the land
>
>   land cover: what is actually there
>


+1, but I think there are even more concepts to consider. Think about
geographical regions / named areas. An area with a forest name will often
(especially if it is bigger) have also other landcover and landuse inside
it. It is not strictly a forest in the sense that every square meter is
shaded by trees. And very often inside a forest area with a name you will
have other forest areas with other names (for these smaller parts), i.e.
nesting. This nested objects should have their name rendered, but not
necessarily they have to be filled or outlined.



>
>
> So landuse=forest is appropriate for land which is being managed for
> production, even if it is little pulp trees.
>


+1, maybe even if the area has just been logged and is bare for the moment.



>
> And natural=wood (or we should move to landcover=wood, really) for areas
> that are dominated by trees.
>



I'd stick with the "natural describes a geographic object" definition and
use natural=forest (and maybe also natural=woodland for less dense areas)
for things I described above (a forest as a geographical entity). For areas
which are covered by trees (and which often aren't forests but only small
patches of trees) I am using and advocating "landcover=trees".

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