[Tagging] Christmas shop

[Graeme Fitzpatrick]

Just mapping a Christmas shop  https://christmasshack.com.au/, which, as
the name suggests!, is a shop that operates year round selling Christmas
decorations & supplies of various sorts.

Best option I could find to tag it is
https://wiki.openstreetmap.org/wiki/Tag:shop=party

Wondering if there would be any point to expanding the very bare entry to
include "types" (using that terrible word again!) of party: Christmas,
fancy dress, fireworks (?) & so on with lot's of examples that I can't
think of or don't know!

Thanks

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Graeme Fitzpatrick]

On Sat, 6 Jul 2019 at 16:27, Joseph Eisenberg 
wrote:

>
> Should we use bbq=yes or barbecue_grill=yes with campsites, caravan
> sites and camp pitches to specify the presence of a grill that can be
> used for bbq / grilling?
>

I would go for barbecue_grill=yes to show that there is "something" provded.

bbq=yes means that you are allowed to cook outside your caravan / tent,
usually using your own gas bbq

Thanks

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

Re: [Tagging] one feature one element

[Joseph Eisenberg]

>> *"For example, use the feature leisure=picnic_site with the property
>> tag drinking_water=yes, instead of using the separate feature tag
>> amenity=drinking_water on the same node or area."
>>
>> This example is a bad idea and mappers shouldn't be encouraged to do
>> so. amenity=drinking_water is far more popular tag and replacing it
>> with drinking_water=yes may hurt data consumers.
>
> I don't think it is an issue of replacing it. But where the location of
> the drinking water is unknown?

Right. It's great to map amenity=drinking_water on a node at the exact
position of a drinking fountain or water tap.

But if you want to say that a leisure=picnic_site has access to
drinking water without creating a separate node, then use the approved
and popular tag drinking_water=yes on the same area or node as the
picnic_site.

The key drinking_water has been used over 60,000 times and was
approved in a well-developed proposal back in 2014, so I picked this
example for the page.

But if there is a better example (eg atm=yes and amenity=atm?) feel
free to change it.

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Joseph Eisenberg]

Another user added bring_own_bbq=yes as a suggestion on the amenity=bbq page

But, getting back to the original question, which I need answered for
my draft proposal Proposed_features/Campsite_properties:

Should we use bbq=yes or barbecue_grill=yes with campsites, caravan
sites and camp pitches to specify the presence of a grill that can be
used for bbq / grilling?

On 7/6/19, Warin <61sundow...@gmail.com> wrote:
> On 06/07/19 02:28, Jmapb via Tagging wrote:
>> On 7/5/2019 10:56 AM, Joseph Eisenberg wrote:
>>> I don't think it would be necessary to combine "bbq=no" and
>>> "bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
>>> tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
>>> most tags with value "no", can be omitted.
>>
>> This is true. A better phrasing of the problem would be bbq=yes combined
>> with bring_own_bbq=yes. Does bbq=yes imply static bbq equipment, or just
>> permission to bbq that's further refined by the bring_own_bbq=yes tag?
>
> To me
>
> bbq=yes means there is a physical bbq there and I can use it. To have a
> physical presence and not being able to use it is foolish.
>
> bbq=no means I cannot bbq here, I don't think have never used it.
>
> If there s a need to specify the bbq is permitted but you have to bring
> your own (BYO is a common abbreviation here) then a new value?
> bbq=bring_your_own???
>
>
>>
>> In my mind, the *only* reason bbq=yes would mean the presence of a grill
>> is by echoing the amenity=atm/atm=yes pattern. But I don't think that
>> pattern works particularly well in this case. And as you pointed out in
>> your translation of the German wiki page, even amenity=bbq is already
>> used both ways, for equipment and permission: "One distinguishes between
>> free barbecue areas, where you have to take care of the grill yourself
>> and fixed barbecue areas with existing grill..." -- but there's no
>> indicating of *how* one distinguishes between the two. Obviously at one
>> point we didn't care to tag the difference, but now that we do, I don't
>> see any clear way of tagging all three possibilities
>> (grill/byo-grill/both) using the current tags.
>
> bbq:cooking_surface=grill/plate/* ??
> where plate is a continuous surface for cooking on, like a fixed pan,
> these usually drain to some point for cleaning.
>
>
>
>
> ___
> 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] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Warin]

On 06/07/19 02:28, Jmapb via Tagging wrote:

On 7/5/2019 10:56 AM, Joseph Eisenberg wrote:

I don't think it would be necessary to combine "bbq=no" and
"bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
most tags with value "no", can be omitted.


This is true. A better phrasing of the problem would be bbq=yes combined
with bring_own_bbq=yes. Does bbq=yes imply static bbq equipment, or just
permission to bbq that's further refined by the bring_own_bbq=yes tag?


To me

bbq=yes means there is a physical bbq there and I can use it. To have a 
physical presence and not being able to use it is foolish.


bbq=no means I cannot bbq here, I don't think have never used it.

If there s a need to specify the bbq is permitted but you have to bring 
your own (BYO is a common abbreviation here) then a new value? 
bbq=bring_your_own???





In my mind, the *only* reason bbq=yes would mean the presence of a grill
is by echoing the amenity=atm/atm=yes pattern. But I don't think that
pattern works particularly well in this case. And as you pointed out in
your translation of the German wiki page, even amenity=bbq is already
used both ways, for equipment and permission: "One distinguishes between
free barbecue areas, where you have to take care of the grill yourself
and fixed barbecue areas with existing grill..." -- but there's no
indicating of *how* one distinguishes between the two. Obviously at one
point we didn't care to tag the difference, but now that we do, I don't
see any clear way of tagging all three possibilities
(grill/byo-grill/both) using the current tags.


bbq:cooking_surface=grill/plate/* ??
where plate is a continuous surface for cooking on, like a fixed pan, 
these usually drain to some point for cleaning.





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

Re: [Tagging] one feature one element

[Warin]

On 05/07/19 19:57, Mariusz wrote:

On 05.07.2019 07:05, Joseph Eisenberg wrote:

I've removed this statement from the page because it leads to
ambiguous data and directly contradicts the One feature per one
element rule

[Examples of bad situations:] "An area object representing a
single-use building with a point object inside it. Move the tags to
the area object and delete the point."


This is common and widly accepted practice. Don't try to change 
mappers behaviour by editing wiki.


Also, there is no contradiction.  From wiki: "It means one 
on-the-ground real world feature should be mapped with only one OSM 
element. " That it - no multiple osm objects for one real world feature.
It is fine to map multiple real objects with one osm element, 
especially if you don't have enough data to map them seperately.


I have done both - mapped a shop on the building way and in a different 
place, as a node inside a building way.


The advantages of having the shop as a node inside a building way .. if 
the shop moves it is much easier to move the node and the history is 
retained. I think I prefer the shop as a node  method in hind sight. 
Much easier to maintain.





If the same feature is tagged with building=* and another feature like
shop=* or office=*, it's ambiguous whether other tags like name=*
represent the building itself or the other feature.


Nothing new, this problem already existed with roads and bridges and 
was fixed by putting bridge name into bridge:name tag.



While it's common to tag single-use buildings in this way, it isn't
the best practice, because of this ambiguity. Users should not be
encouraged to delete all single node objects within buildings without
carefully considering each of the tags.


That's true. POI and building may have more identical tags, for 
example "start_date" or "operator".



Moreover, you recently edited many times 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element and 
some newly introduced things are controversial:
*"Ideally, every OSM element or object should be tagged with only one 
main feature tag, to represent a single on-the-ground feature."


I've never heard of such rule. It doesn't seemed to be correct. It is 
against KISS principle and it is not how mappers map.
For example, there is nothing wrong in placing tags 
"landuse=industrial + barrier=fence" on one osm way. Doing it as 2 
ways would even give you a warning in JOSM (ways in the same position).


Some possible issues with that?
The fence is usually inside the boundaries of the land use.
The fence will have at least gates.
The fence may not be of a consistent height/construction ..



*"For example, use the feature leisure=picnic_site with the property 
tag drinking_water=yes, instead of using the separate feature tag 
amenity=drinking_water on the same node or area."


This example is a bad idea and mappers shouldn't be encouraged to do 
so. amenity=drinking_water is far more popular tag and replacing it 
with drinking_water=yes may hurt data consumers.


I don't think it is an issue of replacing it. But where the location of 
the drinking water is unknown?



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

Re: [Tagging] Maxweight wiki page changes

[Warin]

On 05/07/19 19:33, Mateusz Konieczny wrote:




3 Jul 2019, 12:52 by o...@westnordost.de:

1.1 At the examples: for max empty weight, I propose the key
maxemptyweight. It suggests itself.

Added, with link back to this post


Here that would be called "maximum Tare weight". In the UK?


1.2 At the examples: Conditionals should maybe better be
catch-all, so i.e. axles>=3 instead of axles=3

Changed
https://wiki.openstreetmap.org/w/index.php?title=Key:maxweight&diff=prev&oldid=1874072

2. Maxweightrating:

2.1 At the examples, Poland: This sign is actually an access
restriction for all HGVs: hgv=no. By definition in EU laws and
most other countries, a heavy goods vehicle is a goods vehicle
with a GVWR of 3.5t and above. See the wiki page for Key:hgv for a
longer explanation.

Right, I modified it (changed recommended tagging to hgv=no and moved 
to a separate section

"related signs")
https://wiki.openstreetmap.org/w/index.php?title=Key%3Amaxweightrating&type=revision&diff=1874076&oldid=1873139


3. Maxaxleload mentions that weight in USA must always be given in
short tons while the maxweight article also mentions pounds. Same
with the article about maxbogieweight.


Appears to be changed already.

4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.

I am not sure what is wrong here.

Disclaimer: my maxweight edits activity is done as part of
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849



___
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] New sections added to "Good Practice" page?

[Fernando Trebien]

On Mon, Jul 1, 2019 at 5:33 PM bkil  wrote:
> Be my guest:
> intermittent=yes
> ephemeral=yes
> building=no
> permanent=no
> movable=yes
> stationary=no
> caravan=yes
> mount=trailer
> support=wheels
> foundation=no
>
> https://en.wikipedia.org/wiki/Floating_restaurant
> https://en.wikipedia.org/wiki/Houseboat

Pure fun. Closest I've ever done was a floating restaurant [1], which
had been there for 6 months when I mapped and is there ever since, but
could be gone tomorrow. Also, where I live, there are many weekly
public markets licensed by the prefecture. The main one is a major
meeting point for the locals [2]. The only thing you find there during
weekdays are the signs stating the name, time and location of the
event.

caravan=* is related to access rights [3].

[1] https://www.openstreetmap.org/way/560511031
[2] Main one: https://www.openstreetmap.org/node/2267135759
[3] https://wiki.openstreetmap.org/wiki/Key:caravan

-- 
Fernando Trebien

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

Re: [Tagging] shared planter where you can harvest for free

[Philip Barnes]

On Friday, 5 July 2019, Jmapb via Tagging wrote:
> On 7/5/2019 3:08 PM, Paul Allen wrote:
> 
> > I read joost's comment as "The operator of this map object is a
> > specific private citizen"
> > not as a redefinition of "operator."
> >
> Hah, probably. Regardless, I do think that Les Incroyables
> Comestibles/Incredible Edibles fits better under the brand key, or maybe
> network, than operator -- because it sounds like the organization simply
> organizes, and does not actually do the upkeep.
> 
> Anyway, my suggestion for these free produce spots would be
> amenity=public_produce, similar to amenity=public_bookcase.
> 
I am thinking my local garden, which is looking very nice at the moment would be
network='Incredible Edibles'
operator='Incredible Edibles Wem'

And add website and contact:facebook tags.

Phil (trigpoint)

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] one feature one element

[Tobias Knerr]

On 05.07.19 11:57, Mariusz wrote:
> On 05.07.2019 07:05, Joseph Eisenberg wrote:
>> [Examples of bad situations:] "An area object representing a
>> single-use building with a point object inside it. Move the tags to
>> the area object and delete the point."
> 
> This is common and widly accepted practice. Don't try to change mappers
> behaviour by editing wiki.

It's true that shop tags on building outlines are a common practice.
However, POI nodes inside buildings are likewise common. So I believe it
was a good idea for Joseph to remove this statement. It did present a
widely accepted practice as a "bad situation" in need of fixing, after all.

> It is fine to map multiple real objects with one osm element

It'd say it's ok as a shortcut during initial mapping, but it is far
from ideal. As soon as you want to add tags which only apply to one of
the features (you mentioned "start_date" or "operator" as two examples,
but of course there are more), using separate elements becomes necessary.

> Nothing new, this problem already existed with roads and bridges and was
> fixed by putting bridge name into bridge:name tag.

It wasn't properly fixed until the introduction of man_made=bridge –
that is, a separate OSM element for the bridge.

The bridge:name tag was only a band-aid for a single symptom of a deeper
issue. It did little to address the other symptoms, such as multiple
roads running across the same bridge, and tags other than name.

Tobias

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

Re: [Tagging] shared planter where you can harvest for free

[Jmapb via Tagging]

On 7/5/2019 3:08 PM, Paul Allen wrote:


I read joost's comment as "The operator of this map object is a
specific private citizen"
not as a redefinition of "operator."


Hah, probably. Regardless, I do think that Les Incroyables
Comestibles/Incredible Edibles fits better under the brand key, or maybe
network, than operator -- because it sounds like the organization simply
organizes, and does not actually do the upkeep.

Anyway, my suggestion for these free produce spots would be
amenity=public_produce, similar to amenity=public_bookcase.

Jason

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

Re: [Tagging] shared planter where you can harvest for free

[Paul Allen]

On Fri, 5 Jul 2019 at 19:40, Jmapb via Tagging 
wrote:

> On 7/5/2019 12:18 PM, joost schouppe wrote:
>
> > Operator is actually "a specific private citizen"
>
> What's the source of this definition? On the English wiki, operator is
> "a company, corporation, person or any other entity who is directly in
> charge of the current operation of a map object."
>

I read joost's comment as "The operator of this map object is a specific
private citizen"
not as a redefinition of "operator."  But I could be wrnog.

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

Re: [Tagging] shared planter where you can harvest for free

[Jmapb via Tagging]

On 7/5/2019 12:18 PM, joost schouppe wrote:


Operator is actually "a specific private citizen"


What's the source of this definition? On the English wiki, operator is
"a company, corporation, person or any other entity who is directly in
charge of the current operation of a map object."

J


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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Jmapb via Tagging]

On 7/5/2019 10:56 AM, Joseph Eisenberg wrote:

I don't think it would be necessary to combine "bbq=no" and
"bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
most tags with value "no", can be omitted.


This is true. A better phrasing of the problem would be bbq=yes combined
with bring_own_bbq=yes. Does bbq=yes imply static bbq equipment, or just
permission to bbq that's further refined by the bring_own_bbq=yes tag?

In my mind, the *only* reason bbq=yes would mean the presence of a grill
is by echoing the amenity=atm/atm=yes pattern. But I don't think that
pattern works particularly well in this case. And as you pointed out in
your translation of the German wiki page, even amenity=bbq is already
used both ways, for equipment and permission: "One distinguishes between
free barbecue areas, where you have to take care of the grill yourself
and fixed barbecue areas with existing grill..." -- but there's no
indicating of *how* one distinguishes between the two. Obviously at one
point we didn't care to tag the difference, but now that we do, I don't
see any clear way of tagging all three possibilities
(grill/byo-grill/both) using the current tags.

Jason


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

Re: [Tagging] shared planter where you can harvest for free

[joost schouppe]

Thanks for the help!

I wouldn't want to lose the "Les Incroyables Comestibles" info, so as to be
able to group them by project. But maybe brand=* is the better tag for
that. Operator is actually "a specific private citizen", so that'd be
operator:type=private or maybe community if it is actually run by several
people together.
Allotments is indeed similar. If miniature zoos are permitted, maybe these
are really tiny allotments. I don't really like it though, as it directly
contradicts the first sentence of the wiki.


Op do 4 jul. 2019 om 22:41 schreef LeTopographeFou <
letopographe...@gmail.com>:

> This makes me think of two already used tags but I'm not sure I would use
> them on planters as they describe large lands:
>
>- landuse=allotments (
>https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dallotments) (but
>they imply some parcel assignment)
>- garden:type=community (
>https://wiki.openstreetmap.org/wiki/Key:garden:type) (with this one
>you are close to what you are looking for, but it's not a garden...
>
> Yours,
>
> LeTopographeFou
>
> Le 04/07/2019 à 08:59, joost schouppe a écrit :
>
> Hi,
>
> I stumbled upon some planters that are privately operated, on public
> domain, contain nothing but vegetables, and are meant for anyone passing by
> to help themselves. They are part of a project called "Incredible edibles"
> or "Incroyables comestibles". Here's an example:
>
>
> https://www.mapillary.com/app/user/joostjakob?lat=50.6903739&lng=4.2589972&z=17&pKey=9sx6_zLDzHbXL8om62LfEg&focus=photo
>
> I went with this:
>
> man_made=planter
> self_service=yes
> fee=no
> operator=Les Incroyables Comestibles
>
> But it doesn't really grasp the concept IMHO. Any suggestions?
>
> When looking for other examples, I found a Google MyMaps and several umap
> instances with local gardens. Showing this community that you can "simply
> map them in OpenStreetMap" would be nice. But first a data model!
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Tagging] one feature one element

[Jmapb via Tagging]

On 7/4/2019 11:17 PM, Joseph Eisenberg wrote:

We've also had problems with features tagged "tourism=camp_site" or
"landuse=meadow" plus "barrier=hedge" or "barrier=wall". Is the
barrier supposed to be an area or a linear feature in this case?

I can see the confusion here, but I think this rule still holds:
Normally linear features like barrier and highway will only be
interpreted as areas if tagged with area=yes. The presence of other tags
which imply area is not the same as area=yes.

But it's true that this usage verges on breaking the
one-feature-one-element rule -- unless you think of "fenced camp site"
as a single feature, which is a bit of a stretch.

Regardless, it's quite common to indicate a barrier around a 2D way by
tagging it with barrier=. I don't think it's genuinely ambiguous so I
doubt that it's going away any time soon, barring editor and bot
intervention. (I used to see fenced=yes... but only on pretty old
changesets.)


So I'd like to add a line that recommends to avoid mapping two
different "feature" tags on the same database object.


Which exactly are the "feature" tags? Everything on
https://wiki.openstreetmap.org/wiki/Map_Features ? Obviously building=
shouldn't be included, as it's often combined with other features. I see
cycleway= combined with highway= all the time. Same with sport= and
leisure=, tourism= and historic=. There are many other examples of
commonly used tag combinations, I'm sure.

If you want to try writing a narrower list of "top-level" keys that
should be mutually exclusive, give it a shot -- but I think that's going
to be a short list once we run through it and find all the useful
exceptions.

More likely to work would be: For certain keys, a list of other keys
that should not be used in combination. This list could appear as part
of each section on https://wiki.openstreetmap.org/wiki/Map_Features, or
as its own section on the https://wiki.openstreetmap.org/wiki/Key:*
pages. It might still be difficult to get consensus on these in many cases.

Jason


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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Joseph Eisenberg]

I don't think it would be necessary to combine "bbq=no" and
"bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
most tags with value "no", can be omitted.

There might be times when there is "bbq=yes" and "bring_own_bbq=no",
if you have to use the provided grill and can't bring your own, and
certainly a feature could be tagged with both "bbq=yes" and
"bring_own_bbq=yes".

That said, I'm happy to use the tag "barbecue_grill=yes/no" if there
are other people who clearly prefer this tag to "bbq=yes/no"

See https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties
for the draft proposal

On 7/5/19, marc marc  wrote:
> Le 03.07.19 à 17:17, Jmapb via Tagging a écrit :
>> bbq:grills=yes/no/1+
>
> or device=* (already approved tag do describe the number
> of same devices) ?
>
>> bbq:bring_own=yes/no
>
> or equiped=yes/no : the bbq is always there or it's an allowed
> but not-equiped area and you need to bring your own ?
> ___
> 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] Test prep centres and cram schools as amenity=prep_school?

[Jmapb via Tagging]

On 7/5/2019 2:16 AM, Joseph Eisenberg wrote:

So, what's a better term for a test prep centre, cramp school, or
tutoring office? There the rarely used tag office=tutoring, but that
doesn't quite cover a place like Kaplan or Kumon -
https://au.kumonglobal.com/ - https://www.kaptest.com/

amenity=test_prep
amenity=cram_school
office=test_prep
amenity=tutoring

Other options?


See previous discussions this year:

https://lists.openstreetmap.org/pipermail/tagging/2019-January/042561.html
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042983.html
https://lists.openstreetmap.org/pipermail/tagging/2019-March/043617.html
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045457.html

J

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

Re: [Tagging] New sections added to "Good Practice" page?

[Paul Allen]

On Fri, 5 Jul 2019 at 10:42, Mateusz Konieczny 
wrote:

I added it to
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/street_vendor%3Dyes&diff=1874089&oldid=1871846
> but I still prefer street_vendor
>

I found out yesterday there are also mobile post offices.  I was
surprised.  Comes
under the aegis of street vendor since they sell stamps and weigh parcels
so you
can buy the right amount of stamps.  You can also post letters to which you
have already
affixed a stamp but there's probably a nearer letter box for most people.

In the course of writing the above, the term "street service" came to mind,
to deal with
mobile libraries and banks.  The only problem with "street service" is that
a shoe shine
operation offers a service but the service costs money, whereas for many
things a mobile
library and a mobile bank make no charge.  So not an ideal term for those
two.

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[marc marc]

Le 03.07.19 à 17:17, Jmapb via Tagging a écrit :
> bbq:grills=yes/no/1+

or device=* (already approved tag do describe the number
of same devices) ?

> bbq:bring_own=yes/no

or equiped=yes/no : the bbq is always there or it's an allowed
but not-equiped area and you need to bring your own ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reservation= or booking= for campsites etc? and train

[marc marc]

The other major use booking=* with *!=booking.com concerns trains
in or passing through France, I talked about it on talk-fr and transport 
(the French-speaking transit mailing).
no one has so far opposed to move those in reservation=*,
but I will wait a few more days before modifying these objects.


Le 03.07.19 à 16:06, Joseph Eisenberg a écrit :
> The user (Hjart) who created the wiki page for booking=* says they are
> fine with deprecating it and using reservation=* instead
> 
> See:
> https://wiki.openstreetmap.org/wiki/Talk:Key:booking
> 
> Joseph
> 
> On 7/3/19, Graeme Fitzpatrick  wrote:
>> On Tue, 2 Jul 2019 at 21:37, Joseph Eisenberg 
>> wrote:
>>
>>>
>>> Is there any reason to prefer "booking=*" instead of "reservation=*"?
>>> I'm inclined to think of "booking=*" as a synonym that should be
>>> deprecated, unless it is preferred in British English for certain
>>> features?
>>>
>>
>>  From an Aussie English point of view, it's another either / or.
>>
>> Some places refer to bookings, others refer to reservations.
>>
>> Reservation is used ~10 times more (3000 v a few hundred) so booking could
>> possible be deprecated?
>>
>> 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] Test prep centres and cram schools as amenity=prep_school?

[Philip Barnes]

The issue I see with prep school is that it can be very easily confused with a 
Preparatory School, commonly referred to as a Prep School. I believe the term 
is used in both British and American English, i.e. Prepy.

Phil (trigpoint)

On Friday, 5 July 2019, Joseph Eisenberg wrote:
> I followed a link from amenity=school to amenity=prep_school, which
> was only as stub with the text "Tutorial schools" and
> description="Tutor school".
> 
> Taghistory shows it has been used since 2012, slowly increasing to a
> few hundred uses since 2018, but had no wiki page still March 2019.
> 
> However, I found out that this tag has now been added to
> osmlab/name_suggestion_index for brands like Kumon - an East Asian
> test prep centre, aka "cram school".
> 
> Unfortunately, this usage does not at all match the UK or US English
> meanings of "Prep School":
> 
> 1) "Prep school": in the UK, a private primary school for children,
> especially boys, between the ages of 7 and 13, who will then usually
> go to "public school" (a type of private secondary school). See
> https://dictionary.cambridge.org/dictionary/english/prep-school
> 
> 2) "college preparatory school", informally "Prep school" (North
> American English), a type of secondary school where there students
> plan to attend University. See
> https://dictionary.cambridge.org/dictionary/english/preparatory-school
> 
> I couldn't find any definition of "prep school" which mentioned test
> prep centers, as in this wikipedia article:
> http://wikipedia.org/wiki/Test_preparation - perhaps it's Singaporean
> or Hong Kong English, or a translation error?
> 
> So, what's a better term for a test prep centre, cramp school, or
> tutoring office? There the rarely used tag office=tutoring, but that
> doesn't quite cover a place like Kaplan or Kumon -
> https://au.kumonglobal.com/ - https://www.kaptest.com/
> 
> amenity=test_prep
> amenity=cram_school
> office=test_prep
> amenity=tutoring
> 
> Other options?
> 
> -Joseph
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[Erkin Alp Güney]

School=education is extraneous as a school implies an educational
institution. If you looked at education reform proposal, you would see
education=school. Cram schools are sufficiently different than academic
schools that amenity=school will not fit.

Yours, faithfully
Erkin Alp
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[marc marc]

Le 05.07.19 à 10:53, 石野貴之 a écrit :
> My proposal is the following:
> 1. Use a well-documented tag for the main tag. I think 
> office=educational_institution would be the best, but 

office=* is for office related stuff
the place where the staff do "office activities" can get an office=*
But i would call "office" a educational room where ppl learn something

> amenity=prep_school or another tagging is also OK.

to help the transition from one system to another or to fill in the 
missing information in the first system, for school we can use
amenity=school school=education education=*
I am well aware that this is one more tag but it has the advantage of 
not breaking anything while allowing the uses of the current system to 
have access to the data

> 2. Then, add education=cram_school or education=tutoring as an 
> auxiliary tag.

that's perfect.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] one feature one element

[Mariusz]

On 05.07.2019 07:05, Joseph Eisenberg wrote:

I've removed this statement from the page because it leads to
ambiguous data and directly contradicts the One feature per one
element rule

[Examples of bad situations:] "An area object representing a
single-use building with a point object inside it. Move the tags to
the area object and delete the point."


This is common and widly accepted practice. Don't try to change mappers 
behaviour by editing wiki.


Also, there is no contradiction.  From wiki: "It means one on-the-ground 
real world feature should be mapped with only one OSM element. " That it 
- no multiple osm objects for one real world feature.
It is fine to map multiple real objects with one osm element, especially 
if you don't have enough data to map them seperately.



If the same feature is tagged with building=* and another feature like
shop=* or office=*, it's ambiguous whether other tags like name=*
represent the building itself or the other feature.


Nothing new, this problem already existed with roads and bridges and was 
fixed by putting bridge name into bridge:name tag.



While it's common to tag single-use buildings in this way, it isn't
the best practice, because of this ambiguity. Users should not be
encouraged to delete all single node objects within buildings without
carefully considering each of the tags.


That's true. POI and building may have more identical tags, for example 
"start_date" or "operator".



Moreover, you recently edited many times 
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element and 
some newly introduced things are controversial:
*"Ideally, every OSM element or object should be tagged with only one 
main feature tag, to represent a single on-the-ground feature."


I've never heard of such rule. It doesn't seemed to be correct. It is 
against KISS principle and it is not how mappers map.
For example, there is nothing wrong in placing tags "landuse=industrial 
+ barrier=fence" on one osm way. Doing it as 2 ways would even give you 
a warning in JOSM (ways in the same position).


*"For example, use the feature leisure=picnic_site with the property tag 
drinking_water=yes, instead of using the separate feature tag 
amenity=drinking_water on the same node or area."


This example is a bad idea and mappers shouldn't be encouraged to do so. 
amenity=drinking_water is far more popular tag and replacing it with 
drinking_water=yes may hurt data consumers.



Mariusz



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

Re: [Tagging] New sections added to "Good Practice" page?

[Mateusz Konieczny]

1 Jul 2019, 18:41 by pla16...@gmail.com:

>
> equivalent of a mobile shop, and I'm not even sure there is one.
>
> Mobile=yes|no has the problem of confusion with cell phones.
>
> BTW, there's a fast food outlet near me set up in a shipping container at the 
> side of a road.
> Theoretically mobile, but in practise fixed.
>
> I can't think of a "one size fits all" rag for this.  Maybe static=yes|no.
>

I added it to 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/street_vendor%3Dyes&diff=1874089&oldid=1871846
 

 but I still prefer street_vendor

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

Re: [Tagging] Maxweight wiki page changes

[Mateusz Konieczny]

3 Jul 2019, 12:52 by o...@westnordost.de:

> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
> It suggests itself.
>
Added, with link back to this post

> 1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
> axles>=3 instead of axles=3
>
Changed
https://wiki.openstreetmap.org/w/index.php?title=Key:maxweight&diff=prev&oldid=1874072
 



> 2. Maxweightrating:
>
> 2.1 At the examples, Poland: This sign is actually an access restriction for 
> all HGVs: hgv=no. By definition in EU laws and most other countries, a heavy 
> goods vehicle is a goods vehicle with a GVWR of 3.5t and above. See the wiki 
> page for Key:hgv for a longer explanation.
>
Right, I modified it (changed recommended tagging to hgv=no and moved to a 
separate section
"related signs")
https://wiki.openstreetmap.org/w/index.php?title=Key%3Amaxweightrating&type=revision&diff=1874076&oldid=1873139

>
> 3. Maxaxleload mentions that weight in USA must always be given in short tons 
> while the maxweight article also mentions pounds. Same with the article about 
> maxbogieweight.
>

Appears to be changed already.

> 4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.
>
I am not sure what is wrong here.

Disclaimer: my maxweight edits activity is done as part of
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 


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

Re: [Tagging] track smoothness/quality

[marc marc]

Le 03.07.19 à 03:10, brad a écrit :
> Thoughts?

4) use smoothness if it suits your needs better
without changing the meaning of a tag used elsewhere in your region
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] track smoothness/quality

[marc marc]

Le 03.07.19 à 03:10, brad a écrit :
> Thoughts?

4) use smoothness if it suits your needs better
without changing the meaning of a tag used elsewhere in your region
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[石野貴之]

Hello.

Tagging schemes for cram schools and tutorial centers have been discussed
very often,
but none of the discussion got to the solid conclusion.

I am strongly concerned about the situation, and requested for comments on
my diary.
ML: https://lists.openstreetmap.org/pipermail/tagging/2019-May/045457.html
English: https://www.openstreetmap.org/user/yumean1119/diary/364867
Japanese: https://www.openstreetmap.org/user/yumean1119/diary/364501

My proposal is the following:
1. Use a well-documented tag for the main tag. I think
office=educational_institution would be the best, but amenity=prep_school
or another tagging is also OK.
2. Then, add education=cram_school or education=tutoring as an auxiliary tag.

When I posted my idea on the discussion page at
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative
There was a comment by Warin61:

--cited from
https://wiki.openstreetmap.org/wiki/Talk:Proposed_Features/Education_Reform_Alternative
--
Because it would be confusing to have educational features under 2 keys
particularly when one of them is named *educational*. Think about teaching
a new mapper, a clear logical order is far easier to learn than one where
some bits are other there while others are in yet another area. Warin61
 (talk
) 08:54, 9 June 2019
(UTC)
--end--

Yeah, I must admit that having two keys in one feature is cofusing.
However, throwing away current tags like amenity=school and promoting to
use education=* tags is much worse. This obviously breaks forward
compatibility. That's why I want to use education=* as a sub tag, not as a
main tag.

I think it's the chance of a lifetime to deepen the discussion about
tagging educational features, because today is the very day someone
chaneged the status at
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative
to abandoned and the original auther Erkinalp reverted the status back to
proposed. This shows he/she has not lost the motivation!

Takayuki Ishino (User: yumean1119)
yumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging