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

[Joseph Eisenberg]

These are mainly meant to be used with tourism=camp_site and
tourism=caravan_site to show the total capacity of the facility, which
might be important for groups. For tourism=camp_pitch it could be used
for large "pitches" that are intended for a group, such as an extended
family. I've seen these where a half-dozen or dozen tents are allowed.

I don't camp by caravan myself, but I think there are occasionally
sites that can be reserved or booked as one location for a group of
several caravans at a national park, so caravans=4 or
capacity:caravans=3 might occasionally be useful even with
tourism=camp_pitch.

Joseph

On 7/4/19, Warin <61sundow...@gmail.com> wrote:
> On 04/07/19 11:47, Graeme Fitzpatrick wrote:
>>
>>
>> On Wed, 3 Jul 2019 at 10:06, Joseph Eisenberg
>> mailto:joseph.eisenb...@gmail.com>> 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=
>>
>> 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?
>>
>>
>> I've never seen an individual caravan site / pitch that will handle
>> more than 1 caravan at a time, so I'm not sure if there's any need for
>> that one?
>>
>> With regard to the number of tents on an individual site, you then get
>> the potential problem of the size of the tent.
>>
>> Let's say that your tent site is 5m x 5m - you can get tents that are
>> that size (& bigger!) so only 1 will fit, or, if a group of people are
>> using 1-man pup tents / swags, they could probably fit 10 tents in
>> that same area!
>>
>> Maybe just leave it as tent & caravan = yes / no, without the numbers
>> / capacity fields?
>>
>
> You have never been camping in Germany. Some camp sites are regimented,
> you are allocated a site/pitch on registering, yes for a tent!
>
> Adels Grove in Queensland also dictates a site... and so does Lawn Hill
> NP site. And there are NP sites in Tassie that do the same, booked sites
> for tents.
>
> So capacity:tents=# and capacity:caravans=# are valid things for camp
> sites.
>
> Camp pitches of larger size, with smaller tents ??? I'd leave it to the
> mapper, if they want they can add the tag.
>
>
>

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

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

[Warin]

On 04/07/19 11:47, Graeme Fitzpatrick wrote:



On Wed, 3 Jul 2019 at 10:06, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> 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=

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?


I've never seen an individual caravan site / pitch that will handle 
more than 1 caravan at a time, so I'm not sure if there's any need for 
that one?


With regard to the number of tents on an individual site, you then get 
the potential problem of the size of the tent.


Let's say that your tent site is 5m x 5m - you can get tents that are 
that size (& bigger!) so only 1 will fit, or, if a group of people are 
using 1-man pup tents / swags, they could probably fit 10 tents in 
that same area!


Maybe just leave it as tent & caravan = yes / no, without the numbers 
/ capacity fields?




You have never been camping in Germany. Some camp sites are regimented, 
you are allocated a site/pitch on registering, yes for a tent!


Adels Grove in Queensland also dictates a site... and so does Lawn Hill 
NP site. And there are NP sites in Tassie that do the same, booked sites 
for tents.


So capacity:tents=# and capacity:caravans=# are valid things for camp 
sites.


Camp pitches of larger size, with smaller tents ??? I'd leave it to the 
mapper, if they want they can add the tag.



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

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

[Graeme Fitzpatrick]

On Wed, 3 Jul 2019 at 10:06, 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=
>
> 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?
>

I've never seen an individual caravan site / pitch that will handle more
than 1 caravan at a time, so I'm not sure if there's any need for that one?

With regard to the number of tents on an individual site, you then get the
potential problem of the size of the tent.

Let's say that your tent site is 5m x 5m - you can get tents that are that
size (& bigger!) so only 1 will fit, or, if a group of people are using
1-man pup tents / swags, they could probably fit 10 tents in that same area!

Maybe just leave it as tent & caravan = yes / no, without the numbers /
capacity fields?

Thanks

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

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

[Joseph Eisenberg]

It’s true that tents=yes/no/ are all used. I suppose it takes a
slightly more complicated SQL query to interpret 
as equivalent to “yes”, but it would be easier for mappers to use just one
key, I think?

