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

[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

[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

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

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

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

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

[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 via Tagging]

I fully agree with Martin here. The place=* key is used in OSM to indicate that a particular 
location is known by a particular name, and that is independent of details of the usage.


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

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


tom


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

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



On 22.03.2020 12:24, Martin Koppenhoefer wrote:


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

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


___
Tagging mailing list
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

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

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

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

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

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

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

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

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

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

[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=next=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] 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

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] 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] 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] 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] Public Transport Timetables Proposal RFC

[Tom Pfeifer]

I am strongly against storing timetable data in OSM.

tom

On 31.10.2018 00:54, Leif Rasmussen wrote:

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


https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

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

Thanks,
Leif Rasmussen


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

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

[Tom Pfeifer]

On 26.10.2018 16:41, Robert Skedgell wrote:

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

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


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


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


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

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


tom

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

Re: [Tagging] 2 meaning for crossing=zebra

[Tom Pfeifer]

On 26.10.2018 15:37, Bryan Housel wrote:

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

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

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


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


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



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


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


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


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


tom

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

Re: [Tagging] 2 meaning for crossing=zebra

[Tom Pfeifer]

On 26.10.2018 09:28, SelfishSeahorse wrote:

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


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

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

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


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


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


tom

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

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

[Tom Pfeifer]

On 15.10.2018 10:57, Martin Koppenhoefer wrote:

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


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

This is easily expressed with the min_age + max_age tag, and some folks use 
after_school=yes.

tom

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

Re: [Tagging] Ignore roundabout flare in counting

[Tom Pfeifer]

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


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


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


tom

On 06.10.2018 09:33, Florian Lohoff wrote:

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

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

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

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


Ignore flares if not used in counting.

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

https://www.openstreetmap.org/#map=18/51.90770/8.26519

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

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


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

Re: [Tagging] Area of Firestations

[Tom Pfeifer]

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


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


Thus I don't understand the 'but'.

tom

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

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

[Tom Pfeifer]

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

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


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


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


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


tom

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

Re: [Tagging] Area of Firestations

[Tom Pfeifer]

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

On 20.09.2018 14:06, Philip Barnes wrote:

Yes, just go for it. Makes perfect sense.

Phil (trigpoint)

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

Hello,

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

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

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

Cheers,
dktue


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

Re: [Tagging] landuse for government offices ?

[Tom Pfeifer]

On 20.09.2018 11:19, egil wrote:

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


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

tom

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

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

[Tom Pfeifer]

On 20.09.2018 07:28, Warin wrote:

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


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


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


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


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


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


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


tom

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

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

[Tom Pfeifer]

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


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


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


tom

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

Re: [Tagging] Slow vehicle turnouts

[Tom Pfeifer]

On 08.09.2018 01:30, Martin Koppenhoefer wrote:



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

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



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


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


tom

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

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

[Tom Pfeifer]

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

That's what I read here : https://wiki.openstreetmap.org/wiki/Tag:water%3Driver


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


tom


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

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

[Tom Pfeifer]

On 31.08.2018 14:33, Paul Allen wrote:

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

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

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

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


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


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


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


tom

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

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

[Tom Pfeifer]

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

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


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


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


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


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


tom

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

Re: [Tagging] mobile phone repair only

[Tom Pfeifer]

On 05.08.2018 19:52, Dave F wrote:

I've a shop which only repairs mobile phones.

I've tagged it as
shop=mobile_phone
mobile_phone:repair=yes
sales=no


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


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


[1] https://wiki.openstreetmap.org/wiki/Trolltag
[2] https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar_repair

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

Re: [Tagging] Mirror setting marks

[Tom Pfeifer]

In order to shorten the tag, avoid the crowded amenity space, and be more descriptive what vehicles 
they are for, what about 'hgv=mirror_adjustments' ?


On 26.07.2018 22:04, Tijmen Stam wrote:

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

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

Cheers,
Martin


The sites all look the same.

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


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


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

Tijmen


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

Re: [Tagging] building = house vs detached.

[Tom Pfeifer]

Probably the reason can be explained etymologically.

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


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


tom

On 22.07.2018 20:56, Mike H wrote:
The definitions of building=house and building=detached on the wiki are very similar and don't seem 
to have any meaningful difference.


I've seen people say that house is meant for rowhouses, and detached should be for 
stand-alone houses, but there is no documentation that explains that. If that is the intended 
meanings of the tags, then the wiki pages need some work.


As far as how I've seen things actually mapped, I've only ever seen the building=house tag. Taginfo 
shows 1.2 million uses of detached, and 27.2 million uses of building=house, so they are both used 
quite a bit, but house is used a lot more.


Can anyone elaborate on these tags, or have ideas on how they could be better 
written about?

https://wiki.openstreetmap.org/wiki/Tag:building%3Dhouse
https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached


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

Re: [Tagging] Feature Proposal - RFC - Sauna

[Tom Pfeifer]

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

On 11.06.2018 09:29, Rory McCann wrote:

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

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

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

Hi,

proposing a new (or actually amended) use of the sauna key to specify
which kind of sauna the leisure=sauna is. The proposal can be found in
https://wiki.openstreetmap.org/wiki/Proposed_features/sauna.

The proposed values as of now are as follows:

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




___
Tagging mailing list
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

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