Re: [Tagging] Please don't think name_1 tags are errors.

[Martin Koppenhoefer]

2016-01-15 15:26 GMT+01:00 moltonel 3x Combo :

> But I wonder if some people know about the iD editor behavior below,
> and assume that a name_1 tag must have been created that way ? If so,
> consider this email as a reminder that the _N suffix is used on
> purpose by many people. As always, contact the mapper if unsure.
>


also shop_1 tags are created that way. I wonder why you would want to add
these tags on purpose. E.g. for shops the values indicate a type of shop. A
bookstore that also sells music cds? Still a bookstore IMHO. A music store
that also sells some books? Still a music store. Now, a store that sells
both, music cds and books, and maybe dvds and posters, maybe still a
bookstore, maybe a new category like a media store, not sure, would have to
decide on the particular case. In a majority of cases you still can decide
on one of the types and that it is. A green grocer that also sells
toothpaste, detergents, toys and cheese? That likely not a green grocer any
more, that's either a convenience store or a supermarket.
What I want to say: a shop that is 2 shops in one might well be neither of
these shop types, but a new typology.

In other cases, there is a well defined shop/restaurant/bar/kiosk/... which
also offers some odd service or product you might find in some but not all
of this kind of business, and which you consider so interesting that you
want to map the presence of it. Examples might be tobacco/cigarettes,
icecream, particular soft drinks (club_mate comes to mind [1]), public
transport tickets, fresh milk, etc.
My solution for this is sells:foo=yes(/no/etc.)
Obviously we wouldn't want people to tag the whole assortment of a
supermarket like this, but due to the amount of work the risk is low.
People will likely just tag the things they are particularly interested in,
and that are not automatically thought of being available generally. So far
the list is small ;-) [2]

Now, there are also edge cases, i.e. types that are so rare that you
probably won't find more than a handful on the whole globe, my favorite one
is this: http://www.23hq.com/dieterdreist/photo/7089481?album_id=4242149
that's an optician who also runs a polish deli shop in the same shop (and
it's the same person, one door, same opening hours, not sure if it's one
business actually (on a legal level), but let's suppose for this discussion
that it is). My suggestion is to map them as two overlapping shops rather
than shop=foo shop_1=bar. For the avoidance of doubt you can add the same
VAT identification number (ref:vatin).

For names, the solution should be to use well defined name key variations,
there's a whole lot of them [3], and introducing just another infinite
amount of indexed ones seems completely unnecessary.

Cheers,
Martin


[1] https://matemonkey.com/map/dealer/
[2] http://taginfo.osm.org/search?q=sells%3A
[3] http://wiki.openstreetmap.org/wiki/Names
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Please don't think name_1 tags are errors.

[Kieron Thwaites]

Whichever iD developer thought that adding random _N suffixes was a
good idea deserves to be taken out back and shot.  While handling
newbie mistakes (and teaching them the correct way of doing things) is
most certainly encouraged, doing it in such a way that pollutes
tagging is totally unacceptable.

I completely endorse the removal of any and all *_N tags.

--K

On 15/01/2016, moltonel 3x Combo  wrote:
> Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638
> where the mapper thought that name_1 tags were typos. That user is on
> a key typo fixing spree, which is a good thing in itself, even if
> mistakes happen.
>
> But I wonder if some people know about the iD editor behavior below,
> and assume that a name_1 tag must have been created that way ? If so,
> consider this email as a reminder that the _N suffix is used on
> purpose by many people. As always, contact the mapper if unsure.
>
> On 09/01/2016, Hakuch  wrote:
>> **iD-Editor problem**
>>
>> unfortunately, the iD-editor is creating such prefixed tags and is
>> training newbies to use them as a good tagging practice. When you use
>> the raw-tag-editor and tries to add an already existing tag, iD does not
>> throw any error or information but adds the tag with a suffixed number
>> like _1 or higher.
>> It suggests to the unexperienced mapper, that this is a usable method to
>> add multiple values, although this suffixing is only made to prevent the
>> user of deleting data.
>> We still couldn't convince the developer, that this suffixing method
>> leads new mappers to bad practice
>> (https://github.com/openstreetmap/iD/issues/2896).
>
> ___
> 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] Please don't think name_1 tags are errors.

