date:20190826

26 Aug 2019, 23:55 by graemefi...@gmail.com:

>
>
> On Tue, 27 Aug 2019 at 01:53, MARLIN LUKE <> luke.mar...@viacesi.fr 
> > > wrote:
>
>> I'm going to map a small dog park where there are obstacles for agility 
>> training, and I'm not sure if I should use sport=dog_training[1] or not.
>>
>
> Would leisure=dog_park > 
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Ddog_park 
> >  not cover it?
> "> Sometimes there is an obstacle track for the dogs."
>

And obstacle track itself may be additionally
mapped, as property or object inside
(like playground=sandpit).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Add amenity=childcare to Map Features?

On Tue, 27 Aug 2019 at 13:31, Joseph Eisenberg 
wrote:

> Anyone else have any opinion, in favor or against adding
> amenity=childcare to the wiki page Map Features, and to
> Template:Map_Features:amenity?
>

Can't see any problems, thanks, Joseph.

Thanks

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

Re: [Tagging] Add amenity=childcare to Map Features?

2019-08-26 Thread Joseph Eisenberg

Anyone else have any opinion, in favor or against adding
amenity=childcare to the wiki page Map Features, and to
Template:Map_Features:amenity?

If there are any concerns, I can make a proposal to discuss it fully,
but if no one objects after 2 weeks, then I will add it. (Unless
anyone objects to this process)

On 8/25/19, Valor Naram  wrote:
> why not. Babykarte has also support for `amenity=childcare`
>
>
>  Original Message 
> Subject: [Tagging] Add amenity=childcare to Map Features?
> From: Joseph Eisenberg
> To: "Tag discussion, strategy and related tools"
> CC:
>
>
>> The tag amenity=childcare is fairly popular (used 17,000 times), and
>> it's supported by the iD editor and the Openstreetmap-carto rendering.
>>
>> Should this tag be added to the wiki page Map Features?
>>
>> The original proposal wasn't supported because some people thought
>> that amenity=kindergarten should be used for all types of childcare,
>> not only preschools/kindergartens. This seems to be the common
>> situatoin in Germany, but may not match they types of daycare /
>> childcare / preschool facilities available in other countries. For
>> example, in the USA most preschools do not take older children after
>> school; such after-school care is usually provided by separate
>> programs.
>>
>> Wiki page: https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dchildcare
>> Proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/childcare
>> Compare to Kindergarten:
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dkindergarten
>>
>> ___
>> 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] landcover dune or land form dune


On 26/08/19 21:27, Paul Allen wrote:
On Mon, 26 Aug 2019 at 04:52, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


There seems to be confusion about what the key "landcover" means,
because recently there have also been pages created for
landcover=water and landcover=hedge as well.


I'm in no way justifying any of the landcover=* tags that user has 
invented, but I can
see from his edit comments why he invented landcover=hedge.  He either 
didn't read
about, or did not like, barrier=hedge + area=yes so came up with 
landcover=hedge to
use to represent that situation.  Whatever his reason, he seems rather 
detached from

reality and insulates himself with a thick layer of Dunnnig-Kruger.

This also brings up the question: is it appropriate to edit pages like
this to mention the more common tags at the top, e.g. natural=dune,
natural=sand? Often other editors are unhappy when I add something
like "Consider using the more common tags natural=dune or
natural=sand" - but if anyone can create a Tag: or Key: page, it seems
important that similar and synonymous tags are mentioned at the top.

As this page presents the values as a table then possibly the alternate 
tags can be a separate column in the table?
Should these alternative also be presented in a similar fashion on the 
pages presented as alternatives?


Even though it may trigger an edit war by this user like this one, go 
for it.




Think the user has gained some perspective..
https://forum.openstreetmap.org/viewtopic.php?pid=760094#p760094

So removal of landcover=dune might 'succeed'.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover dune or land form dune

On 26/08/19 23:18, Joseph Eisenberg wrote:

Yes, I agree that for something like landcover=hedge an even stronger
warning is needed.

Some context for why Warin and I are talking about this: The second
section of the key page Key:produce has long mentioned the
differences between produce=* and product=*.

I added to that section, mentioning that crop=* is used more
frequently than produce=* to specify the annual crops grown on
farmland, and trees=*, used more frequently than produce=* to specify
the trees found in an orchard. I probably should have mentioned that
aquaculture=* is the more common tag to specify the type of organisim
in a landuse=aquaculture feature (e.g. shrimp).

But this addition was first reverted, and after I restored it, now it
has been moved it to a "See Also" section. I disagree with this. if we
are going to mention the difference between produce=* and product=*,
there should be a mention of the other tags, otherwise it appears that
product=* is the only similar or overlapping or synonymous tag that
needs to be considered before picking produce=*.

