[Tagging] Reviewing the use of addr:housename

[Andrew Hain]

The uses of the tag addr:housename in the database[1] does not match
documentation[2] well. A high prroportion of uses are accidental; there were
some bug reports[3][4] against iD, which used to have a housename box at the
beginning of every point for entering addresses, pointing out doubtful use
by new mappers. The top 100 values of the tag tell their own story.

--
Andrew

[1] http://taginfo.openstreetmap.org/keys/addr%3Ahousename#values
[2] http://wiki.openstreetmap.org/wiki/Key:addr
[3] https://github.com/openstreetmap/iD/issues/1525
[4] https://github.com/openstreetmap/iD/issues/2124

Bloc   1 265
(empty string) 531
1  472
bloc   385
2  379
3  373
4  335
5  293
6  279
7  269
9  263
8  258
10 240
12 224
11 211
edificio   209
Mairie 206
16 202
15 192
14 189
18 189
s/n184
Edificio   179
Heidehaus  168
San Antonio II 164
17 164
Taman Cantek   159
Rathaus159
20 155
19 152
13 146
casă   146
22 143
21 139
Berg Studentby 138
25 136
26 135
23 132
Rose Cottage   130
24 129
A  124
28 122
Taman Ridgeview Phase 12   121
The Cottage121
27 118
The Lodge  116
B  111
31 103
29 100
32 99
30 98
C  98
Pfarrhaus  96
Garages95
Arcaden94
Haus 1 94
33 91
Nöhren Hof 89
The Bungalow   88
36 88
Edificio␣  88
Haus 2 88
Vestergård 87
Casă   86
Lidl   84
34 84
35 84
D  84
Østergård  83
40 80
38 77
Ældrecentret Kærgården 77
Магазин76
C.C. Condado Shopping  75
37 74
CSI Warehouse  73
Bahnhof73
42 71
44 71
Березники  71
39 70
45 70
The Coach House70
41 69
Stevnshøj  69
Gemeindehaus   68
E  68
McDonald's 68
Golden Haven Memorial Park 66
Gemeindeamt65
Unit 1 65
43 64
Højgård64
The Vicarage   63
Makado 63
46 62
Top Center 62
Netto  62
Møllebækkollegiet  61
Garage 61


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

Re: [Tagging] Spelling: vending=news_papers

[Andrew Hain]

Andreas Goss andig88@... writes:

 Checking with taginfo and the German wiki that's actually what it states 
 and what is used, the spelling was only corrected in the English Wiki. 
 (Most of the nodes are in Germany)

The help pages for some keys such as 
http://wiki.openstreetmap.org/wiki/Key:shop have a template for the list 
of values that is shared between languages so that updating the page in 
one language updates all of them.

--
Andrew


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

Re: [Tagging] [Talk-GB] route relations type=road

[Andrew Hain]

But surely I can see no obvious harm in the presence of the relations. Also 
searching the database by reference doesn’t always work, for instance not all 
road segments tagged  A1 in the UK are part of the road from London to 
Edinburgh.

--
Andrew


From: Chris Hill 
Sent: 07 December 2015 10:27
To: talk...@openstreetmap.org
Subject: Re: [Talk-GB] route relations type=road

On 07/12/15 18:11, Philip Barnes wrote:
> On Sat, 2015-12-05 at 00:54 +, Dave F. wrote:
>> Hi
>>
>> I know this has been discussed before , but recent edits by user:
>> abc26324 prompts me to ask/verify again the point of road relations
>> in the UK. Example:
>>
>> http://www.openstreetmap.org/relation/103301#map=10/51.2112/-2.5578
>>
>> Route relations are meant to represent, err... routes taken by people
>> that transverse multiple different ways; such as bus cycle etc & not
>> just a 'collection' of things, especially when they can easily be
>> collated/extracted from the ref on the actual way.
>>
>> I notice even the M4/M5 have one apiece. This has lead to tag
>> duplication which can never be a good thing.
>>
>> Are there any roads in GB where references are shared? If not, I see
>> no reason for their existence.
>>
> I have noticed that he is at it again and has not responded to either
> my comment with regards to the A50, or chillly's comments with regard
> to the A161.
>
> This time he has added a relation for the bits of the A1 that are not
> A1(M), there is already an A1 relation. I again am not sure why we need
> such relations, and the history is too big to view.delete
>
The author has not responded, so I have deleted the route relation for
A161. I will use changeset comments on any more that I find in the UK to
discuss why they are there - my expectation would be to delete any
others but only after attempting to engage the author.

--
Cheers, Chris (chillly)


___
Talk-GB mailing list
talk...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Tagging] Nominatim’s use of is_in and tag documentation

[Andrew Hain]

A detailed explanation of when Nominatim uses the is_in tag was recently posted 
to the talk mailing list 
[https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html]; it 
only does so for certain objects and only when boundaries haven’t been mapped 
properly.


It may therefore be possible to add advice to the wiki saying that anyone who 
adds this tag anywhere else is wasting their time, but as with other tags you 
would want to consider other data consumers.


So, is there anyone else out there who uses the tag differently and is it safe 
to add this information to the wiki without a health warning?


--

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

Re: [Tagging] BCP 47, Multilingual Standard and OSM

[Andrew Hain]

Unfortunately the wiki editor who changed the page didn't give an explanation 
for the change and there is no discussion on the talk page (OSM tags shouldn't 
be described as deprecated without explaining what is wrong with them). You 
could try contacting the editor.


--

Andrew



From: Satoshi IIDA 
Sent: 10 October 2016 11:35
To: Tag discussion, strategy and related tools
Subject: [Tagging] BCP 47, Multilingual Standard and OSM


Hello list,

Please let me clarify :)
I wonder if there is some consensus on multilingual standard about using BCP 47?

https://tools.ietf.org/html/bcp47

In Japan, we have been using "name:ja_rm" or "name:ja_kana" for expression of 
Roman writing or pronunciation, traditionally (since around 2010?).
But currently, "name:ja_rm" or some other tags are going to be treated as 
deprecated.