[moltonel 3x Combo]

Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638
where the mapper thought that name_1 tags were typos. That user is on
a key typo fixing spree, which is a good thing in itself, even if
mistakes happen.

But I wonder if some people know about the iD editor behavior below,
and assume that a name_1 tag must have been created that way ? If so,
consider this email as a reminder that the _N suffix is used on
purpose by many people. As always, contact the mapper if unsure.

On 09/01/2016, Hakuch  wrote:
> **iD-Editor problem**
>
> unfortunately, the iD-editor is creating such prefixed tags and is
> training newbies to use them as a good tagging practice. When you use
> the raw-tag-editor and tries to add an already existing tag, iD does not
> throw any error or information but adds the tag with a suffixed number
> like _1 or higher.
> It suggests to the unexperienced mapper, that this is a usable method to
> add multiple values, although this suffixing is only made to prevent the
> user of deleting data.
> We still couldn't convince the developer, that this suffixing method
> leads new mappers to bad practice
> (https://github.com/openstreetmap/iD/issues/2896).

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Martin Koppenhoefer]

2016-01-15 16:01 GMT+01:00 Kieron Thwaites :

> Whichever iD developer thought that adding random _N suffixes was a
> good idea deserves to be taken out back and shot.
>


maybe this kind of language is common in your cultural context, but I
believe it is completely inappropriate and extremely offensive around here.
Please be aware that this list is not restricted to the US but people from
all over the world are participating.

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

Re: [Tagging] Please don't think name_1 tags are errors.

[moltonel 3x Combo]

On 15/01/2016, Kieron Thwaites  wrote:
> I completely endorse the removal of any and all *_N tags.

If so, you've got a serious amount of work comming up just to figure
how to say the same thing using different tags. Semicolons and various
namespaced schemes sometimes do the trick, but outright banning *_N
for the sake of (what ?) would cause a lot of headaches.


On 15/01/2016, Martin Koppenhoefer  wrote:
> 2016-01-15 15:26 GMT+01:00 moltonel 3x Combo :
> also shop_1 tags are created that way. I wonder why you would want to add
> these tags on purpose. E.g. for shops the values indicate a type of shop. A
> bookstore that also sells music cds? Still a bookstore IMHO. A music store
> that also sells some books? Still a music store. Now, a store that sells
> both, music cds and books, and maybe dvds and posters, maybe still a
> bookstore, maybe a new category like a media store, not sure, would have to
> decide on the particular case. In a majority of cases you still can decide
> on one of the types and that it is. A green grocer that also sells
> toothpaste, detergents, toys and cheese? That likely not a green grocer any
> more, that's either a convenience store or a supermarket.
> What I want to say: a shop that is 2 shops in one might well be neither of
> these shop types, but a new typology.
> In other cases, there is a well defined shop/restaurant/bar/kiosk/... which
> also offers some odd service or product you might find in some but not all
> of this kind of business, and which you consider so interesting that you
> want to map the presence of it. Examples might be tobacco/cigarettes,
> icecream, particular soft drinks (club_mate comes to mind [1]), public
> transport tickets, fresh milk, etc.

Yes, "shop=foo shop_1=bar" is not great. In the same way that
"shop=foo;bar" is not great. I'm all for either finding a new fitting
value or for tagging the main value plus a subtag, or for using two
objects.

But often mappers are not knowledgable enough or do not have the time
to fuss about this, and instead "simply want to express that this is a
deli and an optician".