The addition was between the 'disambiguation of produce and product' and
external links that give further information on the 'disambiguation of produce
and product'.
As such it broke the information structure and the function of that section.

If cop and tree needs to be mentioned high in the order of the produce page
then produce needs to be similarly mentioned on the crop and tree page.

There was also a statement added that "crop=* can not be used for all
produce=*, but produce=* can be used for all crop=*" which is not
accurate, based on usage of the tags in the database.

Based on the descriptions of 'crop' and 'produce', 'crop' is a subset of
'produce'. Not a matter of frequency of occurrence.

I would prefer that a proposal be made to deprecate a key (eg to
replace crop=*, trees=* and aquaculture=* with produce=*), if this is
the intention, rather than removing or de-emphasizing factual
information that does not fit a certain narrative.

Then propose it.

https://wiki.openstreetmap.org/wiki/Talk:Key:produce#Crop_should_not_be_added_to_the_disambiguation_of_produce_vs_product_section

On 8/26/19, Paul Allen wrote:

On Mon, 26 Aug 2019 at 13:18, Joseph Eisenberg
wrote:

I agree, Paul.
The most important things on a wiki page are 1) The description of the
tag: what sort of feature or property does it represent and 2) How
does one distinguish it from overlapping tags? Both of these should be
in the first paragraph / section.

For example, see highway=raceway:
(https://wiki.openstreetmap.org/wiki/Tag:highway=raceway)
"A racetrack for motorised racing, eg cars, motorbikes and karts.
For cycling, running, horses, greyhounds etc, use leisure=track."

highway=unclassified
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
"The tag highway=unclassified is used for minor public roads typically
at the lowest level of the interconnecting grid network. Unclassified
roads have lower importance in the road network than {{tag|tertiary}}
roads, and are not residential streets or agricultural tracks"

For those examples, that is OK. But those are along the lines of "this
tag applies to this particular situation, there are similar situations
where
a different tag should be used." In the case of landcover=hedge it's
more of "This is a bad tag. Use this instead." (I paraphrase, you'd
phrase it more diplomatically) and should be in its own section right
at the very start. With a warning icon. Because once you know that,
there is no point reading the rest of it.

--
Paul

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

Re: [Tagging] Agility park for dogs

On Tue, 27 Aug 2019 at 01:53, MARLIN LUKE  wrote:

> I'm going to map a small dog park where there are obstacles for agility
> training, and I'm not sure if I should use sport=dog_training[1] or not.
>

Would leisure=dog_park
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Ddog_park not cover it?
"Sometimes there is an obstacle track for the dogs."

Thanks

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

Re: [Tagging] Parking spaces for car charging

On Mon, 26 Aug 2019 at 23:47, Martin Koppenhoefer 
wrote:

>
> > On 26. Aug 2019, at 13:54, Paul Allen  wrote:
> >
> > Third problem is that although the ones my local supermarket recently
> installed have
> > signs (which,so far, are being completely ignored) saying they are only
> for charging,
>

On Mon, 26 Aug 2019 at 23:42, Martin Koppenhoefer 
wrote:

>
> Is it really „parking“?

Yes, I would say that they are primarily a parking space. Yes, you could
plug your car in for 5 minutes while you go in to the shops & get a loaf of
bread, bottle of milk & the morning paper, but that would be pretty
pointless (at least with the current (sorry! :-)) type of chargers, which
take several hours to charge a car). It would be the same as pulling into a
petrol station & putting 1l of fuel into your car.

Thanks

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

Re: [Tagging] Parking spaces for car charging

On Mon, 26 Aug 2019 at 08:53, Paul Allen  wrote:

> On Sun, 25 Aug 2019 at 23:35, Graeme Fitzpatrick 
> wrote:
>
>>
>> A bit messy, but how about
>> amenity=parking_space + access=vehicle_charging_only
>>
>
> Big problem right there: you're expanding on the access tag.  Some on this
> list will
> take great exception to that.  Some editors will take even greater
> exception to it as
> they populate drop-downs from the wiki, so when you map a road the access
> drop-down
> will include yes, no, private, vehicle_charging_only.  Which is why the
> parking_space
> proposal invented access:.  And even that is pushing things, a
> little.
>

Yes, you're quite right there - I hadn't thought that side of access=
through


> car_charging=yes/no
>> truck_charging=yes/no
>> hgv_charging=yes/no
>>
>
> And this will re-open hostilities in a different argument about the
> undesirability of having all
> those different binary tags instead of charging=car|truck|hgv.  Or was it
> the other way
> around that was undesirable?  I forget now.
>

I "think" it was charging=car|truck|hgv arrangement that wasn't liked
because of semi-colons, but you're right - it could be the other way round!