https://wiki.openstreetmap.org/wiki/Names
[https://wiki.openstreetmap.org/w/images/thumb/6/61/Helena%2C_Montana.jpg/240px-Helena%2C_Montana.jpg]

Names - OpenStreetMap Wiki
wiki.openstreetmap.org
If the name can be spelled without an abbreviation, then don't abbreviate it. 
Computers can easily shorten words, but not the other way (St. could be Street 
or Saint).



Problems are...

1. existing tags on objects ("name:ja_rm" and so on)
Maybe mechanical or mass edit would be needed.

I guess this would be huge cost for separation & need cost of existing Mappy 
app clients.

2. name:zh
Chinese language is represented as "zh" in ISO639-1.
But as using BCP 47, it is separated in several scheme.
(such as traditional writing in Taiwan, and simplified one in PRC.)

Currently some Chinese languages are intermingled in one "zh" scheme.

https://taginfo.openstreetmap.org/keys/name%3Azh#values

Some discussion are already rising on Taiwan mappers.
https://osmtw.hackpad.com/RFC-Multilingual-names-ngewyizFYzN
[https://hackpad.com/static/img/hackpad-logo-112.png]

[RFC] Multilingual 
names
osmtw.hackpad.com
?? ??? name ?? (tag),?? alpha-2 code of ISO 639-1,??? 
name:zh?,,? key ??? Everest 
? http://www.openstreetmap.



Your comments welcome!


P.S.
Related information.

https://lists.openstreetmap.org/pipermail/talk/2012-April/062803.html
https://lists.openstreetmap.org/pipermail/tagging/2012-August/011005.html
http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names#Standard_language_codes


--
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Review of wiki documentation for is_in

[Andrew Hain]

The documentation for is_in [https://wiki.openstreetmap.org/wiki/Key:is_in] has 
accreted various additions from multiple hands that do not always correspond to 
the Nominatim advice 
[https://www.mail-archive.com/talk@openstreetmap.org/msg56183.html]. Could we 
thrash out something that represents best practice for this tag?

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

Re: [Tagging] Undiscussed changes for wki pages about access mode "designated".

[Andrew Hain]

Is anyone willing to step forwards to mentor him in the hope of him becoming a 
constructive contributor?
--
Andrew

From: Andy Townsend 
Sent: 10 March 2017 20:29:05
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Undiscussed changes for wki pages about access mode 
"designated".

On 10/03/2017 19:36, Yves wrote:
> Not saying it's not useful, but at least self-moderation should be
> considered.

I'll try and be tactful here - let's just say that that approach has
been suggested :)

Best Regards,

Andy


___
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] Mapping time zones as geometries (relations)

[Andrew Hain]

I think this idea is a winner. We have geometry  for the tricky cases but this 
can just fall through to the administrative geometry in places such as Arizona 
outside the reservations.

--
Andrew

From: Wolfgang Zenker 
Sent: 07 March 2017 10:38:01
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Mapping time zones as geometries (relations)

Hi,

* Colin Smale  [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this.

> We need to address reality; I suggest there are the following options:

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone"

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things.

> What about maritime TZ boundaries that don't correspond to an admin
> boundary?

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done.

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

___
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] wikipedia links and copy + paste in tag definitions

[Andrew Hain]

What about the Wikidata links that some pages have in their infoboxes? Is there 
the same objection there?

--
Andrew

From: Martin Koppenhoefer 
Sent: 29 April 2017 21:26:36
To: tagging@openstreetmap.org
Subject: [Tagging] wikipedia links and copy + paste in tag definitions

A lot of tag definitions sooner or later get a wikipedia link to an article 
(typically with the same name as the tag) attached to their beginning and/or 
the first paragraph(s) are copied to the definition.

I'm sure people are acting in good faith when doing it, but I don't think it's 
helpful. Wikipedia articles have a different scope, and quite often there are 
several articles in WP for what in OSM is tagged with the same tag, and 
sometimes we have multiple tags in OSM each covering a specific aspect or 
subtype of what is covered by a single WP article.

One recent example is the linking of the WP article castle from the osm tag 
castle, where our tag covers much more than just medieval fortified residences 
in Europe and the middle east (e.g. what in WP is described under chateau, or 
the Japanese Shiros and Russian Kremlins), but there are countless others.

Please do not do it. Don't link to WP, especially not in the beginning (as if 
their definition automatically was equal to ours), because even if the current 
state is fine, we don't control WP and don't know how they will structure their 
lemmas in the future. If you copy definitions from WP, check very well if all 
parts that you copy are describing the actual meaning of the OSM tag, and add 
missing aspects or those that might not fit for this specific WP article but 
that are essential for the documentation of the OSM tag.

Cheers,
Martin

sent from a phone
___
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] wikipedia links and copy + paste in tag definitions

[Andrew Hain]

Defending the wiki from the twin editing hazards of editors with more 
enthusiasm than judgement and cargo cult-style copying by people who 
misunderstand the reasons to do or not to do things is difficult. For one thing 
you do not want to sink to that level yourself when editing.

--
Andrew

From: Martin Koppenhoefer 
Sent: 01 May 2017 22:07:11
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] wikipedia links and copy + paste in tag definitions


2017-05-01 20:06 GMT+02:00 Frederik Ramm 
>:
I wouldn't worry too much.

A Wikipedia link is an optional component that can be added to a tag
description to someone who knows what the tag is about.


I also thought like this, but not so rarely I have noticed people are not only 
adding this link as the first word, they are also replacing the following 
definition by the first paragraph of the English wikipedia article with the 
same name.

As some people have now started to create wikidata objects for OSM tags, I am 
sort of worried that part of our authority on the meaning of tags might be 
slowly externalized: https://www.wikidata.org/wiki/Q29637965

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

Re: [Tagging] Emergency shelters

[Andrew Hain]

Is there a case for a general mapping scheme for information that ceases to be 
valid on a date and could be automatically removed afterwards?

--
Andrew

From: Nick Hocking 
Sent: 08 September 2017 04:12:35
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Emergency shelters

Eric wrote   "Why would you delete data that is still valid and useful?"


My concern is that if these are permanent features, then people will say "ooh - 
they'll be the same as last time" and of course they probably won't be the same 
as last time and we may route people to a wrong place, with possible tragic 
results.

I agree that this information should be left in place, but marked , unusable, 
until specifically activated by authorities, which I agree should be well ahead 
of time, so long as people know that they will not be usable until a state of 
emergency is declared.

Activation should be on a center by centre basis so that authorities will be 
more likely to ensure the list of centers is accurate and up-to-date.

I also think that this information should NOT be edited, in any way by anyone 
other than the authorities. This brings back the old arguments about read only 
data in OSM.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation in Feet as part of Peak Names

[Andrew Hain]

Or, indeed, you could put a conversion in the editor between the mapper typing 
a figure in and the elevation being saved to the database.

--
Andrew

From: Warin <61sundow...@gmail.com>
Sent: 08 September 2017 02:59:39
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Elevation in Feet as part of Peak Names

On 08-Sep-17 09:10 AM, Dave Swarthout wrote:
Adding numeric values to the name of a peak is not okay. As for using feet in 
the "ele" tag instead of meters, JOSM discourages this practice and I think we 
should too. It's long past the time when Americans and other countries still 
using archaic and cumbersome measurement systems based on the length of the 
king's foot or thumb should embrace the metric system. The down side is that 
very peak I add involves an extra step.

Aviation still uses feet?
Asking a mapper who may not be familiar with conversion into meters leads to 
errors. I'd rather have the render do the conversion as is done for other 
dimensions.

Cheers,

Dave

On Fri, Sep 8, 2017 at 5:57 AM, Jo 
> wrote:
ele can of course be in feett or lightyears for that matter, but it's a lot 
easier to work with if they are all in the same unit.

2017-09-08 0:22 GMT+02:00 Warin 
<61sundow...@gmail.com>:
On 08-Sep-17 07:39 AM, Shawn K. Quinn wrote:
On 09/07/2017 04:31 PM, Mike Thompson wrote:
User Raymo853 and I are having a friendly discussion on changeset
50470413[1]. He has been adding the elevation of mountain peaks (in
feet) to the name tag. For example, he changed "Crown Point" to "Crown
Point 11,463 ft."[2] While the wiki doesn't specifically address the
issue of elevation as part of a peak name, it does say "Name is the name
only"[3].

Could we get feedback from the wider community on this?
That's what this is for: https://wiki.openstreetmap.org/wiki/Key:ele

The only catch is that it has to be in meters, so you would tag
ele=3493.9 in your example.


+1 to name tag is name only.


--

ele tag should be used for this information.

And I would think that the ele value can be in feet just like other dimensional 
units of width, height etc.

Should this be put as a new proposal?



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


___
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


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

Re: [Tagging] shop=fashion shop=boutique

[Andrew Hain]

Let’s put it this way: how many people who use the map database, whether 
working from planets, editing where these tags could already have been used, 
searching for objects by tags or any other way, find the tags shop=boutique or 
shop=fashion helpful or wish there were more of them?

