Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Tom Pfeifer

On 16.12.2020 14:19, Skyler Hawthorne wrote:

On Wed, Dec 16, 2020, at 05:44, Tom Pfeifer wrote:

What is written on the sign at this junction? If "North" is mentioned there I 
would be
happy enough with the tagging above.

That is correct, the sign says "I 787 North". However the wiki page for the 
destination:ref key states:

The key destination:ref 
<>=* should be
used to specify the reference of the roads directly ahead as indicated on 
signposts, road
markings or similar. The value of this key should be equal to the value of 
the key ref
<>=* of these roads.

Note the last sentence. If the destination:ref must be the same as the ref it is going to, then this 
would be I 787, or else all the ways along the entire I 787 route should have their ref tags changed 
to indicate direction as well.

Well, it says 'should', not 'must', thus in this case using destination:ref="I 787 North" is a 
refinement of just "I 787". Maybe an improvement for the phrase in the wiki would be

"should be equal to or a further qualification of related to the value...".

On 16.12.2020 15:41, Paul Johnson wrote:
> Wouldn't it make more sense, and isn't it already more common, for 
destination tags to contain the
> information on the destination signs, which /do/ differentiate direction?

Haven't analysed that, but if the destinations are signposted that way, it 
should be reflected in
the tagging.

> I feel like this is another example of "the wiki was written by someone with 
inadequate information."

Both tagging and wiki develop, hopefully forward. In this case, 
Key:destination:ref redirects
onto an old 2012 proposal, I'm probably going to resolve that soon with 
describing the current practice.


Tagging mailing list

Re: [Tagging] destination:ref with direction?

2020-12-16 Thread Tom Pfeifer

Trying to understand your question, the way in your example is tagged:

destination Troy
destination:ref I 787 North

From the data consumer perspective, such tagging will generate a navigation 
"turn slightly right towards Troy, I 787 North". This would be helpful as long 
as the driver
is able to recognise it on the local signposting.

What is written on the sign at this junction? If "North" is mentioned there I 
would be
happy enough with the tagging above.

I have seen the compass direction quite often signposted on major roads in the 
thus the question boils down if it is considered to be part of the 'ref'.
A general tag for the compass direction is 'direction', which is used 79% (shy 
of 1 mill
times) on highways.

So for the interstate itself, splitting it into ref=I 787 and direction=N would 
be preferable.


On 16.12.2020 04:40, Skyler Hawthorne wrote:
I've seen a few examples in both New York and California put in the tags of on-ramps the 
destination:ref that has the direction in it, e.g.:

However, after looking through the wiki, to my surprise, I cannot find this practice mentioned 
anywhere. It made sense to me when I saw it because how else is GPS navigation supposed to tell you 
which highway to get onto? But I don't see it mentioned anywhere, and in fact, the only thing the 
wiki page on Highway Directions in the United States mentions is putting the direction on the ways 
of the actual freeway.

Tagging mailing list

[Tagging] Feature Proposal - Voting - vaccination=* and vaccination=covid19

2020-12-08 Thread Tom Pfeifer

Following the 14 days of commenting, the voting is open, 08 - 22 Dec.

Comments received are discussed in the "Discussion results" section.

Please remember the voting is about the single key, not a full scheme.

Voting question:

Do you approve the introduction of the vaccination=* key, the value vaccination=covid19, and the 
principle to name the illness or group of illnesses in further values in a compact form.


Tagging mailing list

[Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-24 Thread Tom Pfeifer

Following the discussion on how to tag COVID-19 vaccination centres previously 
on this list,
I have created a proposal for the vaccination key:


Tagging mailing list

Re: [Tagging] COVID-19 vaccination centres

2020-11-18 Thread Tom Pfeifer

> The wiki mentions healthcare:speciality=vaccination
> although it is not used/

Well it's used 34x already:
While it was not in the original healthcare proposal it has been added on 
and appears in translations of the page. I'd support it.


A "vaccination" subkey makes sense to me; remains the old discussion of
"=yes" lists, or semicolon separated values, i.e.




As the healthcare:speciality key favours CSV, I'd recommend that for the subkey 
as well.

wiki: "If a medical practitioner or a medical facility covers several specializations, they could be 
separated by a semicolon", which was indeed part of the original proposal.


Tagging mailing list

[Tagging] COVID-19 vaccination centres

2020-11-18 Thread Tom Pfeifer
With the first Covid-19 vaccines getting approved, many municipalities are planning facilities for 
administering mass vaccination. In Berlin, the two former airports Tegel and Tempelhof are planned,

along with some sports facilities.

This raises the question for appropriate tagging.

The healthcare key seems suitable, it typically describes the activity in the 
The compact form 'covid19' is already used in various tags.

Thus, what about either

- healthcare = covid19_vaccination
- healthcare:covid19 = vaccination

Related tags & pages:
  related to the "staying open" mapping effort

health_service:prevention:vaccination=yes|no (455x, 80% no, no Wiki page)
which I see unsuitable as it does not use the healthcare key

healthcare:covid19, 7x (covid_test, hospital, 1 user, no wiki)


Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-14 Thread Tom Pfeifer

beaver_made = dam ?

On 14.11.2020 04:02, Kevin Kenny wrote:

On Thu, Nov 12, 2020 at 6:22 PM Adam Franco>> wrote:

  * origination:natural=beavers

Thanks for remembering this one. Around here, beavers are a significant sculpting force on the 

(And `man_made=dam` is the best tagging that we have for their water control structures, which are 
also often adjusted seasonally)

Tagging mailing list

Re: [Tagging] Deprecate water=pond?

2020-11-11 Thread Tom Pfeifer

On 10.11.2020 10:56, Andy Mabbett wrote:

On Tue, 10 Nov 2020 at 05:26, Joseph Eisenberg

I think the best option is to deprecate water=pond and suggest using water=lake 
natural lakes, even small ones, and use water=reservoir or water=basin (or
landuse=reservoir or =basin if you prefer) for the artificial ones.

I have a pond in my garden. I could, if I had a mind to and a decent
run up, jump over it. Not by any stretch of the imagination is it a
lake, reservoir or basin.

Joseph, the world is too diverse to press every object into a rigid category, and to find sharp 
definition boundaries. We need to let categories overlap.

Andy's garden pond is a good example. Everybody agrees that it's a pond, but when we have larger 
objects, the boundaries begin to blur, until we reach an object where everybody agrees that it is 
not a pond at all, it must be a lake.

Thus the objects will be mapped according to the subjective perception, but statistically objects 
like Andy's garden feature end on the pond side of the scale and the Werbellinsee on the lake side.

It's like trying to define a temperature value for 'hot' and 'cold':
For every human -10°C is cold and 45°C is hot, but at 20°C some go in a T-Shirt while others look 
for the woolen jumper.

Against deprecation of 'pond'.


Tagging mailing list

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

2020-11-09 Thread Tom Pfeifer

I appreciate amenity=place_of_mourning.


On 09.11.2020 10:15, wrote:
OK, so I haven't really done all the counting, but my impression is that amenity=place_of_mourning 
has quite some fans while most of the others are at least able to swallow it.

Unless anyone explains me that I got that wrong, I think I'll move the proposal 
there then.

Am 05.11.2020 09:43 schrieb

Thanks for all the interventions.

To avoid that the discussion becomes inconclusive again, could
everybody rate the following "favourable", "acceptable" or


Am 04.11.2020 11:17 schrieb

Dear all,

As there have been no more comments for some time on this proposal,
I've set it to voting. Please have a look and vote:

Chapel of rest: a room or building where families and friends can come
and view someone who has died before their funeral

Proposal page:

Discussion page:



Tagging mailing list

Tagging mailing list

[Tagging] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

2020-11-04 Thread Tom Pfeifer
I was surprised that this tag is rushed into voting despite the arguments against it even here in 
the tagging list discussions.

Let's summarize the criticism first, and look into the alternative "mourning 

* Vollis (the proposer) 18 Sep: ""chapel" will be opposed by some for being 
religiously connotated"

* Peter Elderson 21 Sep: "I have heard mourning chapel, mourning room, funeral 
chapel, funeral room.
Chapel of rest does not seem right to me"

* Janko 23 Sep: images of chapel of rest and mourning room are most 
concentrated and on the target

* Clifford Snow 24 Sep: "Chapel of Rest" sounds to me more like a marketing term not something we 
should be using in OSM.

* Michael Patrick 24 Sep: 'Chapel of Rest' seems to be a dated UK specific term. ... The euphemistic 
'Chapel of Rest' is more generically known as 'Viewing /Visitation Service',

* 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the goat 
to the butcher...
* 28 Sep: since OSM is an international project, my practice is to make it as easy as possible for 
non-native English users.

Indeed, the proposed value contains 'chapel' which is biased to christian religion. It might be used 
in British English, however that is biased itself for having Christianity as a cultural background.

"Chapel of rest" is an euphemism that avoids death-related terminology, but might be mistaken for a 
chapel where somebody could rest along a hiking or pilgrim route. This is a general problem with 
euphemisms that they intentionally don't hit the nail on the head.

OSM so far is successful in choosing tags agnostic of particular religions, such as 
amenity=funeral_hall recently and amenity=place_of_worship long ago. Thus for this feature I'd 
prefer a value that is applicable to any religion as well as secular ones.

Looking deeper in the example of Place of Worship vs. Church:

The British Ordnance Survey did chose "PoW - Place of Worship" in their maps, and OSM apparently 
inherited that term, although probably nobody says in colloquial English that they "go to the Place 
of Worship tonight", if they go to the church or the mosque or whatever holy place.

However both the OS and the OSM maps remain politically correct when using PoW as the technical 
term, preserving neutrality.

OSM is a map for the whole world, and it does not improve acceptance when a bunch of old white males 
(such as myself) chose a biased term for a feature that naturally exists in other cultural/religious 
contexts as well. Thus that part of the world would need a different tag, leading to tag fragmentation.

To close with an alternative, "mourning room" would be a neutral alternative 
from my perspective,
reflecting the process of mourning which I suppose exists in all cultures.

Please go and vote.

On 04.11.2020 11:17, wrote:

Dear all,

As there have been no more comments for some time on this proposal, I've set it to voting. Please 
have a look and vote:

Chapel of rest: a room or building where families and friends can come and view someone who has died 
before their funeral

Proposal page:

Discussion page:

Tagging mailing list

Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site

2020-10-31 Thread Tom Pfeifer

I agree that qualifying the capacity key as capacity:*=N for numbers is more 
than maxSOMETHING, which is still suitable for dimensions, such as maxspeed or 


On 31.10.2020 12:03, Sven Geggus wrote:

Martin Koppenhoefer  wrote:

On 31. Oct 2020, at 11:27, Sven Geggus  wrote:

Similar in spirit would be deprecating "maxtents" unsing "capacity:tents",
"capacity:caravans" and  "capacity:visitors" in future.

What do you think?

prefer this version

I just saw, that capacity:persons is already in wide use thus I propose the

* deprecate maxtents (currently used 1188 times)
* urge people to not use plain capacity anymore
* Instead the following tags should be used in future:
   - capacity:persons
   - capacity:tents
   - capacity:caravans



Tagging mailing list

Re: [Tagging] Tagging a government job centre

2020-10-10 Thread Tom Pfeifer

As Volker said, office=employment_agency is the established tag.

office=government is wrong, since the employees in the job centre do not govern.

The government might be the operator of the job centre, which can be expressed 
in the operator tag,
e.g. operator=Government of Example County


On 10.10.2020 09:21, Volker Schmidt wrote:
If you go to the (admittedly, very short) wiki page for office=employment_agency, you find that the 
picture illustrating the tag shows a German "jobcenter" of the Agentur fuer Arbeit, which is a 
government agency. 

So I think your starting assumption is not reflecting the actual tagging
This means also that your idea of creating a new "government" related tag would be in conflict with 
the established tagging, at least in Germany


 > On 10/10/2020 00:09, António Madeira via Tagging wrote:
 >> I was searching for a way of tagging a government job centre and I found
 >> there's no suitable way of doing this.
 >> There's office=employment_agency which doesn't seem to fit here, cause
 >> it seems to correspond to private companies who work with this kind of
 >> services.



Tagging mailing list

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

2020-09-04 Thread Tom Pfeifer

On 04.09.2020 18:19, Jmapb via Tagging wrote:

I'd suggest natural=rock_shelter as a replacement tag.

+1 for going into the natural key
My expectations to amenity=shelter would be something purpose-built,
which is true for all subtypes except that rock_shelter


Tagging mailing list

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

2020-08-03 Thread Tom Pfeifer

I agree that it would be helpful to distinguish more subtypes of 
However I find the proposed 'service=parking' misleading, as it suggests the 
way itself is
used for parking, not that it provides access to such facility.

I started a similar discussion four years ago, here is the thread start:

Possibilities discussed were:



On 03.08.2020 10:39, Martin Koppenhoefer wrote:

sent from a phone

On 3. Aug 2020, at 06:09, David Dean  wrote:

On the main parking road, I think we are largely in agreement that 
service=parking would be a good addition to OSM documentation (and is already 
in use throughout the world, as such).

if we need a specific service subtag for the access to parkings (which is 
already implicit through the fact that the road leads to a parking, and which 
leads to uncertainty which tag to choose if the road leads to parking and 
another use, like delivery for supermarkets), I would prefer are more verbose 
tag, as it is foreseeable that “parking“ will be confused with “parking_aisle”.

Cheers Martin
Tagging mailing list

Tagging mailing list

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-21 Thread Tom Pfeifer
On 21.05.2020 09:21, Daniel Westergren wrote:
> OSM is increasingly becoming more useful for forest trails than for car roads
> (for which other sources are usually more up-to-date, to be honest). 

Which "other sources" are more up-to-date for car roads? Where I map, new roads 
are documented in
OSM from early planning over construction, and mappers compete who is the first 
to "open" the road
the same second the minister cuts the ribbon.


Tagging mailing list

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

2020-05-11 Thread Tom Pfeifer
On 11.05.2020 03:10, Paul Allen wrote:
> I'm far from convinced that contact:website is useful.  It's certainly
> semantically wrong.  It's a contact;webpage not a contact:website
> (there are maybe a handful of exceptions to that).  Why do you think
> the user is more likely to require the webpage giving contact details
> rather than the home page of the web site?  I'd expect users are
> more likely to want more information on what a POI is than to
> want to find out how to contact it.
> I find the whole contact: namespace to be ill-conceived.  But fine, if
> you want it then use it.  Just please stop suggesting that we
> deprecate website=* and phone=*.

Indeed the main reason why my preference is not to use the contact:* scheme
is that its proponents did not limit the scheme to true means of contacting,
but tried to press everything into it that was not up in the trees when counting
to three.

The most prominent example is website, where only a page with a message form 
be clearly in this category. However what is more recommended to be mapped is 
basic homepage of a POI, because it is least likely to be changed in website 

The main purpose for me to read a website is to gain information about the 
and not to contact it.

In countries where an imprint is not mandatory, websites often do not even 
provide contact
details at all.

There are many more examples on the contact:* wiki page that are pure methods 
of dissemination
and not of contact, such as contact:youtube or even contact:flickr

How is contact:webcam supposed to fit into the scheme?

In contrast, postal addresses are a very typical means of contact, I can send a 
there. So consequently, we would have to to move the "addr:*" scheme into 
which would make the scheme even more stilted.

I guess that contact:[phone|fax|email], and nothing more, could have won easily 
if the
scheme had not tried to include all the other stuff.


Tagging mailing list

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-22 Thread Tom Pfeifer
On 20.04.2020 16:52, Paul Allen wrote:
> Amenity is much larger and much more of an eclectic hodge-podge than
> social_facility.  I'm not even sure that amenity=social_facility is a good
> idea, but at least you can then refine it with social_facility=*.  Moving
> do amenity=nursing_home just makes amenity a bigger mess than it
> already is.  And a nursing home is a social facility, not some sort of
> recreational POI for the general public.

amenity=social_facility with subkeys social_facility=* and social_facility:for=*
was voted in favour in 2010 with an unusual 96% on a quorum of 28.
The only vote against was just about dropping the amenity key above.
It turned out as a big help to keep values out of the top-level amenity=* space.
The proposal explicitly excluded facilities for the "treatment of specific 
acute medical
conditions", giving hospitals as example.

With about a dozen values that have significant usage I cannot see that there
were "too many different features lumped together", quite in contrast to 
amenity=* itself.

The problem comes with the the dynamics of amenity=nursing_home and 

If you look into the history graphs [1] you see that in 2011 there was 
apparently a massive import
of amenity=nursing_home;
which was partially removed in 2012, and partially converted
into social_facility=group_home and social_facility=assisted_living

social_facility=group_home was an over-ambitious attempt, coming from the 
examples of the
social_facility proposal, to tag a "Retirement Home" as amenity=social_facility 
social_facility=group_home + social_facility:for=senior, which blurred the 
of which homes provide nursing.

The new value social_facility=nursing_home provides clarity and is becoming 
organically popular
without mechanical changes.

It would be helpful if somebody could provide insight in the 2011 import and 
the 2012 mechanical
edit, and by which criteria the nursing_homes were separated into group_home 
vs. assisted_living.

It appears to me that in particular the imported objects nobody knows and 
nobody cares about.



Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

2020-03-30 Thread Tom Pfeifer
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote:
>> How will that help? What errors are you commonly finding?
> For example: . In this case
> Key:playground was used to tag playground equipment on the playground
> object itself. But for such cases we use Key:playground:* . This is one
> example of many.

Well the equipment in this case is playground=sandpit.
As the outline of the sandpit is identical with the outline of the 
leisure=playground, why would
this be wrong?


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

2020-03-30 Thread Tom Pfeifer
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote:
>> How will that help? What errors are you commonly finding?
> For example: . In this case
> Key:playground was used to tag playground equipment on the playground
> object itself. But for such cases we use Key:playground:* . This is one
> example of many.

Well the equipment in this case is playground=sandpit.
As the outline of the sandpit is identical with the outline of the 
leisure=playground, why would
this be wrong?


Tagging mailing list

Re: [Tagging] Updating definition and description of place=square

2020-03-28 Thread Tom Pfeifer

On 28.03.2020 12:45, ael wrote:

On Fri, Mar 27, 2020 at 10:58:00PM +0100, Martin Koppenhoefer wrote:

Piccadilly Circus (note the different word).
Is this a town square for British people? I notice the English WP seems to 
avoid the word square (although it then calls it a plaza), while both, Italian 
and German, have the word piazza / Platz in the subtitle.

As a native who once lived on the south margins of London, I have never
heard anyone refer to it as a square. I would certainly find such a
description bizarre.
"You are here: Home > Things to Do > Sightseeing > London Attraction > Public Square > Piccadilly 
"This legendary square was founded in 1819 and became an extremely important junction since its 
construction. The square is famous for its neon signs, different displays..."
"As for ‘Circus’, this word comes from the Latin word for ring or circle and was commonly used by 
Romans to refer to public areas like this. Though the ring over time morphed into a square, it’s 
original name remained."

Tagging mailing list

[Tagging] Please fix unnamed square tagging / was: ... description of place=square

2020-03-22 Thread Tom Pfeifer

Yes there is inconsistent use of place=square, in particular for _unnamed_ 
As the place=* key is used to indicate that a particular location is known by a 
particular name,
a place=* tag without a name is fundamentally wrong.

(As the world is not black and white, there might be exceptions.)

In Germany alone I found >600 such taggings, and all I probed were:

1. not squares as in the definition, but small and insignificant paved surfaces, like a round piece 
of footway in a park, the service yard of a fire station, or similar.

2. they were all added by the iD editor, typically since 2018.

Thus my assumption is that place=square is suggested in an iD preset to 
unsuitable features.
Could somebody with sufficient iD insight check what that preset suggests, and why it does not ask 
for names?

Further I recommend that everybody checks their area for place=square _without a name_, evaluate 
what it is and adjust the tagging. This can not (!) be done mechanically, besides the issues with 
mechanical edits, because the correct tagging will differ (e.g. highway=service + area=yes; or 
highway=footway + area=yes), or the tag was correct indeed and the name has been forgotten.

Query for unnamed square in a bounding box:

I also suggest to update wiki descriptions of place=* tags, upgrading the "name=*" from "useful 
combination" to "required", and add that to validators.


On 21.03.2020 01:32, Joseph Eisenberg wrote:

A few of us have been updating the Tag:place=square page, and Square:

Unfortunately, this tag has been used rather inconsistently around the
world, often for any feature that includes the word "square" or a
translation of that word, or which might be considered similar in the
local language.

Some poorly mapped examples are shown on github:


Check if any of the place=square features in your area should instead
be junction=yes (for a named street intersection or road junction) or
leisure=park or place=neighborhood.

Tagging mailing list

Re: [Tagging] Updating definition and description of place=square

2020-03-22 Thread Tom Pfeifer via Tagging
I fully agree with Martin here. The place=* key is used in OSM to indicate that a particular 
location is known by a particular name, and that is independent of details of the usage.

It might be that Joseph's perspective is driven by his intense work on the 
Carto style,
where it has to be decided if a name is being rendered in the place-style or in 
the park-style.

However OSM is more than rendering, it is about analysing the data. And when I 
ask e.g. Nominatim
or Overpass where all the Squares in my town are, I wish them to be included by the place=square tag 
and not lose some where the place tag has been omitted just because they are filled with a park.


On 21. Mar 2020, at 01:34, Joseph Eisenberg  wrote:

Check if any of the place=square features in your area should instead
be junction=yes (for a named street intersection or road junction) or
leisure=park or place=neighborhood.

On 22.03.2020 12:24, Martin Koppenhoefer wrote:

I don’t agree that an open space inside a settlement that is mainly used as a 
traffic junction, cannot be a place=square at the same time.
Squares are generally deliberately left / created open / spaces in contrast to 
space occupied by buildings (they are voids cut out from building areas, places 
where the road enlargens, typically at crossings or placed as rhythmic 
sequences within a street).
They come in all scales, as big central places with significance for the whole 
city (or even nation) or as small squares  at crossings in a residential area. 
They might be frequent or rare, depending on the cultural context, and their 
characteristics will depend generally on context.
There is no need to impose arbitrary size limits or usage requirements (both, 
on the square and at its borders), nor to make the question of leisure=park 
junction=yes exclusive to place=square. They can perfectly coexist.

IMHO place=square is a tag for a toponym that refers to a void inside a built 
environment, and size and usage is implicit from geometry and other objects.

Tagging mailing list

Re: [Tagging] Ponds are not observable on the ground

2020-03-19 Thread Tom Pfeifer
This discussion originally started in this changeset, which quite obviously was _not_ driven by a 
ground survey:

Some even larger in Sweden:

The latter give source="Lantmäteriet Topographic Map" which appears to be CC0 
according to the wiki,
ok, however probably not the best source for large-scale mechanical edits.

Haven't found the edits on the Balkan yet that you mentioned in the CS 

Regarding the question lake vs. pond, please remember the world is not black 
and white.

As with many features in OSM that could be A or B, there are always clear cases where everybody 
agrees that one object is A and the other clearly B, but there are cases where it depends on the 
judgment of the mapper.

The water in my neighbour's garden is a pond. The thing in the middle of a village is a pond. Quite 
The excavation from the most recent ice age, where I can swim, is a lake. Now go and find things in 

On 19.03.2020 14:15, pangoSE wrote:
> IMO pond should not be mapped because it is not observable on the ground. How do you determine if 
it is

> "artificially created"/"man made"?

On 19.03.2020 14:42, Paul Allen wrote:

Oh, you're talking about water=pond after all.  Nothing about
water=pond says man_made or natural, it just says that there is
a pond of water.


Tagging mailing list

Re: [Tagging] a kind of name:XX-modern-not-used

2020-01-24 Thread Tom Pfeifer
I am against transforming OSM into an etymological dictionary. While etymological research is of 
course valuable, such results are not easily verifiable for other users, and overload the tagging of 
objects that have plenty of tags in current languages already.

There are systems like suitable for these details, which can be sufficiently linked 
with wikidata references. Thus there is no reason to duplicate that in OSM.


On 24.01.2020 06:43, Phake Nick wrote:
You can consider using BCP 47 extension T as language tag in OpenStreetMap follow BCP 47 practice. 
The extension T is for denoting content that have been transformed from one language into another, 
so if you write fr-t-frm then it would denote the content is transformed fron Middle French 
(15th-17th century) to Modern French (with frm being the ISO 639 code for Middle French, and thus 
you can write name:fr-t-frm=X into the object. You can read the BCP47 original document for more 

 05:51,marc marc 


some words in the name of some street is not understood by some people.
these are often old notations, sometimes borrowed from another language
but used in the official language to name this street.
street sign have those "one-name-but-in-mixed-language" and only that.

a contributor spends time trying to find the meaning of these words and
replaces the name with a modern version, absent both from the ground and
from use, in favour of a name that is the one that could have been
written if this street had been created today.
it's a bit as if this contributor added to Big Ben name:fr="Grand Ben"
or "Nouveau York" for "New York"
it's obviously wrong. but how could we keep track of the meanings
of the words from the old days?
I thinking about a kind of tag name:fr-modern-not-used or a kind of
name:etymology but which does not inform a person but an object, a
building, a profession, ...

Tagging mailing list

Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

2020-01-19 Thread Tom Pfeifer

On 19.01.2020 06:10, Joseph Eisenberg wrote:

2) =fire_water_pond " A man made or natural pond with water for a fire
department." 2785 uses

Why is that not verifiable? Such ponds typically have a red-framed sign
Ground-verifiable, not necessarily Bing-verifiable.

I see how that's verifiable in Germany, but isn't it actually an
emergency=suction_point in that case? The sign is the place where you
suction water into the fire engine, right?

In other countries we are not so picky about what water sources we use
for fighting fires. ;-)