On Mon, 26 Aug 2019 at 21:56, Paul Allen  wrote:

> On Mon, 26 Aug 2019 at 01:37, Warin <61sundow...@gmail.com> wrote:
>
>> amenity=charging _space? Says what it is.
>>
>
> First problem is that goes against the design of amenity=parking_space.
> Somebody
> will then decide to have amenity=disabled_parking_space rather than use the
> appropriate subtag with amenity=parking_space.
>

& then, in a few years as electric vehicles become more popular, you'll
have disabled, charging bays! (Which started as a joke but is actually
quite correct - charging bike racks, perhaps?)

Thanks

Graeme

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

Re: [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

Am Mo., 26. Aug. 2019 um 06:09 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> All approved and de facto landforms in Map Features are under
> natural=*, eg natural=ridge, natural=valley, natural=cliff,
> natural=valley, natural=peak, natural=mountain_range... - it's one of
> the main uses for the key natural=*, along with types of vegetation.



yes, but natural=dune is about a specific dune, what the user probably
wanted (dunes) is an area with (an unspecified number of) dunes. "sand"
might be closest, although it doesn't seem as specific (used for golf
courses I hear). He would have wanted natural=dunes?
Btw.: I guess natural=peak for the peak of dunes is OK?


Cheers
Martin


PS: There's a lot of dune classification available, according to shape and
orientation, complexity, location
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

Am Mo., 26. Aug. 2019 um 00:19 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> While some have suggested that uses of the landuse=* key like
> landuse=grass, landuse=village_green and landuse=recreation_area lead
> to misuse of the landuse=* key, the landcover=* key appears to be even
> more problematic.
>
> A newer user, Henke54, has continued to create new pages like
> Tag:landcover=dunes -
> https://wiki.openstreetmap.org/wiki/Tag:landcover%3Ddunes (instead of
> Tag:natural=dune), Tag:landcover=water (instead of natural=water),
> Tag:landcover=hedge (instead of barrier=hedge) and
> Tag:landcover=greenery (meant for all types of vegetation? Or
> shrubberies? Flower beds?) in the Tag: space.
>



IMHO this is less a problem of the landcover tag and more a problem of the
user Henke54. Did you contact him?
E.g. "dunes" are a landform and clearly not suitable for the landcover tag,
and with 3 uses there is not more to it than a misleading wiki page



>
> I think this shows that the concept of "landcover" is not clear even
> among users who promote this key over the established keys for
> vegetation and landform features (eg natural=*).
>


I would say this could be solved by education, at least there is a concept,
which sooner or later could be understood by most of the mappers.



>
> What should we do with a page like Tag:landcover=dunes? I already
> tried adding a mention that natural=dune was more common and mentioned
> on the Talk page that "dune" is a landform, not a landcover, but this
> was reverted.
>


IMHO it should be converted into a proposal or moved to the user's area in
the wiki, tag documentation is about tags that are used and where there is
consensus about their use. If this is not clear, a proposal suits better.

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

[Tagging] Agility park for dogs

2019-08-26 Thread MARLIN LUKE

Hi there,

I'm going to map a small dog park where there are obstacles for agility 
training, and I'm not sure if I should use sport=dog_training[1] or not.
It seems like it's just an old proposal and there was quite some discussion 
about it.
It also looks like it's not much used, less than 500 times[2].

Is there a better way that has been accepted/documented?

Note: if that matters, it's public, anyone can go anytime.

[1]https://wiki.openstreetmap.org/wiki/Proposed_features/Dog_training
[2]https://taginfo.openstreetmap.org/tags/sport=dog_training

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

Re: [Tagging] phone vs contact:phone

2019-08-26 Thread Dave F via Tagging

I've yet to see an argument for collecting all under the 'contact:*' tag 
that bears scrutiny .


The "group them without having to keep a hardcoded list" falls down as 
they have to be split into separate variables to make sense of them.


DaveF

On 25/08/2019 20:48, marc marc wrote:

Le 25.08.19 à 16:55, Martin Koppenhoefer a écrit :

What about deprecating the contact: prefix, at least for phone?

not "AT LEAST FOR" that's the main issue !

having some contact with contact: prefix and some other without
is a very bad idea.
we need to switch all contact to key with contact: prefix
(pro : a datauser is able to group them without havng to keep
a hardcoded list of all key (phone, fax, email, web, social network )
and update to list everytime one user add a new contact)
OR
we need to forget this idea of grouping all contacts
(ironic pro : we tag for the database, not to have easy to use data)
___
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] Relations/proposed/circuit

2019-08-26 Thread Richard Welty

i would like to get a discussion of this proposal started again:

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit

it fills a need i have and i've been using it in both OSM and OHM.
i have made a couple of new comments on the Talk page. right
this instant i'm looking at mapping street circuits and i think
it'd be nice to talk about this before i commit any time to
them.

richard
-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

sent from a phone

> On 23. Aug 2019, at 09:07, Morten Lange  wrote:
> 
> Could you/someone explain how you can search for objects that form such 
> spatial relationships?

I’m not sure how to do it with publicly available services, but if I’m not 
misguided, overpass api allows you to do it.

Typically this would be done by people who use a spatial db, e.g. during the 
rendering of a map, or during the transformation of OpenStreetMap data for a 
specific application. To do it yourself at home without external services you 
could import an extract into a PostGIS database, e.g. with osm2pgsql or imposm. 
You could then issue queries to this db through the command line, or e.g. by 
attaching layers from it to QGIS (to get adhoc visual output).

The wiki has lots of information on all of these topics, the exact way of doing 
it depends on what you need it for, and what you feel comfortable with. I would 
also suggest help.osm.org as this question is offtopic on this list.

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

Re: [Tagging] phone vs contact:phone

sent from a phone

> On 25. Aug 2019, at 21:48, marc marc  wrote:
> 
> we need to switch all contact to key with contact: prefix
> (pro : a datauser is able to group them without havng to keep
> a hardcoded list of all key (phone, fax, email, web, social network ) 
> and update to list everytime one user add a new contact)
> OR
> we need to forget this idea of grouping all contacts

I agree it is appealing to have structured keys so you can understand 
(automatically) the key although you only know part it. It could work for 
things like social media, (e.g. social:facebook or maybe more generically 
url:facebook=* ), but IMHO we don’t need this for phone, fax or email. 

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

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose

2019-08-26 Thread Colin Smale

On 2019-08-26 15:53, Martin Koppenhoefer wrote:

> sent from a phone
> 
> On 25. Aug 2019, at 18:06, Andy Mabbett  wrote:
> 
> there are at least two possibilities:
> phone=
> phone:emergency=
> phone:staff=
> 
> and:
> phone=
> emergency:phone=
> staff:phone=
> 
> Neither of which requires "contact:"
> 
> exactly, I was about to reply the same, it is not an issue for more specific 
> tags that there is also a generic tag.

So will we now have the OSM-style discussion about which phone number to
put in the generic tag? All numbers are equal, but one is slightly more
equal than the rest...___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose



sent from a phone

> On 25. Aug 2019, at 18:06, Andy Mabbett  wrote:
> 
> there are at least two possibilities:
> 
> 
> phone=
> phone:emergency=
> phone:staff=
> 
> and:
> 
> phone=
> emergency:phone=
> staff:phone=
> 
> Neither of which requires "contact:"


exactly, I was about to reply the same, it is not an issue for more specific 
tags that there is also a generic tag.

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

Re: [Tagging] Parking spaces for car charging



sent from a phone

> On 26. Aug 2019, at 13:54, Paul Allen  wrote:
> 
> Third problem is that although the ones my local supermarket recently 
> installed have
> signs (which,so far, are being completely ignored) saying they are only for 
> charging,
> in other places (particularly as charging stations become more common) such 
> spaces
> may not be restricted to charging but allow parking of any kind.  In fact 
> it's very likely to
> happen whenever/wherever the proportion of charging spaces is significantly 
> larger
> than the proportion of electric vehicles.  Your method does not permit such 
> dual-use
> situations to be mapped.


I would say these are two different things: one is a parking space which offers 
battery charging if you like, the other is a charging space where you are not 
allowed to park (i.e. the second is not a kind of parking space, regardless of 
access tags, it is a different main class).

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

Re: [Tagging] Multiple tags for one purpose

2019-08-26 Thread Richard Fairhurst

Valor Naram wrote:
> some long time ago I wondered why we have two tags for one 
> purpose sometimes? For example: A mapper can use either the 
> tag `contact:phone`or `phone` to add a phone number to the 
> database. I think this makes the database dirty and for 
> developers - like me - it's annoying to support two or more tags 
> for one purpose.

As an annoyance in consuming OSM data, I find this ranks about #936 on the
list tbh.

If you really want to spend your life going through the bulk edit process
500 times then knock yourself out, but the effect it'll have is minimal.
Developers have to cope with synonyms anyway, because mappers express nuance
with new values, but most data consumers aren't interested in the nuance.
(For example, in cycle.travel, I treat access values of =yes, =designated,
=official, =permissive the same.)

If you want to make it easier for developers to consume OSM tags, the best
way would be to write and curate documentation covering the 90% cases,
ideally using a github-like PR model that's resistant to getting sidetracked
by the 10% (the OSM wiki problem). The second best way would be to code
libraries in common scripting languages (maybe drawing on common data
tables) that make parsing OSM tags easier.