> My solution for this is sells:foo=yes(/no/etc.)
> Obviously we wouldn't want people to tag the whole assortment of a
> supermarket like this, but due to the amount of work the risk is low.
> People will likely just tag the things they are particularly interested in,
> and that are not automatically thought of being available generally. So far
> the list is small ;-) [2]

Yes, ns:foo=boolean is a good alternate scheme, when you can use it.

> For names, the solution should be to use well defined name key variations,
> there's a whole lot of them [3], and introducing just another infinite
> amount of indexed ones seems completely unnecessary.

The problem is that all those name key variations carry semantic
meaning. A loc_name isn't the same thing as an alt_name which isn't
the same thing as an old_name. You can't shuffle all your names into
random foo_name keys, it has to make sense. And as soon as you've got
more than one name, you've got a problem. Which is solved very nicely
by _N.

To get back to my http://www.openstreetmap.org/relation/5257865
example, I've got 3 names to tag. One of them distinguishes itself by
also appearing on an out-of-copyright map, the other two are at the
exact same level with each other and, as far as I'm concerned, pretty
much at the same level as the first one. I can't fit them into "loc"
or "old" or "whatever" categories, to the best of my knowledge they
are just "other names". Which is solved very nicely by putting them in
name_1 and name_2.


Having multiple values for one tag is awkward in OSM, so we always try
to find clever ways around it. Sometimes that clever trick is the
right thing to do, sometimes we really just need a way to tag multiple
values. Semicolons and _N are two ways to do that, each with their
pros and cons (I don't think it likely or desirable to deprecate one
for the other). They are sometimes usefull, please leave them be an
accept them as another tool in your mapper's toolbox.



Changing the topic a little bit, I'd like to comment on alt_name vs
name_1 va alt_name_1. To me name_1 and alt_name are exact synonyms, I
don't see a semantic difference (as opposed to loc_name for example).
Therefore, if you've only got two names to tag you can use either. But
once you've got at least three you'll need to use either alt_name_N or
name_N. I find the concept of alt_name_N silly and would rather use
name_N, but I've seen some people disagree, For what it's worth,
alt_name_N is much less frequent in the db than name_N, but Nominatim
supports only alt_name_N. Any opinions on that issue (other than
"remove all *_N" :p) ?

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Ralph Aytoun]

I am quite in favour of people coming forward to discuss the possibility of 
improving the iD Editor if it is causing problems.


I object to the continuous use of naming new mappers as a problem. I will 
defend the reason for iD preventing new mappers from being given the option 
of inadvertently or erroneously deleting other mapper's work. At least until 
they understand what they are deleting.


New mappers have a lot to learn. They have enough of a problem just learning 
how to use the tools and finding out what basic tagging is without being 
inundated with error messages telling them they cannot save their work 
because of some technical fault. Let them save their work rather than it 
getting lost or they get so frustrated that they give up and walk away. And 
believe me when I say that they are nor learning bad tagging from the iD 
Editor because most new mappers will not understand what just happened or 
that the tag is different, they will just be grateful that their work has 
been saved and they can continue mapping.


To really understand the tagging requires a concerted study and even then it 
does not help. When I started a waterway=wadi was an accepted tag but within 
a period of three months it was deprecated by a group that did not really 
understand it's cartographic usage. Now we are left with intermittent=yes 
which does not adequately depict a dry river bed that is a natural feature 
but only occasionally (as opposed to regularly or seasonally) has flowing 
water. Throughout the arid countries we now have these features 
(wadi/ouadi/arroyo/dry gulch/ etc.) without an appropriate tag. So I would 
say, do not knock the new mappers, this area is a minefield of correctness 
... or incorrectness as the case may be ...

and we do not want to discourage new mappers.

I sympathise with the frustrations of the very experienced 
mappers/taggers/renderers but we have to remember that Openstreetmap has 
developed and grown with everyone being a new mapper at some stage. Please 
be tolerant of the new mappers so that they can grow with us and become the 
experienced mappers of the future... with our help not our criticism.


