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

[Tom Pfeifer]

I agree that it would be helpful to distinguish more subtypes of 
highway=service.
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:
https://lists.openstreetmap.org/pipermail/tagging/2016-March/028982.html

Possibilities discussed were:

service=parking_access
service=main
service=access
service=major

tom

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging




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

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

[Tom Pfeifer]

On 04.09.2020 18:19, Jmapb via Tagging wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter



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

tom

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

Re: [Tagging] Tagging a government job centre

[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

tom

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


Volker
(Italy)


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


 
	Virus-free. www.avast.com 
 



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

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




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

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

[Tom Pfeifer]

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

tom

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
following:

* 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

Regards

Sven




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

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

[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 
room"

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

So:
Please go and vote.
https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest#Voting


On 04.11.2020 11:17, woll...@posteo.de 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: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest

Discussion page: 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest


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

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

[Tom Pfeifer]

I appreciate amenity=place_of_mourning.

tom

On 09.11.2020 10:15, woll...@posteo.de 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 woll...@posteo.de:

Thanks for all the interventions.

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

amenity=mourning
amenity=place_of_mourning
amenity=mourning_room
amenity=viewing_arrangements
amenity=deceased_viewing

Am 04.11.2020 11:17 schrieb woll...@posteo.de:

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:
https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest

Discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest

Thanks!

Vollis


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



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

Re: [Tagging] Deprecate water=pond?

[Tom Pfeifer]

On 10.11.2020 10:56, Andy Mabbett wrote:

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


I think the best option is to deprecate water=pond and suggest using water=lake 
for
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'.

tom

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

Re: [Tagging] Deprecate water=pond?

[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 mailto:adamfra...@gmail.com>> wrote:

  * origination:natural=beavers

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


(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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] COVID-19 vaccination centres

[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 
value.
The compact form 'covid19' is already used in various tags.

Thus, what about either

- healthcare = covid19_vaccination
- healthcare:covid19 = vaccination


Related tags & pages:

https://wiki.openstreetmap.org/wiki/COVID-19_-_How_to_Map
  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)

tom

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

Re: [Tagging] COVID-19 vaccination centres

[Tom Pfeifer]

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

Well it's used 34x already:
https://taginfo.openstreetmap.org/tags/healthcare%3Aspeciality=vaccination
While it was not in the original healthcare proposal it has been added on 
6feb2017
and appears in translations of the page. I'd support it.


healthcare:speciality=vaccination
vaccination:covid19=yes


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

vaccination:covid19=yes
vaccination:influenza=yes
vaccination:measles=yes

vs.

vaccination=covid19;influenza;measles

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.


tom

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

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

[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:

https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination

tom

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

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

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


https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination#Voting

tom

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

Re: [Tagging] destination:ref with direction?

[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 
instruction:
"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 
US,
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.

tom

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.: https://www.openstreetmap.org/way/5566969


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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] destination:ref with direction?

[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 
<https://wiki.openstreetmap.org/wiki/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
<https://wiki.openstreetmap.org/wiki/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.

 tom


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

Re: [Tagging] Feature Proposal - Voting - Payment denominations

[Tom Pfeifer]

Accepting a particular coin or banknote is among short-living business policies 
that can change
frequently and is often harder to observe than e.g. opening_hours. Thus they 
are difficult to
maintain and likely to be outdated. In my opinion, they should not be in the 
OSM database in general.

Sometimes such changes can even have technical reasons. E.g. the metro rail in 
Berlin has separate
blocks in their ticket vending machines, for coins, bills, card to be inserted, 
cards with NFC.
They take them in and out as they like, you cannot rely on finding a particular 
one the next day.
Reasons might be defective blocks or vandalism fear on particular stations.

tom

On 09.10.2022 21:57, m.brandt...@posteo.de wrote:
> Hello,
> 
> voting has started for the proposal Payment denominations.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Payment_denominations
> 
> 
> Have a nice week!
> 
> Kind regards,
> Michael (Discostu36)
> 

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

Re: [Tagging] Feature Proposal - Voting - Payment denominations

[Tom Pfeifer]

On 10.10.2022 17:01, Marc_marc wrote:
> Le 10.10.22 à 10:54, Tom Pfeifer a écrit :
>> Sometimes such changes can even have technical reasons
> 
> this does not change the problem: if you have a banknote that
> is not accepted by the vending machine, you cannot buy your ticket,
> no matter if it is a technical reason or an operator's mood.

Sure. My point was that the technical reasons are even more volatile than the 
policies.
Thus for me that is in the catagory
"Don't map temporary events and temporary features".

tom


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

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Tom Pfeifer]

On 07.11.2022 10:57, Mateusz Konieczny via Tagging wrote:

> Favoring emergency=marine_rescue seems sensible to me
> 
> 
> What about such stations on freshwater lakes and on rivers? Is "marine" 
> fitting there?

Not really.  emergency=lifeboat_station  implies the presence of a boat. Not 
all water rescue
related infrastructure has a boat, and not all is located directly at the coast 
line or river bank.
"marine" implies salt water.

Maybe emergency=water_rescue ?

Having a boat, a diving department, or being located at the shore can all be 
expressed in sub-tags.

tom

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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Tom Pfeifer]

Still does not resolve my problem with a water rescue station where there is no 
boat.

Before people ask again how that is possible - they might have their boats 
mooring at changing
locations without a station, but the station is not directly at one of the 
rivers/lakes.

tom

On 06.12.2022 00:47, Graeme Fitzpatrick wrote:
> Bringing this forward to the new month.
> 
> https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html
> 
> 
> Are there any further comments that anybody would like to raise?
> 
> To sum-up, proposal is to:
> Approve emergency=lifeboat_station
> Deprecate emergency=marine_rescue & merge it's usages into =lifeboat_station
> Deprecate amenity= lifeboat_station & merge it's usages into 
> emergency=lifeboat_station
> Remove incorrect tagging of amenity=lifeboat, currently being used to show 
> the location that
> lifeboats are moored at.
> 
> If there's nothing further, then I'll move it to voting over the next few 
> days.
> 
> Thanks
> 
> Graeme
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] leisure=practice_pitch a bad idea because too overspecific for a main tag ?

[Tom Pfeifer]

It is current habit in OSM to tag everything that can be played a sports game 
on as "pitch".
Ripping part of those objects out of the name space and tag them differently 
breaks backward
compatibility for data users.

For such reasons we have subtagging schemes. So you tag the area with
leisure=pitch
as usual, and add a subtag with a more detailed description, such as
pitch={training|fullsize|children_only|or_whatever_you_like}.

That keeps the existing scheme compatible and adds more detail.

tom

On 31.01.2023 10:15, Warin wrote:
> 
> On 31/1/23 04:34, Illia Marchenko wrote:
>> Marc_marc :
>>
>> Hello,
>>
>> Le 30.01.23 à 16:24, Illia Marchenko a écrit :
>> > leisure=practice_pitch is not suitable for full game.

>> leisure=practice_pitch is intended for pitches that are physically 
>> unsuitable for normal game -
>> for example, small basketball pitch with one basket. 
>>
> 
> Soccer pitches have defined dimensions.. but there are smaller soccer pitches 
> for children to play
> soccer on, I'd not call those practice pitches. So just by looking at the 
> vacant pitch I'd not be
> able to tell if some sport pitches are 'practice' or not.

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

Re: [Tagging] bear box in campground ?

[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?


tom

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

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

[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 
halls.


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.


tom

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

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

[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
https://www.mcmenamins.com/kennedy-school) 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 
building.
Thus having both a building=X and leisure/amenity=X on the same polygon is not 
redundant.

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


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.


tom

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

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

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


[1] https://wiki.openstreetmap.org/wiki/Gymnasium

tom

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

Re: [Tagging] building typology vs usage

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


tom

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

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

[Tom Pfeifer]

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

Hi,

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

[...]
– 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=* .


tom

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

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

[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
assumptions:



- 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 
neighbourhoods,
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...


tom

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

Re: [Tagging] Tagging meadow orchards

[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
arbitrary.


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.

tom


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

Re: [Tagging] Tagging meadow orchards

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

tom



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

Re: [Tagging] Deprecating mini_roundabout

[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
junction.


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.


tom

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

Re: [Tagging] Deprecating mini_roundabout

[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 n.th 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
traversable.


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.

tom

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

[Tagging] 360 degrees / Re: Deprecating mini_roundabout

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


tom

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

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

[Tom Pfeifer]

type=destination_sign + amenity=hospital"
https://wiki.openstreetmap.org/wiki/Relation:destination_sign


I had a look at the original proposal, and it does not contain the word 
'amenity'.
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

tom

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

[Tagging] Supermarket pick-up service

[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 ?

tom


[1] 
https://shop.rewe-static.de/homepage/239036b7585997a3323062a8f5ee218f410147b2/img/hero/as.jpg

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

Re: [Tagging] Supermarket pick-up service

[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
https://wiki.openstreetmap.org/wiki/Tag:shop%3Doutpost

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.


tom

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

Re: [Tagging] Feature Proposal - RFC - park_drive

[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 
city.

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.

tom

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

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

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


tom

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

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

[Tom Pfeifer]

On 09.12.2019 19:09, Paul Allen wrote:

On Mon, 9 Dec 2019 at 17:31, Tom Pfeifer mailto:t.pfei...@computer.org>> 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 maps.me <http://maps.me>) 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.

tom

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

Re: [Tagging] Public WLAN boxes

[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 
OSM:


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.


tom

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

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

[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 
retaining
a fee for themselves, and finally claims it from revenue.

IIRC a similar scheme exists for US sales taxes.

tom

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

Re: [Tagging] amenity=tourist_bus_parking

[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 
somewhere.



tom

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

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

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

tom

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

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

[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 
numbers.


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 
"Löschwasserteich".
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 
heterogeneous,
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?


tom

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

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

[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
"Löschwasserteich".
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
headings?

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.

tom

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

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

[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 wiktionary.org suitable for these details, which can be sufficiently linked 
with wikidata references. Thus there is no reason to duplicate that in OSM.


tom

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


 05:51，marc marc 



Hello,

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tom Pfeifer]

This discussion originally started in this changeset, which quite obviously was _not_ driven by a 
ground survey:


https://www.openstreetmap.org/changeset/76766631

Some even larger in Sweden:
https://www.openstreetmap.org/changeset/76998968
https://www.openstreetmap.org/changeset/77003019
https://www.openstreetmap.org/changeset/76996948

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

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 
observable.
The excavation from the most recent ice age, where I can swim, is a lake. Now go and find things in 
between.


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.


tom

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

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

[Tom Pfeifer]

Yes there is inconsistent use of place=square, in particular for _unnamed_ 
objects.
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: https://overpass-turbo.eu/s/ROw

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


tom

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:

*https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593045858
* 
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046473
* 
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046673

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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


https://www.visitlondon.com/things-to-do/place/77552-piccadilly-circus
"You are here: Home > Things to Do > Sightseeing > London Attraction > Public Square > Piccadilly 
Circus"


https://www.londoncitybreak.com/piccadilly-circus
"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..."


https://freetoursbyfoot.com/things-to-see-in-piccadilly-circus/
"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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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: https://www.openstreetmap.org/way/137931618 . 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?

tom

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

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

[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: https://www.openstreetmap.org/way/137931618 . 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?

tom

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

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

[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 
social_facility=group_home:

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

Tom


[1]
https://taghistory.raifer.tech/#***/social_facility/nursing_home&***/amenity/nursing_home&***/social_facility/group_home&***/social_facility/assisted_living

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

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

[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 
would
be clearly in this category. However what is more recommended to be mapped is 
the
basic homepage of a POI, because it is least likely to be changed in website 
relaunches.

The main purpose for me to read a website is to gain information about the 
object
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 
letter
there. So consequently, we would have to to move the "addr:*" scheme into 
"contact:addr:*",
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.

tom

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

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

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

tom

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

Re: [Tagging] leisure=hammock_hook

[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.
https://wiki.openstreetmap.org/wiki/Key:playground

tom


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

Re: [Tagging] Printing company for newspapers

[Tom Pfeifer]

On 14.12.2018 11:09, dktue wrote:

Hi,

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.


tom

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

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

[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.:

phone_credits=yes
transport_credits=yes
cocktail_glasses_topped_up=yes

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


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
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tom Pfeifer]

On 26.12.2018 19:05, bkil wrote:

Please don't confuse top ups with refilling:
https://wiki.openstreetmap.org/wiki/Proposed_features/Refilling_a_purchased_drink


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


top_up:credit_card:‹brand›=yes;no


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.


tom

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

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

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


Thanks
tom

On 04.01.2019 17:38, Thilo Haug OSM wrote:

8X-




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

[Tagging] amenity=taxi vehicle type

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

tom


[1] https://github.com/gravitystorm/openstreetmap-carto/issues/3621

[2] archived Approved features/Tag:amenity=taxi :
https://wiki.openstreetmap.org/w/index.php?oldid=62088

[3] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dtaxi&diff=next&oldid=763230

[4] 
https://wiki.openstreetmap.org/wiki/Philippines/Mapping_conventions#Commuter_Transportation_.2F_Auto_Shops_.26_Services



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

Re: [Tagging] amenity=taxi vehicle type

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


tom

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

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

[Tom Pfeifer]

On 07.01.2019 16:53, Konrad Lischka wrote:


My solution would be:
amenity=kindergarten
operator=[Name of theregistered association]
operator:type=charitable


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: https://taginfo.openstreetmap.org/keys/organisation


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
operator:umbrella_organisation=*

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

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

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

[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
religion=christian
denomination=catholic


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 
longer
> operator:umbrella_organisation=*


tom

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

Re: [Tagging] club=scout for similar organisations

[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 
(https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcommunity_centre#Differentiation): 
"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 
suitable.


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

or the target community, such as
community_centre:for=child

Adding club=scout does not hurt in you case.

tom

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

Re: [Tagging] club=scout for similar organisations

[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? https://wiki.openstreetmap.org/wiki/Key:club


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
amenity=community_centre
where you can specify more closely what it is, e.g.
community_centre=club_home or
community_centre=youth_centre
and specify the target group with
community_centre:for=*

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.


tom

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

Re: [Tagging] motorcycle:scale

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


tom

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

[Tagging] tree rows vs individual trees

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

tom

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

Re: [Tagging] tree rows vs individual trees

[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 
objects.

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.

tom

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

Re: [Tagging] edit war about deletion of proposal

[Tom Pfeifer]

On 09.02.2019 22:53, Richard wrote:

On Tue, Feb 05, 2019 at 11:44:13PM +0100, Sergio Manzi wrote:

done!


oh well.. now they moved it into some users namespace.

I guess we need category:humor ?


As his opponents in the edit war are taking a break, EzekielT created a new category in this 
battlefield:


Edit-warring himself! 7 edits of blanking/filling/moving one page within 10 
minutes!
Should we call the Guinness book?

tom

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

Re: [Tagging] tree rows vs individual trees

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


tom

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

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

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


Giovanni,

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.

tom

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

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

[Tom Pfeifer]

Giovanni,

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


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.


[2] https://lists.openstreetmap.org/pipermail/talk-it/2019-February/065837.html
[3] https://lists.openstreetmap.org/pipermail/talk-it/2019-February/065839.html
[4] https://wiki.openstreetmap.org/wiki/Import/Guidelines
[5] 
https://www.dati.friuliveneziagiulia.it/Istruzione-cultura-e-sport/Strutture-Alberghiere-e-RTA/fiiw-i5su

[6] https://www.dati.gov.it/content/italian-open-data-license-v20
[7] https://www.openstreetmap.org/node/2088900846/history

Tom

On 09.03.2019 12:19, Cascafico Giovanni wrote:

[1] http://umap.openstreetmap.fr/it/map/turismo-fvg_295722

Il sab 9 mar 2019, 12:18 Cascafico Giovanni mailto:cascaf...@gmail.com>> ha 
scritto:


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 mailto:t.pfei...@computer.org>> ha
scritto:

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.

Giovanni,

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.

tom


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

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

[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 
quality.


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.

tom

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

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

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


tom

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

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

[Tom Pfeifer]

On 23.03.2019 18:19, Paul Allen wrote:

On Sat, 23 Mar 2019 at 17:05, Jean-Marc Liotier mailto:j...@liotier.org>> 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 
would
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.


tom

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

Re: [Tagging] Apps of delivery

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

tom

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

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

[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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tom Pfeifer]

"capacity" is the well established for the number of items the facility can 
hold,
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?


tom


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
caravans=yes/no?


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

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

[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 
appropriate?

tom

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

Re: [Tagging] Public art definition

[Tom Pfeifer]

I don't see exhibitions in museums following the definition of public art.
While they are accessible to the public when visiting the museum, they are not as accessible as an 
outdoor installation in urban spaces.


There should be a different tagging scheme for them, e.g. exhibit=artwork
tom

On 26.01.2018 21:00, Daniel Koć wrote:

During discussing rendering of artwork in Louvre:

https://github.com/gravitystorm/openstreetmap-carto/issues/3031

it became non obvious to me what is the "public art" and what should be 
definition on the wiki:

https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dartwork

Currently it's defined as "A tag for public pieces of art", but it's interesting if artworks at 
permanent exhibition in museum with tickets can be tagged this way or it has to be tagged as for 
example exhibition=artwork (or maybe amenity=artwork in general)?


This way or another fixing rendering will be easy (if this is proper tagging, we have indoor=yes to 
select and hide such objects), but the tagging definition should be more detailed first.






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

Re: [Tagging] Public art definition

[Tom Pfeifer]

On 27.01.2018 03:22, Martin Koppenhoefer wrote:
I'm for a different key, something "specialist" (i.e. not a key of those of the current 
mapfeatures), and in particular not "tourism=artwork" which should remain reserved for public art.


So, how does "exhibit=artwork" work for you?

tom

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

Re: [Tagging] Mixed paid, free and forbidden parking

[Tom Pfeifer]

Have a look at https://wiki.openstreetmap.org/wiki/Key:parking:lane which also discusses 
parking:condition for time dependance.


I would not map the pollution restriction since it is very dependent on 
occasional situations.

On 28.01.2018 12:40, José G Moya Y. wrote:

Hi!
Near Prado Museum in Madrid, there is a parking zone that is paid (with time limit) from 9:00 to 
21:00 on weekdays and saturdays, free (without time limit) sundays from 15:00 to 00:00, free 
(without time limit) from 21:00 to 9:00 on weekdays, free (without time limit) on saturdays from 
21:00 from sunday 0:00 and FOBIDDEN (no parking) on sunday from 8:00 to 15:00.

Also, how can I map "do not park in case of high pollution"?



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

Re: [Tagging] How to tag sports halls?

[Tom Pfeifer]

On 07.02.2018 00:15, Martin Koppenhoefer wrote:

I'm unsure about indoor pitches, but would tend to require an indoor specific 
key.


Pitch remains pitch, the specific key is indoor=yes.

On 07.02.2018 00:15, Martin Koppenhoefer wrote:
> There seem to be recommendations to tag table tennis tables as pitches, and 
someone proposed this
> even for tables where you can play chess.

You seem to refer to discussion #3039 in carto. The argument there was meant, if leisure=pitch is 
used for table_tennis, it could as well be used for chess tables. If we find a better tag for 
table-oriented sports, it should apply to both.


On 07.02.2018 01:33, Warin wrote:
> Chess? Not certain if that can be classified as a 'sport' ... certainly a 
game of skill.

wikipedia: "FIDE is a member of the International Olympic Committee, which can be considered as a 
recognition of chess as a sport". You should also be careful in arguing with a chess player about 
that, some are also trained in Sudoku!


On 07.02.2018 01:51, Paul Allen wrote:
> Whatever you classify chess as, it's played on a board, not a pitch or a field.  Maybe if you 
play with human pieces (a
> novelty game) you might play it on marked grass but it would still be referred to as a board, not 
a pitch.


Sometimes with human pieces as a show, but chess is regularly played in parks all over the world on 
ground pitches:

https://commons.wikimedia.org/wiki/File:Innsbruck_17.jpg

On 07.02.2018 02:33, Warin wrote:
> Dictionary time - pitch...
> Oxford - An area of ground marked out or used for play in an outdoor team 
game.

OSM usually starts on a dictionary definition, but has the habit to grow larger than this. What we 
need in the end is an agreed denominator for a class of objects, even if that deviates a bit from 
colloquial English.


tom

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

Re: [Tagging] How to tag sports halls?

[Tom Pfeifer]

On 07.02.2018 17:27, Paul Allen wrote:

On Wed, Feb 7, 2018 at 2:45 PM, Tom Pfeifer mailto:t.pfei...@computer.org>> wrote:
OSM usually starts on a dictionary definition, but has the habit to grow 
larger than this. What
we need in the end is an agreed denominator for a class of objects, even if 
that deviates a bit
from colloquial English.

Absolutely.  But the idea of a table-tennis pitch, chess pitch, ice-skating pitch and swimming pitch 
makes me

cringe.  That's not bashing a square peg into a round hole, that's shoving a 
camel through the eye of a
needle.  It can be done, with a hydraulic press, but the camel isn't much use afterwards (unless you 
like

camel soup).


I understand you, but some of the cringing comes from language-based bias. Where you have two words 
for pitch and court, I might have -platz (de) for both in my language and be more inclined to throw 
them into the same pot.


"Field of play" might encompass football, rugby, soccer, baseball, and even tennis.  Misleading, but 
good

enough, for cricket (nobody understands the rules anyway, so a terminological 
error is OK).  Still wrong
for ice-skating and swimming.


Yeah, we have leisure=ice_rink and =swimming_pool and don't want to change them.

We might need a new tag for the table-oriented sports (are the more than 
table_tennis and chess?).

We are struggling with sport that has a diffuse location, without fixed boundaries, often using a 
natural feature, such as swimming in a lake or climbing a rockface, or kite surfing.


Back to the original questions, I have a severe problem with leisure=pitch for the sports hall, it 
might also have pitches inside, indoor=yes. For that, leisure=sports_centre is only slightly better, 
in particular if the hall is part of a campus that is the real sports centre.


Thus I am inclined to follow Martin's proposal of leisure=sports_hall.

tom

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

Re: [Tagging] How to tag sports halls?

[Tom Pfeifer]

On 07.02.2018 23:20, Hufkratzer wrote:

7.2.2018 19:04,  Tom Pfeifer wrote:
Back to the original questions, I have a severe problem with leisure=pitch for the sports hall, it 
might also have pitches inside, indoor=yes. For that, leisure=sports_centre is only slightly 
better, in particular if the hall is part of a campus that is the real sports centre.


Thus I am inclined to follow Martin's proposal of leisure=sports_hall.


The German wiki page for amenity=school explains (different from the English page), that sports 
halls with only one pitch shall be tagged with leisure=pitch and sports halls with more than one 
pitch with leisure=sports_centre. Before Oct. 2017 it was also described like that on the wiki page 
for pitch. But probably leisure=sports_hall is better. Here are some of the current database entries 
with leisure=sports_hall:


222 says taginfo. There is also a proposal from 2013
https://wiki.openstreetmap.org/wiki/Proposed_features/Sports_hall
I am inclined to document that as in use.


Is the building=* tag optional if leisure=sports_hall is present? It looks like 
that.


No, I would consider that bad tagging. Somebody rendering the 3D shape of a town is not interested 
in the leisure tag.


Building describes the building typology, leisure the usage. So, if a church is converted for a 
sports_hall, it is still building=church.


tom

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

Re: [Tagging] Shops that sell printer ink cartridges

[Tom Pfeifer]

On 23.02.2018 14:42, Thilo Haug wrote:

IMHO there are no shops selling BUT printer ink, so a subtag might be more 
useful :


Not sure what the "but" means in your sentence. If you doubt that there are shops being specialized 
in selling nothing but ink, I know some.



printer:ink=sales
printer:ink=refill
printer:repair=yes
printer:sales=yes

and so on...


The "and so on" indicates the problem. I am against turning OSM into a shop inventory or an ontology 
of all products on the planet. I agree with Frederik below and his shop=printer_ink favourite.



Am 23. Februar 2018 13:08:59 schrieb Fredrik :


I came across shops that sell printer ink on taginfo [1] and saw they
were split in three.

shop=ink (42)

shop=ink_cartridge (13)

shop=printer_ink (12)

I created this wikipage [2] for shop=printer_ink and was wondering what
the list thinks.

shop=printer_ink sounds the clearest in meaning of the three and the
other values should be converted to this.


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

Re: [Tagging] Tagging request: missing admin_level tags

[Tom Pfeifer]

On 10.03.2018 09:36, Simon Poole wrote:
I would have to second this observation, this would seem to go exactly against what we've tried to 
fix with multi-polygons (not to mention a future area object type). Not to mention that a single way 
can be a member of multiple different borders at different admin levels, so this would seem to be a 
non-starter in any case.


In addition, the border ways can be other objects. Rivers are quite typical, which are easily 
included in a border relation. Tagging all border properties on the waterway leads to chaos.


Besides the minor and not yet explained "maritime boundaries" case - what are the other advantages 
of the proposed change?


tom


On 2018-03-10 01:51, Matthijs Melissen wrote:


Hi all,

OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is
considering to change the mechanism for rendering admin boundaries.
The proposed rendering of admin borders will be based on admin
boundary ways rather than polygons. This has a number of advantages -
for example, it will make it possible to style maritime boundaries
differently.


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

Re: [Tagging] Rubberised playground surface

[Tom Pfeifer]

On 12.03.2018 13:03, Andy Mabbett wrote:

Suggestions, please, for tagging the surface underneath playground
items like swings and slides, which is made of a soft, rubber-like
material.

I've used surface=rubber, for now, but that's not really accurate.


It might help to describe why you feel it is not accurate?

tom


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

Re: [Tagging] Rubberised playground surface

[Tom Pfeifer]

On 12.03.2018 14:13, Andy Mabbett wrote:

On 12.03.2018 13:03, Andy Mabbett wrote:



Suggestions, please, for tagging the surface underneath playground
items like swings and slides, which is made of a soft, rubber-like
material.

I've used surface=rubber, for now, but that's not really accurate.



It might help to describe why you feel it is not accurate?


Because it's not rubber.


It might help even more if you tell us what it is, not what it is not :-)

Thus, I cannot follow what you are trying to find.

I'd consider 'rubber' as a generic term for a group of elastic materials. If you want to distinguish 
if that is natural, or silicone, or caoutchouc, or butadiene rubber, feel free to propose a sub-tag.


For the playground user, the only difference would be if it is a compact elastic surface, or loose 
rubber chips/crumbles the offspring falls onto.


Similarly, I would not want to analyse which minerals are ground into the 
filling of the sandpit.

tom

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

Re: [Tagging] Shop=tailor vs craft=tailor

[Tom Pfeifer]

This might have been discussed here a while ago?

If you check the wiki pages, with history and comments, there are the following 
things to observe:

- shop was apparently in use before the concept of craft=* came up, this 
explains the higher number
- there is a semantic difference:
  'craft' clearly describes the place where the suit/dress is made.
  'shop' can mean different things. There are places where the customer is just measured, and the 
actual tailoring is done in a place with cheaper labour cost

  'shop' could also mean tailoring-supplies (or is there a different tag for 
it?)

Some people also distinguish making a new dress, vs. doing minor alterations (shortening the legs, 
small repairs).


tom

On 18.03.2018 05:57, osm.tagg...@thorsten.engler.id.au wrote:

“tailor” sounds very much like a craft to me.

On the other hand, it’s hard to argue with 1 tagged objects.

 From the title of the issue, I assume that craft wasn’t being rendered before? Which might very 
well explain why everyone used shop to tag it…


*From:*James 
*Sent:* Sunday, 18 March 2018 12:19
*To:* Tag discussion, strategy and related tools 
*Subject:* [Tagging] Shop=tailor vs craft=tailor
10 000 uses
vs
https://taginfo.openstreetmap.org/tags/craft=tailor#overview
5000
Should we support both or just one(if so which?)


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

Re: [Tagging] red housenumbers

[Tom Pfeifer]

You would need to find first _why_ they have different numbers.

In AT, CS, SK, there are "conscription" numbers in addition to housenumbers,
which are described here:
https://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber
(heavily used)

https://de.wikipedia.org/wiki/Konskriptionsnummer
https://cs.wikipedia.org/wiki/%C4%8C%C3%ADslo_popisn%C3%A9
https://sk.wikipedia.org/wiki/S%C3%BApisn%C3%A9_%C4%8D%C3%ADslo

On 19.03.2018 18:02, Martin Koppenhoefer wrote:
In the Italian city of Genoa there are housenumbers in black and in red, which are different 
numbers. People have started mapping them with the postfix "rosso" (red in italian) but are now 
wondering if there are other areas with similar objects and how these are tagged.


Example housenumber
https://www.openstreetmap.org/node/5479906188


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

Re: [Tagging] Nursing homes

[Tom Pfeifer]

On 23.03.2018 00:27, Philip Barnes wrote:

On Thu, 2018-03-22 at 19:19 -0400, Greg Troxel wrote:

Graeme Fitzpatrick  writes:


The other thing is that the tag that renders in map edit & also on OSMAND+
shows someone in a wheelchair? Yes, there will be a number of people in any
nursing home confined to a wheelchair, but there are also a *lot* who
aren't! Are we possibly inviting complaints suggesting that nursing
home =disabled?


(First, that's a discussion for osmand or carto; 


I am not aware of any wheelchair symbol in osm carto.
Graeme mentioned "map edit", which I assume means the iD editor, and OsmAnd.


the tag is fine even if renderers do something unwanted.)


I think Graeme's original question was about campus and building tagging.
As nursing homes often have some green area around, mapping the campus is preferred, and the campus 
gets the amenity tag. The building on campus are just tagged building=* according to their typus.


Only if there is no campus, the amenity tag goes on the building, that seems to be the case in the 
other example, just the building tag is missing here.


There are other building tagging errors nearby, e.g. "Varsity view" with a building around buildings 
(if these are towers, they would have to be tagged building:part=yes instead).


On 23.03.2018 00:06, Graeme Fitzpatrick wrote:
> (which is now  supposed to be amenity=social_facility & so on, ...

Indeed, the more modern style of tagging is amenity=social_facility which in carto renders as caring 
hands, both on buildings or campus, and can be sub-tagged with nursing home, assisted living and so on.


tom



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

Re: [Tagging] Nursing homes

[Tom Pfeifer]

On 23.03.2018 09:03, Mateusz Konieczny wrote:

On Fri, 23 Mar 2018 09:06:14 +1000
Graeme Fitzpatrick  wrote:


The places I've looked at are:


Can you link OSM object? Example of link -


As said, there were just tagging errors like building tag on campus, or building without building 
tag. They are fixed meanwhile.


tom

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

Re: [Tagging] Historic building usage

[Tom Pfeifer]

On 28.03.2018 23:20, Dave F wrote:

Hi

I've a building to tag which used to be a train_station but currently has a 
different use.


The building=train_station tag remains, since it describes the building type, independent of the 
current usage.



https://wiki.openstreetmap.org/wiki/Key:historic


If you consider it of historic value you can add the tag, however it is a bit 
vague.
If it is protected, heritage=* would be used, which allows to give details 
about the protection status.

This page recommends historic=building, but I don't see how that's beneficial. It can't be tagged to 
describe it's historic use. Building=* should be used to describe what it is now.


No, building=* remains as the original type. You can add building:use=* for the 
current use.


Wouldn't historic:building=* be better?


not necessary as the above covers the case.

Refs:

https://wiki.openstreetmap.org/wiki/Key:building:use
https://wiki.openstreetmap.org/wiki/Key:heritage

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

Re: [Tagging] Historic building usage

[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 
roundabouts.


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

"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 
all).


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 
say:
"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: 
building=disused:train_station
>
> But that doesn't account for what it currently is.

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

tom

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

Re: [Tagging] Carpet hangers

[Tom Pfeifer]

Which is strange, since the beater is the instrument you keep at home:
https://en.wikipedia.org/wiki/Carpet_beater

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, mailto:tom...@wp.pl>> 
wrote:

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

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


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

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

[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 <61sundow...@gmail.com> 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: https://en.wikipedia.org/wiki/Carpet_hanger

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:
https://wiki.openstreetmap.org/wiki/Proposed_features/carpet_hanger



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

Re: [Tagging] How orphanage should be tagged?

[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 https://wiki.openstreetmap.org/wiki/Key:social_facility seems
to fit so I used social_facility=orphanage


used 17x


Is there any good reason to use other tag?


The structured approach is

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

in combination ca 260x in overpass
tom

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

Re: [Tagging] How orphanage should be tagged?

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


tom

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

Re: [Tagging] How orphanage should be tagged?

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


tom

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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

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

https://luxeadventuretraveler.com/wp-content/uploads/2013/03/Jdombs-Travels-Beer-Bike-Berlin-1.jpg

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

Re: [Tagging] 3d-tagging

[Tom Pfeifer]

On 24.05.2018 13:25, Stefan K. wrote:

Sorry, more information needed :)
Okay, i found https://wiki.openstreetmap.org/wiki/Simple_3D_buildings ...

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. https://wiki.openstreetmap.org/wiki/Key:tunnel


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.


tom

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