Are others ok with tents= and caravans= in addition to
a”yes” and “no” values?

Joseph

On Thu, Jul 4, 2019 at 5:37 AM marc marc  wrote:

> all maxtents=yes are in a "small" area in the north of the USA.
> https://overpass-turbo.eu/s/KrR
> I have send a changeset comment to ask the meaning.
>
> despite that, maxtents= are indeed a bad idea.
>
> capacity:tents is a more common schema
> but I don't really see any advantage with
> tents=yes + capacity:tents=
> versus
> tents=
>
> Regards,
> Marc
>
> Le 03.07.19 à 10:18, Tom Pfeifer a écrit :
> > "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
>
> ___
> 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 - amenity=power_supply

[Mateusz Konieczny]

3 Jul 2019, 22:18 by tagging@openstreetmap.org:

>
>  I don't have enough interest and motivation to try to  fit at least four 
> different kinds of power-providing devices into  one tag
>
>
Note that you are not obligated to follow all (or any) suggestions.
If you prefer you may make simple version without various extra tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=power_supply

[Valor Naram via Tagging]

Like your message (+1) marc marc Original Message Subject: Re: [Tagging] Feature Proposal - RFC - amenity=power_supplyFrom: marc marc To: tagging@openstreetmap.orgCC: I think you were badly inspired when you listened to the supportersof the mega proposals that fail to pass the vote (see history of police=* diaper=* and many other).I think the first version of your proposal was good, just focus on anew tag, without including the unfinished debate on a common scheme for plugs/sockets/cables, without any depreciated tags. these 2 points are big enough in themselves to make each one a next proposal.Le 03.07.19 à 22:18, Michael Brandtner via Tagging a écrit :> I have now canceled the proposal. I really just wanted to establish a > tag for the shore power devices in front of my workplace. I don't have > enough interest and motivation to try to fit at least four different > kinds of power-providing devices into one tag. And I also can't think of > a way to prevent overlap in case of different tags for them.> > > Am 25.06.2019 um 13:32 schrieb Michael Brandtner via Tagging:>> I've now rewritten the whole proposal. To prevent overlap, the idea is >> now to incorporate all devices that provide electrical power under the >> same main tag. A problem I have not solved yet is how to incorporate >> the sub-tags of the tags that would be marked as deprecated?? (mainly >> amenity=charging_station). Am Samstag, 22. Juni 2019, 17:41:08 MESZ hat Michael Brandtner via >> Tagging  Folgendes geschrieben:>> Thank you for your comments so far. I've now written a proposal. https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dpower_supply >> The definition (wording can surely be improved):>> "??A place where you can get electrical power." I've not taken into account your discussion about different socket >> types. This would be the topic for a different proposal about >> improving the power_supply= sub-tag. But this proposal is only about >> establishing the new main tag. I'm looking forward to your comments!??>> ___>> Tagging mailing list>> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging>> ___>> Tagging mailing list>> Tagging@openstreetmap.org>> https://lists.openstreetmap.org/listinfo/tagging> > > ___> Tagging mailing list> Tagging@openstreetmap.org> https://lists.openstreetmap.org/listinfo/tagging> ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - amenity=power_supply

[marc marc]

I think you were badly inspired when you listened to the supporters
of the mega proposals that fail to pass the vote (see history of 
police=* diaper=* and many other).

I think the first version of your proposal was good, just focus on a
new tag, without including the unfinished debate on a common scheme for 
plugs/sockets/cables, without any depreciated tags. these 2 points are 
big enough in themselves to make each one a next proposal.