--
Andrew

From: Marc Gemis 
Sent: 01 September 2017 12:27:38
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] shop=fashion shop=boutique

because other mappers thought it was needed to distinguish the two ?
Who are we (the people using this mailing list) to decide that other
mappers cannot tag a shop=boutique if it is already used 11.000 times
?
So if you want to tag that shop as shop=clothes with subtags fine, do
it. Document it, we'll see in a couple of years which one of the 2
methods is more popular.
But please do not write that one is better than the other at this
moment, nor  mark one as obsolete. Let the (whole) community decide.

and now we all go back to mapping :-)

m.

On Fri, Sep 1, 2017 at 12:48 PM, Jean-Marc Liotier  wrote:
> I still don't understand the need for anything other than shop=clothes
> used with assorted modifiers. Fashion is subjective and I do not see
> why exclusive distribution channels should be tagged differently as
> they are essentially clothes shop with no price tags and an attitude.
>
> shop=car covers both the average Volskwagen dealership and the workshop
> that sells handmade locally built overpriced exotics with golden urinal
> that you never heard of. Why should it be different for clothes ?
>
> ___
> 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] Dog-friendly cafes

[Andrew Hain]

How should an establishment that bills itself as “the dog friendly cafe” be 
tagged?

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

[Tagging] Odd and even ranges of addresses

[Andrew Hain]

Where I live in Britain some properties have a range of numbers in their 
address. Depending on how the the road is numbered a building tagged 
addr:housenumber=100-102 may be even numbers only leaving out 101. I have been 
using addr:interpolation to model this but Osmose gives a warning. Is there a 
better way to map this or does Osmose need a bug report?

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

Re: [Tagging] address property vs. housenumber as a feature

[Andrew Hain]

I was recently on holiday in Turin, where addresses are mapped as POIs inside 
the buildings; a few have been fleshed out as businesses but many shops remain 
unmapped. I was once able to identify which node to fill out but the others 
were going to take more time than I was willing to spend.


--

Andrew



From: Martin Koppenhoefer 
Sent: 09 May 2018 22:41
To: tagging@openstreetmap.org
Subject: [Tagging] address property vs. housenumber as a feature

Is there a way to indicate a housenumber is a feature, vs. a property?

In many places, housenumbers refer to buildings or sites, and you might omit 
addresses on contained features (because you can hope for inheritance from the 
containing address object). Unfortunately the situation in Italy is a bit 
different in this regard, as housenumbers are assigned to entrances (either 
site or building) and even potential entrances.

This leads to the common situation that the same housenumber appears multiple 
times (on the entrance as a feature and on the contained features like 
businesses as an address property). Businesses being accessible through 
different housenumbers is not a rare exception but rather common. They deal 
with it differently: while some list all or a bunch of the numbers as their 
address, others choose one (often but not always the main entrance).

If you map the POI as an area, you might often be able to represent the numbers 
that are part of the area (unless they are not on the ground floor, or the 
building is not directly on the street hence the number is typically at a gate 
on the site perimeter). Still most people (including myself) don’t map small 
businesses in shared buildings as areas, so duplicated address information is 
common.

Some of my fellow mappers are dealing with this by adding the poi information 
to the entrance, but this is unsatisfactory because of several reasons:

- it can only deal with cases where one number is for one business, it doesn’t 
work for multiple entrances or numbers and it doesn’t work for shared entrances 
(one number for several pois)

- it is topologically wrong (the poi is not on the perimeter, neither inside 
nor outside, it is inside). The poi is also not the same as the entrance, if 
you add entrance=* it is an entrance and should not get other tags for a 
different object (the poi) like name etc.

Thoughts?

Cheers,
Martin

sent from a phone
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Tagging Info Page - 
OpenStreetMap
lists.openstreetmap.org
Your email address: Your name (optional): You may enter a privacy password 
below. This provides only mild security, but should prevent others from messing 
with your subscription.


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

Re: [Tagging] How to tag shop areas in a shopping mall ?

[Andrew Hain]

If of course all of their shops are mapped in detail as areas, they still get a 
consistent target.

--
Andrew

From: OSMDoudou <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com>
Sent: 24 January 2018 19:46:26
To: 'Tag discussion, strategy and related tools'
Subject: Re: [Tagging] How to tag shop areas in a shopping mall ?


Following the discussion here, I changed the mapping of the mall to move tags 
from individual nodes to an area.



For one shop, it attracted feedback from the commercial entity who maintains 
its data on OpenStreetMap saying the change broke something at their side. See 
the discussion on the changeset: [1].



I'm very glad a company enriches the map and actively maintains the data (1700 
nodes, they say), so I really want to support them and I reverted the change.



But as they're asking to maintain their shops tagged as node, this is 
effectively asking the community refrains itself from improving the tagging of 
the mall (following the idea that shops are better mapped as areas than nodes), 
and this is not in the interest of the community (which is to have a complete, 
coherent, accurate and maintained mapping of the place).



So, I wanted to ask your views on how to deal with this situation.



[1] https://www.openstreetmap.org/changeset/55640175#map=19/50.45645/3.93247


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

Re: [Tagging] Missing access value (access=license / authorization?)

[Andrew Hain]

It’s not absolutely necessary but you get the chance of some feedback from 
other OSM users that you may appreciate later if you do it, together with the 
chance to advertise the tagging scheme to other mappers or data consumers. 
Think of it as your call, there are other ways especially for intrinsically 
local tags.

--
Andrew

From: Szem 
Sent: 02 August 2018 20:35
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Missing access value (access=license / authorization?)

I would just ask that this proposal process is absolutely necessary? (I
don't want to bypass it simply I don't know)

2018.08.02. 21:25 keltezéssel, Marc Gemis írta:
> Kevin,
>
> Just to prepare you a bit: it's very well possible that you will get
> objections very late in the approval process. eg. during the voting
> phase from people that never discussed the tag before. We've seen this
> e.g. with amenity/tourism=reception(_desk), where people just ignored
> all previous discussion on the mailing list and the discussion page.
>
> I wish you good luck with your proposal though.
>
> m.
> On Thu, Aug 2, 2018 at 8:11 PM Kevin Kenny  
> wrote:
>> Is there a documented process for putting a proposal? I'm certainly willing 
>> to draft the text, although I'm not going to be able to do it before the 
>> weekend. Can someone else run the proposal process or at least guide me 
>> through it?
>>
>> On Thu, Aug 2, 2018, 12:55 PM Szem  wrote:
>>> A couple of us have said their opinion.
>>> It seems to me nobody have said the access=permit tag is useless.
>>> And now, what is the next step? Worldwide the 97% of editors have not read 
>>> this mailing list. Without written a short explanation in the wiki only a 
>>> few editor will use it, or they will use a lot of other form.
>>>
>>> (There would be no greater agreement if we would analyze e.g. 
>>> access=permessive tag…)
>>>
>>>   Szem
>>>
>>> ___
>>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

My own preference is to have no (zero) units in the database, decimals where 
wanted (maxwidth=2.2) and unit management support in editors.

--
Andrew

From: Warin <61sundow...@gmail.com>
Sent: 27 July 2018 12:27:04
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values

On 27/07/18 21:11, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 26. Jul 2018, at 21:26, François Lacombe  
>> wrote:
>>
>> I don't want to break things but only improve them, all the best
>
> one issue with using only one unit for a tag is that they can’t always be 
> transformed without rounding. E.g. maxspeed=55mph cannot be converted to kph 
> without losing information
>
> Also, shorter notations are better readable, hence reduce the likeliness of 
> errors not noted.
>
> On the other hand, I agree in the example of voltage it would make it easier 
> for queries to use the same unit. (you still can make queries, but they are 
> more complicated if you have to take units into account)
>
>

Unfortunately not everyone uses the same units... heights are in meters, feet 
.. depending on where you come from or what activity you follow.

Voltages are in volts so the same units... but multiplies are common for high 
voltages .. no one uses 33000 volts .. they all use 33 kv.
If you stipulate that all voltages have to be in kv then 115 v becomes 0.115 
kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
that is not how people talk about these things.



___
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] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

Data consumers would convert to units they are interested in, no others.

--
Andrew

From: Andy Townsend 
Sent: 27 July 2018 14:34:41
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values

On 27/07/2018 13:19, Andrew Hain wrote:
> ... and unit management support in editors.

... and presumably also in every data consumer that uses OSM data too?

___
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] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

I disagree in the specific case of maxheight and maxwidth:

An important use of these tags is to compare the dimension of a vehicle with 
the limits. Also the format maxheight=12'11" imposes a particular cognitive 
load on subsequent mappers and data users who may not be familiar with the 
format.

--
Andrew

From: Philip Barnes 
Sent: 27 July 2018 17:52:31
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values



On 27/07/2018 16:20, marc marc wrote:
> I agree maybe with the exeption of case like maxspeed
And maxheight and maxwidth.

Phil (trigpoint)

___
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] building = house vs detached.

[Andrew Hain]

I see building=house as useful because it distinguishes houses from blocks of 
flats but the case to have anything that repeats way geometry or 
building:levels is much less obvious.

--
Andrew

From: Paul Allen 
Sent: 23 July 2018 22:55:36
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] building = house vs detached.

On Mon, Jul 23, 2018 at 10:45 PM, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:

> On 23. Jul 2018, at 17:07, Paul Allen 
> mailto:pla16...@gmail.com>> wrote:
>
> How about building=residential to replace house/terrace/detached?


-1, there are several established tags for residential buildings in osm, e.g. 
apartments,

The wonderful thing about standards is that there are so many of them.  We have 
many tags for residential buildings
and the result is that they're used inconsistently.

and as the example shows, it isn’t possible to reliably identify terraced 
houses just by analyzing the geometry, so
why would we want to remove the details? If someone is only interested in a 
detail level like “residential”, they won’t have to care about the differences 
in meaning and can normalize them all locally to residential.

That's what we do with some other types of buildings.  We separate form from 
function.   We have industrial buildings
and then specify the industry.

We can have building=bungalow but that is redundant when it just means 
building:levels=1.

We can have building=detached, building=semi,  building=house with most people 
using them incorrectly or
inconsistently or we can have building=residential and let the footprint 
indicate the type.  Or, if you insist, add
residential=* where clarification is desirable.

We've just had a lot of people say "The wiki says this should be 
building=detached but I always use building=house."
That indicates the tags don't map well to how people actually think.  It also 
means that you can't rely on the value
used indicating what it is meant to.  We can carry on with the current muddle 
or we can try to do better.  You vote muddle.

--
Paul

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

Re: [Tagging] building = house vs detached.

[Andrew Hain]

I will admit to having stuck to building=house in Britain and letting the 
geometry of the way identify the configuration.

--
Andrew

From: Tom Pfeifer 
Sent: 22 July 2018 21:27:30
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] building = house vs detached.

Probably the reason can be explained etymologically.

In the UK, terraced houses (AmE row houses) are very common, so those lucky 
enough to hear less
noise from their neighbours emphasize that by owning a 'detached' (not attached 
to a terrace) or
'semi-detached' (two houses sharing a wall) building. The 
detached/semi-detached also allow outdoor
access to the back garden, so the 'end-of-terrace' house is marketed with a 
similar advantage.

In countries where terraced houses are less common, there is less need to 
emphasize that the house
is free-standing. Also, 'house' is easier to understand for a non-native 
speaker than 'detached'.

tom

On 22.07.2018 20:56, Mike H wrote:
> The definitions of building=house and building=detached on the wiki are very 
> similar and don't seem
> to have any meaningful difference.
>
> I've seen people say that house is meant for rowhouses, and detached should 
> be for
> stand-alone houses, but there is no documentation that explains that. If that 
> is the intended
> meanings of the tags, then the wiki pages need some work.
>
> As far as how I've seen things actually mapped, I've only ever seen the 
> building=house tag. Taginfo
> shows 1.2 million uses of detached, and 27.2 million uses of building=house, 
> so they are both used
> quite a bit, but house is used a lot more.
>
> Can anyone elaborate on these tags, or have ideas on how they could be better 
> written about?
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dhouse
> https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached

___
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] Is waterway=riverbank an 'Old scheme' ?

[Andrew Hain]

Would you favour a campaign like the one to update old style multipolygons then?

--
Andrew

From: Dave F 
Sent: 06 September 2018 19:04:23
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Is waterway=riverbank an 'Old scheme' ?

Clarifying:

natural=water, water=river fits in with all other bodies of water mapped
as polygons.

Cheers
DaveF

___
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] Town Currencies

[Andrew Hain]

You could try something following 
https://wiki.openstreetmap.org/wiki/Key:payment like payment:bristol_pound=yes.

--
Andrew
Key:payment - OpenStreetMap 
Wiki
Defines if a certain payment method is accepted or not. The notation is made 
with a subkey: payment:method = yes/no/interval
wiki.openstreetmap.org



From: Neil Matthews 
Sent: 07 July 2018 00:47
To: tagging@openstreetmap.org
Subject: [Tagging] Town Currencies

How should one map that an establishment accepts payment in the local
town currency* (as well as the traditional national one), e.g. Bristol
pounds (B£) as well as pounds sterling (GBP).

Cheers,
Neil

*actually a gift voucher -- where B£1 == £1.



___
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] Tagging fraction house numbers?

[Andrew Hain]

Unicode fractions have an important advantage: they can’t run into a previous 
number, 1½ rather than 11/2.

--
Andrew


From: James 
Sent: 12 March 2018 15:43:33
To: Tag discussion, strategy and related tools
Subject: [Tagging] Tagging fraction house numbers?

https://i.imgur.com/eigT5hX_d.jpg?maxwidth=640=thumb=medium

How should this be tagged in housenumber? Using unicode ( ½ ) or ASCII( 1/2 )?


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

Re: [Tagging] Tagging request: missing admin_level tags

[Andrew Hain]

I agree entirely with Dave on this. Consider this a request to consider 
systematically removing the admin_level tag from ways or making it a 
discardable tag only for ways.

--
Andrew


From: Dave F 
Sent: 11 March 2018 23:49:45
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Tagging request: missing admin_level tags

On 11/03/2018 09:51, Christoph Hormann wrote:
>
> * tagging the ways in addition to the relation is ok but not required.

I agree with all your points except this. I think duplication is prone
to error & should be discouraged.

DaveF.

___
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 - (consulate)

[Andrew Hain]

Embassies that extend over multiple sites or are neighbours (the embassies of 
Ecuador and Colombia in London are flats in a block of flats) don’t correspond 
to the normal meaning of the landuse tag.

--
Andrew

From: Allan Mustard 
Sent: 25 October 2018 02:25:07
To: tagging@openstreetmap.org
Subject: [Tagging] Feature Proposal - RFC - (consulate)


I like Graeme's idea.  Round peg in round hole.  How would people feel about 
modifying the current Consulate proposal to encompass this?  Or should I leave 
the proposal for amenity=consulate as it is?