Richard

--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Parking spaces for car charging



sent from a phone

> On 26. Aug 2019, at 00:33, Graeme Fitzpatrick  wrote:
> 
> A bit messy, but how about 
> amenity=parking_space + access=vehicle_charging_only
> car_charging=yes/no
> truck_charging=yes/no
> hgv_charging=yes/no


Is it really „parking“? Maybe we should introduce an amenity=charging_space?

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

Re: [Tagging] landcover dune or land form dune

2019-08-26 Thread Joseph Eisenberg

Yes, I agree that for something like landcover=hedge an even stronger
warning is needed.

Some context for why Warin and I are talking about this: The second
section of the key page  Key:produce has long mentioned the
differences between produce=* and product=*.

I added to that section, mentioning that crop=* is used more
frequently than produce=* to specify the annual crops grown on
farmland, and trees=*, used more frequently than produce=* to specify
the trees found in an orchard. I probably should have mentioned that
aquaculture=* is the more common tag to specify the type of organisim
in a landuse=aquaculture feature (e.g. shrimp).

But this addition was first reverted, and after I restored it, now it
has been moved it to a "See Also" section. I disagree with this. if we
are going to mention the difference between produce=* and product=*,
there should be a mention of the other tags, otherwise it appears that
product=* is the only similar or overlapping or synonymous tag that
needs to be considered before picking produce=*.

There was also a statement added that "crop=* can not be used for all
produce=*, but produce=* can be used for all crop=*" which is not
accurate, based on usage of the tags in the database.

I would prefer that a proposal be made to deprecate a key (eg to
replace crop=*, trees=* and aquaculture=* with produce=*), if this is
the intention, rather than removing or de-emphasizing factual
information that does not fit a certain narrative.

https://wiki.openstreetmap.org/wiki/Talk:Key:produce#Crop_should_not_be_added_to_the_disambiguation_of_produce_vs_product_section

On 8/26/19, Paul Allen  wrote:
> On Mon, 26 Aug 2019 at 13:18, Joseph Eisenberg 
> wrote:
>
>> I agree, Paul.
>> The most important things on a wiki page are 1) The description of the
>> tag: what sort of feature or property does it represent and 2) How
>> does one distinguish it from overlapping tags? Both of these should be
>> in the first paragraph / section.
>>
>> For example, see highway=raceway:
>> (https://wiki.openstreetmap.org/wiki/Tag:highway=raceway)
>> "A racetrack for motorised racing, eg cars, motorbikes and karts.
>> For cycling, running, horses, greyhounds etc, use leisure=track."
>>
>> highway=unclassified
>> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
>> "The tag highway=unclassified is used for minor public roads typically
>> at the lowest level of the interconnecting grid network. Unclassified
>> roads have lower importance in the road network than {{tag|tertiary}}
>> roads, and are not residential streets or agricultural tracks"
>>
>
> For those examples, that is OK.  But those are along the lines of "this
> tag applies to this particular situation, there are similar situations
> where
> a different tag should be used."  In the case of landcover=hedge it's
> more of "This is a bad tag.  Use this instead." (I paraphrase, you'd
> phrase it more diplomatically) and should be in its own section right
> at the very start.  With a warning icon.  Because once you know that,
> there is no point reading the rest of it.
>
> --
> Paul
>

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

Re: [Tagging] landcover dune or land form dune

On Mon, 26 Aug 2019 at 13:18, Joseph Eisenberg 
wrote:

> I agree, Paul.
> The most important things on a wiki page are 1) The description of the
> tag: what sort of feature or property does it represent and 2) How
> does one distinguish it from overlapping tags? Both of these should be
> in the first paragraph / section.
>
> For example, see highway=raceway:
> (https://wiki.openstreetmap.org/wiki/Tag:highway=raceway)
> "A racetrack for motorised racing, eg cars, motorbikes and karts.
> For cycling, running, horses, greyhounds etc, use leisure=track."
>
> highway=unclassified
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
> "The tag highway=unclassified is used for minor public roads typically
> at the lowest level of the interconnecting grid network. Unclassified
> roads have lower importance in the road network than {{tag|tertiary}}
> roads, and are not residential streets or agricultural tracks"
>

For those examples, that is OK.  But those are along the lines of "this
tag applies to this particular situation, there are similar situations where
a different tag should be used."  In the case of landcover=hedge it's
more of "This is a bad tag.  Use this instead." (I paraphrase, you'd
phrase it more diplomatically) and should be in its own section right
at the very start.  With a warning icon.  Because once you know that,
there is no point reading the rest of it.

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

Re: [Tagging] landcover dune or land form dune

2019-08-26 Thread Joseph Eisenberg

I agree, Paul.
The most important things on a wiki page are 1) The description of the
tag: what sort of feature or property does it represent and 2) How
does one distinguish it from overlapping tags? Both of these should be
in the first paragraph / section.

For example, see highway=raceway:
(https://wiki.openstreetmap.org/wiki/Tag:highway=raceway)
"A racetrack for motorised racing, eg cars, motorbikes and karts.
For cycling, running, horses, greyhounds etc, use leisure=track."

highway=unclassified
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
"The tag highway=unclassified is used for minor public roads typically
at the lowest level of the interconnecting grid network. Unclassified
roads have lower importance in the road network than {{tag|tertiary}}
roads, and are not residential streets or agricultural tracks"

And see the next section
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified#When_is_this_applicable.3

place=town
"Use place=town to identify an important urban centre that is larger
than a place=village, smaller than a place=city, and not a
place=suburb."

leisure=park
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpark
Second paragraph (first section): "... Such large, national-level ...
parks not so designed and manicured, but rather left in a more wild
and natural state should not get this tag, instead, use another tag
like boundary=national_park; see below."

Also see pages like
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmland and
https://wiki.openstreetmap.org/wiki/Key:surface which prominently
mention the other similar tags in the first section below the
description,

As these examples show, it's common practice to mention other tags
that might be confused with the tag, rather than just listing them in
the "See Also" section.

"See Also" comes from Wikipedia, where it suggests other articles that
might be interesting. It's fine for tags that are not likely to be
confused or overlap with the tag in question. But it doesn't work when
there are synonyms or tags that appear like they could be used in the
same way; these need to be mentioned up-front.

-Joseph

On 8/26/19, Paul Allen  wrote:
> On Mon, 26 Aug 2019 at 05:35, Warin <61sundow...@gmail.com> wrote:
>
>>
>> Traditionally OSMwikis had a section 'See also' where other tags were
>> placed.
>>
>> Placing more and more information at the top of the page confuses people.
>>
>> The page should first describe the tag and how to use it. This is good
>> educational practice.
>>
>>
> But bad documentation practise.  I would be very unhappy investing my time
> reading what a tag
> does only to then get to a section saying "don't use that, use this."  That
> wastes my time and
> loads my (these days, rather limited) brain with conflicting ideas.
>
> Only once that is done should alternatives and complementary tags be
> suggested.
>>
>>
> Complementary tags can, and should, come later.  These are optional things
> that can be
> used to refine the details of the object.  Alternative methods of tagging
> that are equally
> valid, and equally popular (both for approximate values of "equal") can
> also come later.
> A "This tag is a BAD idea, use that instead" warning SHOULD come first:
> don't bother
> reading the rest of this page unless you're trying to figure out what some
> other mapper
> meant by it because it doesn't render, goes against conventions and we have
> a far
> better (even if "better" means "more popular") alternative.
>
> --
> Paul
>

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

Re: [Tagging] landcover dune or land form dune

2019-08-26 Thread marc marc

Le 26.08.19 à 12:57, Warin a écrit :
> Is there a requirement to go in to all of these wiki pages and explain 
> why the demotion of one over the other simply due to frequency of use 
> without consideration of other factors?

I ask myself "what would we do if the other tag didn't exist ?"
would we create the more currently common one or something better ?
if the answer is "something better", then I wouldn't put demotion
on the "better" tag page but simply the information "another tag
is more common tag" + the argument why this alternative exist
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Parking spaces for car charging

On Mon, 26 Aug 2019 at 01:37, Warin <61sundow...@gmail.com> wrote:

> amenity=charging _space? Says what it is.
>

First problem is that goes against the design of amenity=parking_space.
Somebody
will then decide to have amenity=disabled_parking_space rather than use the
appropriate subtag with amenity=parking_space.  I'm not saying
amenity=parking_space
is perfect, but it's there and I hesitate to invent yet another way of
doing things.

Second problem is that a car parked there to charge is actually parked
there.  So it's
still a parking space, in the same way that a disabled parking space is
still a
parking space.  There are restrictions on who can use it, but it's still a
parking
space.

Third problem is that although the ones my local supermarket recently
installed have
signs (which,so far, are being completely ignored) saying they are only for
charging,
in other places (particularly as charging stations become more common) such
spaces
may not be restricted to charging but allow parking of any kind.  In fact
it's very likely to
happen whenever/wherever the proportion of charging spaces is significantly
larger
than the proportion of electric vehicles.  Your method does not permit such
dual-use
situations to be mapped.

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

Re: [Tagging] landcover dune or land form dune

On Mon, 26 Aug 2019 at 05:35, Warin <61sundow...@gmail.com> wrote:

>
> Traditionally OSMwikis had a section 'See also' where other tags were placed.
>
> Placing more and more information at the top of the page confuses people.
>
> The page should first describe the tag and how to use it. This is good 
> educational practice.
>
>
But bad documentation practise.  I would be very unhappy investing my time
reading what a tag
does only to then get to a section saying "don't use that, use this."  That
wastes my time and
loads my (these days, rather limited) brain with conflicting ideas.

Only once that is done should alternatives and complementary tags be suggested.
>
>
Complementary tags can, and should, come later.  These are optional things
that can be
used to refine the details of the object.  Alternative methods of tagging
that are equally
valid, and equally popular (both for approximate values of "equal") can
also come later.
A "This tag is a BAD idea, use that instead" warning SHOULD come first:
don't bother
reading the rest of this page unless you're trying to figure out what some
other mapper
meant by it because it doesn't render, goes against conventions and we have
a far
better (even if "better" means "more popular") alternative.

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

Re: [Tagging] landcover dune or land form dune

On Mon, 26 Aug 2019 at 04:52, Joseph Eisenberg 
wrote:

There seems to be confusion about what the key "landcover" means,
> because recently there have also been pages created for
> landcover=water and landcover=hedge as well.
>

I'm in no way justifying any of the landcover=* tags that user has
invented, but I can
see from his edit comments why he invented landcover=hedge.  He either
didn't read
about, or did not like, barrier=hedge + area=yes so came up with
landcover=hedge to
use to represent that situation.  Whatever his reason, he seems rather
detached from
reality and insulates himself with a thick layer of Dunnnig-Kruger.

This also brings up the question: is it appropriate to edit pages like
> this to mention the more common tags at the top, e.g. natural=dune,
> natural=sand? Often other editors are unhappy when I add something
> like "Consider using the more common tags natural=dune or
> natural=sand" - but if anyone can create a Tag: or Key: page, it seems
> important that similar and synonymous tags are mentioned at the top.
>

Even though it may trigger an edit war by this user like this one, go for
it.

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

Re: [Tagging] landcover dune or land form dune


On 26/08/19 20:36, Mateusz Konieczny wrote:




26 Aug 2019, 12:31 by 61sundow...@gmail.com:

On 26/08/19 20:22, Mateusz Konieczny wrote:


26 Aug 2019, 05:51 by joseph.eisenb...@gmail.com
:

This also brings up the question: is it appropriate to edit
pages like
this to mention the more common tags at the top, e.g.
natural=dune,
natural=sand?

Yes. Especially in cases of tags that
are

- duplicates of far more used tags
- without support among any editors
- without real support among mappers
- without support among data consumers
- page was created without discussion

In blatant cases like landcover=water
I would also add tag to list of
deprecated or at least deprecated status
and add note strongly encouraging using one of standard tags.


Oftenother editors are unhappy when

Are they also offering some
sort of argument against doing this?


In some cases, yes there are points in favour of the less
frequently used key/tag.

landuse=grass anyone?

Obviously in case that already had deep
and long discussion we can base on
arguments presented there.

Just that in case of obvious cases
it is not necessary to have discussion
as large as one for landcover=grass to
improve the wiki page with note about the
situation.


Unfortunately there may be long discussions on other cases!
And I and others probably don't want long discussions as 'we' would 
rather do other things .. like map.


Presently the wiki is being changed to promote the key crop over the key 
produce simply due frequent use.

It is clear to me that the key crop is a subset of the key produce.

The key crop probably has more use because it has wiki pages for its 
values where as produce does not. These wiki pages are mear stubs but if 
you search for 'wheat' the prominent return is crop=wheat thus mappers 
use it without any thought to produce=wheat.


Is there a requirement to go in to all of these wiki pages and explain 
why the demotion of one over the other simply due to frequency of use 
without consideration of other factors?


"Any key you like" as long as it is popular?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover dune or land form dune




26 Aug 2019, 12:31 by 61sundow...@gmail.com:

> On 26/08/19 20:22, Mateusz Konieczny  wrote:
>
>>
>> 26 Aug 2019, 05:51 by >> joseph.eisenb...@gmail.com 
>> >> :
>>
>>> This also brings up the question: is it  appropriate to edit pages 
>>> like
>>> this to mention the more common tags at the  top, e.g. natural=dune,
>>> natural=sand?
>>>
>> Yes. Especially in cases of tags that
>> are 
>>
>> - duplicates of far more used tags
>> - without support among any editors
>> - without real support among mappers
>> - without support among data consumers
>> - page was created without discussion
>>
>> In blatant cases like landcover=water
>> I would also add tag to list of
>> deprecated or at least deprecated status
>> and add note strongly encouraging using one ofstandard tags.
>>
>>>
>>> Oftenother editors are unhappy when
>>>
>>>
>> Are they also offering some
>> sort of argument against doing this?
>>
>
> In some cases, yes there are points in favour of the less frequentlyused 
> key/tag.
>  
>  landuse=grass anyone? 
>
Obviously in case that already had deep
and long discussion we can base on
arguments presented there.

Just that in case of obvious cases
it is not necessary to have discussion
as large as one for landcover=grass to
improve the wiki page with note about the
situation.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover dune or land form dune


On 26/08/19 20:22, Mateusz Konieczny wrote:


26 Aug 2019, 05:51 by joseph.eisenb...@gmail.com:

This also brings up the question: is it appropriate to edit pages like
this to mention the more common tags at the top, e.g. natural=dune,
natural=sand?

Yes. Especially in cases of tags that
are

- duplicates of far more used tags
- without support among any editors
- without real support among mappers
- without support among data consumers
- page was created without discussion

In blatant cases like landcover=water
I would also add tag to list of
deprecated or at least deprecated status
and add note strongly encouraging using one of standard tags.


Oftenother editors are unhappy when

Are they also offering some
sort of argument against doing this?


In some cases, yes there are points in favour of the less frequently 
used key/tag.


landuse=grass anyone?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover dune or land form dune


26 Aug 2019, 05:51 by joseph.eisenb...@gmail.com:

> This also brings up the question: is it appropriate to edit pages like
> this to mention the more common tags at the top, e.g. natural=dune,
> natural=sand?
>
Yes. Especially in cases of tags that
are 

- duplicates of far more used tags
- without support among any editors
- without real support among mappers
- without support among data consumers
- page was created without discussion

In blatant cases like landcover=water
I would also add tag to list of
deprecated or at least deprecated status
and add note strongly encouraging using one of standard tags.

>
> Oftenother editors are unhappy when
>
>
Are they also offering some
sort of argument against doing this?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc


23 Aug 2019, 09:07 by tagging@openstreetmap.org:
> Could you/someone explain how you can search for objects that form such 
> spatial relationships?
>
Overpass API is good for start.
Wiki has page with examples
for Overpass API/Overpass turbo, including
"X within N meters from Y, limited to Z area".___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

2019-08-26 Thread Morten Lange via Tagging

Martin wrote:> IMHO no. We do not need tags of an is_in fashion for this, > we 
can model this universally by making use of implicit > spatial relationships 
(i.e. put the bike kitchen inside the community > centre or pub, or the other 
way round, according to our > interpretation of the situation)

Could you/someone explain how you can search for objects that form such spatial 
relationships?
I noted in another message in the thread that I am not aware of how to search 
for combined features, each tagged in a separate object (point/way/relation) 
close to oneanother.
Although that is in principle a separete issue from how to tag "ground truth", 
I think it is relevant.  And I am curious as to how such searches can be 
carried out. 

-- Regards / Kveðja / Hilsen Morten Lange 


On Sunday, 18 August 2019, 23:22:05 CEST, Martin Koppenhoefer 
 wrote:  
 
 

sent from a phone
On 18. Aug 2019, at 23:06, Morten Lange via Tagging  
wrote:


I am skeptical as that makes finding them less straightforward, if you are 
looking for   [ a place where I can get my bicycle repaired or receive some 
help].


it will require you look for them explicitly or the app you are using would 
take them into account. On the other hand from my experience these aren’t 
places “to get your bicycle repaired”, they are rather places you can go to and 
hang out with other bicycle enthusiasts of a certain political orientation and 
repair your bike yourself.



Many potential users will not know about bicycle kitchens or that other 
community centres offer bicycle repairs.


again, these places around here don’t “offer bicycle repairs”, they offer 
enabling you to do the repairs yourself 
"
But I think they should be searchable also as somethings separate form the 
ordinary bicycle shop. Additional tags can do the trick.
For bicycle kitchens I guess 
      service:bicycle:diy:yes     might cover it. 


while it isn’t factually wrong, it isn’t useful as a distinction from forprofit 
places where you pay to use a space to adjust your bike




Here follow some new ideas that just popped out:

Perhaps add something like     shop:bicycle:type=bicycle_kitchen


yes, if it _is_ a kind of bicycle shop. An idea that is not universally shared.




Other values for that tag could be     with_pub    with_cafe    job_training    
in_community_centre


IMHO no. We do not need tags of an is_in fashion for this, we can model this 
universally by making use of implicit spatial relationships (i.e. put the bike 
kitchen inside the community centre or pub, or the other way round, according 
to our interpretation of the situation)

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

Re: [Tagging] landcover dune or land form dune