Le 03.07.19 à 22:18, Michael Brandtner via Tagging a écrit :
> I have now canceled the proposal. I really just wanted to establish a 
> tag for the shore power devices in front of my workplace. I don't have 
> enough interest and motivation to try to fit at least four different 
> kinds of power-providing devices into one tag. And I also can't think of 
> a way to prevent overlap in case of different tags for them.
> 
> 
> Am 25.06.2019 um 13:32 schrieb Michael Brandtner via Tagging:
>> I've now rewritten the whole proposal. To prevent overlap, the idea is 
>> now to incorporate all devices that provide electrical power under the 
>> same main tag. A problem I have not solved yet is how to incorporate 
>> the sub-tags of the tags that would be marked as deprecated?? (mainly 
>> amenity=charging_station).
>>
>> Am Samstag, 22. Juni 2019, 17:41:08 MESZ hat Michael Brandtner via 
>> Tagging  Folgendes geschrieben:
>>
>>
>> Thank you for your comments so far. I've now written a proposal.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dpower_supply 
>>
>>
>> The definition (wording can surely be improved):
>> "??A place where you can get electrical power."
>>
>> I've not taken into account your discussion about different socket 
>> types. This would be the topic for a different proposal about 
>> improving the power_supply= sub-tag. But this proposal is only about 
>> establishing the new main tag.
>>
>> I'm looking forward to your comments!??
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

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

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

[marc marc]

all maxtents=yes are in a "small" area in the north of the USA.
https://overpass-turbo.eu/s/KrR
I have send a changeset comment to ask the meaning.

despite that, maxtents= are indeed a bad idea.

capacity:tents is a more common schema
but I don't really see any advantage with
tents=yes + capacity:tents=
versus
tents=

Regards,
Marc

Le 03.07.19 à 10:18, Tom Pfeifer a écrit :
> "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

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

Re: [Tagging] Feature Proposal - RFC - amenity=power_supply

[Michael Brandtner via Tagging]

I have now canceled the proposal. I really just wanted to establish a 
tag for the shore power devices in front of my workplace. I don't have 
enough interest and motivation to try to fit at least four different 
kinds of power-providing devices into one tag. And I also can't think of 
a way to prevent overlap in case of different tags for them.



Am 25.06.2019 um 13:32 schrieb Michael Brandtner via Tagging:
I've now rewritten the whole proposal. To prevent overlap, the idea is 
now to incorporate all devices that provide electrical power under the 
same main tag. A problem I have not solved yet is how to incorporate 
the sub-tags of the tags that would be marked as deprecated?? (mainly 
amenity=charging_station).


Am Samstag, 22. Juni 2019, 17:41:08 MESZ hat Michael Brandtner via 
Tagging  Folgendes geschrieben:



Thank you for your comments so far. I've now written a proposal.

https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dpower_supply 



The definition (wording can surely be improved):
"??A place where you can get electrical power."

I've not taken into account your discussion about different socket 
types. This would be the topic for a different proposal about 
improving the power_supply= sub-tag. But this proposal is only about 
establishing the new main tag.


I'm looking forward to your comments!
___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging


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


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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[marc marc]

Le 03.07.19 à 17:36, Paul Allen a écrit :
> On Wed, 3 Jul 2019 at 16:16, marc marc wrote:
> Le 03.07.19 à 16:55, Paul Allen a écrit :
>>> What "unsigned" doesn't do is identify how the mapper came 
>>> to any conclusion about the weight
>>> limit or how other mappers may verify it.
>> unsigned just said "no info on the ground"
> The same can be achieved by omitting the tag.   

without a tag, you can't tell if somebody have already check
for a sign or if you need to survey it.
you cannot tell the difference between a lanes=2 road with road markings 
and a lanes=2 road without road markings (see previous thread)

> A fixme is better because quality tools can help mappers  
> see where more information is needed.

No sign on the ground is not an error in osm, it's a fact !
My neighbour did not put the regulatory sign on his new house,
unsigned=addr:housenumber changeset source=survey (so no more need
for other contributors to do a survey the next day)
another day, somebody may add addr:housenumber= changeset 
source=local knowledge or opendata
what do you want a contributor to correct in osm ?
fixme is fully wrong when nothing need to be fixe in osm

the same for a road without lanes marking
the same for a bridge without maxheight sign
none of them is an "stuff to fix in osm"

> an object can end up with maxweight=3.5 + unsigned=maxweight

Yes, it can happen.

> without telling anyone how or why the mapper decided 
> that the maxweight is, in fact, 3.5.