Please all have a Happy Mapping year and help this immense undertaking to 
grow.


-Original Message- 
From: moltonel 3x Combo

Sent: Friday, January 15, 2016 2:26 PM
To: Tag discussion, strategy and related tools
Subject: [Tagging] Please don't think name_1 tags are errors.

Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638
where the mapper thought that name_1 tags were typos. That user is on
a key typo fixing spree, which is a good thing in itself, even if
mistakes happen.

But I wonder if some people know about the iD editor behavior below,
and assume that a name_1 tag must have been created that way ? If so,
consider this email as a reminder that the _N suffix is used on
purpose by many people. As always, contact the mapper if unsure.

On 09/01/2016, Hakuch  wrote:

**iD-Editor problem**

unfortunately, the iD-editor is creating such prefixed tags and is
training newbies to use them as a good tagging practice. When you use
the raw-tag-editor and tries to add an already existing tag, iD does not
throw any error or information but adds the tag with a suffixed number
like _1 or higher.
It suggests to the unexperienced mapper, that this is a usable method to
add multiple values, although this suffixing is only made to prevent the
user of deleting data.
We still couldn't convince the developer, that this suffixing method
leads new mappers to bad practice
(https://github.com/openstreetmap/iD/issues/2896).


___
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] Please don't think name_1 tags are errors.

[Richard Fairhurst]

Kieron Thwaites wrote:
> Whichever iD developer thought that adding random _N suffixes was 
> a good idea deserves to be taken out back and shot.

Please withdraw that comment.

Advocating violence to people is not funny. You might want to say a
_feature_ should be taken outside and shot, but don't extrapolate it to a
person.

Being abusive to developers is not funny either. OpenStreetMap is unlikely
to prosper in an environment where the (precious few) developers can expect
to be abused on any random mailing list or issue tracker.

Thank you.

Richard
tagging@ list admin




--
View this message in context: 
http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875p5864887.html
Sent from the Tagging mailing list archive at Nabble.com.

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Marc Gemis]

On Fri, Jan 15, 2016 at 4:02 PM, Martin Koppenhoefer
 wrote:
> Obviously we wouldn't want people to tag the whole assortment of a
> supermarket like this, but due to the amount of work the risk is low.

I'll agree with what you wrote, but I still wonder how you
differentiate between all the supermarket types.

I'm thinking about

* in some countries supermarkets do not sell alcoholic beverages
* some supermarkets sells newsletters, card, cleaning products
* some chains are famous for selling 1 type of computer, smartphone,
or clothes for 1 week.
* the larger ones sometimes sells toys, bicycles, TVs, etc.

I was planning on writing a diary entry about supermarkets, but didn't
found the time yet.
(e.g. on how do you map that certain areas are manned - wine, butcher,
cheese, backery)

regards

m

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Martin Koppenhoefer]

sent from a phone

> Am 15.01.2016 um 17:40 schrieb Marc Gemis :
> 
> I'll agree with what you wrote, but I still wonder how you
> differentiate between all the supermarket types.


I don't yet, but it is indeed a field where we might want to map more detail in 
the future.


> 
> I'm thinking about
> 
> * in some countries supermarkets do not sell alcoholic beverages

yes, in others they do or not sell cigarettes, or ammunition. 


> * some supermarkets sells newsletters, card, cleaning products
> * some chains are famous for selling 1 type of computer, smartphone,
> or clothes for 1 week.


special offers don't belong into osm, IMHO


> * the larger ones sometimes sells toys, bicycles, TVs, etc.
> 
> I was planning on writing a diary entry about supermarkets, but didn't
> found the time yet.
> (e.g. on how do you map that certain areas are manned - wine, butcher,
> cheese, backery)


yes, also fish, fresh sweets, deli, ...
These could become attributes...

Maybe we should also have an attribute to say something like style=discounter
Or a scheme for ware groups, e.g. newspapers, electronics, gardening stuff, 
stationery, pharmaceutical products...

A lot of the details are country specific, partly due to the legal situation 
but more due to cultural differences. This is a big problem because most 
mappers will not even be aware of it and although it would be useful for 
ignorant tourists they will hardly be willing to add a lot of tags for details 
they take for granted ;-)

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

[Tagging] Feature Proposal - RFC - Discourage amenity=public_building

[Matthijs Melissen]

Hi all,

Based on the discussion arising from my previous message, it seems
that there is support to discourage the tag amenity=public_building.

I have therefore created a proposal page to explicitly mark this tag
as discouraged in the wiki:

http://wiki.openstreetmap.org/wiki/Proposed_features/Discourage_amenity%3Dpublic_building

Please let me know what you think.

-- Matthijs

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Martin Koppenhoefer]

sent from a phone

> Am 15.01.2016 um 17:25 schrieb Ralph Aytoun :
> 
> Throughout the arid countries we now have these features 
> (wadi/ouadi/arroyo/dry gulch/ etc.) without an appropriate tag.


time to make a proposal ;-)

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

Re: [Tagging] Please don't think name_1 tags are errors.

[Christoph Hormann]

On Friday 15 January 2016, Ralph Aytoun wrote:
> When I started a waterway=wadi was an accepted tag
> but within a period of three months it was deprecated by a group that
> did not really understand it's cartographic usage.

I don't want to hijack this thread but the above is not quite correct - 
on the wiki the tag was indicated as having issues with verifiability 
and discussion was opened regarding this more than a year earlier:

http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Dwadi=953081

But you indeed correctly identified the problem that mappers had a 
highly variable understanding of what this tag means and its use was 
very incoonsistent as a result.

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

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

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

[Warin]

On 16/01/2016 7:03 AM, Matthijs Melissen wrote:

Hi all,

Based on the discussion arising from my previous message, it seems
that there is support to discourage the tag amenity=public_building.

I have therefore created a proposal page to explicitly mark this tag
as discouraged in the wiki:

http://wiki.openstreetmap.org/wiki/Proposed_features/Discourage_amenity%3Dpublic_building

Please let me know what you think.


There should be a mention of tagging a feature as well as a function.

So I would separate up the tags thus;

..."Some examples:

To tag a function;

 * office =public
    for an
   office of an agency or department of the national/state government.
 * office
   =administrative
    for
   an office of a local administrative authority, not related to the
   state government.
 * amenity =townhall
    for a
   local government seat.

To tag a feature;

 * building =public
     for a
   public building.
 * building =school
    for
   a school.

"

?



-- Matthijs

___
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 - RFC - Discourage amenity=public_building

[Colin Smale]

How would you translate or apply these tags in e.g. the UK or the
Netherlands (my home countries)? What is a "state government"? What is a
"local government seat"? These things will mean different things to
different people. 

Although this is phrased a bit rhetorically, I do think we should be
aware that a description in one person's vernacular is not necessarily
clear to a diverse audience. A "town hall" is (to me) a bit archaic, but
I think many people would be able to answer the question "where is the
town hall?" for their home municipality. It will often be a historic
building, and may or may not be where the council chamber is, or where
the "mayor" or the head of the council has their office. So how do you
decide if a building is a/the Town Hall? 

And what would be an example of "an office of a local administrative
authority, not related to the state government"? I cannot imagine, maybe
someone can jog my brain in the right direction. 

As for building=public, well, words fail me. What is a "public
building"? A building to which the public has access? That's not an
attribute of the building, that needs an access=* tag. 

This kind of unclear semantics is exactly why I will vote to discourage
amenity=public_building. Let's not throw the baby out with the bath
water and suggest a replacement which is just as bad, if not worse.

//colin 

On 2016-01-15 22:13, Warin wrote:

> On 16/01/2016 7:03 AM, Matthijs Melissen wrote: 
> 
>> Hi all,
>> 
>> Based on the discussion arising from my previous message, it seems
>> that there is support to discourage the tag amenity=public_building.
>> 
>> I have therefore created a proposal page to explicitly mark this tag
>> as discouraged in the wiki:
>> 
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Discourage_amenity%3Dpublic_building
>> 
>> Please let me know what you think.
> 
> There should be a mention of tagging a feature as well as a function.
> 
> So I would separate up the tags thus;
> 
> ..."Some examples: 
> 
> To tag a function;
> 
> * office [1]=public [2] for an office of an agency or department of the 
> national/state government.
> * office [1]=administrative [3] for an office of a local administrative 
> authority, not related to the state government.
> * amenity [4]=townhall [5] for a local government seat.
> 
> To tag a feature; 
> 
> * building [1]=public [2]  for a public building.
> * building [1]=school [3] for a school.
> 
> "
> 
> ?
> 
>> -- Matthijs
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] http://wiki.openstreetmap.org/wiki/Key:office
[2] http://wiki.openstreetmap.org/wiki/Tag:office%3Dgovernment
[3] http://wiki.openstreetmap.org/wiki/Tag:office%3Dadministrative
[4] http://wiki.openstreetmap.org/wiki/Key:amenity
[5] http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtownhall
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Please don't think name_1 tags are errors.

[Dave F.]

On 15/01/2016 16:25, Ralph Aytoun wrote:
I am quite in favour of people coming forward to discuss the 
possibility of improving the iD Editor if it is causing problems.


Could a "this key already exists,,," dialog be displayed?



I object to the continuous use of naming new mappers as a problem.


Are you sure it's not the design of the editor that's being called out 
as the culprit?


Dave F.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

[Warin]

On 16/01/2016 3:40 PM, John Willis wrote:



On Jan 16, 2016, at 9:12 AM, Colin Smale > wrote:


If they should be improved .. or discouraged .. then do that as 
separate issues.


If you want to fix a problem, don't replace it with another one.



Then I will work on a civic building / civic office something 
extension this week.

Two different things - so two different tags;
 ... one a physical thing - the building (building=yes being the least 
specific, for a building full of clerks ? building=clerical?)
... one a service thing - the office .. office=administration ? 
office=tax (that looks to be common :) )


All the counties use admin levels, right? We should also be able to 
use admin level tags to denote the government level rather than 
relying on words.


Have to rely on words to translate the 'level' into something 'we' 
understand. The problem remains.


However, defining the office types will surely run into odd 
combinations ( like the American Alcohol - tobacco - guns dept), so 
the the system will have to have a whole bunch of civic:foobar=yes or 
civic:category:foobar=yes,

Yes.
as well as support for names of the department., like operator or 
brand or chain something (many many offices are branches of a main 
office, or a "chain" of offices related to each other).



Again yes.

I will try to get something setup - and something to go with landuse - 
so we have a solution for o plug into fill this hole.


Landuse ... is also a problem .. some have more than one 'use'.
 An example.
In Australia there are 'water catchment' areas - to gather drinking 
water. They have secondary functions of flora and fauna preservation. 
The areas are fairly large to allow for periods of little (to no, though 
that is more a storage volume problem) rainfall of up to 5 years.


In the UK there are 'water catchment' areas too .. also to gather 
drinking water. They also function as farms .. etc... I think the little 
to no rainfall problem here was 2 weeks... to put the reliability of 
rainfall in perspective.


So there needs to be a way of multiple landuses.. some with priority, 
others without priority... some mixed - for example a primary use, and 
many secondary.
I have not thought greatly on it. But that is at least some of the 
landuse problem.




Hopefully I'll have something to show this week.


Good. Don't envy you it. Rather get on with some actual mapping at the 
moment.


Javbw.


___
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 - RFC - Discourage amenity=public_building

[Colin Smale]

On 2016-01-16 00:12, Warin wrote:

> On 16/01/2016 8:35 AM, Colin Smale wrote: 
> 
>> How would you translate or apply these tags in e.g. the UK or the 
>> Netherlands (my home countries)? What is a "state government"? What is a 
>> "local government seat"? These things will mean different things to 
>> different people. 
>> 
>> Although this is phrased a bit rhetorically, I do think we should be aware 
>> that a description in one person's vernacular is not necessarily clear to a 
>> diverse audience. A "town hall" is (to me) a bit archaic, but I think many 
>> people would be able to answer the question "where is the town hall?" for 
>> their home municipality. It will often be a historic building, and may or 
>> may not be where the council chamber is, or where the "mayor" or the head of 
>> the council has their office. So how do you decide if a building is a/the 
>> Town Hall? 
>> 
>> And what would be an example of "an office of a local administrative 
>> authority, not related to the state government"? I cannot imagine, maybe 
>> someone can jog my brain in the right direction. 
>> 
>> As for building=public, well, words fail me. What is a "public building"? A 
>> building to which the public has access? That's not an attribute of the 
>> building, that needs an access=* tag. 
>> 
>> This kind of unclear semantics is exactly why I will vote to discourage 
>> amenity=public_building. Let's not throw the baby out with the bath water 
>> and suggest a replacement which is just as bad, if not worse.
> 
> These tags and the descriptions are already on the wiki. 
> If they should be improved .. or discouraged .. then do that as separate 
> issues.

If you want to fix a problem, don't replace it with another one. The
proposal is one step forwards, and one step back. The recommended
replacement tagging is just as bad (if not worse). The core of the
proposal (deprecating public_building) is a definite step in the right
direction, but we shouldn't jump out of the frying pan into the fire.
The examples of alternative tagging need tightening up, or possibly
removing if we cannot improve them sufficiently.


Town Halls... 
England ... 
https://www.thsh.co.uk/town-hall/
http://www.leeds.gov.uk/townhall/Pages/default.aspx
http://www.cheltenhamtownhall.org.uk/
https://www.loughboroughtownhall.co.uk/

and a few more... 

We are not short of examples, everyone can give an example of something
they call a town hall. It's a definition we need here. When is a
building a "town hall"? 

Where I live in NL three municipalities merged a couple of years ago.
Each had their own town hall. Now there is only one council. The former
town halls are still council offices. Everybody knows them as the town
halls, and they are still used for weddings etc but not normally open to
the public. But the council meeting itself is too big for any of them,
and now meets elsewhere. Which building(s) are the town hall(s)? Does a
town, or a council, necessarily have to have one?

> ---
> "an office of a local administrative authority, not related to the state 
> government" 
> 
> Errr some names ? local council, shire council, county council...

These (depending on the context) could be three names for the same type
of entity - one is official, one is generic, one is archaic. It seems
for the UK you suggest the "state" is the UK, and anything else is a
"local administrative authority". What about a federal system such as
Germany? You have government on so many levels... What is the "state"?
The EU? Germany? Or the Bundeslaender? What about private companies
carrying out outsourced government duties? Or municipalities carrying
out non-core functions such as their own public transport? Someone who
works in a large company may even consider their own HR department as
"office=administrative". We can't tag it all in the same way. 

Anyway, "administrative" could mean just about anything,
government-related or not. Office=government might help here, for an
office (from part of a building up to a campus of multiple buildings?)
where generic government things take place. This can cover both
office=administrative and office=public. The level of government, or the
organisation, can be indicated by a different tag such as operator=*
(although that specific tag might conflict with the operator of the
building as a whole). Office implies (to my mind) not normally open to
the public, i.e. not the walk-in facilities with waiting rooms and
counters, but that is a different can of worms to be discussed in the
context of the "office" tag. 

---
building=public .. already done this. I do agree that it is not 'good'.
But someone put it up. And it can be discussed .. on the wiki or as a
separate thread. 

//colin 

On 2016-01-15 22:13, Warin wrote:

On 16/01/2016 7:03 AM, Matthijs Melissen wrote: 

Hi all,

Based on the discussion arising from my previous message, it seems
that there is support to discourage the tag amenity=public_building.

I have 

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

[Warin]

On 16/01/2016 8:35 AM, Colin Smale wrote:


How would you translate or apply these tags in e.g. the UK or the 
Netherlands (my home countries)? What is a "state government"? What is 
a "local government seat"? These things will mean different things to 
different people.


Although this is phrased a bit rhetorically, I do think we should be 
aware that a description in one person's vernacular is not necessarily 
clear to a diverse audience. A "town hall" is (to me) a bit archaic, 
but I think many people would be able to answer the question "where is 
the town hall?" for their home municipality. It will often be a 
historic building, and may or may not be where the council chamber is, 
or where the "mayor" or the head of the council has their office. So 
how do you decide if a building is a/the Town Hall?


And what would be an example of "an office of a local administrative 
authority, not related to the state government"? I cannot imagine, 
maybe someone can jog my brain in the right direction.


As for building=public, well, words fail me. What is a "public 
building"? A building to which the public has access? That's not an 
attribute of the building, that needs an access=* tag.


This kind of unclear semantics is exactly why I will vote to 
discourage amenity=public_building. Let's not throw the baby out with 
the bath water and suggest a replacement which is just as bad, if not 
worse.




These tags and the descriptions are already on the wiki.
If they should be improved .. or discouraged .. then do that as separate 
issues.




Town Halls...
England ...
https://www.thsh.co.uk/town-hall/
http://www.leeds.gov.uk/townhall/Pages/default.aspx
http://www.cheltenhamtownhall.org.uk/
https://www.loughboroughtownhall.co.uk/

and a few more...
---
"an office of a local administrative authority, not related to the state 
government"


Errr some names ? local council, shire council, county council...

---
building=public .. already done this. I do agree that it is not 'good'. 
But someone put it up. And it can be discussed .. on the wiki or as a 
separate thread.



//colin

On 2016-01-15 22:13, Warin wrote:


On 16/01/2016 7:03 AM, Matthijs Melissen wrote:

Hi all,

Based on the discussion arising from my previous message, it seems
that there is support to discourage the tag amenity=public_building.

I have therefore created a proposal page to explicitly mark this tag
as discouraged in the wiki:

http://wiki.openstreetmap.org/wiki/Proposed_features/Discourage_amenity%3Dpublic_building

Please let me know what you think.


There should be a mention of tagging a feature as well as a function.

So I would separate up the tags thus;

..."Some examples:

To tag a function;

  * office =public
 for
an office of an agency or department of the national/state
government.
  * office
=administrative

for an office of a local administrative authority, not related to
the state government.
  * amenity =townhall
 for a
local government seat.

To tag a feature;

  * building =public
 for
a public building.
  * building =school

for a school.

"

?


-- Matthijs

___
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


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

Re: [Tagging] Feature Proposal - RFC - Discourage amenity=public_building

[John Willis]

On Jan 16, 2016, at 9:12 AM, Colin Smale  wrote:

>> If they should be improved .. or discouraged .. then do that as separate 
>> issues.
> If you want to fix a problem, don't replace it with another one.
> 

Then I will work on a civic building / civic office something extension this 
week. 

All the counties use admin levels, right? We should also be able to use admin 
level tags to denote the government level rather than relying on words. 

However, defining the office types will surely run into odd combinations ( like 
the American Alcohol - tobacco - guns dept), so the the system will have to 
have a whole bunch of civic:foobar=yes or civic:category:foobar=yes,  as well 
as support for names of the department., like operator or brand or chain 
something (many many offices are branches of a main office, or a "chain" of 
offices related to each other).  

I will try to get something setup - and something to go with landuse - so we 
have a solution for o plug into fill this hole. 

Hopefully I'll have something to show this week.  

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