Indeed the Germans are picky about these things ;-) But suction_point and the pond are two different 
things. The first could also be some pre-installed pipe in a stream, the pond is a dedicated feature 
often prescribed in the planning permission when you erect something, and might need to be 
maintained so it is filled. The first is a point, the second is a water body.

there should be a template
separate from the Map features template that can be included in each of
them. Do you know how to
handle translation of the subheadings in such case?

Since the page is just several taglists, I'm not sure if it's still
necessary to have a separate template. Probably it's easier to just
copy and past the taglists, then add the language and translate the

I will try this out for the Indonesian page and see if it works easily.

either method is ok, a new template would have the advantage that it keeps the 
translations consistent.


Tagging mailing list

Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

2020-01-18 Thread Tom Pfeifer

On 18.01.2020 14:18, Joseph Eisenberg wrote:

Should we remove some of the rare values of "emergency=" which have
got into Map Features?

In general it might make sense to have the complete list on the key page of emergency, and a 
selection on map features.

Like some other key pages, the Key:emergency page is a big list of
features generated from a template, and the same template goes
straight to the main list of Map Features.

This is probably why the Map Features page section for "Emergency" has
24 values, even though half of them are rarely used and very few were
every approved.

Be careful not to look into lower absolute numbers for features that exist in reality only in low 

Discussing some of your reasonings below:

) =mountain_rescue - "A mountain rescue base for a team providing
search and rescue services in mountainous environments" - 185 uses
- Remove: rare tag, only relevant in some regions.

Quite important in those regions!

2) =fire_water_pond " A man made or natural pond with water for a fire
department." 2785 uses
- Remove: This tag isn't verifiable, or else it could be added to any
pond or small lake. It's not much used outside of Germany.

Why is that not verifiable? Such ponds typically have a red-framed sign 
Ground-verifiable, not necessarily Bing-verifiable.

3) =access_point "A sign number which can be used to define your
current position in case of an emergency" -  uses
- Remove: the similar tag 'highway=access_point" is much more common
and was approved.

This is a good approach to improve tagging of emergency features by aggregating them under the 
emergency key, in particular those that are not highway features.

) =landing_site "Preselected flat area for a helicopter to land in an
emergency" 2543 uses
- Uncertain: the tag aeroway=helipad is more common, and the
distinction  is unclear

The distinction is that aeroway=helipad is a purpose-built infrastructure,
while emergency=landing_site is a predefined spot that is only used if there is 
an emergency nearby.
This could be a meadow, and there might be an agreement with the farmer to cut 
the grass regularly.

(I think it will help to use a separate list at Key:emergency, which
can be longer than the "official" list of Map Features.)

Yes. I noted that the language-translations of the Key:emergency page are quite 
some having their own list, some used the Map features list. Probably there should be a template 
separate from the Map features template that can be included in each of them. Do you know how to 
handle translation of the subheadings in such case?


Tagging mailing list

Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Tom Pfeifer

On 06.01.2020 21:32, Tomek wrote:
Exactly, does a buoy with the inscription "Baltic Sea" swim at 56° N18° E? No, there is simply water 
that Poles call the "Morze Bałtyckie", Germans "Ostsee", etc.

Hey, if that solves the conflict, let's check OSMF's budget, charter the OSMbow-Warrior and plant 
such a buoy! Funds can probably be claimed back from Wikimedia as a community building project.

> Please support (vote) my proposal or write a reason why not.

For the count, +1 against.


Tagging mailing list

Re: [Tagging] amenity=tourist_bus_parking

2020-01-04 Thread Tom Pfeifer
I agree, I had the problem on motorway service areas, where parking is segregated between HGVs and 
cars. I solved it with access tags for the respective vehicle class.

On 04.01.2020 22:10, Volker Schmidt wrote:

I have just detected the wiki page "amenity=tourist_bus_parking"
It has so far only 16 uses (including one by myself a few minutes ago)
I am not happy with this new tag. Agreed, we have the tags amenity=bicycle_parking and 
amenity=motorcycle_parking, but they have been with OSM for years, whereas the tourist_bus parking 
is new (from Feb 2019) and has so far very few uses.

My feeling is that we should not add more humanities along that line, like RV_parking, hgv_parking, 
snowmobile_parking, cargo_bike_parking and so on, but try to think,of something better.
In particular I would like some tagging scheme that allows you to identify a parking facility, and 
within that same facility (which carries the name) the parking sub-facilities for cars,  buses, 
HGVs, motorcycles, ...That would make more sense.The parking I have just inserted has two separate 
areas and separate entrances for cars and tourist buses, but it has only one name. Another frequent 
situation are motorway stations where parking is usually split into cars, busses, and HGVs.
Hopefully it's just my ignorance and someone else has already implemented the prefect tagging scheme 


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Tax free shopping

2020-01-04 Thread Tom Pfeifer

On 04.01.2020 19:47, Hauke Stieler wrote:

* no:
All customers of a shop with duty_free=no have to pay normal taxes.

I don't think it can be phrased that way. As for the VAT in the EU,
everybody who proves that the goods were exported is eligible for a tax refund.

However, since this requires to provide evidence and send complicated forms
to the revenue office of the country of the purchase, this process is taken over
by a company that has booths in major airports. Thus participating shops
prepare a special receipt, and the airport office refunds the tax while 
a fee for themselves, and finally claims it from revenue.

IIRC a similar scheme exists for US sales taxes.


Tagging mailing list

Re: [Tagging] Public WLAN boxes

2019-12-18 Thread Tom Pfeifer

On 18.12.2019 16:26, Andy Townsend wrote:

On 18/12/2019 15:22, Tod Fitch wrote:
In the U.S. it would be called wifi or wi-fi rather than wlan. Anyone know what the British 
English is?
In the UK it's also "wifi" or "wi-fi", but wlan is understood and has considerable establishment in 

Wi-Fi vs WLAN is not AmE vs BrE,
WLAN is the technical term, standing for Wireless Local Area Network.
It is standardised in the IEEE 802.11 series, using "Wireless LAN" in the title.
Wi-Fi is a brand name, introduced by the Wi-Fi Alliance.

OSM should therefore continue to focus on the standardised, generic term WLAN.

On 18.12.2019 11:20, Cascafico Giovanni wrote:
> My tagging would be:
> man_made=antenna

The 'box' would contain a full access point and not just the antenna, thus I'd prefer not to tag the 
antenna alone.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Leisure=Skatepark

2019-12-10 Thread Tom Pfeifer

On 09.12.2019 19:09, Paul Allen wrote:

On Mon, 9 Dec 2019 at 17:31, Tom Pfeifer>> wrote:

I'd prefer to keep it leisure=pitch, avoiding top-level tag fragmentation. 
Refinements about the
sport definition can appear in the sport=* subtagging.

I can understand that viewpoint.  I'm not sure that there is any technical 
merit, in terms of db
queries, to it, other than making life easier for somebody who wants to find 
all types of sporting
activity in a given area.  Where it does cause problems is for people using the 
query tool (or
equivalent in things like <>) being confused by tennis pitches, shooting 
pitches, and

the like.  It's far from the only tagging infelicity we have, and we'll never 
be able to fix it because
of existing usage, but I see no reason to extend the confusion.

I'd say that your query tool has to be improved. Tagging in OSM is done in 
key/value pairs,
and using elements from natural language for them is just to slightly improve 
human readability.
Sure there are some deviations from the dictionary use of a term when used in 
OSM, but tools like
presets in editors can cope with it.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Leisure=Skatepark

2019-12-09 Thread Tom Pfeifer

On 09.12.2019 03:13, Scott via Tagging wrote:

Description: An area designated and equipped for skateboarding, in-line 
skating, BMX'ing, or scootering.

Proposal for fixing improper definition of sport=skateboarding, creating skatepark as a result, and 
other relevant access and equipment tags.

I'd prefer to keep it leisure=pitch, avoiding top-level tag fragmentation. Refinements about the 
sport definition can appear in the sport=* subtagging.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - park_drive

2019-12-08 Thread Tom Pfeifer

On 08.12.2019 00:49, Martin Scholtes wrote:

Am 07.12.2019 um 18:59 schrieb brad:

We already have park_ride tag.   I don't see the new tag adding anything?

"park and ride" rather describes the change to public transport and not
the continuation of driving with others in a private vehicle.

However it is the same concept to reduce the number of individual cars in the 

Literally it means that you park your own and ride another vehicle,
whether that is a public transport train, a pooled car, an otherwise shared car,
a rental/shared bike, a scooter -- it is all the same concept.

There will be more coming in near future.

Thus it would be helpful and prevent tag fragmentation to group them all
under the established "park and ride" concept
and specify the respective riding facility in subtag.


Tagging mailing list

Re: [Tagging] Supermarket pick-up service

2019-11-08 Thread Tom Pfeifer

On 08.11.2019 13:40, Philip Barnes wrote:
> Its not a shop, you don't buy anything there.

In my local case, the payment is done at collection time with any method the 
main marked uses,
i.e. cash and card. Thus I'd call it a shop

> Maybe supermarket=customer_collect or customer_pickup. Collect fits my British English ears 
better than pickup, that means something a bit different.

Indeed having 'collect' in the value sounds better than pick-up.

> They are covered, so the customer can drive in, so maybe borrow the drive_through tag from fast 
food outlets.

> Not all are attached to the supermarket, others are a separate building in 
the car park.

That layout sounds more like a loading point?