check the source of the changeset that add maxweight=3.5
unsigned=* doesn't try to replace the source tag

> you cannot deduce what the absent sign is about.

I think you read my message a little too quickly.
unsigned=maxspeed is about maxspeed
unsigned=maxheight is about maxheight.
unsigned= is about this key

I just propose to replace a variety of inconsistent tags
by a structured schema for all, for exemple :

maxheight:sign=no (and maybe maxheight=default)-> unsigned=maxheight
lanes:marking=no and lanes:unmarked=yes-lanes=unmarked > unsigned=lanes
nosign=yes (but nobody known for witch sign) -> unsigned=
marking=unmarked (but nobody known for witch sign) -> unsigned=
fixme/note/description=no  sign -> unsigned=key
info=unmarked -> unsigned=

>> Similarly, when I  do a survey and I notice that a house 
>> does not have the USUAL sign indicating  
>> its house number, I can said that the sign is not there.
> Which would be a little annoying around here, because maybe a tenth of 
> the houses do not have numbers, only names.
> Most of those name-only houses have never had numbers. 
> You think it sensible to tag unsigned=addr:housenumber for those?

I was saying "does not have the USUAL sign"
if it's common that houses don't have a addr:housenumber,
it's not very useful to put unsigned=addr:housenumber.
as it's not very useful to put it on a tree or a field.
an app/a contributor can use common sense to be satisfied
with addr:housenumber or addr:housename

I'm not proposing to decide WHEN a contributor should or should
not add the information of a missing sign.
I just propose a unified tag when it DOES add it.

> I don't think it actually solves any issues that are not better handled 
> with a fixme or a source tag, or simply omitting the tag.

do you propose that app like streetcomplete or that contributors who 
have added one of the many tags I listed above add a fixme "nosign, 
maybe something to fix, maybe not" just "in case of" ?
it's noise these fixme that indicates a fact and not a problem to solve.
or do you suggest that the contributors who add these tags don't add 
anything to make it uniform ? It seems to me a solution that has no 
chance of being accepted, check taginfo, some mapper add it.
so the question is: a different tag for each missing sign
or a tag for all ?

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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[Martin Koppenhoefer]

sent from a phone

> On 3. Jul 2019, at 17:14, marc marc  wrote:
> 
> Similarly, when I 
> do a survey and I notice that a house does not have the usual sign 
> indicating its house number, I can said that the sign is not there.


yes, and if they advertize their street address including “snc” it means they 
do not have a housenumber assigned. Here’s a real life example of a trash 
service point:

http://www.amaroma.it/raccolta-differenziata/4210-centri-di-raccolta.html#cdr-8


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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[Paul Allen]

On Wed, 3 Jul 2019 at 16:16, marc marc  wrote:

> Le 03.07.19 à 16:55, Paul Allen a écrit :
> > What "unsigned" doesn't do is identify how the mapper came to any
> > conclusion about the weight
> > limit or how other mappers may verify it.
>
> unsigned just said "no info on the ground"
>

The same can be achieved by omitting the tag.  Possibly supplemented with a
fixme.  A fixme
is better because quality tools can help mappers see where more information
is needed.

the panel may have fallen, stolen or not yet installed,
> the unsigned key says nothing else.
>

It does when, as seems to be implied by you,  an object can end up with
maxweight=3.5 + unsigned=maxweight without telling anyone how or why
the mapper decided that the maxweight is, in fact, 3.5.

Moreover, when you notice that a bridge has no sign, you generally
> cannot deduce anything more than "there is no sign".


Actually, it's worse than that.  Because you cannot deduce what the absent
sign is
about.  Is it an absent sign for a speed limit, or a weight restriction, or
something else?
I'd expect, for modern bridges on modern roads, the speed limit of the road
as appears
on signs somewhere (possibly a long way) before and after the bridge
applies to the
bridge itself.  I'd only expect speed limit signs on the bridge if the
limit is lower than for
the rest of the road.  By your logic, though, I should tag modern bridges
on modern roads
with unsigned=maxspeed.