On 10/25/2018 3:13 AM, Graeme Fitzpatrick wrote:
Just had a thought :-)

Would this work under the landuse=government / civic_admin / public_admin that 
was being discussed t'other day?

Maybe something like:

landuse=government

government=diplomatic (rendering with the current "embassy" flag)

diplomatic=embassy / consulate etc

services=visa; passport etc

Thanks

Graeme

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Andrew Hain]

The sum total of all of the properties making up a university absolutely is an 
area.

--
Andrew

From: Richard 
Sent: 02 October 2018 20:21:45
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] My "weirdly unnatural aversion to relations"

On Tue, Oct 02, 2018 at 09:05:53PM +0200, Mateusz Konieczny wrote:
>
>
>
> 2. Oct 2018 19:27 by ricoz@gmail.com :
>
>
> > On Tue, Oct 02, 2018 at 05:01:17PM +0200, Mateusz Konieczny wrote:
> >
> >> > I can give you a case that is more complicated.  The University of 
> >> > Edinburgh.  As well as a main>  campus, and a subsidiary mini-campus,  
> >> > it has individual buildings scattered all around the city.> It could be 
> >> > mapped as a multipolygon but it would be a lot of work.  Imagine using a 
> >> > multipolygon>  natural=wood to handle many individual, widely-spaced 
> >> > trees by poking lots ofi rregular, large holes>  in it where trees 
> >> > aren't.
> >> > See > >> https://www.ed.ac.uk/maps/maps 
> >> > >>  <>> https://www.ed.ac.uk/maps/maps 
> >> > >> >>   And note that what you get there 
> >> > is the first of five tabs> covering different agglomerations of 
> >> > buildings.
> >> >
> >> > I think the only feasible way of handling this would be a site relation. 
> >> > Maybe you can think of a better> way of handling it.
> >>
> >>
> >>
> >>
> >> Why selecting buildings and tagging them to site relation is easier than 
> >> selecting building and adding them to  a multipolygon realation?
> >
> > looks like abuse of multipolygon relation to me.
> >
>
>
>
>
> why abuse? Sole reason for multipolygon relations is to tag
> disjointed areas or areas with holes in them.

you name it. AREAS. A university is not an area.

Rcihard

___
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] Rethinking Map Features

[Andrew Hain]

Now the wiki has data items and scripting in Lua I have been wondering whether 
they are a useful alternative to Taginfo-driven lists.

Advantages of server scripts:

  1.  Descriptions can be generated from data items, tharefore they can be in a 
language where there is no long form documentation for the key. This resolves 
the issues that have limited use of taglists in languages other than English 
because descriptions can be rolled out quickly and some can be copied from the 
old map features templates.
  2.  Tables at the top of pages are visible immediately,
  3.  A successful connection to tagindo.openstreetmap.org is unnecessary.

Advantages of taglists driven by Taginfo:

  1.  The technology aleady exists and can be rolled out.
  2.  Separate scripts avoid overloading the server (Map Features in Polish, 
Ukrainian and Japanese hits wiki limits).
  3.  The web scripts are free-standing and can be hosted on another website 
outside the wiki,

(crossposted from 
https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists)

--
Andrew
Talk:Taginfo/Taglists - OpenStreetMap 
Wiki<https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists>
Languages. This is a very cool feature! One question: Could the template get 
the langugage automatically? I know this is done on some templates (e.g. 
Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a template 
wizard.
wiki.openstreetmap.org


From: Joseph Eisenberg 
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Rethinking Map Features

Andrew,

I now think it is a good idea to switch to taglists for all of the Map
Feature page templates. It will make it much easier to keep the pages
consistent and to a reasonable length if all of the descriptions are
pulled from the wiki pages directly (just as is done for descriptions
used by Taginfo).

This just means that any deprecated or discouraged tags which are
currently "strikethrough" on Map Features will need something in the
description that mentions that they are discouraged. This is a good
idea anyway, so that the documentation is consistent.

Joseph

On 7/7/19, Andrew Hain  wrote:
> I have been working on a scheme to improve the cross-language quality of Map
> Features.
> [https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]
>
> Of course the page may deserve a bigger or deeper rethink.
>
> --
> Andrew
> Talk:Map Features - OpenStreetMap
> Wiki<https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features>
> amenity=school rendering colour. amenity=school is displayed in the page as
> a light-purple area for ways, whereas mapnik renders them as a pale yellow
> colour
> wiki.openstreetmap.org
>
>

___
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] Rethinking Map Features

[Andrew Hain]

How would you stop the bot from going down and protect against whoever runs it 
leaving OSM?

--
Andrew

From: Yuri Astrakhan 
Sent: 03 August 2019 23:06
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Rethinking Map Features

The biggest issue with using Lua/Server side scripting with large lists is that 
every single data item used on a wiki page requires a separate SQL query (or 
even multiple ones), due to how mediawiki + wikibase is implemented.  On the 
other hand, relying on TagInfo has some shortcomings - TagInfo does not (yet) 
understand data items, relying on its own wiki page parser, it is very fixed in 
a way it can present information, and every wiki page view also uses makes 1 or 
more external call to taginfo (higher chance of something going down).

There is a popular middle ground that can solve it for us -- very flexible, 
highly performant, uses a common data source (data items), and relies on a 
single system.  Essentially it is a bot-updated wiki markup:

* an editor adds a special template at the top of a wiki page, where they 
specify a SPARQL query for the data they want - i.e. "find all 
label+description+image of data items, whose type is a 'tag' and whose key is 
'denomination'".  A bot would run that query on occasion (e.g. once a day), and 
append query results to that same page after the template.  Thus, the result 
becomes a regular wiki markup, without any significant server costs.  See 
https://www.wikidata.org/wiki/Template:Wikidata_list

The PROs:
* The bot can run at any moment, by anyone, to update the data
* In the worst case of a bot completely dying, wiki markup could be edited by 
hand until the bot is fixed
* very flexible - a complex query could get any data needed for the output, and 
the output is templated to show in any kind of a list/table format.

CONs:
* every list update is essentially a wiki page edit, slowly increasing history. 
This is not that big of a deal because size wise the growth is small and has 
very little performance impact, plus it makes it possible to track changes with 
time.

On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>> wrote:

Now the wiki has data items and scripting in Lua I have been wondering whether 
they are a useful alternative to Taginfo-driven lists.

Advantages of server scripts:

  1.  Descriptions can be generated from data items, tharefore they can be in a 
language where there is no long form documentation for the key. This resolves 
the issues that have limited use of taglists in languages other than English 
because descriptions can be rolled out quickly and some can be copied from the 
old map features templates.
  2.  Tables at the top of pages are visible immediately,
  3.  A successful connection to 
tagindo.openstreetmap.org<http://tagindo.openstreetmap.org> is unnecessary.

Advantages of taglists driven by Taginfo:

  1.  The technology aleady exists and can be rolled out.
  2.  Separate scripts avoid overloading the server (Map Features in Polish, 
Ukrainian and Japanese hits wiki limits).
  3.  The web scripts are free-standing and can be hosted on another website 
outside the wiki,

(crossposted from 
https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists)

--
Andrew
Talk:Taginfo/Taglists - OpenStreetMap 
Wiki<https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists>
Languages. This is a very cool feature! One question: Could the template get 
the langugage automatically? I know this is done on some templates (e.g. 
Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a template 
wizard.
wiki.openstreetmap.org<http://wiki.openstreetmap.org>


From: Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
mailto:tagging@openstreetmap.org>>
Subject: Re: [Tagging] Rethinking Map Features

Andrew,

I now think it is a good idea to switch to taglists for all of the Map
Feature page templates. It will make it much easier to keep the pages
consistent and to a reasonable length if all of the descriptions are
pulled from the wiki pages directly (just as is done for descriptions
used by Taginfo).

This just means that any deprecated or discouraged tags which are
currently "strikethrough" on Map Features will need something in the
description that mentions that they are discouraged. This is a good
idea anyway, so that the documentation is consistent.

Joseph

On 7/7/19, Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>> wrote:
> I have been working on a scheme to improve the cross-language quality of Map
> Features.
> [https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]
>
> Of course the page may deserve a bigger or dee

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose

[Andrew Hain]

Unless you can justify a difference based on the nature of the information 
recorded instead of tag counts, deprecating contact:phone makes tagging less 
orthogonal, which is a nuisance for both mappers and map consumers.

--
Andrew

From: Valor Naram 
Sent: 25 August 2019 17:40
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one 
purpose

https://wiki.openstreetmap.org/wiki/Key:phone and 
https://wiki.openstreetmap.org/wiki/Key:contact don't provide any tagging 
method to tag numbers for emergency, general enquiries etc. Both keys just 
allow the tagging of one phone number on one object.

But feel free to write a proposal to extend the tagging scheme of `phone` to:
- `phone`
- `phone:emergency`
- `phone:night`
- `phone:press`

Feel free also to extend the `email` tag:
- `email`
- `email:press`
- `email:legal`

But we're drifting away from the topic "Multiple tags for one purpose". We 
should discuss the problem of "fragmentation" in general. But deprecating 
`contact:phone` in favor of `phone` can be the logical step.

Cheers

Sören Reinecke alias Valor Naram


 Original Message 
Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one 
purpose
From: Colin Smale
To: tagging@openstreetmap.org
CC:



Your model (using only phone=*) only allows an object to have a single phone 
number. How do you propose modelling multiple phone numbers on a single object? 
For example, one for general enquiries, one for emergencies, one for staff,...

Note I am not talking about tagging here, but trying to discuss the underlying 
data model.




On 2019-08-25 17:11, Valor Naram wrote:

> What about deprecating the contact: prefix, at least for phone? It doesn't 
> seem it will ever make it and is basically a deliberate tag fragmentation.

Yes, I recommend deprecating `contact:phone`


 Original Message 
Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 25. Aug 2019, at 07:20, Warin wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 
> 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that "key:phone" shows up first for a search for "phone", it's 
straightforward, and it's also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn't use 
presets type longer key names when there are no alternatives which would 
require to distinguish the tag from? People who do use presets don't have to 
care for tag names anyway.

If you search for "contact phone" the first hit is key:contact, one could argue 
a better result would be showing key:phone first for this search term as well, 
as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn't seem 
it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
___
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 - (Phone)

[Andrew Hain]

I oppose selectively deprecating contact:phone because without explaining whhy 
it diifers from other contact tags (populist appeals to tag counts don’t count) 
it makes tagging less orthogonal.

--
Andrew

From: Valor Naram 
Sent: 28 September 2019 09:31
To: Tagging@openstreetmap.org 
Subject: [Tagging] Feature Proposal - RFC - (Phone)

Hey,

now I'm ready to open a new proposal which you can see here
https://wiki.openstreetmap.org/wiki/Proposed_features/Phone#Second_proposal_.28pending.29
I use the old proposal page for that but seperated content into section
to keep the history intact. The content is based on the discussion at
https://lists.openstreetmap.org/pipermail/tagging/2019-September/048339.html
. It tends to deprecate `contact:phone` in favor of the more used de-
facto `phone` tag. It's awful that we have two tags for the same
puropose in our database and that makes it more difficult for
developers and researchers to work with our data.

Cheers

Sören Reinecke alias Valor Naram


___
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] Rethinking Map Features

[Andrew Hain]

I have been working on a scheme to improve the cross-language quality of Map 
Features. 
[https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]

Of course the page may deserve a bigger or deeper rethink.

--
Andrew
Talk:Map Features - OpenStreetMap 
Wiki
amenity=school rendering colour. amenity=school is displayed in the page as a 
light-purple area for ways, whereas mapnik renders them as a pale yellow colour
wiki.openstreetmap.org

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

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[Andrew Hain]

Is it time for another controversial decisions page then?

--
Andrrw

From: Paul Allen 
Sent: 29 January 2020 17:04
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

On Wed, 29 Jan 2020 at 16:39, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:

for things like pharmacies or hospitals this is only true as long as iD also 
adds the tags that carto supports along the “non-standard” tags, or their users 
will complain about things not showing up on “the map”.

Or until carto gives in to iD (on the basis of numerical usage).  So it looks 
like
dual-tagging is going to become the norm any time iD comes up with an
alternative way of tagging something.

Carto and iD, they’re both very important for the actual tagging that people 
use.

Yep.  Anything decided here (on those rare occasions we manage to agree)
can be overridden by carto and/or iD.  It seems that, at best, we're filtering
out bad ideas before they get to carto/iD.  When I'm feeling particularly 
cynical,
I wonder if we're serving any useful purpose.

--
Paul

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

Re: [Tagging] Country-specific images for tags

[Andrew Hain]

One possibility would be to create data items for mappable attributes, for 
instance post_box:type=pillar.

--
Andrew


From: Paul Allen 
Sent: 13 April 2020 14:35
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Country-specific images for tags

On Mon, 13 Apr 2020 at 14:03, Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>> wrote:
I copied pictures from the Tag:amenity=post_box page in various languages, any 
more would be added by hand.

The UK has several types of postbox, only one of which is shown on the wiki
page for amenity=postbox.  What do you do in the wikidata if more UK examples
are added to amenity=postbox?