On 08.11.2019 16:02, Mateusz Konieczny wrote:

I encountered shop=outpost used for that

May be poor name - AFAIK it never went through a proposal process and appeared 
in non-english
countries first, but is fairly popular.

I find "outpost" completely misleading (usage <500). An outpost is a small military position at some 
distance from the main army, a remote part of a country, or an isolated branch of something (Oxford 
dict). It has nothing to do with the collection of pre-ordered goods.


Tagging mailing list

[Tagging] Supermarket pick-up service

2019-11-08 Thread Tom Pfeifer
A supermarket chain offers to order groceries online, being collected and packed, and picked up by 
the customers themselves in a small shop in the local supermarket building. Illustration [1].

How should the shop be tagged? shop=pick-up ?



Tagging mailing list

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

2019-10-28 Thread Tom Pfeifer

type=destination_sign + amenity=hospital"

I had a look at the original proposal, and it does not contain the word 
Thus I conclude it had been later fiddled into the wiki page.

Anyway looking into the voting results the whole proposal looks fiddled,
the proposer counts some of the No votes as approvals :-o


Tagging mailing list

[Tagging] 360 degrees / Re: Deprecating mini_roundabout

2019-10-23 Thread Tom Pfeifer

On 23.10.2019 15:08, Philip Barnes wrote:
You can enter a normal roundabout, do 360 degrees and then be traveling in the opposite direction. 

And you recognise a fellow OSM mapper by seeing her/him doing 360 degrees plus the angle for the 
intended exit, to create the full circle in her/his GNSS trace.


Tagging mailing list

Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Tom Pfeifer

On 23.10.2019 12:05, Florian Lohoff wrote:

On Wed, Oct 23, 2019 at 12:00:13PM +0200, Tom Pfeifer wrote:

..., it can give instructions like at a normal junction, just using
the tag to describe the junction:
"At the mini-roundabout [turn right|go straight|turn left]".

You would expect (as you see a roundabout sign) to get instructions to
take the exit.

Eh, no ;-) As I said above, _I_ would expect "At the mini-roundabout turn X",
and be very happy with such instruction.
That fits seeing the roundabout sign, and my experience driving over it.

Basically the mini-roundabout is effectively more about who has priority,

A mini_roundabout has the same rules as normal roundabout from what i
look at the definition. The only difference is that its physically

Yes, and the size. Having the roundabout rule on a mini_roundabout,
the driving _experience_ is that you have to give way to
anything already on the junction.

> So i'd suggest to deprecate it and replace it with a highway=* +
> junction=roundabout and if its a "mini roundebout" physically
> you can driver over it (Thats IMHO the only difference) you add
> an area=yes to the circular road.

This would make routing more complicated and not simpler.
Now you would have to route over the area.


Tagging mailing list

Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Tom Pfeifer

On 23.10.2019 11:35, Florian Lohoff wrote:

These are a very common feature, it does seem odd that routers are not 
supporting them.

The point is that a mini roundabout does need a LOT of preprocessing to
put it into some graph for your classical A* or Dijkstra. You need to
eliminate the node and replace it with a circular road much like a

Could you explain what the preprocessing is needed for, and why you need to replace it in the 
routing algorithm.

From my perspective nothing is needed. The routing engine recognises from which way you come and 
where to leave, and, since the feature is so small and clear, it can give instructions like at a 
normal junction, just using the tag to describe the junction:

"At the mini-roundabout [turn right|go straight|turn left]".

Basically the mini-roundabout is effectively more about who has priority, and here all incoming 
roads have to 'give way'. Similar a four-side "stop" sign in the US. I have used them in Britain and 
they are often just a bucket of white paint poured in the middle of a junction.


Tagging mailing list

Re: [Tagging] Tagging meadow orchards

2019-10-04 Thread Tom Pfeifer

On 04.10.2019 19:10, Markus wrote:
While orchard=meadow_orchard is the most used way of tagging a meadow orchard (2 748 uses), there 
are also 668 uses of the other subtag meadow=meadow_orchard. That means that people don't agree that 
the orchard is more important than the meadow.

Apparently there is a semantic difference. When someone counts 3 apple trees on a hectare, it is 
more a meadow. If there are 35 varieties of old sorts in the backyard, it is more an orchard, and 
the farmer needs the small mower to cut the grass.

Thus the subtagging allows to preserve the subtle differences, while a new catch-all high-level tag 
doesn't. Subtle, from Latin subtilis ‘fine, delicate.’ ;-)

Compared to landuse=meadow_orchard (48 uses), the two subtags certainly only have such a high usage 
because they render, while landuse=meadow_orchard doesn't.

They render for a reason, because they represent major types of landuse.


Tagging mailing list

Re: [Tagging] Tagging meadow orchards

2019-10-04 Thread Tom Pfeifer

On 03.10.2019 21:12, Markus wrote:

How shall we remain now? Can we agree on on a single way of tagging in
order that this discussion doesn't come up again in a year or two?

I still think that landuse=meadow_orchard (as well as
landuse=silvopasture for forest and pasture) is the best option. The
other used or proposed tags demand from mappers that they define which
land use is more important than the other. However, such a choice is

I reviewed the thread and found the most convincing argument that the subtagging solution is already 
the preferred tagging in 2787 cases (according to overpass, most of them in Germany). It helps to 
prevent tag fragmentation and will not lead to crying how to render it. I also think it is the best 
option semantically.

This contrasts 48 cases of landuse=meadow_orchard, only in DE and CH.


Tagging mailing list

Re: [Tagging] Default values for surface by road category and country

2019-09-21 Thread Tom Pfeifer

On 21.09.2019 17:09, Richard Fairhurst wrote:

voschix wrote:

I am trying to figure out where the surface default values by road
category and country are defined.

I don't believe there's a place where it's stated, but I work on these

- in developed countries, all "higher" highway types can be assumed paved
- in developing countries, anything from secondary down (or even primary)
may be unpaved
- in rural areas of the US, it's not safe to assume highway=residential is
paved if tiger:reviewed=no

In the outskirts of Berlin, I have unpaved highway=residential in good 
that are muddy when wet and dusty when dry. Thus Germany qualifies as 
developing country?

Now that residents are relieved from paying the state parts of the building cost of their roads from 
this year on, the situation might improve eventually...


Tagging mailing list

Re: [Tagging] Tagging ideas for a non-profit ”course center”

2019-09-21 Thread Tom Pfeifer

On 21.09.2019 10:46, Jyri-Petteri Paloposki wrote:


At least in Finland we have course centers maintained by non-profit organisations, for example 
religious and scout organisations. These usually have accommodation space to some extent, kitchen 
facilities and usually also some yard space for tents and other outdoor accommodation for having 
larger outdoor events. They're located in the countryside away from the city center and for example 

– amenity=community_centre. Not suitable because they are only used for private or limited events, 
ie. are not used for regular support groups or other community activities.

I'd see that very suitable. You can define the subtype by tagging community_centre=*, and I would 
not see a requirement that the facility needs to be open to everybody, it can be for a specific user 
group, which can be tagged with community_centre:for=* .


Tagging mailing list

Re: [Tagging] building typology vs usage

2019-09-08 Thread Tom Pfeifer

On 07.09.2019 11:00, Frederik Ramm wrote:

It is true that this is the canonical way of dealing with things,
however it would be interesting to check how mappers and editing tools
actually use this. We might well find that everyone is confused about this.
I think we cannot simply throw the distinction over board and therefore

I do not agree with Josh, but I also think the distinction is not really
well thought out/well implemented in OSM and needs clarification.

In cases for usage apparently contradicting the building type it often helps the fellow mapper to 
tag a note that this school building was converted into a hostel, or this church building is used 
for climbing now.


Tagging mailing list

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

2019-09-07 Thread Tom Pfeifer

On 07.09.2019 07:57, Hufkratzer wrote:
Recently you [jesienbe] added to the wiki page for sports_centre that sports halls inside of sports centres 
don't need a leisure tag if the centre is mapped as an area. 

And this is wrong, as it fails the purpose of the leisure=sports_hall tag.

As I remember the tag development, any value like 'gym/gymnasium' was deliberately avoided because 
it has too many different local meanings, ranging from fitness over weightlifting over climbing gym 
over school sport up to the German word for a secondary school itself. [1]

Therefore the slightly more stilted leisure=sports_centre came into use for any facility where 
sports are performed and was widely accepted (183k).

This however led to the situation that
a) a simple school facility with a wooden floor and a changing room is not 
really a 'centre',
b) sport campuses with several buildings for different sports became tagged with 
leisure=sports_centre, and the buildings leisure=sports_centre again, inside of the campus.

The solution was found in 2018 with activating a tag with small usage that time, 
leisure=sports_hall, which solves both cases,

a) having a tag for a small individual facility,
b) having a tag for each of several facilities like the rowing hall, the climbing hall, the ice 
skating hall, you might have on a campus that is a centre for having a multitude of such facilities, 
accompanied by the sports pub.

This tag is growing rapidly since.

Any buildling=* tagging describes the original building typology and is orthogonal to the usage, see 
my other mail.

Please recognise that the world is not black and white, and there is a continuous spectrum of sport 
facility sizes. So while there are examples that are clearly 'just a sports hall' or a 'large 
centre', there will be edge cases, where the hall gets a reception that sells you a coffee, and then 
a little weight-lifting corner, and so on, so an individual decision would have to been made to 
decide to mark that as a hall or a centre.



Tagging mailing list

[Tagging] building typology vs usage / Re: Adding leisure=sports_hall to leisure=sports_centre page

2019-09-07 Thread Tom Pfeifer

On 07.09.2019 09:16, Joseph Eisenberg wrote:

To me it seems redundant to tag leisure=sports_hall on buildings
inside of a leisure=sports_center, like tagging
"healthcare=hospital_ward" on each building inside of a large medical
center which is already mapped as amenity=hospital. The standard
tagging that is building=hospital, like building=school inside of an
amenity=school area.

While in theory building=school could be reused as a hotel/pub (See in that case the building
will be inside of a tourism=hotel polygon so it's clear that it's no
longer a school.

Please understand that the building typology is orthogonal to the usage of the 
Thus having both a building=X and leisure/amenity=X on the same polygon is not 

If the usage changes to Y, and the building structure remains as X, it will be tagged building=X and 

This approach works in both cases, the tagging on the identical polygon, or the tagging being on the 
surrounding campus polygon and the building inside.


Tagging mailing list

Re: [Tagging] Adding leisure=sports_hall to leisure=sports_centre page

2019-09-05 Thread Tom Pfeifer

On 05.09.2019 15:48, Joseph Eisenberg wrote:

Another user would like the proposed tag (used 329 times)

346 if you count all tags. Look at taghistory and see it has grown from 22 in early 2018, thus about 
15 times.

It was a result of discussion in some communities that time.

leisure=sports_hall to be added to leisure=sports_centre.

No. You cannot add the value to the same key.

The intention of leisure=sports_hall is to describe facilities better that were incorrectly tagged 
leisure=sports_centre, an example are simple school sport halls, which certainly are not 'centres'.

However, I believe that rarely used, proposed tags should be approved
through the proposal process or should become commonly used
organically, before being added to the pages of common tags and keys.

If you look at the history, it is being growing organically.
A hint to consider a more suitable tag on the centre page tagging cannot hurt.

So, this can be a synonym for a sports_centre, or a tag for a building
found in a sports_centre?

More precisely, leisure=sports_hall is for facilities that are not centres.
Surely a centre can hold, among other facilities to form a centre, one or more 

Why not just use building=sports_hall and sports_centre for the whole area?

Because building=* describes the building typology, not the usage. leisure=* 
describes the usage.
Thus, a purpose-built sports hall is leisure=sports_hall+building=sports_hall, while a converted 
church that is now used for sports is leisure=sports_hall+building=church.


Tagging mailing list

Re: [Tagging] bear box in campground ?

2019-08-21 Thread Tom Pfeifer

On 21.08.2019 19:44, Rob Savoye wrote:

   Many western state campgrounds have metal bear proof food storage
boxes in each campsite, but not all of them. At certain times of the
year this can be important. :-) Around here the bears will destroy your
car if there is food left inside. I see zero instances of this type of
data, at least not in Colorado. My guess would 'amenity='bear_box' ?
(looking at amenity=bbq as an example)

The question remains if tagging the boxes would give bears an advantage as they could exploit the 
knowledge and focus on sites without such boxes?


Tagging mailing list

Re: [Tagging] leisure=garden for private front/back gardens

2019-07-13 Thread Tom Pfeifer

On 13.07.2019 09:35, Volker Schmidt wrote:
I have tagged many planted centre pieces of roundabouts as leisure=garden, access=private in lack of 
better alternatives.

Why 'private' if it is a public roundabout?
If it not allowed to trample the flowers down, wouldn't access=no be more 


Tagging mailing list

Re: [Tagging] Maxtents= or capacity:tents= for campsites?

2019-07-03 Thread Tom Pfeifer

"capacity" is the well established for the number of items the facility can 
from students in school, parking spaces to hotel rooms.

"maxtents" is hard to understand, ambiguous and likely leading to confusion.
It could refer to the size as well (maxi tents?) which might explain the poorly tagged 
"maxtents=yes". Did you check if that came from a weird import?


On 03.07.2019 02:05, Joseph Eisenberg wrote:

Some users specify the number of tents or caravans allowed at a
campsite or camp pitch with tents= and caravans=, but
more frequently these are specified with capacity:caravans=,
capacity:tents= or maxtents=

Currently maxtents=* is used most frequently and it's the shortest
key, but there is no equivalent tag for carvans other than
capacity:caravans=* - and also, the majority of maxtents= tags are
"maxtents=yes" - and I don't understand what this could mean.

So I'm thinking that capacity:tents=# and capacity:caravans=# would be
the least ambiguous option, along with tents=yes/no and

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - juggling spot

2019-05-22 Thread Tom Pfeifer

On 22.05.2019 00:09, marc marc wrote:

I you think that juggling is a sport, sport tag exist,
just add sport=juggling

but we miss a main tag for sport that does not take place on a delimited
sports field, the same issue exist with outdoor sport=scuba_diving

maybe leisure=location or leisure=sport[s]_location ?

Tagging mailing list

Re: [Tagging] Apps of delivery

2019-05-15 Thread Tom Pfeifer

On 15.05.2019 17:07, Martin Koppenhoefer wrote:

On 15. May 2019, at 11:32, Philip Barnes  wrote:

We have deliveroo operating locally, however I have never seen verifiable 
evidence on the restaurants that they offer that service.

Therefore I would not consider this a suitable thing to tag in OSM.

would you consider the thing validated if you ordered through them and the 
order arrived?

That means, validation comes at the cost of an order?

I am against mapping business policies in OSM, which include

- detailed stock listings in the style nuts:stainless:metric:m5 = yes
- delivery services with which a restaurant or furniture shop cooperates.


Tagging mailing list

Re: [Tagging] I have been tagging mosques wrong all along

2019-03-23 Thread Tom Pfeifer

On 23.03.2019 18:19, Paul Allen wrote:

On Sat, 23 Mar 2019 at 17:05, Jean-Marc Liotier>> wrote:

The case I have in mind is where the mosque is a complex of several
buildings - such as the building for ritual ablutions, a separate prayer
building for women, the outside prayer ground for days of large
gatherings, the toilets etc.

Until you mentioned outside prayer, the obvious solution to a building complex 
be a multipolygon.

No, there is no MP needed. As there are several distinct objects used for worshiping, it would even 
be wrong.
Thus you can tag the campus complex with landuse=religious, and the individual worshiping places 
with amenity=place_of_worship. You could even add description=* to explain their individual purpose, 
and building=* if it is a building.


Tagging mailing list

Re: [Tagging] I have been tagging mosques wrong all along

2019-03-23 Thread Tom Pfeifer

On 23.03.2019 15:12, Jean-Marc Liotier wrote:
I have learned from Muslims and confirmed in literature that this tagging scheme is wrong: what I 
considered as the mosque itself is merely the main prayer hall. The mosque is actually the whole 
complex that I used to tag as landuse=religious.

So, if the actual praying happens in the building, this is the place where the 
worshiping happens,
hence the place of worship, hence amenity=place_of_worship

Thus I see no need for different tagging.

The wikipedia article has some insight in the process, however it also mentions that a mosque can be 
a building. So, if the mosque is a building, tagging building=mosque would be fine.

Even for the situation that the worshiping happens without a building, the general campus can be 
tagged landuse=religious, the more specific location of the worshiping amenity=place_of_worship, but 
without a building tag.


Tagging mailing list

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

2019-03-13 Thread Tom Pfeifer

On 13.03.2019 10:50, Cascafico Giovanni wrote:

The lattest is great and leads to grotesque consequences: when a colleague hands me 12 guidepost 
locations to geocode, I must message planet import ML, local ML, write an import page and ask my 
fellow a consent form with certified signature. Is this what we aim?
I think setting such a binding requirements on small size "imports" is putting a gravestone on many 
potential small, local sources.

I think you misunderstand. OSM is based on locally sourced, handcrafted data. That creates the high 

Import means data are copied from another database into OSM. That means, somebody else collected the 
data. This collector has made his own mistakes. All databases contain errors, or outdated items, 
even if they are labelled official, governmental etc.

IIRC the dataset you are using is several years old, last updated 2017. The items in your Umap do 
not say when the database entry was last checked.

Thus when copying these data into OSM, they appear as freshly updated, March 2019, although the 
information is much older and the hotel might have closed or changed ownership/pet policies/wifi in 
2018. In particular in a "stealth" import, one node at a time, I would assume the OSM data to be 
individually checked and current.

Thus your task is to discuss with the Italian community if your import, i.e. copying the other data, 
improves or decreases the OSM data quality. The changeset size is less important, though I would 
prefer an community-approved import to be traceable in not too many changesets.

Your colleagues data of 12 guideposts are fine if they are freshly collected 
from the ground.

Hope that helps to understand why we are careful with imports.


Tagging mailing list

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

2019-03-09 Thread Tom Pfeifer


I have severe problems with your process. First, yes it is an import. You called it an import 
yourself ("manually importing") here, and on the Italien list where you first asked about the 
tagging [2]. Where did you see a "100 nodes" limit documented? You are copying from one database 
into another, and if you do just one node a day, it is a slow import.

Imports require the Import Guidelines to be followed [4]. I cannot see any discussion with the 
community. I cannot see any check of license compatibility. There is no documentation. There is no 
entry in the import catalogue.

You were criticized for stretching the opening_hours syntax to describe seasonal operations ("Jan 01 
- Dec 31"), but did not respond nor adjust your tagging.[3]

The link on your Umap site leads to [5], which is licensed under the Italian Open Data License, 
linked here [6]. It requires attribution, machine-translated: "On condition of: indicate the source 
of the Information and the name of the Licensor, including, if possible, a copy of this license or a 
link (link) to it."

You have not attributed correctly. You changesets, e.g. [7], give in the CS comment "RAFVG source", 
which is an incomprehensible acronym if you don't know the context. The CS has no source tag at all 
(although the editor you use has a mechanism for it), thus you do not name the source correctly, you 
do not name the Licensor, and you do not include a link although possible. You have also not checked 
if the attribution on the changeset only would be sufficient.

Your import does not include any check, how current or old the data in the imported set are. In the 
hotel business, things can change very fast. Hotels open and close, and change ownership and 

Your import focuses on soft business policies, such as allowing pets or supervising kids. Such 
policies can change even more rapidly, and are better shown in separate datasets and not OSM itself.

You use and advertise in your umap the use of Level0 as an editor. This tool is excellent for 
quickly fixing a tag, but I would find it error-prone to upload mass changes without a validation step.

Thus I conclude: Visualising the dataset in your Umap approach [1] is an excellent idea, unreviewed 
copying of the data into OSM is not.




On 09.03.2019 12:19, Cascafico Giovanni wrote:


Il sab 9 mar 2019, 12:18 Cascafico Giovanni>> ha 

In short (I'm on phone)...
Please find here [1] umap used for manual conflation. For source data and 
license, follow footer
info link.

AFAIK <100 nodes don't fall in import category.

Il sab 9 mar 2019, 11:46 Tom Pfeifer>> ha

On 09.03.2019 10:10, Cascafico Giovanni wrote:
 > Well, hotels dataset I'm manually importing has a boolean 
baby-sitting field (as for
"pets" in other
 > ML thread).
 > I think that a generic info is better than no info, particularly if 
hotel features
childcare=yes and
 > whatever contact tag.


can you please let us know, which hotels dataset you are importing,
under what license this dataset is published,
and where you discussed the import with the OSM community?

Please not that an import is an import even if you do just one hotel 
per day.


Tagging mailing list

[Tagging] Hotel dataset import? / Re: Baby-sitting

2019-03-09 Thread Tom Pfeifer

On 09.03.2019 10:10, Cascafico Giovanni wrote:
Well, hotels dataset I'm manually importing has a boolean baby-sitting field (as for "pets" in other 
ML thread).
I think that a generic info is better than no info, particularly if hotel features childcare=yes and 
whatever contact tag.


can you please let us know, which hotels dataset you are importing,
under what license this dataset is published,
and where you discussed the import with the OSM community?

Please not that an import is an import even if you do just one hotel per day.


Tagging mailing list

Re: [Tagging] tree rows vs individual trees

2019-02-10 Thread Tom Pfeifer

On 10.02.2019 09:53, Markus wrote:

On Sat, 9 Feb 2019 at 20:41, Paul Allen  wrote:

[...] I see individual trees
and tree rows as alternative ways of dealing with things and plotting 
individual trees on a
tree row seems bizarre (a row of individual trees is obviously a tree row, 
there's no need to
map both at the same time).

That's my opinion too.

Thanks Paul, Markus, that's what I mean.

In a related discussion I have heard the argument that, after mapping the individual trees, "if we 
delete the tree_row way, we lose the information that they are part of a tree row."

The problem with that argument is that a tree_row only exists as an 
abstraction/simplification/interpolation of a number of not-yet-mapped trees.

Thus it is more comparable to the addr:interpolation which we use before all addr:housenumber are 
mapped individually. Once we have achieved that, the interpolation line becomes obsolete.

So, once the trees are mapped individually, we have all the information we need. The tree_row is 
then unverifiable, as there is no definition where it begins and where it ends. As said before, I 
could call any two trees a "row", e.g. each pair of trees on the opposite sides of the road. Or, I 
could say I need a new row once a tree is missing in some equidistant spacing, or I could ignore 
missing trees.


Tagging mailing list

Re: [Tagging] tree rows vs individual trees

2019-02-09 Thread Tom Pfeifer

On 09.02.2019 20:15, Tobias Knerr wrote:

Because the two feature types exist at different levels of abstraction
(a tree is *part* of a tree row), I do not see this as a violation of
one feature, one element.

Instead, I consider it comparable to mapping building:part areas within
a building=residential outline within a landuse=residential, or mapping
amenity=parking_space areas within an amenity=parking.

On 09.02.2019 20:14, John Sturdy wrote:
> I think it's also comparable to mapping the pylons of a power line and the 
line itself.

I would not consider those analogies applicable.

Both pylon and line exist, and both building:part and building are tangible 

The tree_row, on the other hand, is a virtual collection of trees, and forming a row is just in the 
perspective of the observer. There is nothing tangible between the trees, once the individual, 
tangible trunks are mapped.

Thus the tree_row is a simplification, because the mapper was not able to map 
the trees.

Otherwise I could just arbitrarily connect some trees in a park and declare it 
a row.


Tagging mailing list

[Tagging] tree rows vs individual trees

2019-02-09 Thread Tom Pfeifer

On the natural=tree page I stumbled over the phrase:

"Tree rows ... This approach can also be combined with individually mapped trees for 
further details."

On natural=tree_row I found it was part of the 2010 proposal which said:
"if individual trees in a tree row are mapped, the tree nodes should be part of the tree row way. 
Usually, however, it's not necessary to map the individual trees in a tree row."

In the discussion this was reasoned with:
"...connecting the trees with a way allows renderers to generalize the tree row into a single 
entity, rather than showing each tree separately"

IMHO this violates the one object - one OSM element principle. Either I choose the coarser approach 
to map a way for the row, or I refine it to individual trees, but should not use the row anymore.

If a renderer wants to cluster any trees that can be done algorithmically.

I suggest to remove the idea that tree and tree_row could be combined,
or even declare it should not be done.


Tagging mailing list

Re: [Tagging] motorcycle:scale

2019-02-04 Thread Tom Pfeifer

On 04.02.2019 08:51, Frederik Ramm wrote:

* invent keys - ok

* document widely used/established keys that never went through a
proposal process - ok

* invent keys and document them as if they were widely used or
established - questionable

* the whole thing done by someone who has in the past unilaterally
documented their personal preferred tagging on the wiki, then made
mechanical edits to push it through, and when challenged in changeset
comments, cited the wiki pages they had edited themselves as an
authority - ...

It is particularly questionable in this case to mark the documentation as "approved", and include a 
proposal link to a proposal for a different scheme (i.e. mountainbiking). While any other user could 
have convinced me that this was a copy/paste oversight, with the history of a user who had staged a 
fake voting in the past I can only conclude it was intentional.


Tagging mailing list

Re: [Tagging] club=scout for similar organisations

2019-02-02 Thread Tom Pfeifer

On 02.02.2019 09:21, s8evq wrote:

Thank you for your input. I'm glad there are other examples of youth 
organisation that are clearly different from Scouts.

Could we agree that club=youth does have a meaningful usage, despite what the 
wiki currently states?

A club, being an association between people, is not a geographical entity.

Thus I prefer tagging the physical entity, which is the club home, with
where you can specify more closely what it is, e.g.
community_centre=club_home or
and specify the target group with

Adding club=* to describe the intentions of the club even further, the special interest, is fine, 
but I'd not use it alone. club=scout, from the original question, would be such special interest.

Contrary, the age group (senior, youth) is not a special interest in that sense, compared to the 
long list of valid examples on the page.


Tagging mailing list

Re: [Tagging] club=scout for similar organisations

2019-01-30 Thread Tom Pfeifer

On 30.01.2019 22:41, s8evq wrote:

2) According to the wiki there's also club=youth, but it's not used and 
amenity=community_centre should be used instead.
Reading the wiki on amenity=community_centre 
"When the centre is open to general audiences (...) gathering for particular 
activities, it should be tagged amenity=community_centre. When it addresses an audience 
with specific problems, and/or is staffed with professional helpers (social workers, 
nurses), amenity=social_facility would be preferred. "
Both don't fit the case here, as these places (just like scouts) are only open 
for members.

The statement is there to distinguish between facilities where people with specific problems get 
help, and those you'd visit voluntarily. Thus if everybody (maybe within a specific age group) could 
join (i.e. become a member) of the scouts, or a sports club, than amenity=community_centre would be 

There are subtags that describe the facility closer, such as
- community_centre=youth_centre
- community_centre=club_home

or the target community, such as

Adding club=scout does not hurt in you case.


Tagging mailing list

Re: [Tagging] Tagging of amenity=kindergarten operated by charitable operators and organisations

2019-01-07 Thread Tom Pfeifer

On 07.01.2019 19:08, Volker Schmidt wrote:

if it is a religion related operator, I usually also add religion and 
denomination tags, i.e. in
your Caritas example it would be

I would not be sure how to handle this:
Are these "access" tags, in the sense that (in the example) the kindergarten only accepts Roman 
Catholic children, or is it only indicating the religious background of the institution, but they 
accept children with other religious backgrounds as well.

I have never considered the 'religion' tag as an access tag. Typically I can freely enter a PoW, and 
listen to the ceremony, without being a member of that community or believe in that religion.

Similarly, educational institutions in my scope mostly accept children with different background, in 
particular if the receive state funding. E.g. Ireland, the majority of the schools is operated by 
the catholic church, and as a recipient of public funding they have to accept everybody, equally.

Back to Konrad's question, any better ideas to tag the name of the operator's 
umbrella organisation?
I drafted:
> operator:umbrella=* would be more suitable, or more self-explanatory but 
> operator:umbrella_organisation=*


Tagging mailing list

Re: [Tagging] Tagging of amenity=kindergarten operated by charitable operators and organisations

2019-01-07 Thread Tom Pfeifer

On 07.01.2019 16:53, Konrad Lischka wrote:

My solution would be:
operator=[Name of theregistered association]

operator:type seems to be established with 180k uses. Plausible to me.

organisation=[organisation name like Caritas]

What you are trying to tag is the umbrella organisation of the operator,
kind of the operator of the operator,
not the "organisation of the kindergarten".

Thus organisation=* seems a bad fit to me.

(2) organisation=
alltough there is some use:

usage is very low (161) and unstructured regarding the values. Would not count 
on that.

Thus something like
operator:umbrella=* would be more suitable, or more self-explanatory but longer

(Langenscheidt: de: Dachverband = en: umbrella organization )

Tagging mailing list

Re: [Tagging] amenity=taxi vehicle type

2019-01-05 Thread Tom Pfeifer

On 05.01.2019 23:55, Warin wrote:

But 'type' does not say much. Better to specify what type of 'type' is to be 
used :)

In this case it is the type of vehicle.. so taxi_vehicle= 
car/motorcycle/rickshaw/* ?

Thanks, I consider that the best idea so far!

On 05.01.2019 16:13, Dolly Andriatsiferana wrote:
> wouldn't it be preferable using a different value of amenity=* or
> something else and leave amenity=taxi for "taxis"?

Using a new amenity value for a feature that we currently have about 300x in 
the database
leads to further tag fragmentation. According to previous discussion the 
alternative vehicles
are indeed called motorcycle taxi etc.

So, amenity=taxi lets the data consumer evaluate individual transportation for hire, and 
taxi_vehicle specifies it in more detail.


Tagging mailing list

[Tagging] amenity=taxi vehicle type

2019-01-04 Thread Tom Pfeifer
Following a discussion on osm-carto [1], I am looking for a suitable tagging of taxi services that 
are not passenger cars.

Examples are motorcycle taxis and rickshaws.

While the original approval for amenity=taxi (32k) [2] does not specify the vehicle type, some 
additions were introduced in 2013 [3], apparently from the Philippines community [4], to add the 
following tags:

+ motorcar=yes|no (usage 289, mostly Philippines)
+ motorcycle=yes|no (usage 290, mostly Philippines)

The problem I see here that this method hijacks access-tags, while the intention is to specify the 
type of the taxi. The next best candidates for the type are also already occupied with access tagging:

taxi=yes|no (18k)
vehicle=* (203k)

Thus I propose to discourage the use of those access tags, and to use a new subtag for the type of 
the taxi with an unambiguous key, e.g.:

taxi_type = car|motorcycle|rickshaw, etc,
while car is considered the implicit default.



[2] archived Approved features/Tag:amenity=taxi :



Tagging mailing list

Re: [Tagging] A fool with a tool ... Vehicle service tags

2019-01-04 Thread Tom Pfeifer
As a side note, I find those mails with fancy "scissor" lines hard to read, as the actual 
contribution is hidden somewhere in between.

It would help me if you could use the traditional method of quoting with '>' symbols, which is often 
supported in mail clients with some syntax highlighting.


On 04.01.2019 17:38, Thilo Haug OSM wrote:


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Top up

2018-12-26 Thread Tom Pfeifer

On 26.12.2018 19:05, bkil wrote:

Please don't confuse top ups with refilling:

No I don't confuse it. The refilling proposal is about refills without 
additional charge.
To top-up a drink is purchasing a new one without wasting another clean glass.

I think "top up" is standard terminology in the UK for increasing the balance of prepaid mobile 
phone accounts.

By which standard? I think it is marketing slang, as it makes no sense 


As said, if the amount is pre-paid, it is not a credit card. It might be a debit card because you 
have to have the money in advance.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Top up

2018-12-26 Thread Tom Pfeifer

I find "top_up" alone highly misleading and unspecific.

I encountered the term in filling stations, where you would order either "5 gallons" or "top up", 
i.e. to fully fill the tank. Or when pre-paying the fuel, you would either pay "fuel for $20", or 
leave your credit card with the cashier to allow "top up".

In the same sense, you could ask the bar keeper to "top up" your cocktail glass.

In the context of pre-paying credits for phone or transport, there is no such "top", no upper limit, 
you could buy any amount you want. Thus this marketing slang is misleading.

It is unspecific to be used in OSM since it does not indicate which service is 
being paid for.
Using it on the object tagged with amenity=bar it gets absolutely confusing 
what is getting topped up.

Thus, I'd not use the term "top_up" at all, and as Martin proposed, indicate the type of service 
first, e.g.:


Even 'credits' seem problematic, since what you pre-pay is not a credit.

On 25.12.2018 21:03, Daniele Santini wrote:> Hi, I propose to introduce the top_up=* key to specify 
whether a shop/amenity sells top-ups (mobile

> phone credit recharge vouchers,  over-the-air credit top up and/or public 
transport credit recharge
> vouchers).

On 26.12.2018 12:33, Martin Koppenhoefer wrote:

+1, I was proposing on talk-it a very similar
phone_top_up:=yes/ no

but given that top_up=yes already has some uses (mainly for public transport it 
seems), a more general scheme top_up:phone: could be more obvious to 
data users and more consistent with the current data, so +1 to this.

Tagging mailing list

Re: [Tagging] Printing company for newspapers

2018-12-14 Thread Tom Pfeifer

On 14.12.2018 11:09, dktue wrote:


I would like to tag a company where newspapers are being printed, but I feel that shop=copyshop 
doesn't fit well.

My suggestion would be to go with craft=printer. Any opinions on that?

I'd say it depends on the size. A small printer that focuses on business cards, letterheads, 
congratulation cards, I'd tag as craft.

For a larger one, and probably for the newspapers they have larger machinery, I might go for 
man_made=works where a subtag product=* is defined. Leaving open how to describe the product.


Tagging mailing list

Re: [Tagging] leisure=hammock_hook

2018-12-10 Thread Tom Pfeifer

On 10.12.2018 00:29, Sérgio V. wrote:

Hi, I've found a playground equipment that is made to hang hammocks.

If it is playground equipment, you should use the playgound=* key.


Tagging mailing list

Re: [Tagging] Public Transport Timetables Proposal RFC

2018-10-31 Thread Tom Pfeifer

I am strongly against storing timetable data in OSM.


On 31.10.2018 00:54, Leif Rasmussen wrote:

Hello everyone!
I recently wrote up a proposal page for public transport schedule data.  This information would 
allow OpenStreetMap to store information about when or how often certain buses or trains arrive at a 

Please feel free to look over the page and give feedback.  I am very open to changing the proposal, 
so let me know if you have any ideas for improvements to it.

Leif Rasmussen

Tagging mailing list

[Tagging] unmarked crossing, tactile paving, lowered kerbs / was: 2 meaning for crossing=zebra

2018-10-26 Thread Tom Pfeifer

On 26.10.2018 16:41, Robert Skedgell wrote:

On 26/10/18 11:44, Tom Pfeifer wrote:

Tagging "unmarked crossings" does not make sense for me. An unmarked
crossing is defined in OSM by a road and a footway sharing a node, there
is no need for a tag here, as there is nothing special.

An unmarked crossing may have no road markings or signs, but if there is
tactile paving and/or a raised/lowered/flush kerb on the footway
(sidewalk), how else would one tag it?

These are clearly markings for me, the tactile pavings are typically white and even visible in 
aerial imagery. Thus "unmarked crossing" is wrong. The tag is tactile_paving=*, used 300k.

The question is then, should they be mapped on the road or where they are, at 
the kerb?

For the lowered kerbs, they should be mapped as lowered kerbs, there is a tag for them, 
kerb=lowered, used 100k.


Tagging mailing list

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tom Pfeifer

On 26.10.2018 15:37, Bryan Housel wrote:

On Oct 26, 2018, at 6:44 AM, Tom Pfeifer  wrote:

Tagging "unmarked crossings" does not make sense for me. An unmarked crossing 
is defined in OSM by a road and a footway sharing a node, there is no need for a tag 
here, as there is nothing special.

Otherwise I would need to set a node every meter on the road, tagging it "unmarked 
crossing" because I can cross the road everywhere.

Try to imagine what crossing the street might be like for someone who can not 
cross the road everywhere and could benefit from guidance to tell them where it 
is possible or safe.

Do you see the contradiction? If the crossing is unmarked, the ground object already does not 
provide any guidance. As we map what's on the ground, there is nothing to map.

And I hate it when the satnav announces a warning for the upcoming crossing, 
and there comes nothing the requires extra attention.

Again, try to have some empathy towards other users who are not you.  It’s 
great that you are such an attentive driver.  If the satnav warning helps bad 
drivers not hit kids, I’m all for it.

It's not about empathy, it's about psychology. If you hear the same warning at each and every 
corner, again and again, you stop listening, and eventually switch it off.

The warning is useful when it comes only in situations that are different, such as a marked crossing 
where the pedestrian has priority, and often exercises it without watching or very suddenly.


Tagging mailing list

Re: [Tagging] 2 meaning for crossing=zebra

2018-10-26 Thread Tom Pfeifer

On 26.10.2018 09:28, SelfishSeahorse wrote:

What about tagging the presence or absence of traffic signals with a
subkey, e.g. crossing:traffic_signals=yes/no?

Why should we invent a new subtagging scheme when we already have one with 
crossing=* + crossing_ref=* ?

On Fri, 26 Oct 2018 at 01:19, Bryan Housel  wrote:
> - `crossing=unmarked` which is labeled “Unmarked Crossing”

Tagging "unmarked crossings" does not make sense for me. An unmarked crossing is defined in OSM by a 
road and a footway sharing a node, there is no need for a tag here, as there is nothing special.

Otherwise I would need to set a node every meter on the road, tagging it "unmarked crossing" because 
I can cross the road everywhere.

And I hate it when the satnav announces a warning for the upcoming crossing, and there comes nothing 
the requires extra attention.


Tagging mailing list

Re: [Tagging] issues with the list of deprecated features

2018-10-15 Thread Tom Pfeifer

On 15.10.2018 10:57, Martin Koppenhoefer wrote:

3. amenity=creche and amenity=nursery
For both tags amenity=kindergarten is suggested as alternative tagging, which seems clearly wrong 
(kindergarten is usually for ages 3-6 while these tags are for ages 0-3). 

I thought the consensus was here that it depends on the country. In Germany, I see mostly the "Kita" 
(Kindertagesstätte) structure which in the same institution enrols age 0-6 in different departments 
or groups, and a lot offer afterschool supervision (Hort).

This is easily expressed with the min_age + max_age tag, and some folks use 


Tagging mailing list

Re: [Tagging] Ignore roundabout flare in counting

2018-10-06 Thread Tom Pfeifer
Calling the driveway a 'flare' is a bit confusing, in my understanding a roundabout flare is the 
typical widening with two oneway segments around a small island. Such flares should be counted.

I encountered a similar situation as you describe, where some private gravel parking area in front 
of a house was connected to a roundabout, and OsmAnd counted it. Tagged highway=service without 

I agree with those that tagging highway=service + service=driveway should cause the router not to 
count it as exit. If the router does still count it, I'd recommend to open an issue there.


On 06.10.2018 09:33, Florian Lohoff wrote:

On Fri, Oct 05, 2018 at 11:26:01PM +0200, André Pirard wrote:

On 2018-10-05 20:35, Florian Lohoff wrote:

is there a tag to ignore a roundabout flare in counting the exits?

Is it a good idea for a navigator to ignore an exit and risk confusion?
What number should it say if that's the way to go?

Ignore flares if not used in counting.

The roundabout i have in mind has 4 normal exits and one "exit" which is
basically i private driveway. Its that small that noone not known to the
location would notice it.

Mapillary has some images but the website is broken right now.
In the josm plugin you can view the images.

Typical exists have islands and 2 oneway flares. But there is one very
small driveway exit nobody really notices but it will be counted.

Tagging mailing list

Re: [Tagging] Area of Firestations

2018-09-21 Thread Tom Pfeifer

On 21.09.2018 03:23, Mike H wrote:
I've only mapped one station like this so far, but the area is actually rendered on the map. 

Yes police and firestation areas are rendered for a while this year in osm-carto, with the same 
colour as military but without the hatching.

Thus I don't understand the 'but'.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

2018-09-20 Thread Tom Pfeifer

On 20.09.2018 16:29, José G Moya Y. wrote:

If we start mapping refill=soft_drinks;coffee... and so on, how would you map sites where some soft 
drinks are refillable and some are not?

I am strongly against tagging the business practice how often a _paid_ glass of beverage is being 
refilled (with cheaply produced unhealthy liquids anyway). This is close to a restaurant review and 
not a geographical property.

I would support tagging the free tap-water refilling campaign as it is apparently a litter-avoiding 
idea and presumably ground-verifiable (by some sticker or so at the door?).

As a side note, I am surprised it needs such a campaign. I was never refused a filling of my water 
bottle, in various countries. Not in a pub while hiking, nor in an airport cafe (behind security 
where carrying water is not allowed).  It does not need much language either, handing the bottle and 
and a friendly look are usually self-explanatory and sufficient.


Tagging mailing list

Re: [Tagging] Area of Firestations

2018-09-20 Thread Tom Pfeifer

Yes of course, I've been doing this for long already.

On 20.09.2018 14:06, Philip Barnes wrote:

Yes, just go for it. Makes perfect sense.

Phil (trigpoint)

On 20 September 2018 12:56:03 BST, dktue  wrote:


I love how we map areas with amenity=school and buildings inside of it
with building=school. The same goes for amenity=hospital and

What I'd like to have is the same schema for firestations: They often
have a large area and one or multiple buildings on it.

Should I go with amenity=fire_station for the area and
building=fire_station for the buildings inside of it?


Tagging mailing list

Re: [Tagging] landuse for government offices ?

2018-09-20 Thread Tom Pfeifer

On 20.09.2018 11:19, egil wrote:

In Sweden government agencies are actually not allowed to own the properties 
they use.

Well, but we tag the _use_, not the _ownership_.
So if they have long-running tenancy, they use it this way.


Tagging mailing list

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

2018-09-20 Thread Tom Pfeifer

On 20.09.2018 07:28, Warin wrote:

On 20/09/18 09:26, Tom Pfeifer wrote:

First, how much of a delay is added by the routing engines, have you investigated this? If so, 
this would be a few seconds once-per trip, not every 500m like a traffic light. Thus the 
difference on the calculated overall travel time would be insignificant.
An old toll both was where I'd have to stop, dig out some money, hand it over, wait for any change, 
then I could go on. 30 seconds to 1 minute unless I drop the money.
I think these are all gone now on highways and bridges. They still exist and are in use for some 
National Park entries, possibly some parking places.

It's a while since I have seen them in the US for bridge toll, you would through a couple of 
quarters in a funnel-shaped basket, thus a bit faster. But yes, there is a delay, but not so often 
on your trip that it has significant impact on your travel time.

The main advantage of free-flow systems is that you have no breaking that causes a congestion behind 

Second, the problems described would be more easily and more elegantly solved with subtagging the 
existing barrier=toll_booth, instead of inventing a new first level tag. Subtagging preserves 
backward compatibility, while a new tag has to be implemented everywhere,

But a toll gantry has no stopping, nor slowing down. A very different beast, with the ones around 
here the vehicle is meant to have an electronic device that the toll thing responds with and the 
payment is deducted automatically. If you don't have one of these electronic do dads then you get a 
letter .. with a higher fee. Don't know that "toll both" is how they should be tagged from a human 
conceptual view point rather than the practical computing one.

All fine, just we don't need a new high-level tag for that. You can add all free-flow properties, 
payment methods, average delay times, etc to the existing one. I'm always in favour of some level of 
structure instead of blatant duck tagging.


Tagging mailing list

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

2018-09-19 Thread Tom Pfeifer

On 19.09.2018 19:31, Jonathon McClung wrote:
The issue is mostly with how the current standard (as stated here 
) impacts routing. This is said on the 
proposal page here "Many current routing softwares add a delay to trip time when encountering the 
tag barrier =toll_booth 
. However, the delay on these more 
modern toll collection systems is significantly less; not requiring the driver to stop in most 
cases. In effect, this means that many drivers will be routed onto a slower route.” This is the 
major difference. Of course the way itself should be tagged toll=yes. This is a clean way to a) show 
where the toll begins and b) give the routing software something to account for on the way.

First, how much of a delay is added by the routing engines, have you investigated this? If so, this 
would be a few seconds once-per trip, not every 500m like a traffic light. Thus the difference on 
the calculated overall travel time would be insignificant.

Second, the problems described would be more easily and more elegantly solved with subtagging the 
existing barrier=toll_booth, instead of inventing a new first level tag. Subtagging preserves 
backward compatibility, while a new tag has to be implemented everywhere,


Tagging mailing list

Re: [Tagging] Slow vehicle turnouts

2018-09-08 Thread Tom Pfeifer

On 08.09.2018 01:30, Martin Koppenhoefer wrote:

On 8. Sep 2018, at 01:19, Graeme Fitzpatrick  wrote:

I'm also quite definitely not an expert Dave :-), but personally, I think that 
your highway=service + service=turnout concept may be the easiest, least messy 
or complicated way of doing it?

if these are lanes it would not be acceptable, but if there’s a proper 
carriageway on its own it is the way to go.

What Martin means is, it depends on physical separation. If the lane is physically separated e.g. by 
a barrier being at least a kerb, highway=service + service=* is fine. If not, the lane tagging comes 
in, and we have an established tagging style for lane properties.


Tagging mailing list

Re: [Tagging] Is waterway=riverbank an 'Old scheme' ?

2018-09-06 Thread Tom Pfeifer

On 06.09.2018 15:15, yves wrote:
> Is waterway=riverbank an 'Old scheme' ?

That's what I read here :

well it is certainly the _older_ scheme than natural=water + water=river, insofar the statement is 
not wrong. The wiki page for 'riverbank' says, it "remains in widespread use and is still preferred 
by some mappers." I.e. 279K vs. 19K for water=river.


Tagging mailing list

Re: [Tagging] non-physical / why do we discourage leisure=skatepark/skate_park?

2018-08-31 Thread Tom Pfeifer

On 31.08.2018 14:33, Paul Allen wrote:

On Thu, Aug 30, 2018 at 11:08 PM, Graeme Fitzpatrick wrote:

What are "non-physical" & "physical" tags?

My interpretation of the wiki is based upon my classification of things.  My brain is a physical 
object, my thoughts
are not.  A grass field with lines marked on it and intended to play sports on is a physical thing 
we call a "pitch"

whereas a game of football is not a physical thing.  So "pitch" is physical and 
"sport" is not.

While I agree with that, I do not see a need that sport=* is always attached to 
a physical object.
In particular sports that are performed in a natural environment often have no sharp geographical 

Examples are areas in a lake for sport=swimming, or areas with rocks where you 
can sport=climbing.
Unless there is a physical barrier, like a floating line in the lake, you are not limited how far 
you want to swim, but you would not use the whole lake. Similarly, a geolocation is known for good 
climbing spots, however you don't want to tag each boulder, or they are hard to map cause GNSS is 
poor under the trees and the rocks are not visible from aerials for the same reason.

Thus the location is surrounded by the physical object, but the tag is on a separate node, such as a 
shop in a larger building.


Tagging mailing list

Re: [Tagging] why do we discourage leisure=skatepark/skate_park?

2018-08-30 Thread Tom Pfeifer

On Thu, Aug 30, 2018 at 7:50 PM, Martin Koppenhoefer wrote:

Once again I stumbled across a warning which discourages these 
leisure=skate_park and skatepark
on the sport skateboard page because of low usage, but with the only 
alternative “pitch”. If you
can speak about pitches in this context, I would expect a skatepark to 
often consist of more
than one “pitch”.

On 30.08.2018 21:10, Paul Allen wrote:
I'd expect a pitch to be flat.  I'd expect a skateboard park to not be flat. 

Well that's the old issue of trying to fit a tag semantically to equal natural language, which is 
not necessary.

In OSM a pitch can be a field where a particular sport is performed. Multiple pitches form a 

If I am not interested what particular sport is performed there, it is enough to evaluate the pitch 
and the sports_centre tagging, and I know it is not a quarry. Keep things slightly structured.


Tagging mailing list

Re: [Tagging] mobile phone repair only

2018-08-05 Thread Tom Pfeifer

On 05.08.2018 19:52, Dave F wrote:

I've a shop which only repairs mobile phones.

I've tagged it as

I'd call that 'troll tagging', tagging a feature and telling in the subtag that it is not what the 
primary tag says [1].

Why not following the pattern of other repair shops, such as
shop=car_repair ?


Tagging mailing list

Re: [Tagging] Mirror setting marks

2018-07-26 Thread Tom Pfeifer
In order to shorten the tag, avoid the crowded amenity space, and be more descriptive what vehicles 
they are for, what about 'hgv=mirror_adjustments' ?

On 26.07.2018 22:04, Tijmen Stam wrote:

On 26-07-18 15:51, Martin Koppenhoefer wrote:
I'm fine with your proposal, I just wondered if the name is appropriate. Is access to these sites 
regulated / opening hours, etc., is it just a kind of "parking space" (where you might not be 
allowed to park), etc.

An alternative could be mirror_adjustment_site but maybe this sounds too big?


The sites all look the same.

Some of them are on the site of a trucking agency and thus private, some are accessible at places 
where truckers come often, i.e. at the exits of large distribution centres, at motorway truck stops 

It's a spot where one would pull up a truck (or bus/touring car), then check whether the mirrors are 
right, and if not, adjust them. It would be rude to really park there.

I wouldn't make more than a node out of it.


Tagging mailing list

Re: [Tagging] building = house vs detached.

2018-07-22 Thread Tom Pfeifer

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'.


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?

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Sauna

2018-06-11 Thread Tom Pfeifer

I suggest to distinguish the key for the operation mode (hot, steam etc)
from those for the expected user group and dress code.

On 11.06.2018 09:29, Rory McCann wrote:

I suggest adding `sauna=gay`, for a gay bathhouse. "gay" is a
simplification since many men who have sex with men visit them (not just
gay men). `sauna=msm` sounds clinical and might be not obvious to data

In some countries (like Germany) saunas are always naked, in others
(e.g. Ireland) that is definitely not the case, you're expected to wear
your swimsuit). I don't know if that's worth tagging or if data users
should just deduce it from the country.

On 10/06/18 14:01, Jyri-Petteri Paloposki wrote:


proposing a new (or actually amended) use of the sauna key to specify
which kind of sauna the leisure=sauna is. The proposal can be found in

The proposed values as of now are as follows:

– sauna=yes
   General purpose value
– sauna=hot
   A Finnish-style sauna with a temperature of over 60°C because of the
water thrown on the rocks of the stove. This kind of sauna is relatively
dry because of the high temperature.
– sauna=steam
   A Turkish-style steam sauna with a lower temperature and limited
visibility because of the steam generated.
– sauna=smoke
   A Finnish-style hot sauna in which the stove has no chimney but
instead the smoke fills the room when the sauna is prepared, and the
smoke is then ventilated out when the sauna is ready.
– sauna=dry
   A non-steam dry sauna in which water is not thrown on the stove.
– sauna=aroma
   A sauna that constantly has an aroma. A Finnish sauna with occasional
aroma liquid added to the water is tagged as sauna=hot.
– sauna=infrared
   A sauna-like construction that is used for infrared therapy.

Tagging mailing list

Re: [Tagging] 3d-tagging

2018-05-24 Thread Tom Pfeifer

On 24.05.2018 13:25, Stefan K. wrote:

Sorry, more information needed :)
Okay, i found ...

I'm right now asking because i am wondering if there is a somehow "official" one. 

"Official" is what is used by data consumers - this is the case for the simple scheme, as there are 
3D renderer in the field.

... but for a castle entry, also 
tunnel=building_passage is needed.

The 'simple 3D' tags are used in addition to the other tags like width and height, so you can keep 
using the tunnel tag of course.

However please consider that 'simple' means it is not a fully fledged CAD system where you can 
represent every little detail. It helps to show useful 3D-outlines of a town.

At some stage it might collide with the interest of Indoor mappers, who want to represent indoor 
rooms and support indoor routing, most prominently in complex railway stations.


Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

2018-05-19 Thread Tom Pfeifer

On 19.05.2018 16:56, marc marc wrote:

if an operator decided to replace a diesel engine with a bicycle
crankset for each passenger, would that stop being a PT?

Yes - the operator would have to serve beer, and we'd have to tag them
tourism=attraction + highway=obstacle.

Tagging mailing list

Re: [Tagging] How orphanage should be tagged?

2018-04-23 Thread Tom Pfeifer

On 23.04.2018 12:12, Martin Koppenhoefer wrote:
For privacy concerns we obviously wouldn't map foster families, I'm less sure for supervised shared 
apartments (it depends whether they are publicly known / promoted / listed, have a sign, etc., or if 
you need "insider knowledge"). 

Exactly. I would not map anything that is not officially signposted with the 
purpose and an operator.
In particular the concept of a shared apartment is to make the life as normal as possible, that 
excludes labelling them.


Tagging mailing list

Re: [Tagging] How orphanage should be tagged?

2018-04-22 Thread Tom Pfeifer

On 22.04.2018 23:12, Martin Koppenhoefer wrote:

On 22. Apr 2018, at 22:23, Paul Allen  wrote:

It might have as much to do with tagging as trying to replace terms with 
euphemisms.  They're all social facilities.
They're all group homes.  Then specify the target group.

I am getting more and more the impression that whole amenity=social_facility 
tagging system was not a good idea. It would be so much simpler and clearer at 
the same time if we used duck tagging. amenity=nursing_home / orphanage / 
soup_kitchen / daycare / food_bank etc.
When needed you could still add the target group tag, but sometimes it is 
already implied.

I still consider the social_facility tagging system a success. It allows a data consumer to quickly 
distinguish e.g. an area with such facilities from an area with offices, without maintaining a large 
list of duck tags from the crowded amenity key.

As for the part of the world I live in, Charles Dickens-style 'orphanages' 
don't exist anymore.
Younger minors that are separated from their parents would be placed in foster families, or live in 
family-style structures following the SOS-Kinderdorf model. Juveniles live in supervised shared 
apartments (betreute Wohngemeinschaft). For the short term accommodation, there are group homes, 
however they would not primarily distinguish whether the minor is an orphan or separated from their 
parents for any other reason.


Tagging mailing list

Re: [Tagging] How orphanage should be tagged?

2018-04-20 Thread Tom Pfeifer

On 20.04.2018 12:00, Mateusz Konieczny wrote:

I encountered one with amenity=social_facility, JOSM is asking to
provide proper social_facility tag (what makes sense)

None from seems
to fit so I used social_facility=orphanage

used 17x

Is there any good reason to use other tag?

The structured approach is

  social_facility=group_home  (26820x)
  social_facility:for=child  (1259x)

in combination ca 260x in overpass

Tagging mailing list

Re: [Tagging] Feature Proposal - RFC - Carpet hanger

2018-04-10 Thread Tom Pfeifer
Again I agree with Warin, man_made suits better since it is more specific and avoids the crowded 
amenity key.

On 10.04.2018 09:03, Warin wrote:

Don't be too hasty.

There may be others who disagree.

On 10/04/18 15:52, Mateusz Konieczny wrote:

I see no meaningful difference between amenity=carpet_hanger and
man_made=carpet_hanger so I changed proposal to man_made=carpet_hanger

On Tue, 10 Apr 2018 14:57:55 +1000
Warin <> wrote:

man_made would be a more specific key and avoids excluding ones that
are not for the community, e.g. a commercial enterprise.

man_made "for identifying man-made/(artificial)/  structures added to
the landscape" amenity "an assortment of community facilities"

On 10/04/18 14:37, Mateusz Konieczny wrote:

carpet hanger (also carpet stand or carpet rack) is a construction
to hang carpets for cleaning with the help of carpet beaters.

Wikipedia page:

Currently there is no documented tagging scheme for this feature. At
this moment amenity=beater is typically used, but it seems poor tag
name, not matching English name for this feature.

the proposal page:

Tagging mailing list

Re: [Tagging] Carpet hangers

2018-04-01 Thread Tom Pfeifer

Which is strange, since the beater is the instrument you keep at home:

On 31.03.2018 18:45, Mateusz Konieczny wrote:

It seems that amenity=beater is the most popular tagging (at least it was when 
I was checking it).

On Sat, 31 Mar 2018, 18:12 Tomasz Wójcik, > 

You may don't know about this, but in central and eastern--Europe
countries there are outdoor carpet hangers for cleaning them before

Tagging mailing list

Re: [Tagging] Historic building usage

2018-03-29 Thread Tom Pfeifer

On 29.03.2018 15:38, Dave F wrote:
The building=train_station tag remains, since it describes the building type, independent of the 
current usage.

No. The building tag is for current usage. OSM maps the present with its primary tags. If 
contributors want to indicate it had previous use, as I do in this case, it should be tagged with 
clearly defined sub tags.

We understand that you have strong personal opinions, and remember the debate about exit nodes in 

However the consensus with many other mappers in OSM is, as descried in the 

"the [building=*] value may be used to classify the _type_ of building. Note that it may be not the 
same as the building's current use (tagged using building:use=*). For example, a hospital building 
that is abandoned or repurposed to be a marketplace is still a building=hospital, and to mark active 
hospitals amenity=hospital is used. "

It also perfectly reflects common language. Imagine the following BrE example:
"Do you see the church building over there? It is now used as a climbing hall!"

The building:use tag is inaccurately used. (I believe it shouldn't be used at 

Again this is your personal opinion. building:use is well defined in the wiki, 
and used 63 times.

IMO this is poor tagging. If a building is now used as a place for people to live then it clearly 
isn't a warehouse any more.

No, but it has the building type of a warehouse. Ans some people like it, and 
"Hey, I have an new loft in the old warehouse."

A separate tag is required.

We have two separate tags, building=* and building:use=, they are well defined and serve their 
intention. If your intention is different, I understand that, but that will not change our minds.

On 29.03.2018 16:26, Dave F wrote:
> On 29/03/2018 09:05, Johnparis wrote:
>> Interesting. Musée d'Orsay in Paris offers another possibility: 
> But that doesn't account for what it currently is.

Correct, that's what people use building:use for.


Tagging mailing list

  1   2   3   4   >