Similarly, when I  do a survey and I notice that a house does not have the
> usual
>
sign indicating its house number, I can said that the sign is not there.
>

Which would be a little annoying around here, because maybe a tenth of the
houses do
not have numbers, only names.  Most of those name-only houses have never
had numbers.
You think it sensible to tag unsigned=addr:housenumber for those?  Many
houses around
here have numbers without names.  You think it sensible to tag
unsigned=addr:housename
for those?


> another time, with another source (official or local knowledge),
> this information could be completed (no limit, no number, no name,...)
> with another key. the unsigned key doesn't try to solve others issues.
> one type of information -> one key
>

I don't think it actually solves any issues that are not better handled
with a fixme or a
source tag, or simply omitting the tag.

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

[Jmapb via Tagging]

On 7/2/2019 8:20 AM, marc marc wrote:


Le 02.07.19 à 13:38, Joseph Eisenberg a écrit :

There are two similar property tags that describe the presence of a
barbecue (BBQ) grill at another feature such as a campsite or picnic
site.

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

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

If you check taghistory.raifer.tech it's clear that
barbecue_grill=yes/no is older and still slightly more common, but
bbq=yes/no is becoming more common in the past 2 years.

The similar feature tag is amenity=bbq


Is there a reason to pick one of these two tags over the other?

I like having the same string between the main tag for the device
and the key for the caracteristic of a site having this device.
so imho bbq=yes is better


Certainly tagging foo=yes to indicate that amenity=foo exists as part of
another feature is standard practice in many cases (atm, toilets, bar
being the most prominent).

Nonetheless I think bbq=yes is ambiguous. To me, the most natural
interpretation of bbq=* is to indicate whether barbecuing is permitted,
rather than to specify the presence or absence of an on-site bbq apparatus.

Consider the situation brought up in this thread last month:

https://lists.openstreetmap.org/pipermail/tagging/2019-June/046064.html

The question was: how to tag a feature where barbecuing is permitted,
but no fixed bbq grill exists? The best suggestion was
bring_own_bbq=yes. But the combination of bbq=no and bring_own_bbq=yes
seems contradictory. Despite the inconsistent spelling,
barbecue_grill=no + bring_own_bbq=yes makes more sense... slightly more.

I'm afraid the possibilities are complex enough that I'd actually
suggest using a bbq:* namespace, ie:

bbq=yes
bbq:grills=yes/no/1+
bbq:bring_own=yes/no

There's the issue of redefining bbq=yes, which has 219 uses... but those
219 uses are already ambiguous IMO -- the only thing I know for sure is
that barbecuing is permitted there. So I don't actually think this is a
redefinition, just a clarification.

(These subtags could also be used to clarify amenity=bbq, which
according to Joseph Eisenberg at
https://lists.openstreetmap.org/pipermail/tagging/2019-June/046072.html
is already ambiguous on the German version of the wiki, covering both
the grill itself and the area where grilling is allowed.)

Jason


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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[marc marc]

Le 03.07.19 à 16:55, Paul Allen a écrit :
> What "unsigned" doesn't do is identify how the mapper came to any 
> conclusion about the weight
> limit or how other mappers may verify it.

unsigned just said "no info on the ground"
the panel may have fallen, stolen or not yet installed,
the unsigned key says nothing else.
Moreover, when you notice that a bridge has no sign, you generally 
cannot deduce anything more than "there is no sign". Similarly, when I 
do a survey and I notice that a house does not have the usual sign 
indicating its house number, I can said that the sign is not there.

another time, with another source (official or local knowledge),
this information could be completed (no limit, no number, no name,...) 
with another key. the unsigned key doesn't try to solve others issues.
one type of information -> one key

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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[Paul Allen]

On Wed, 3 Jul 2019 at 14:56, Martin Koppenhoefer 
wrote:

>
> "unsigned" means there is no sign on the ground, this would not avoid
> noname=yes or nohousenumber=yes because they state there is no name or
> housenumber, not that it isn't signed.
>

Surely "unsigned" means that the weights can only be positive.  Trucks with
negative weights are
not allowed.  Therefore the data schema can accommodate weights with an
unsigned int.

It also means that the sign, stating that only positive weights are
permitted, does not have a
signature.

What "unsigned" doesn't do is identify how the mapper came to any
conclusion about the weight
limit or how other mappers may verify it.

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

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

[Joseph Eisenberg]

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

Re: [Tagging] extend unsigned to describe "no info on the ground" for a key

[Martin Koppenhoefer]

Am Mi., 3. Juli 2019 um 15:48 Uhr schrieb marc marc <
marc_marc_...@hotmail.com>:

> Le 13.06.19 à 15:15, Tobias Zwick a écrit :
> > it semantically refers to the <...> key
>
> it is a problem common to many keys but there is no overall coherence.
>
> extend unsigned used for name with unsigned=
> is easy to make a link betweeen the key and "no info on the ground".
>
> it avoids:
> - using funny no*=yes
> - namespaces without any coherence between usecase
> - to be generalizable : any key can be filled in this way without having
> to discuss the value of the key or without having to code a difference
> rule in the tools that can benefit from it (I think for example of
> streetcomplete)




"unsigned" means there is no sign on the ground, this would not avoid
noname=yes or nohousenumber=yes because they state there is no name or
housenumber, not that it isn't signed.

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

[Tagging] extend unsigned to describe "no info on the ground" for a key

[marc marc]

Le 13.06.19 à 15:15, Tobias Zwick a écrit :
> it semantically refers to the <...> key

it is a problem common to many keys but there is no overall coherence.

extend unsigned used for name with unsigned=
is easy to make a link betweeen the key and "no info on the ground".

it avoids:
- using funny no*=yes
- namespaces without any coherence between usecase
- to be generalizable : any key can be filled in this way without having 
to discuss the value of the key or without having to code a difference 
rule in the tools that can benefit from it (I think for example of 
streetcomplete)

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

[Tagging] disclosing grant (was Re: Maxweight wiki page changes)

[Mateusz Konieczny]

I was unsure how much the grant that I disclosed in
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 
 
should be mentioned (it is mostly offtopic here and mentioning it everywhere 
would be 
spammy) but to explain situation in a bit of detail

- "it is clearly that the success of what Mateusz is working on is in the end 
dependent
on you accepting and merging it" - I will be still paid in case that what I 
will make will be
rejected and not included in StreetComplete (obviously, not applicable to cases 
with
broken patches rejected as not working). In such case I would release fork 
(in case of patches rejected for legitimate reasons it would be done solely to
confirm that I actually implemented it but for some unforeseen reason it turned 
out to be a bad idea).

- "should be disclosing that Mateusz is being paid to work on your project"
If anyone should be mentioning this - then it should be me.

- https://github.com/westnordost/StreetComplete/issues/361 
 was proposed and 
planned
before even idea of the grant appeared and I deliberately focused on ideas that 
predated grant,
especially for ones that involve some tagging decisions
Note posting date of
https://wiki.openstreetmap.org/wiki/Talk:Key:maxweight#Support_for_.22no_weight_limit.22
 


- selection of things that I planned to do was entirely on my side and with 
rare exceptions of explicitly
listed tasks (like bypassing of censorship of Overpass Turbo in Russia) I am 
completely 
free to change/modify tasks that I am working on. In case of someone else 
starting their
own work or presenting good ideas why things from 
https://github.com/westnordost/StreetComplete/issues 
 should not be implemented
I have no problem with changing what will be done.

I can quote something like
 https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 
 under 
every posting
tangentially related to implemented PRs but I am not convinced that it would be 
a good idea
(I even included it in my initial mail draft and deleted it as a spammy 
self-promotion offtopic to this list).
(should I also disclose that mentioning that my work on StreetComplete is 
sponsored by this
grant is encouraged by my grant?)

What would you think would be appropriate way of handling this?

Mention that it is related to a grant and include link to
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 
 ?

Is anything missing in this diary entry?

Do something else?

3 Jul 2019, 13:03 by si...@poole.ch :

> Could both of you be a bit more transparent about the situation. You
> should be disclosing that Mateusz is being paid to work on your project
> and while not a direct employer-employee relationship, it is clearly
> that the success of what Mateusz is working on is in the end dependent
> on you accepting and merging it, and so you are not commenting on just
> random third party wiki edits.
>
> Am 03.07.2019 um 12:52 schrieb Tobias Zwick:
>
>> Reviewed it. That is some impressive work, thank you for this!
>>
>> A few remarks:
>>
>> 1. Maxweight
>>
>> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
>> It suggests itself.
>>
>> 1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
>> axles>=3 instead of axles=3
>>
>> 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.
>>
>> 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.
>>
>> 4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.
>>
>> Tobias 
>>
>>
>> On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
>>  wrote:
>>
>>> There were recently significant changes at OSM Wiki page about
>>> maxweight tag
>>> and related tags. Review is welcomed.
>>>
>>> See
>>> https://wiki.openstreetmap.org/wiki/Key:maxweight
>>>  - major changes
>>> included fixing mistakes
>>> in examples, adding additional examples, reformatting, documenting how
>>> object without max weight
>>> sign may be tagged
>>>
>>> https://wiki.openstreetmap.org/wiki/Key:maxweightrating
>>>  - page itself
>>> is quite new. Recent changes
>>> included 

Re: [Tagging] Maxweight wiki page changes

[Simon Poole]

Could both of you be a bit more transparent about the situation. You
should be disclosing that Mateusz is being paid to work on your project
and while not a direct employer-employee relationship, it is clearly
that the success of what Mateusz is working on is in the end dependent
on you accepting and merging it, and so you are not commenting on just
random third party wiki edits.

Am 03.07.2019 um 12:52 schrieb Tobias Zwick:
> Reviewed it. That is some impressive work, thank you for this!
>
> A few remarks:
>
> 1. Maxweight
>
> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
> It suggests itself.
>
> 1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
> axles>=3 instead of axles=3
>
> 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.
>
> 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.
>
> 4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.
>
> Tobias 
>
>
> On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
>  wrote:
>> There were recently significant changes at OSM Wiki page about
>> maxweight tag
>> and related tags. Review is welcomed.
>>
>> See
>> https://wiki.openstreetmap.org/wiki/Key:maxweight
>>  - major changes
>> included fixing mistakes
>> in examples, adding additional examples, reformatting, documenting how
>> object without max weight
>> sign may be tagged
>>
>> https://wiki.openstreetmap.org/wiki/Key:maxweightrating
>>  - page itself
>> is quite new. Recent changes
>> included reformatting and new examples
>>
>> https://wiki.openstreetmap.org/wiki/Key:maxaxleload
>>  - smaller
>> changes, but for completeness:
>> fixing mistake and additional examples
>>
>> Again, review is welcomed!
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

Reviewed it. That is some impressive work, thank you for this!

A few remarks:

1. Maxweight

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

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

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.

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.

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

Tobias 


On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
 wrote:
>There were recently significant changes at OSM Wiki page about
>maxweight tag
>and related tags. Review is welcomed.
>
>See
>https://wiki.openstreetmap.org/wiki/Key:maxweight
> - major changes
>included fixing mistakes
>in examples, adding additional examples, reformatting, documenting how
>object without max weight
>sign may be tagged
>
>https://wiki.openstreetmap.org/wiki/Key:maxweightrating
> - page itself
>is quite new. Recent changes
>included reformatting and new examples
>
>https://wiki.openstreetmap.org/wiki/Key:maxaxleload
> - smaller
>changes, but for completeness:
>fixing mistake and additional examples
>
>Again, review is welcomed!

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

Re: [Tagging] track smoothness/quality

[Martin Koppenhoefer]

sent from a phone

> On 3. Jul 2019, at 07:16, Tomas Straupis  wrote:
> 
> How come? You are pushing the changing of entire water tagging schema!


this is an off topic comment here and is not comparable because with water 
tagging the meaning of tags should not be changed, but different tags 
(compatible because different key) would be additionally added.

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

[Tagging] Maxweight wiki page changes

[Mateusz Konieczny]

There were recently significant changes at OSM Wiki page about maxweight tag
and related tags. Review is welcomed.

See
https://wiki.openstreetmap.org/wiki/Key:maxweight 
 - major changes included 
fixing mistakes
in examples, adding additional examples, reformatting, documenting how object 
without max weight
sign may be tagged

https://wiki.openstreetmap.org/wiki/Key:maxweightrating 
 - page itself is 
quite new. Recent changes
included reformatting and new examples

https://wiki.openstreetmap.org/wiki/Key:maxaxleload 
 - smaller changes, but 
for completeness:
fixing mistake and additional examples

Again, review is welcomed!
___
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] track smoothness/quality

[Mark Wagner]

On Tue, 2 Jul 2019 19:10:24 -0600
brad  wrote:
 
> Unfortunately, the wiki for highway, in the section for track says: "
> To describe the quality of a track, see tracktype 
> =*. "
> But, as described in the wiki,  tracktype is not very relevant to the 
> western US, since the first sentence of the description is 
> Solid/Mostly*/Soft.  Perhaps relevant to the English countryside, but 
> the roads around here are usually Solid, but could be 
> smoothness:very_horrible.   It seems redundant with surface=* also.
> It looks like the common usage is to just use tracktype intuitively 
> (grade5 is 4wd even if it's Solid), and ignore the wiki & the
> smoothness tag.  Unfortunately its usage is inconsistent.  I see
> roads that are clearly (by onsite inspection) 4wd, tagged as grade2
> and some graded gravel roads tagged as grade2.
> Tracktype could be sufficient if clarified, and if we were starting
> from scratch that's what I would prefer.
> 
> As I see it, two paths forward to improve this situation.
> 1) Change the wiki for highway so it mentions Smoothness=*, and 
> de-emphasize  tracktype=*
> 2) Take the leading sentence mentioning Solid/Soft out of the
> tracktype description (or de-emphasize it), and add more verbage
> about high clearance or 4 wheel drive.    There is some discussion on
> the key:tracktype discussion page about adding grade6+.
> 3) Ignore the wiki, and just use tracktype.   I see in the discussion 
> page that is what many are doing.

Option 3 won't work.  Locally, tracks come in two basic types:

1) A logging road created by a work crew with a bulldozer.  Cut down
any trees, scrape off any remaining vegetation, level the road
side-to-side, and call it done.  These roads range in quality from
"easily passable by a passenger car" to "high-clearance
four-wheel-drive vehicle required".

2) A ranch road created by a truck driving the same route repeatedly
for years.  These are generally fairly smooth, but the older ones are
only passable by a high-clearance truck because of the central ridge
between the tracks.

According to the wiki, these are uniformly "grade5" ("Almost always an
unpaved track lacking additional materials, same surface as surrounding
terrain."), although calling them "soft" is misleading, since the local
soil produces a rock-hard surface during the summer and fall (and a
muddy one during spring melt). They're tagged pretty much at random as
anything from "grade1" to "grade5".

-- 
Mark

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

Re: [Tagging] track smoothness/quality

[Warin]

On 03/07/19 11:10, brad wrote:

A pretty standard nomenclature on maps in the US for unpaved roads is
Improved Road
Unsurfaced Road (High Clearance)
Four Wheel Drive
Other variations exist , but not too dissimilar.
Pretty simple and anyone who spends time in the mountains or forest 
gets a feel for what it means and has an idea what to expect.   OSM is 
a mess in this regards.   The inconsistency make it difficult if not 
impossible to render a good map.


As I read the OSM wiki,  smoothness=* is the relevant tag to 
distinguish between a 2wd road, a high clearance road, and a 4 wheel 
drive road.    Surface is important too, but isn't sufficient if it's 
dirt/unpaved/ground.


There is use of 4wd_only=yes/no see 
https://wiki.openstreetmap.org/wiki/Key:4wd_only


And yes the wiki/osm is a bit of a mess.

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