Would it be better (if it's technically possible) to instead have the wikidata
refer to
https://wiki.openstreetmap.org/wiki/Key:post_box:type#Values_in_use_in_United_Kingdom

--
Paul

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

[Tagging] Country-specific images for tags

[Andrew Hain]

One feature of the OSM wiki data items that has seen little use so far is the 
ability to set geographically specific properties. I have reorganised the 
images for amenity=post_box (https://wiki.openstreetmap.org/wiki/Item:Q6349) to 
use this scheme, but many countries are still missing and still need to be set 
up as options.

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

Re: [Tagging] Country-specific images for tags

[Andrew Hain]

I copied pictures from the Tag:amenity=post_box page in various languages, any 
more would be added by hand.

--
Andrew


From: Jake Edmonds via Tagging 
Sent: 13 April 2020 13:48
To: Tag discussion, strategy and related tools 
Cc: Jake Edmonds 
Subject: Re: [Tagging] Country-specific images for tags

It’s not obvious how this works (at least to me). At first I assumed the 
gallery pulled images from Wikidata but the Wikidata page doesn’t have those 
images listed.

> On 13 Apr 2020, at 14:16, Andrew Hain  wrote:
>
> One feature of the OSM wiki data items that has seen little use so far is the 
> ability to set geographically specific properties. I have reorganised the 
> images for amenity=post_box (https://wiki.openstreetmap.org/wiki/Item:Q6349) 
> to use this scheme, but many countries are still missing and still need to be 
> set up as options.
>
> --
> 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] Route names that aren’t names

[Andrew Hain]

Proposal for QA tools: flag anything with the same number in the name and ref.

--
Andrew


From: Richard Fairhurst 
Sent: 28 March 2020 18:18
To: Tag discussion, strategy and related tools 
Subject: [Tagging] Route names that aren’t names

Hello folks,

Route relation names aren’t in a great state, are they?

Let’s say that I want to render cycle route names on a map (because, well, I 
do). I zoom in on a way along the East Coast of Britain and I find it’s a 
member of this route:
 https://www.openstreetmap.org/relation/9579
 name=NCN National Route 1

Hm, ok. That’s not the name of the route, it’s a duplication of the ref (and 
network) - something we’ve known not to do with the name/ref tags for roads 
since time immemorial. No matter, there are other relations for the way, so 
let’s see if they’re any better:
 https://www.openstreetmap.org/relation/9476069
 name=EuroVelo 12 - North Sea Cycle Route - part United Kingdom 5

That’s _definitely_ not the name of a route. “part United Kingdom 5” is some 
OSM mapper’s shorthand. If I were to tell someone that I’m having a holiday on 
“part United Kingdom 5”, even someone who works for the route authorities at 
Sustrans or the European Cycling Federation, they’d look at me blankly. Anyway, 
this has a parent relation:
 https://www.openstreetmap.org/relation/9476239
 name=EuroVelo 12 - North Sea Cycle Route - part United Kingdom

Nope, that’s not great either. It in turn has a parent relation:
 https://www.openstreetmap.org/relation/1207220
 name=EuroVelo 12 - North Sea Cycle Route

That’s not good. It duplicates the ref and the network; it enforces arbitrary 
punctuation upon the data consumer. It is, I guess, the least wrong of any of 
these names. But that’s not saying much.

This isn't just a British thing, or an NCN thing, or a EuroVelo thing. Refs in 
names are depressingly ubiquitous. Better still: there are hundreds of routes 
with something like ref=12-83, name=(12) - (83) - with the added brackets 
meaning you can’t even filter them out based on a simple match. Then there are 
routes called "Aare-Route (Etappe 3)” and "Alpenpanorama-Route- Etappe 6 
(Thun-Fribourg)” and "[D10] Elberadweg [Abschnitt K] Dessau-Roßlau - Elster 
[linkselbisch]”. I wish I were making this up.

The upshot: bad luck if you want to render the actual names of routes on a map. 
You can’t.

A modest proposal: let’s use the name= tag in route relations for route names. 
Let’s use the ref= tag for route numbers. If it doesn’t have a name, it 
shouldn’t have a name= tag. Same as we do everywhere else.

If you need somewhere for a mapper-facing route description (and I can see that 
you need that for “part United Kingdom 5”), then I guess the obvious place to 
put that is the note= tag. But let’s keep it out of the name tag; and let’s 
have a concerted effort to remove them from existing name tags.

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

Re: [Tagging] Route names that aren’t names

[Andrew Hain]

This tagging habit arose because the ref isn’t displayed in the side panel, 
only the name. Fix that and we can do a big clean-up.

--
Andrew


From: Sarah Hoffmann 
Sent: 29 March 2020 10:41
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Route names that aren’t names

Hi,

On Sat, Mar 28, 2020 at 06:18:01PM +, Richard Fairhurst wrote:
> Route relation names aren’t in a great state, are they?
>
> The upshot: bad luck if you want to render the actual names of routes on a 
> map. You can’t.

Or want to search for them. The sad state of the name tag is the
only reason why you still can't search for hiking/cycling
routes on osm.org[1].

[1] https://github.com/osm-search/Nominatim/issues/413

> A modest proposal: let’s use the name= tag in route relations for route 
> names. Let’s use the ref= tag for route numbers. If it doesn’t have a name, 
> it shouldn’t have a name= tag. Same as we do everywhere else.
>
> If you need somewhere for a mapper-facing route description (and I can see 
> that you need that for “part United Kingdom 5”), then I guess the obvious 
> place to put that is the note= tag. But let’s keep it out of the name tag; 
> and let’s have a concerted effort to remove them from existing name tags.

Problem is that a large part of routes is mistagged this way.
The public transport people even officially recommend this crappy
tagging for the name tag[2]. So I suspect that this particular ship
has sailed a long time ago.

[2] 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Route

These days I wonder if it wouldn't be better if we introduce a tag
that explicitly contains the name only. How about official_name for a,
well, official name of the route and local_name for one that is used
by everybody else.

On top of that, it would be good to encourage more use of tags for all the
other info that nowadays ends up in the name tag. Most of the are actually
defined somewhere already:

* ref
* symbol
* operator
* region [3]
* itinary (or, as PT people prefer: from, to, via)
* section_name (section? stage? leg?)
* section_ref

[3] Basically the entity that 'ref'refers to. Sometimes that is a touristic
area, sometimes the operator. I'd rather call it 'network' but that tag
is already used for something else.

If this kind of extended tagging gets widely enough used, then the
name tag can just fall into oblivion.

Sarah

___
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] Route names that aren’t names

[Andrew Hain]

I’ve added a ticket to the side report:

https://github.com/openstreetmap/openstreetmap-website/issues/2573

--
Andrew


From: Andrew Hain 
Sent: 29 March 2020 11:19
To: Sarah Hoffmann ; Tag discussion, strategy and related 
tools 
Subject: Re: [Tagging] Route names that aren’t names

This tagging habit arose because the ref isn’t displayed in the side panel, 
only the name. Fix that and we can do a big clean-up.

--
Andrew


From: Sarah Hoffmann 
Sent: 29 March 2020 10:41
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Route names that aren’t names

Hi,

On Sat, Mar 28, 2020 at 06:18:01PM +, Richard Fairhurst wrote:
> Route relation names aren’t in a great state, are they?
>
> The upshot: bad luck if you want to render the actual names of routes on a 
> map. You can’t.

Or want to search for them. The sad state of the name tag is the
only reason why you still can't search for hiking/cycling
routes on osm.org[1].

[1] https://github.com/osm-search/Nominatim/issues/413

> A modest proposal: let’s use the name= tag in route relations for route 
> names. Let’s use the ref= tag for route numbers. If it doesn’t have a name, 
> it shouldn’t have a name= tag. Same as we do everywhere else.
>
> If you need somewhere for a mapper-facing route description (and I can see 
> that you need that for “part United Kingdom 5”), then I guess the obvious 
> place to put that is the note= tag. But let’s keep it out of the name tag; 
> and let’s have a concerted effort to remove them from existing name tags.

Problem is that a large part of routes is mistagged this way.
The public transport people even officially recommend this crappy
tagging for the name tag[2]. So I suspect that this particular ship
has sailed a long time ago.

[2] 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Route

These days I wonder if it wouldn't be better if we introduce a tag
that explicitly contains the name only. How about official_name for a,
well, official name of the route and local_name for one that is used
by everybody else.

On top of that, it would be good to encourage more use of tags for all the
other info that nowadays ends up in the name tag. Most of the are actually
defined somewhere already:

* ref
* symbol
* operator
* region [3]
* itinary (or, as PT people prefer: from, to, via)
* section_name (section? stage? leg?)
* section_ref

[3] Basically the entity that 'ref'refers to. Sometimes that is a touristic
area, sometimes the operator. I'd rather call it 'network' but that tag
is already used for something else.

If this kind of extended tagging gets widely enough used, then the
name tag can just fall into oblivion.

Sarah

___
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] Which languages are admissible for name:xx tags?

[Andrew Hain]

Why on earth would we not (excluding exceptional copyright issues) want to have 
lots of different name:XX tags?

--
Andrew


From: Frederik Ramm 
Sent: 25 March 2020 09:26
To: Tag discussion, strategy and related tools 
Subject: [Tagging] Which languages are admissible for name:xx tags?

Hi,

the "name:xx" tags are something of an exception in OSM because while we
defer to "local knowledge" as the highest-ranking source normally, this
is not being done for name:xx tags. It is possible for no single citizen
of the city of Karlsruhe to know its Russian name, but still a Russian
name could exist. Who is the highest-ranking source for that?

My guess is that about 5% of name:xx tags in OSM actually represent a
unique name in its own right; all others are either copies of the name
tag ("this city does not have its own name in language XX but I want
every city to have a name:xx tag so I'll just copy the name tag"), or
transliterations (or, worst case, even literal translations).

A while ago we had a longer discussion about Esperanto names; in that
discussion, it was questioned whether Esperanto could be in the name tag
but nobody disputed that adding name:eo tags is ok, even though
Esperanto is an invented (or "constructed") language.

Yesterday someone added a few dozen Klingon names to countries in OSM. I
have reverted that because of a copyright issue, but I think we also
need to discuss which languages we want to accept for name:xx tags.

In my opinion, a name:xx tag should only be added if you can demonstrate
that people natively speaking the living language xx are actually using
this name for this entity. I think we have a very unhealthy inflation of
names in OSM that are added by "single-purpose mappers" - they come in,
stick a name:my-favourite-language tag onto everything, and go away
again. Nobody knows if these names are even correct, and nobody cares
for their maintenance. The country North Macedonia changed its name
almost one year ago, yet roughly half of its ~ 170 name tags are still
what they were before this change. Nobody cares; these names suggest a
data richness that is not backed up by an actual living community that
cares for them.

What are your opinions on which languages should be accepted in name
tags? What do you think about

* niche constructed languages (say, FredLang which has 2 words I
invented just now)
* popular constructed languages (Klingon, Elvish) - note place names in
these languages will often be algorithmically derived from the English
or local name
* "serious" constructed languages (Esperanto)
* languages that once existed but are not natively spoken any more (Roman)
* languages that are natively spoken but their speakers do not have
their own name for the entity in question (instead they use the same
name the locals use, possibly transcribed into a different alphabet)
* ...

Or if you don't have the time to think about this in detail, just answer
the question: tlhIngan Hol - Hlja' or ghobe'?

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
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] Tagging of individual terraced houses?

[Andrew Hain]

Use building=house, you can deduce that they are terraced from the geometry.
--
Andrew


From: Oliver Simmons 
Sent: 07 September 2020 15:30
To: Tag discussion, strategy and related tools 
Subject: [Tagging] Tagging of individual terraced houses?

For terraced houses `building=terrace` is used for the whole block,
but there is no tag for each individual building when they are separate,
the reason for this is because the terraced building could be any of the 
`building=*` values, a shop, a house e.t.c, it could even be a weird small 
church; they are not always houses.

`terraced=yes/apartments` has 227 uses on 
taginfo, but no wiki page or 
discussion as far as I know.
Should I make a page for it?
Or should a proposal be made (I have no idea how these work)?

Please note `terrace=*` 
(taginfo) is for used something 
else (not sure what, but it doesn't matter anyways)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Proposal: Use description instead of name for route relations

[Andrew Hain]

I have started a new proposal: that the name tag should be restricted to the 
same meaning for route relations that it has on other elements and that the 
description tag should be used otherwise.


https://community.openstreetmap.org/t/proposal-use-description-instead-of-name-for-route-relations/104656/1
[https://community-cdn.openstreetmap.org/uploads/default/original/1X/1ec32427766f2efdc81c1fd1a6879e4084bfd00d.png]
Proposal: Use description instead of name for route 
relations
I have started a new proposal: that the name tag should be restricted to the 
same meaning for route relations that it has on other elements and that the 
description tag should be used otherwise. 
https://wiki.openstreetmap.org/wiki/Proposal:Use_description_instead_of_name_for_route_relations
community.openstreetmap.org


https://wiki.openstreetmap.org/wiki/Proposal:Use_description_instead_of_name_for_route_relations


--

Andrew

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

[Tagging] addr:town

[Andrew Hain]

The key addr:town is currently documented as de facto 
[https://wiki.openstreetmap.org/wiki/Item:Q1070][https://wiki.openstreetmap.org/wiki/Key:addr:town].
 However investigations in the UK have found it to generally be a mistake for 
addr:city or 
addr:suburb[https://wiki.openstreetmap.org/wiki/Addresses_in_the_United_Kingdom#Address_tags].
 Should it be deprecated?
addr:town
The town of the object that forms part of the address.
wiki.openstreetmap.org


--
Andrew
Addresses in the United Kingdom - OpenStreetMap 
Wiki
There are also several tags that have been used in the UK which shouldn't have 
been. These include addr:locality, addr:subdistrict and addr:site.See the tags 
to avoid section below. Please note that addr:district (Local Authority area), 
addr:county and addr:country have also been added to the tags to avoid section. 
This is because all three can be automatically determined using the admin ...
wiki.openstreetmap.org

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

Re: [Tagging] addr:town

[Andrew Hain]

Clearly mappers in Bosnia, South Korea, Australia and particularly the 
Philippines should be asked about this. I am also concerned that the current 
description (“The town of the object that forms part of the address”) 
encourages using the tag instead of addr:city.

--
Andrew


From: Martin Koppenhoefer 
Sent: 24 September 2022 16:07
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] addr:town



Am Sa., 24. Sept. 2022 um 13:38 Uhr schrieb Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>>:
The key addr:town is currently documented as de facto 
[https://wiki.openstreetmap.org/wiki/Item:Q1070][https://wiki.openstreetmap.org/wiki/Key:addr:town].
 However investigations in the UK have found it to generally be a mistake for 
addr:city or 
addr:suburb[https://wiki.openstreetmap.org/wiki/Addresses_in_the_United_Kingdom#Address_tags].
 Should it be deprecated?
addr:town<https://wiki.openstreetmap.org/wiki/Item:Q1070>
The town of the object that forms part of the address.
wiki.openstreetmap.org<http://wiki.openstreetmap.org>

In the areas I know this tag should not be used, but addresses can be very 
different globally. Looking at taginfo, this seems to be a regional thing (some 
mix ups with addr:city aside): 
https://taginfo.openstreetmap.org/keys/addr%3Atown#map

Still looking at taginfo, I see on 35% in combination with addr:city, or 41k 
items, it's these that may indicate there could be something behind it, 
intention rather than confusion ;-)
https://taginfo.openstreetmap.org/keys/addr%3Atown#combinations

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

Re: [Tagging] building=entrance

[Andrew Hain]

I also support that mass retagging of building=entrance nodes attached to 
buildings.

--
Andrew

From: Martin Koppenhoefer 
Sent: 13 December 2022 00:26
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] building=entrance



sent from a phone

> On 12 Dec 2022, at 22:13, Marc_marc  wrote:
>
> i dislike the idea to have tag with several meaning depending
> if it's on a node or a closed way


One could say the distinction is in the  meaning, not in the object type,

there is a tag that was used in the past on nodes of building outlines, 
building=entrance, it is deprecated for ages, since then tagged as entrance=*

and it is should be hardly confused with building=entrance, which is a regular 
use of the building tag to specify an entrance building.

I think the case is so well defined it would be possible to automatically retag 
those remaining 2400 building=entrance on nodes that are part of a building 
area outline to entrance=yes .

Or maybe a call to action and manually distinguish between main and yes values?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging