Re: [Tagging] Creating shop=caravan

[Mark Wagner]

On Tue, 8 Jan 2019 07:54:00 +1000
Graeme Fitzpatrick  wrote:

> Possibly something like caravan:type=caravan / motorhome / Winnebago /
> camper trailer etc, but then you get to the problem of what is
> difference between a camper van, motorhome & Winnebago?

In the (US) industry, the terminology for self-propelled RVs is "Class
A", "Class B", and "Class C":

Class A: An integrated unit with the driving area being part of the
living area, usually built on a custom or bus chassis.  I think this
corresponds to your "Winnebago".

Class B: Sometimes referred to as a "van conversion", this, as the
name implies, usually uses a full-sized van as the starting point for
construction. I think this corresponds to your "camper van".

Class C: Built on a truck chassis with little or no connection between
the driving and living areas.  I think this corresponds to your
"motorhome".

On the non-self-propelled side of things, the split is (roughly) "Fifth
wheel", "travel trailer", and "popup".

Fifth wheel: Connects to the tow vehicle via a fifth-wheel hitch.
Usually the largest and heaviest trailers.

Travel trailer: A hard-sided trailer that connects to the tow vehicle by
a ball hitch.

Popup: A collapsible, usually soft-sided trailer that connects to the
tow vehicle by a ball hitch.

The self-propelled/non-self-propelled split is important enough to be
worth tagging.  It's also, at least in the US, very common for a dealer
to sell one or the other, but not both.  On the other hand, it's very
common for a dealer to sell both Class A and Class C units, or both
fifth-wheels and travel trailers.

-- 
Mark

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

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

[Marc Gemis]

While I was first thinking of brand like Warin, I think this is the
better solution. Just as, we do not map the share holders of companies
(even when they are other companies) on shops, man_made=works object
etc., we typically do not map properties of the operator (besides
brand).

m.

On Tue, Jan 8, 2019 at 9:22 AM Topographe Fou  wrote:
>
> Personnaly I don't think I would map umbrella organisations... I would put 
> operator and operator:wikidata and let Wikidata update partnerships between 
> associations. It is not a property of the kindergarten, it is a property of 
> the operator.
>
> LeTopographeFou
>
>   Message original
> De: t.pfei...@computer.org
> Envoyé: 7 janvier 2019 11:14 PM
> À: tagging@openstreetmap.org
> Répondre à: tagging@openstreetmap.org
> Objet: Re: [Tagging] Tagging of amenity=kindergarten operated by charitable 
> operators and organisations
>
> 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
> ___
> 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] Tagging of amenity=kindergarten operated by charitable operators and organisations

[Martin Koppenhoefer]

sent from a phone

> On 7. Jan 2019, at 19:08, Volker Schmidt  wrote:
> 
> 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.


these are not access tags, they convey a connection of a feature to a specific 
religion, similar as a place of worship. I would expect them to accept other 
children as well, but often the parents would not want to send their offspring 
to a place with a strong influence of a foreign religion. There are also edge 
cases, e.g. a kindergarten operated by scientology in Germany: scientology is 
not a charity in Germany and I am not sure whether they are recognized as a 
religion, but I think they are not, while in other countries they might be


Cheers, Martin 




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

Re: [Tagging] service

[Simon Poole]

No magic, the preset has curated values for the subtags (which is
naturally possible in iD too) most of them have historically been
gleaned from the wiki or from actual use.  The upside and the downside
of this is that they are curated, so there is always a certain lag
between a value being used in the wild and it turning up in the preset.

Simon

Am 08.01.2019 um 15:50 schrieb Bryan Housel:
>> On Jan 8, 2019, at 2:30 AM, Simon Poole  wrote:
>>
>> Am 07.01.2019 um 16:12 schrieb Bryan Housel:
>>> ...
>>> On “both is OK”. the `service:vehicle` issue was because we can’t use the 
>>> same key `service=*` to contain both things like `tyres` (a few thousands) 
>>> and `driveway` (a few millions).  Sorry, but the `service=tyres` has to go. 
>>>  A few thousand uses is not “established tagging practice”.  And I doubt 
>>> that that usage was ever discussed here or proposed either.  If it was, I 
>>> missed the proposal where someone said “lets put tyres in a tag already 
>>> used 3 million times for something else”.  My “no” vote on such a thing 
>>> would not have mattered anyway.
>>>
>>> ...
>> This is not a given, your problem exists just as a consequence of iD
>> retrieving tag values from taginfo and how iD presets are designed.
>> Everything else (as in any other editor) definitely doesn't have an
>> issue with sub-tag keys using the same name as there is more than enough
>> context to be able to differentiate the different usages. 
> How does Vespucci work around this?
> Do you:
> - just build in lists of what all the acceptable values are that people are 
> allowed to enter in different contexts?
> - or let people type anything but expect them to already know what the good 
> values are from wiki research?
> - or just don’t support the `service=` key in some contexts?
> - or something else?
>
> (skipping the rest of the email about `sells=`.. it’s way off topic)
>
> Thanks, Bryan
>
>
> ___
> 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] Facts and opinions

[Simon Poole]

Am 08.01.2019 um 23:55 schrieb Martin Koppenhoefer:
> ...
> With current tools there is no tag completion for the individual
> values in lists, while the alternative already works.
>
Value completion has for lists has woked since ages in Vespucci (you
normally would use the form interface where you just select an option,
but the conventional tag - value UI supports lists).


> It is also simpler for data consumers, and as long as you want to
> distinguish only yes/no you could get along with just one bit for storage.
>
That is nonsense as you have to store the key string in some form. In
practical terms any database will use a key-value store for such tags
with a number of associated issues.

Simon

>
> Cheers, Martin 
>
> ___
> 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] Facts and opinions

[Martin Koppenhoefer]

sent from a phone

> On 8. Jan 2019, at 14:35, Simon Poole  wrote:
> 
> I'm not convinced that we really want to model such a level of detail in the 
> first place, but using a small set of common keys for facilities with similar 
> purpose has obvious advantages over a multitude of special purpose keys that 
> are difficult to discover.


I do not believe either that we would want to map generally at such level of 
detail, but I can imagine people being interested in a particular detail, e.g. 
https://taginfo.openstreetmap.org/keys/drink%3Aclub-mate (or e.g. postage 
stamps, or public transport tickets)
and for these few exceptions (things with sufficient supporters and interest to 
“take off”) I am not sure a generic tag with multiple values is better than a 
specific property. A drink:club-mate=yes tag is less inviting to tag the 
availability of milk, cherry lemonade or beer than a generic tag 
available_drinks=club-mate, which will most likely lead to long lists soon.

With current tools there is no tag completion for the individual values in 
lists, while the alternative already works.

It is also simpler for data consumers, and as long as you want to distinguish 
only yes/no you could get along with just one bit for storage.


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

Re: [Tagging] Facts and opinions

[Graeme Fitzpatrick]

On Tue, 8 Jan 2019 at 23:36, Simon Poole  wrote:

> I'm not convinced that we really want to model such a level of detail in
> the first place,
>
Agree with you there!

If the place is a shop=tyres, isn't that really all that OSM needs to say?

After that, isn't it up to "you" to make a simple phone call, or look at
their linked website, to check if they sell motorbike or bicycle tyres?

& where do we stop with extreme details?

As Martin put it

"or sells=tyres:white:motorcycle..."

sells=tyres:car:brand_a:black;brand_a:white_wall;brand_a:white_lettering:brand_b:black,,,

Then do we start on tyre sizes?

tyres:car:brand_a:195_65r15 for literally the 1000s (10s of 1000s?) of
variants that any tyre shop will carry?

Where does it end?

Thanks

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

Re: [Tagging] How do you say "no" with semicolon'ed lists? Re: Facts and opinions

[Simon Poole]

Am 08.01.2019 um 16:25 schrieb Rory McCann:
> On 08/01/2019 08:30, Simon Poole wrote:
>> and yes you could even document that something is -not- sold in a
>> structured fashion.
>
> How do you do that? To me "sells:blah=no" is clear: that blahs are, by
> default, sold in this type of thing, but aren't here. Is there a
> standard way to do that with semicolon'ed values?
>
You don't,  just as you wouldn't set the other 23 electronic purses
values to "no" for a shop that only accepts one specific type (to use
the granddaddy of the nonsense, the payment scheme).

I really don't think you can extrapolate from it making sense requiring
to be able to set "no" for individual overall attributes of an object
(say oneway=no) to long lists of goods and services for which in
practical terms nobody is going to enumerate all possible values and set
them to "no" if they are not offered at the facility.

Simon





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

Re: [Tagging] How do you say "no" with semicolon'ed lists? Re: Facts and opinions

[Paul Allen]

On Tue, 8 Jan 2019 at 15:27, Rory McCann  wrote:

>
> How do you do that? To me "sells:blah=no" is clear: that blahs are, by
> default, sold in this type of thing, but aren't here. Is there a
> standard way to do that with semicolon'ed values?
>

Yes.  You list all the things that are sold there and omit blah from that
list.

Admittedly, that leaves uncertainty: is blah unlisted because the mapper
got tired of typing
in all the items sold, or because the mapper is unsure, or because blah is
definitely not
sold there despite expectations that it is the type of shop that would sell
it.

The uncertainty could be resolved for consumers that run algorithms by
using "!blah" but would
likely be misinterpreted by consumers that are not versed in computer
programming.

Or, assuming that we have a sells=* tag then, we could add a does_not_sell
tag.

It's not insoluble using lists.  It's a matter of which approach works best
for all concerned.

-- 
Paul


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

[Tagging] How do you say "no" with semicolon'ed lists? Re: Facts and opinions

[Rory McCann]

On 08/01/2019 08:30, Simon Poole wrote:

and yes you could even document that something is -not- sold in a
structured fashion.


How do you do that? To me "sells:blah=no" is clear: that blahs are, by 
default, sold in this type of thing, but aren't here. Is there a 
standard way to do that with semicolon'ed values?



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

Re: [Tagging] service

[Bryan Housel]

> On Jan 8, 2019, at 2:30 AM, Simon Poole  wrote:
> 
> Am 07.01.2019 um 16:12 schrieb Bryan Housel:
>> ...
>> On “both is OK”. the `service:vehicle` issue was because we can’t use the 
>> same key `service=*` to contain both things like `tyres` (a few thousands) 
>> and `driveway` (a few millions).  Sorry, but the `service=tyres` has to go.  
>> A few thousand uses is not “established tagging practice”.  And I doubt that 
>> that usage was ever discussed here or proposed either.  If it was, I missed 
>> the proposal where someone said “lets put tyres in a tag already used 3 
>> million times for something else”.  My “no” vote on such a thing would not 
>> have mattered anyway.
>> 
>> ...
> 
> This is not a given, your problem exists just as a consequence of iD
> retrieving tag values from taginfo and how iD presets are designed.
> Everything else (as in any other editor) definitely doesn't have an
> issue with sub-tag keys using the same name as there is more than enough
> context to be able to differentiate the different usages. 

How does Vespucci work around this?
Do you:
- just build in lists of what all the acceptable values are that people are 
allowed to enter in different contexts?
- or let people type anything but expect them to already know what the good 
values are from wiki research?
- or just don’t support the `service=` key in some contexts?
- or something else?

(skipping the rest of the email about `sells=`.. it’s way off topic)

Thanks, Bryan


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

Re: [Tagging] Facts and opinions

[Simon Poole]

Inconsistent tagging is inconsistent tagging, don't think that is really
relevant for this discussion, inconsistent tagging schemes however are
on topic.

I'm not convinced that we really want to model such a level of detail in
the first place, but using a small set of common keys for facilities
with similar purpose has obvious advantages over a multitude of special
purpose keys that are difficult to discover.

Simon

Am 08.01.2019 um 13:55 schrieb Martin Koppenhoefer:
>
> Am Di., 8. Jan. 2019 um 08:31 Uhr schrieb Simon Poole  >:
>
> To hypothesize on some of the stuff floating around, obviously
> there is
> a desire to document exactly what kind of stuff a shop sells, so
> people
> have proposed stuff like
>
> motorcycle:tyres=yes
>
> service:tyres:car=yes
>
> service:bicycle:tyres=yes
>
> a hodgepodge of different ways of tagging and potential for 100s
> of keys.
>
> But it could be so simple:simply structure the value space.
>
> All of the above could be:
>
> sells=tyres:motorcycle;tyres:cars;tyres:bicycle;tools:cars
>
>
>
> or sells=motorcycle:tyres;car:tyres
> or sells=car_tyres;motorcycle_tyres
> or sells=tyres:white:motorcycle...
>
>
> what makes you believe there will be less hodgepodge when we shift
> more information into the values? Look at your own example, there's a
> standardization issue with plural (cars) vs. singular (motorcycle,
> bicycle). Freeform tagging always will bring us also a lot of variants.
>
> If we open the sells="long list" box the only thing that will help us
> maintain a minimum of oversight will probably be the 255 char limit.
> On the other hand I can already imagine people inventing abbreviation
> codes to cram more things into the values.
>
> I am not a CS person, and if the pros agree that overall, value lists
> are better than distinct properties, I will happily accept this, but
> currently I see issues with both. Inconsistent tagging can occur just
> as well in value lists.
>
> Cheers,
> Martin
>
> ___
> 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] Facts and opinions

[Martin Koppenhoefer]

Am Di., 8. Jan. 2019 um 08:31 Uhr schrieb Simon Poole :

> To hypothesize on some of the stuff floating around, obviously there is
> a desire to document exactly what kind of stuff a shop sells, so people
> have proposed stuff like
>
> motorcycle:tyres=yes
>
> service:tyres:car=yes
>
> service:bicycle:tyres=yes
>
> a hodgepodge of different ways of tagging and potential for 100s of keys.
>
> But it could be so simple:simply structure the value space.
>
> All of the above could be:
>
> sells=tyres:motorcycle;tyres:cars;tyres:bicycle;tools:cars
>
>

or sells=motorcycle:tyres;car:tyres
or sells=car_tyres;motorcycle_tyres
or sells=tyres:white:motorcycle...


what makes you believe there will be less hodgepodge when we shift more
information into the values? Look at your own example, there's a
standardization issue with plural (cars) vs. singular (motorcycle,
bicycle). Freeform tagging always will bring us also a lot of variants.

If we open the sells="long list" box the only thing that will help us
maintain a minimum of oversight will probably be the 255 char limit. On the
other hand I can already imagine people inventing abbreviation codes to
cram more things into the values.

I am not a CS person, and if the pros agree that overall, value lists are
better than distinct properties, I will happily accept this, but currently
I see issues with both. Inconsistent tagging can occur just as well in
value lists.

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

[Tagging] OSM Notes too! Re: Changeset tag for issue closing

[Rory McCann]

On 07/01/2019 23:51, Bryan Housel wrote:
So I’m thinking of introducing changeset tags like 
“closes:x=123;456;789” where x can be a tracking service like 
“keepright”, “osmose”, “improveosm”, “maproulette” or any other issue 
tracker we want to connect iD to.


This is a good idea! You could include OSM notes too. I've often 
wondered if an editor could easily close an OSM note based on the 
current/last changeset, it could add this tag to the changeset, then 
leave a comment on the note ("This has been closed by changeset NNN") 
and close it.



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

Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

[Janko Mihelić]

I think we need to map peninsulas in three ways, as nodes, areas, and ways.

Areas when the land border is obvious. Nodes for little ones, when you
don't have time to draw an area and the shape of the peninsula is obvious.
Then there are ways, when the peninsula is huge, or when the land border
isn't obvious, like the Italian peninsula or the Peninsula of India. I made
a proposal for mapping peninsulas as ways:

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

Janko

On Sat, Jan 5, 2019, 23:10 Christoph Hormann  wrote:

>
> For understanding of the Florida physical geography - Cape Canaveral is
> located here
>
> https://www.openstreetmap.org/node/4887735121
>
> USGS topos identify another cape - unmapped in OSM - slightly northwest
> called the 'False Cape' (somewhat generic term for capes that are
> likely mistaken for the real thing from the sea) near here:
>
> https://www.openstreetmap.org/node/5316727559
>
> The area Cape Canaveral AFS is built on
>
> https://www.openstreetmap.org/relation/7384620
>
> is called Canaveral Peninsula (unmapped in OSM - see USGS topos as well)
> which is part of Merritt Island.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Tagging of amenity=kindergarten operated by charitable operators and organisations

[Topographe Fou]

Personnaly I don't think I would map umbrella organisations... I would put 
operator and operator:wikidata and let Wikidata update partnerships between 
associations. It is not a property of the kindergarten, it is a property of the 
operator.

LeTopographeFou

  Message original  
De: t.pfei...@computer.org
Envoyé: 7 janvier 2019 11:14 PM
À: tagging@openstreetmap.org
Répondre à: tagging@openstreetmap.org
Objet: Re: [Tagging] Tagging of amenity=kindergarten operated by charitable 
operators and organisations

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