Re: [Tagging] oneway=yes on motorways

[Jean-Marc Liotier]

On 5/26/20 5:44 AM, Paul Johnson wrote:


It can't hurt to specify oneway=yes. I have noticed that the JOSM
style
that shows lane counts and lane use will sometimes not show ways
properly if oneway=yes isn't there, but that's probably a bug in the
style more than an indictment of implying oneway=yes.


I'm on the side of "team tag explicitly" on this.  If anything, it 
gives validators more to work with if you start doing something weird.


Isn't that what oneway=no is for ?

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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 5/25/20 3:42 AM, Warin wrote:


You will need to be very clear what a 'common' is and how it is 
different from other tags such as amenity=marketplace, leisure=park


The defining characteristics are: being open to public, not designated 
for a specific purpose, not landscaped (or that would be a park), not a 
marketplace (in West Africa, marketplaces are regulated and occur almost 
only at designated locations), not a pitch (when a couple pairs of 
goalposts are planted at extremities, the pitchness sometimes takes 
precedence and a few such locations are rightfully mapped as soccer 
pitches - but usually playing ball is just one of the uses of such places)


A possible alternative, not yet mentioned here, is place=square (which 
by the way is the English for the concept of piazza/plaza) "A town or 
village square: a paved open public space, generally of architectural 
significance, which is surrounded by buildings in a built-up area such 
as a city, town or village" - 
https://taginfo.openstreetmap.org/tags/place=square 
https://en.wikipedia.org/wiki/Town_square - but it is part of the 
place=* hierarchy, which is not fit for our purpose: place=* requires a 
name=* and this places are rarely named.




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

Re: [Tagging] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

So, we are actually all in agreement, aren't we ?

Nous sommes donc tous d'accord, non ?


On 5/3/20 6:00 PM, severin.menard wrote:

Oui désolé, en effet je me suis trompé sur la clé !

Yes sorry, my mistake regarding the right key!



‐‐‐ Original Message ‐‐‐
Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml 
 a écrit :



Fr

Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin, 
je disais bien

leisure=common

En

Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did 
say...

 leisure=common
*//*


Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier 
 a écrit :



So, this discussion gravitates towards using landuse=common for those 
African urban freely accessible multipurpose open spaces, which I 
fully support.


Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English 
(I'll do that)


- Reinstating the rendering of leisure=common in downstream 
cartographic styles, would be even better if the color matched the 
surface=* so that sandy surfaces don't appear green.


- Reinstating the rendering of leisure=common in JOSM's default style 
(it recently changed to grey to mark deprecation). (I'll open a JOSM 
ticket


- Altering QA rules (JOSM Validator and Osmose) so that the 
leisure=common deprecation only applies to the United Kingdom of 
Great Britain, where commons have a legal definition and 
designation=common must be used for them. (I'll open a JOSM ticket 
but if someone has prior experience interacting with the Osmose 
people, that would be nice)




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

[Tagging] Quality and the Openstreetmap value chain

[Jean-Marc Liotier]

On 5/12/20 11:42 AM, Richard Fairhurst wrote:

I love the fact that we are now 50 messages into discussing, for the second
time, a change that would be made ostensibly for the benefit of data
consumers, and yet no one has asked any actual data consumers.


Yes. Users are the ultimate measure of quality, yet they are most often 
absent from our discussions. Our history explains why: in the beginning, 
we had a blank map, which we set upon filling with whatever we could, to 
get the stone soup started. There were no consumers at all - so 
naturally our universe was supply-side entirely: the availability of 
data inspired usage, which came second. Nowadays, Openstreetmap is used 
- let's take advantage of that to improve ! Looking at the world and 
thinking about how we should model it should be done with an 
understanding of how users want it. This is difficult when we have few 
users around and very little feedback from downstream. So, if one has 
opportunities to bring that to our knowledge, please do: it is valuable 
information to the Openstreetmap project, information without which we 
cannot allocate our efforts optimally.



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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 5/3/20 7:36 PM, Marc M. wrote:

Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
it is true that this tag (leisure=common)is ambiguous because it is 
being used for totally different purposes in different countries. 
I think this argument is crucial. if more than one meaning exists for 
a tag, having a precise meaning for a country is useless, osm is a 
global base, it's a bad idea to hope a render style "tag A rendered as 
meaning1 in Africa, as meaning2 in Europe, as meaning3 in Asia".


Then, isn't it nice that leisure=common has been abandoned in it's 
former British usage ? As far as I know, that was its only other usage - 
or is it also used in other parts of the world ?



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

Re: [Tagging] [Talk-sn] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

Indeed I have misread. Let's leave the debate open for a little while 
more - this is no time for implementation yet.


Oui, j'ai mal lu, trop rapidement. Laissons donc la discussion continuer 
- ce n'est pas encore le moment d'agir.



On 5/3/20 5:54 PM, Pierre Béland wrote:

Fr

Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin, je 
disais bien

leisure=common

En

Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did 
say...

 leisure=common

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

Re: [Tagging] [Talk-ml] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

So, this discussion gravitates towards using landuse=common for those 
African urban freely accessible multipurpose open spaces, which I fully 
support.


Implementing this change requires the following actions:

- Editing the leisure=common wiki page, in French and in English (I'll 
do that)


- Reinstating the rendering of leisure=common in downstream cartographic 
styles, would be even better if the color matched the surface=* so that 
sandy surfaces don't appear green.


- Reinstating the rendering of leisure=common in JOSM's default style 
(it recently changed to grey to mark deprecation). (I'll open a JOSM ticket


- Altering QA rules (JOSM Validator and Osmose) so that the 
leisure=common deprecation only applies to the United Kingdom of Great 
Britain, where commons have a legal definition and designation=common 
must be used for them. (I'll open a JOSM ticket but if someone has prior 
experience interacting with the Osmose people, that would be nice)



On 5/3/20 4:19 PM, severin.menard via Tagging wrote:
Je suis d'accord avec Pierre : le tag landuse=common convient bien à 
ces espaces ouverts dans les villages et villes africaines et un parc 
n'a pas grand-chose à voir avec.


I agree with Pierre: the tag landuse=common is well suited to these 
open spaces in African villages and towns and a park has little to do 
with it.



‐‐‐ Original Message ‐‐‐
Le mercredi 29 avril 2020 21:59, Pierre Béland via Talk-ml 
 a écrit :


Like others, I did map many of these. I can tell you that we often 
see a common space in center of african villages, often near the 
school,  and  it is surely not green and have no facilities like in 
the Nordic countries parks.


People have to understand that there are often no infrastructures in 
African villages. But young people still gather and play.


I dont think that the OSM tagging schema should reflect the legal 
status in specific countries like UK. Various tags can reflect 
various realities.  And leisure=common seems to be quite well adapted 
to Africa and dont exist to stretch the legal defininition of UK.


When the tag is used in UK, I would understand that the UK 
contributors want to follow a certain rule particular to their country.


But I dont agree to deprecate the the leisure=common tag for Africa.



Le mercredi 29 avril 2020 15 h 34 min 57 s UTC−4, Jean-Marc Liotier 
 a écrit :



Here is a 360° picture of a square in Dakar:
https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA - larger than a
street (it occupies a whole city block), used as a multipurpose common
area (pickup soccer games are a staple but parking or lounging around
also occur, and the occasional popular event) and usually surfaced with
sand or whatever the ground is.

We have long tagged it leisure=common (389 ways in Senegal and 486 in
Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of
stretch from the British legal definition, but worked well enough and
did not conflict with its British usage. But leisure=common is now
deprecated

So, what should we use instead ?
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon suggests using
leisure=park - which isn't too much of a stretch functionally but evokes
greenery that does not occur here (though British commons are just as
green and we were happy with leisure=common)... Any other ideas ? Or I'm
going to use leisure=park+surface=sand !


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

Re: [Tagging] natural=water inside natural=wetland

[Jean-Marc Liotier]

On 5/1/20 12:12 PM, John Willis via Tagging wrote:
There is often overlap where I am where a wetland lives permanently in 
the bottom of a basin, and the surrounding area is a park or sports 
field. When there is a storm the basin fills up and wetland, pitch, 
and parking lot end up under 3m of water for a day or so.


The wetland is not exclusively part of that structure. The basin or 
intermittent reservoir consumes everything inside of it.


[..]

In a lake, some corner of the lake is often a wetland - yet that 
wetland is 100% the part of the lake. It should be layered IMO. That 
could happen for a wetland too, right?


I always thought of the lake as part of the wetland - but now you open 
my mind to the reverse...


What I'm attempting to tag is seasonal Sahelian lakes, the core of which 
is often permanent, surrounded by a humidity gradient of swamp and 
mudflats - often surrounded by vegetable gardens. Indeed, the whole area 
is what is often designated as "lake something"... Would that be the 
correct way or is the lake the water body stricto sensu ?


Then comes the question of of to tag - but that part of the answer I 
guess is multipolygon too.



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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 5/1/20 2:25 PM, John Willis via Tagging wrote:
lots of urban areas have commons around buildings that are not mere 
landscaping - are those parks? landuse=grass? highway=ped?


Indeed, in France I have seen such mapped as highway=pedestrian - but 
that emphasizes their role as thoroughfare rather than their role as 
destination.


Conceptually, I believe plaza is what we are debating about. Now, how to 
tag that ?


place=plaza would be in the place=* hierarchy, which is meant for named 
locations.


The focus on function places those plaza squarely in the leisure=* field.

So far, I think that appropriating leisure=common for this purpose is a 
solid idea.



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

[Tagging] natural=water inside natural=wetland

[Jean-Marc Liotier]

Consider a wetland that contains a water body. I'm used to map that as 
natural=water inside natural=wetland - no multipolygon fanciness, just 
one on top of the other. JOSM validator complains about it, which irks 
me, so I opened a ticket at https://josm.openstreetmap.de/ticket/19171 - 
where mdk suggests that I may be doing it wrong...


Is my simple way incorrect ? It feels correct to me because wetlands are 
complex objects - water bodies are part of them, cross them or partially 
overlap them. From a tagging point of view, it implies that some area is 
both natural=water and natural=wetland - I see no problem with that... 
But others might consider that a logical impossibility.


So, which is the correct way: plain natural=water inside 
natural=wetland, or a natural=water multipolygon with natural=wetland on 
its inner ?



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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 4/30/20 2:12 PM, Martin Koppenhoefer wrote:
Am Do., 30. Apr. 2020 um 14:07 Uhr schrieb Andy Townsend 
mailto:ajt1...@gmail.com>>:



How about "leisure=common"?


+1, I would prefer leisure=common over landuse, as these seem to be 
"features"

(countable, etc.)


leisure=common is an especially good candidate because land which is 
legally designated as common land in the UK should nowadays be tagged as 
designation=common - and there is therefore no longer a namespace 
collision... leisure=common is available for recycling into our African 
purpose !





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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 4/30/20 12:08 PM, Martin Koppenhoefer wrote:
if these are significant open areas that are used for recreation and 
to meet each other, it seems improbable that they do not have names. 
Can you back your claim with real world examples?


Go wander around Dakar and Bamako !


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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 4/30/20 3:13 AM, Warin wrote:
It may look like sports are played there to you and me. It may 
resemble a park to others. However none of those may be the case! Or 
it may not be the primary use. Simply viewing it without local 
knowledge may well cause errors!


The local mapper should say what the area is primarily used for .. It 
may be used for a weekly market (some 'weeks' are 6 days in Africa).  
It may be used for social/political gatherings.


I know these places well. They are never a marketplace (in Senegal and 
Mali, those are dedicated areas - clearly marked). They are not 
dedicated sport pitches - but soccer kids play soccer. They are 
sometimes used for gatherings. Or parking.


The concept they are closest to is "plaza" 
(https://en.wikipedia.org/wiki/Plaza) - which, by the way, does not seem 
to have currency in Openstreetmap.



The surface is not grass. I would hesitate to call it sand, could be 
ground. In any case 'unpaved' could be used.



surface=ground ?

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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

On 4/30/20 12:20 AM, Volker Schmidt wrote:

place=square seems to fit the bill


place=square exists within the place=* hierarchy which , as documented 
in https://wiki.openstreetmap.org/wiki/Key:place, is used to 
characterize named locations. What we tag here is almost always unnamed.


Our goal is to record the nature of that space - and most importantly 
its functionality as a common free space.



On Wed, 29 Apr 2020 at 23:18, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


   I agree, the area in this spot
   (https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA) is a
   moderly sized open area of bare earth, with buildings on 3 sides and
   a paved streets on a long side. It appears to be used for sports and
   recreation, and for walking. I suspect it might be a "de facto"
   leisure=pitch - in the USA it would be an "empty lot" used for
   soccer/baseball/etc. It could also be a highway=pedestrian +
   area=yes - an open pedestrian area or "town square" - those are
   usually paved in some way in developed countries, but that's not a
   requirement. It does not appear to be a park.

   There was not any formal discussion to deprecate leisure=common, and
   mappers are certainly free to keep using that tag. It was marked as
   deprecated by one wiki user, about a year ago.

   But since the tag it is not well defined, it will be hard for
   database users to interpret what it means.


   On Wed, Apr 29, 2020 at 1:41 PM Mateusz Konieczny via Tagging
   mailto:tagging@openstreetmap.org>> wrote:


   Apr 29, 2020, 21:37 by skqu...@rushpost.com
   <mailto:skqu...@rushpost.com>:

   On 4/29/20 14:34, Jean-Marc Liotier wrote:

   Here is a 360° picture of a square in Dakar:
   https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA
   - larger than a
   street (it occupies a whole city block), used as a
   multipurpose common
   area (pickup soccer games are a staple but parking or
   lounging around
   also occur, and the occasional popular event) and
   usually surfaced with
   sand or whatever the ground is.

   We have long tagged it leisure=common (389 ways in
   Senegal and 486 in
   Mali according to http://overpass-turbo.eu/s/TqN) -
   which is a bit of
   stretch from the British legal definition, but worked
   well enough and
   did not conflict with its British usage. But
   leisure=common is now
   deprecated

   So, what should we use instead ?
   https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon
   suggests using
   leisure=park - which isn't too much of a stretch
   functionally but evokes
   greenery that does not occur here (though British
   commons are just as
   green and we were happy with leisure=common)... Any
   other ideas ? Or I'm
   going to use leisure=park+surface=sand !


   While leisure=park might work, there is also
   leisure=recreation_ground
   to consider.


   leisure=recreation_ground sounds fitting to me and is without
   baggage of legal
   status bundled into leisure=commons

   This specific place looks like leisure=pitch. And for example in
   Poland some
   sport pitch may be used for an occasional event, festival of
   various types.

   Note: I am unfamiliar with on-the-ground situation in Africa

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

[Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Jean-Marc Liotier]

Here is a 360° picture of a square in Dakar: 
https://www.mapillary.com/map/im/jYNQFMwHiNEZRCnpi71heA - larger than a 
street (it occupies a whole city block), used as a multipurpose common 
area (pickup soccer games are a staple but parking or lounging around 
also occur, and the occasional popular event) and usually surfaced with 
sand or whatever the ground is.


We have long tagged it leisure=common (389 ways in Senegal and 486 in 
Mali according to http://overpass-turbo.eu/s/TqN) - which is a bit of 
stretch from the British legal definition, but worked well enough and 
did not conflict with its British usage. But leisure=common is now 
deprecated


So, what should we use instead ? 
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon suggests using 
leisure=park - which isn't too much of a stretch functionally but evokes 
greenery that does not occur here (though British commons are just as 
green and we were happy with leisure=common)... Any other ideas ? Or I'm 
going to use leisure=park+surface=sand !



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

Re: [Tagging] Specific tag for Satellite Dishes

[Jean-Marc Liotier]

On Mon, July 29, 2019 7:03 am, Enock Seth Nyamador wrote:
> I am looking for specific tags for Satellite Dish [1]. I haven't found
> anything near so far. May be am missing something, else it doesn't exist
> and might be useful to propose and come handy in some cases.

Prior discussion about that:
http://gis.19327.n8.nabble.com/quot-satellit-quot-td5934448.html -
inconclusive because there is no consensus about granularity

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

Re: [Tagging] unused tags and properties

[Jean-Marc Liotier]

I agree. The wiki is a point of entry for inexperienced contributors and 
should therefore document established practices rather than serve as a 
way to make marginal ideas appear established.


That said, the subjectivity of what constitutes "established practices" 
guarantees controversy...



On 4/27/19 1:54 AM, Martin Koppenhoefer wrote:
A few people continue to add unused tags and properties to feature 
definitions, e.g. looking at the page for tourism=guesthouse, which is 
quite long in the meantime, you can find "proposed" values with names like

"fridge"
"stove"
"drying:room"
"dinner"
which all hardly reach a 2 digit number of usage.

https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house

For the "view" tag there isn't even a definition.

I believe treating the wiki like this will generally lead to a decline 
in quality of our documentation, because immature tags are pushed that 
haven't undergone any kind of peer review (aparently).


Am I the only one with these concerns?



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

Re: [Tagging] I have been tagging mosques wrong all along

[Jean-Marc Liotier]

On 3/23/19 6:04 PM, Greg Troxel wrote:

I find the implicit rules really problematic, as we don't have a
machine-readable repository of them that can be used to processs tags as
they are to the full logical set of what they mean.


So, should the amenity=place_of_worship complex have landuse=religious 
too ? I wouldn't mind - if a consensus here believes so.




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

Re: [Tagging] I have been tagging mosques wrong all along

[Jean-Marc Liotier]

On 3/23/19 4:55 PM, Tom Pfeifer wrote:

On 23.03.2019 15:12, Jean-Marc Liotier wrote:

The wikipedia article has some insight in the process, however it also 
mentions that a mosque can be a building. So, if the mosque is a 
building, tagging building=mosque would be fine.
Yes, the case of a single building containing an integrated mosque is 
"amenity=place_of_worship + religion=muslim + building=mosque".


The case I have in mind is where the mosque is a complex of several 
buildings - such as the building for ritual ablutions, a separate prayer 
building for women, the outside prayer ground for days of large 
gatherings, the toilets etc. The main prayer hall, with the dome roof 
and the minaret tower is what comes to mind when we think "mosque" but 
the mosque is actually the whole walled complex - hence tagging it 
"amenity=place_of_worship + religion=muslim".



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

Re: [Tagging] I have been tagging mosques wrong all along

[Jean-Marc Liotier]

On 3/23/19 5:28 PM, Greg Troxel wrote:

Jean-Marc Liotier  writes:

So, no landuse=religious anymore at all and no building=mosque for the

I don't understand why you think landuse=religious shouldn't be
present. It seems that all land used for religious purposes should
have that tag


Redundancy ? I have the same issue for shop=* (or even amenity=fuel) 
also tagged with landuse=retail - same sort of redundancy.


To me, amenity=place of worship is implicitly landuse=religious and 
shop=* is implicitly landuse=retail... Am I alone in thinking that way ?




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

[Tagging] I have been tagging mosques wrong all along

[Jean-Marc Liotier]

In the Sahelian Openstreetmap I enjoy tagging mosques because they are 
prominent features, nice for navigation and easy to spot on orbital 
imagery - for me it has definitely turned into a "gotta catch'em all" 
game... And I'm not even Muslim !


The tagging scheme I had settled upon was amenity=place_of_worship + 
religion=muslim (building=mosque if there is a main building) and 
landuse=religious + religion=muslim for the plot.


I have learned from Muslims and confirmed in literature that this 
tagging scheme is wrong: what I considered as the mosque itself is 
merely the main prayer hall. The mosque is actually the whole complex 
that I used to tag as landuse=religious.


So, here is my current position regarding the tagging of mosques:

Single building mosque, no change:
amenity=place_of_worship + religion=muslim + building=mosque

Mosque complex: tag the whole plot (often the perimeter is also 
barrier=wall):

amenity=place_of_worship + religion=muslim

So, no landuse=religious anymore at all and no building=mosque for the 
buildings inside a mosque complex (building=yes - or, for the 
adventurous, multipart buildings with distinct minaret and dome)


Anyone else obsessed with mosques to give an opinion on this 
clarification - is it correct ?



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

Re: [Tagging] discouraging shop=fashion

[Jean-Marc Liotier]

On Tue, March 12, 2019 5:23 am, Marc Gemis wrote:
> Before deprecating the shop=fashion tag, shouldn't we reach out to the
> mappers that use shop=fashion ?
>
> Maybe they have a lot more domain knowledge than the people on this
> mailing list

There is of course value in sourcing outside of our group of
self-appointed priesthood - the values of clothes=* are a complicated
matter full of non-orthogonal dimensions, that absolutely requires input
from domain experts outside of this list... I did not know about the term
"fast fashion" until two minutes ago
(https://en.wikipedia.org/wiki/Fast_fashion).

But it will be nice when this mess is relegated to the clothes=* subtag
while shop=clothes provides a simple and universally recognized category
that contributors with no domain knowledge can apply easily with few
mistakes.

There will be arguments for a distinct shop=fashion category - some may
remark that shop=fashion sells some shoes and some accessories... But
those are accessory - the main product is clothes and I claim that, in the
present case, taxonomic compactness is more valuable than this minor
distinction.

While large groups are superior in providing more information, they are
incapable of simplification - pushing it requires a small group and the
proposal can then be submitted to the community as a whole.

> and can explain why they used shop=fashion and not
> shop=clothes; clothes=...

From the Openstreetmap data, I see no distinction in most cases - the
others look like they belong elsewhere, such as shop=cosmetics or
shop=bag.


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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On 3/10/19 1:30 PM, Markus wrote:

On Sun, 10 Mar 2019 at 10:35, severin.menard via Tagging
 wrote:

shop=boutique is also one of the most confusing tags for French speaking 
people, especially in Africa as boutique is used there for another type of 
shops (the most common one: small shops selling food items): 
http://overpass-turbo.eu/s/GOO

I'm aware of this linguistic problem. But instead of abandoning
shop=boutique, this problem can be solved if editors correct the
French translation ("boutique de mode"?) and if renderers display an
appropriate icon (maybe a shirt and a handbag?).


That would help - I would insist on the luxury aspect, something like 
"vêtements de luxe".


But ultimately, I believe that shop=clothe+clothes=luxury would take 
that special case back into the fold of a logical tagging scheme... The 
fewer special cases the better !




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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On 3/10/19 10:33 AM, severin.menard via Tagging wrote:

Date: Sat, 9 Mar 2019 23:16:58 +0100

From: Markus selfishseaho...@gmail.com

I'm in favour of deprecating shop=fashion because of its unclear
meaning, but i prefer to keep shop=boutique for (and only for) small
shops selling high-priced clothes and accessories.

shop=boutique is also one of the most confusing tags for French speaking 
people, especially in Africa as boutique is used there for another type of 
shops (the most common one: small shops selling food items): 
http://overpass-turbo.eu/s/GOO


Hello Severin ! Enock and I mentioned that here a few days ago - 
https://lists.openstreetmap.org/pipermail/tagging/2019-March/043462.html




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

Re: [Tagging] discouraging shop=fashion

[Jean-Marc Liotier]

On 3/10/19 9:11 AM, Mateusz Konieczny wrote:

Mar 9, 2019, 11:16 PM by selfishseaho...@gmail.com:

I'm in favour of deprecating shop=fashion because of its unclear
meaning

Based on discussion(s) it seems that there is no benefit from
keeping this tag.

I would support editors proposing to replace it by shop=clothes + 
clothes=*


I was about to post to say that - so I support this proposal.

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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On 3/6/19 8:51 PM, Markus wrote:

What you describe is a shop=newsagent [1]. I wasn't aware of this tag
until four days ago when someone mentioned [2] on the Swiss mailing
list that some newsagents (k kiosk brand) are wrongly tagged as
shop=kiosk instead of shop=newsagent. Unfortunately, the word "Kiosk"
is also used for newsagents in German (or at least in Swiss German).


That may be because in the French language a street stall that sells 
mostly newspaper with a side of candy is called "un kiosque à journaux"...




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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On Wed, March 6, 2019 4:33 pm, Mateusz Konieczny wrote:
> Yes, shop is not becoming shop=kiosk just becomes you are unable to enter
> inside.

Apologies - unsaid assumption was that we were talking about shops
carrying the typical convenience supplies, for which the distinction
between shop=convenience and shop=kiosk is necessary.

> In some funny cases kiosk-type shops (sells drinks, newspapers, magazines,
> snacks, cigarettes and the like) may be big enough that you can enter
> (for example at train stations).


Enock and I have West Africa in mind... Another unsaid assumption in our
exchange. The concept of kiosk in Europe is typically linked to press
distribution as an important part of its activity.

Moral of the story: check for unsaid assumptions and make them explicit...

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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On Wed, March 6, 2019 4:28 pm, Jean-Marc Liotier wrote:
>
> Enock's razor sums it up nicely:
> - stand outside to buy goods -> shop=convenience
> - you can enter the shop -> shop=kiosk

Aargl. I inverted it - gross mistake, sorry... So, again but in the
correct order:

Enock's shop razor:
- stand outside to buy goods -> shop=kiosk
- you can enter the shop -> shop=convenience


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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On Wed, March 6, 2019 4:23 pm, Tobias Zwick wrote:
>
> - convenience: small supermarket that is usually too small to have
> shopping carts but still also sells things of daily need (shampoo, toilet
> paper, milk, cornflakes, bread and spread,...). The typical 7-Eleven store
> (doesn't exist in Germany btw)
>
> - kiosk: very small store that usually only sells drinks, newspapers,
> magazines, snacks, cigarettes and the like. Sometimes even so small that
> you can't go inside but buy things through the window

This is correct, modulo local cultural differences. Enock's razor sums it
up nicely:
- stand outside to buy goods -> shop=convenience
- you can enter the shop -> shop=kiosk


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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On Wed, March 6, 2019 3:58 pm, Enock Seth Nyamador wrote:
> Jean-Marc I agree with about shop=boutique much used in West Africa. The
> reason being that the shops have boutique attached to their names.

Indeed. In Dakar and Bamako, when you need to buy a Fanta, tu vas à la
boutique... So I can't really blame contributors for using the word that
sound most natural to them.

Depending on how big the shop is, solutions would be shop=kiosk (after
years of pushing we are beginning to see that one adopted) and
shop=convenience (which is not used enough)


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

Re: [Tagging] shop=clothes vs shop=fashion

[Jean-Marc Liotier]

On Wed, March 6, 2019 3:42 pm, dktue wrote:
>
> I currently found out that shops that sell clothes are either tagged with
> shop=clothes or with shop=fashion
> but I can't find out when to use which.

shop=clothes only sell unfashionable clothes.

But seriously, shop=clothes is factual whereas shop=fashion is a matter of
appreciation, so I would go with shop=clothes and let subsidiary tags
optionally describe the particular sort of clothes sold.

And then there is shop=boutique which I hate with a particular passion,
not just because is is as subjective as shop=fashion but also because
"boutique" is French for "small shop" and it is therefore used all over
West Africa to tag all sorts of shops...

Links:
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dboutique
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dclothes
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfashion

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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On Wed, March 6, 2019 2:37 pm, Sergio Manzi wrote:
>
> I still fail to see _who could benefit_ from that fragmentary, sparse,
> information of unknown quality: I surely would not

I do not know either - but I'll let those who do have their fun and make
sure that it does not interfere with the common usage of navigational
cartography, hence my proposal of the straightforward basic attribute
chain and the optional radio stuff on top for those who enjoy it.

> (/but I'd probably be interested into knowing how high the antenna
> stands and approximately how big it is.../).

height=*, ele=* etc. -  yes, they apply too.

At some point we'll also have to draw the line between man_made=antenna
and man_made=mast (pretty sure there will be confusion for the typical
rural GSM BTS that are currently usually recorded as man_made=mast +
tower:type=communication - not very consistent but there are 56k
occurrences of that combination), and mention the cases where the
man_made=antenna may also be a building=* (that humongous radio-telescope
?)

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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On 3/6/19 6:00 AM, Warin wrote:

So .. what is the best way to map them?


My proposal would be a straightforward main tags chain to describe the 
physical landmark features - and then all the extra sauce specialists 
might want, but in a way that won't complicate the basics. So...


man_made=antenna
antenna=dish (or monopole/dipole/yagi/helical/phased_array ...)

and then radio aficionados may add as much of 
https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use as 
they want (so we would amend this proposal to make it a complement to 
the physical landmark features main tags).




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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On 3/6/19 3:31 AM, Sergio Manzi wrote:
My friend, there are 88 persons who have mapped 520 antennas 
(https://taginfo.openstreetmap.org/keys/antenna).


Compare it to the billions of antennas out there and I think we are 
far below the "/noise level/" and that all energy "invested" in trying 
to regulate this is... lost energy.


The only antennas I would personally map and tag are those who are 
enough conspicuous to represent landmarks


We are currently at 7252 for man_made=antenna alone 
(https://taginfo.openstreetmap.org/tags/man_made=antenna) and then there 
are all the strange things such as (man_made=mast + 
tower:type=communication) which may or may not record a mast with antennas.


But yes, my goal is landmarks such as conspicuous parabolas, not my 
neighbour's pet yagi.



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

[Tagging] leisure=common replacement for urban public areas in Africa

[Jean-Marc Liotier]

The openstreetmap-carto rendering of leisure=common was recently dropped
(https://github.com/gravitystorm/openstreetmap-carto/commit/4df96c4e4927c3e029b31e34c0cf1be2dda6f637).

In Mali and Senegal, I had found leisure=common to be an expedient way to
describe explicitly designed publicly accessible undeveloped
municipality-owned open dirt areas in cities, public squares in the barest
sense, used for gatherings, impromptu soccer games and more generally as
breathing space in a dense urban fabric: it is dedicated to leisure and it
is a common area...

But it did stray a bit from the original British vernacular meaning, which
was akin to landuse=village_green in that the commons are normally grass
covered. So I usually combined leisure=common with surface=ground or
surface=sand to express the African reality... But still - this bends the
concept quite far out of its original shape.

So, though we do not map for the renderer, maybe this is a good time to
find a better tag to map that feature.

My candidate is
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Drecreation_ground - and
now that I think about it, I wonder why I didn't use it to begin with.

As I'm the author of a good many leisure=common in Mali and Senegal, my
near-term goal about them is to replace occurrences of leisure=common with
the better term but only in Mali and Senegal.

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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On Mon, March 4, 2019 11:20 pm, Warin wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use

This is a way to solve most of the problem, but it fails the "map it as I
see it" test.

man_made=antenna + antenna:reflector=dish does map the satellite
communications antenna I just spotted... But what the naïve mapper I am
really wants is man_made=antenna + antenna=dish (or
monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !

Then one can add antenna:propagation, antenna:application,
antenna:propagation, antenna:polarisation etc. but they are accessory.

Am I mistaken in believing that the main tags chain should focus on
offering a straightforward way to map the apparent physical features,
rather than invisible distinctions ? Not that invisible distinctions are
not welcome too - but they should stay out of the way.

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

[Tagging] "satellit"

[Jean-Marc Liotier]

https://taginfo.openstreetmap.org/keys/antenna%3Atype#values mentions
"parabolic_satellit" "parabolic_satellit_uplink" and
"parabolic_satellite_uplink". I have two remarks about that...

First, evidently, "satellit" is wrong and should be "satellite"... Or have
I missed something ? Unless someone explains that "satellit" is a distinct
legit concept, I'll replace it globally with "satellite".

Second, do we want to specify "_uplink" where appropriate ? Most parabola
large enough to tag in Openstreetmap are going to feature an uplink. But
most important, the physical features of downlink and uplink/downlink
antennas are identical - the same antenna might even have more than one
feeder to switch its purpose. So, should we have only
"parabolic_satellite" or both "parabolic_satellite" and
"parabolic_satellite_uplink" ? Or should we leave the antenna's purpose to
a subtag (something like
antenna:purpose=downlink;uplink;uplink/downlink;tracking;etc.) ? I admit I
like the subtag option because it shifts the problem to somewhere it won't
complicate the mapping of physical features...

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

Re: [Tagging] Walking route on a beach

[Jean-Marc Liotier]

On Thu, December 20, 2018 1:04 am, Andrew Harvey wrote:
> On Thu, 20 Dec 2018 at 10:27, Sergio Manzi  wrote:
>> Why don't you use trail_visibility=no on the sections of path which are
>> invisible as they are just plain beach? Routing will not be affected (it
>> will work...).
>
> I agree. I think trail_visibility=no + surface=sand (or whatever the
> beach surface) is essential so that data consumers know this is just
> walking on the beach and there is no special infrastructure there

I agree that highway=path with the above precisions are an expedient model
to represent beach routing, but it is nevertheless most often a hack to
work around lack of routing across area features.

So, I'll gladly use highway=path + surface=sand + trail_visibility=no but
how to handle a walking route on a beach is actually a discussion about
routing - and a well-worn one:
-
https://www.researchgate.net/publication/305272744_Integrating_Open_Spaces_into_OpenStreetMap_Routing_Graphs_for_Realistic_Crossing_Behaviour_in_Pedestrian_Navigation
- https://github.com/Project-OSRM/osrm-backend/issues/64


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

Re: [Tagging] Power=cable for low voltage lines?

[Jean-Marc Liotier]

On 10/21/18 11:23 AM, François Lacombe wrote:
Le dim. 21 oct. 2018 à 09:21, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> a écrit :



no, the argument is that this is a basic distinction which anyone
can make, without knowing about transmission, distribution or voltage.

Line is on poles? so it is a minor line. On towers? line.

Which is not true because you find poles more massive than tiny towers.

Big... small... minor... major what does that mean?


height=* then ? A bit harder to describe for the novice contributor, but 
still within reach with no specific technical skills and it adds a 
measure of objectivity to the description. cables=* is even easier. Both 
provide a beginning of importance classification, accessible with no 
domain knowledge of the electric network. Maybe that is the way forward ?


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

Re: [Tagging] Power=cable for low voltage lines?

[Jean-Marc Liotier]

On Mon, October 15, 2018 2:28 pm, Joseph Eisenberg wrote:
> Is there any limit to what can be mapped power=cable ?
> Can micromappers use this tag for wires connecting their
> house to a garage ?

voltage=* is a clear importance filter that offers a simple practical
solution to fears of excessive detail - anything less than 1000 Volts is
low voltage and rendering shall relegate it to accordingly low scales.

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

[Tagging] Car pound, tow pound etc.

[Jean-Marc Liotier]

When the police impounds a wrongly parked vehicle, it takes it to a
managed parking facility where they keep it until the infraction is
resolved. How should we tag that place ?

There are single digit numbers of amenity=pound, amenity=car_pound and
amenity=tow_pound - that seems very little considering the widespread
police practice.

Or should we subtag it as a special sort of amenity=parking,
access=private ? It has also been done that way in quite a few places.

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

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

[Jean-Marc Liotier]

On Fri, 1 Dec 2017 01:33:16 +0100
Daniel Koć  wrote:
>
> land over which the public has general rights of use for certain
> leisure activities

That is exactly how I use leisure=common in Senegal: usually a
block-sized area in town, which has no dedicated purpose but to provide
some urban empty space for various activities such as public gatherings,
soccer games, children playing etc.

The British version is grassy, the Senegalese one is sandy and the
green rendering looks a bit odd - but the purpose of the commons are
the same, even though there is no legal definition in Senegal while
there is one in Britain.

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

Re: [Tagging] Swimming pool facilities

[Jean-Marc Liotier]

On Tue, 26 Sep 2017 18:38:15 +0200
Selfish Seahorse  wrote:
>
(2) indoor swimming pools seem not to be tagged

Because they do not appear on imagery, so fewer people are in a
position to map them... But nothing keeps anyone from tagging them.

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

Re: [Tagging] Swimming pool facilities

[Jean-Marc Liotier]

On Mon, 18 Sep 2017 10:56:59 +0200
Selfish Seahorse <selfishseaho...@gmail.com> wrote:
>
> On 18 September 2017 at 09:42, Jean-Marc Liotier <j...@liotier.org>
> wrote:
> > "sport=swimming for a centre containing one or more swimming pools
> > that is mainly focussed on swimming as a sport, including swimming
> > lessons. Use however leisure=swimming_pool to indicate the water
> > areas"  
> 
> This conflicts a bit with the definition of sports centre being a
> 'distinct facility where a *range of sports* take place'.

Hello semi-colon value separator !
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

sport=swimming;water_polo;fitness;scuba_diving 
 
> Apart from that, as José mentioned, the main problem is that sports
> centre does not seem to be appropriate for an outdoor swimming pool
> facility that is mainly used for recreation but doesn't meet the
> criteria of a water park.

Lounging & splashing around is a common use of sport swimming
facilities, but their designed use remains swimming as a sport. If it
has swimming lanes, it is definitely part of sport=swimming. If it
doesn't have swimming lanes, then it may lean on the side of the
leisure=water_park

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

Re: [Tagging] Swimming pool facilities

[Jean-Marc Liotier]

On Mon, 18 Sep 2017 09:46:24 +0200
Frederik Ramm <frede...@remote.org> wrote:
> 
> On 18.09.2017 09:42, Jean-Marc Liotier wrote:
> > Whole facility:
> > leisure=sports_center  
> 
> leisure=sports_centre (British English spelling)

Thanks. And I don't even have an autocorrect to blame...

On the upside, I just checked
https://taginfo.openstreetmap.org/search?q=leisure%3Dsports_center
which returns no records - I guess that there must be some automated QA
for that somewhere...

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

Re: [Tagging] Swimming pool facilities

[Jean-Marc Liotier]

On Sun, 17 Sep 2017 18:20:44 +0200
Selfish Seahorse  wrote:
>
> 
> The current situation of how public outdoor and indoor swimming pool
> [..]

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsports_centre#Combinations

"sport=swimming for a centre containing one or more swimming pools that
is mainly focussed on swimming as a sport, including swimming lessons.
Use however leisure=swimming_pool to indicate the water areas"

Whole facility:
leisure=sports_center
sport=swimming

The pools:
leisure=swimming_pool
indoor=yes

Existing practice is that everything is outdoor by default - exceptions
are marked with indoor=yes

leisure=water_park must be kept for the amusement park with features
like recreational swimming pools, water slides or lazy rivers.

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

Re: [Tagging] Feature Proposal - RFC - Sinkholes refinement

[Jean-Marc Liotier]

On Mon, 11 Sep 2017 07:54:09 +
David Marchal  wrote:
> [..]
> flow_direction=both, to model water streams connected to estavelles,
> which is a karst feature acting as spring or ponor depending on the
> current conditions, as these streams can have their flow reversed if
> the estavelle starts acting the opposite to usual; I remember this
> tag has already been used a few times in OSM.

That one is especially interesting as it answers the need of
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg84532.html
(in French) who wondered how to map waterways in marshy grounds, that do
not have a clear flow directions or whose flow direction may vary.

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

Re: [Tagging] Emergency shelters

[Jean-Marc Liotier]

On Thu, 7 Sep 2017 07:41:37 +0200
Marc Gemis  wrote:
>
> On Thu, Sep 7, 2017 at 6:44 AM, Nick Hocking 
> wrote:
>>
>> "I think amenity=shelter is well established  "
>
> The social facility shelter
> https://wiki.openstreetmap.org/wiki/Tag:social_facility%3Dshelter
> mentions emergency shelter.

amenity=social_facility + social_facility=shelter is foremost temporary
housing whereas amenity=shelter is a protection from something defined
in shelter_type=* (https://wiki.openstreetmap.org/wiki/Key:shelter_type)

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

Re: [Tagging] Feature Proposal - RFC - shop=clothes subtags

[Jean-Marc Liotier]

On Wed, 6 Sep 2017 13:40:16 +0200
Martin Koppenhoefer  wrote:
>
> my favorite one is this:
> http://www.23hq.com/dieterdreist/photo/7089481?album_id=4237494
> An optician also selling delicatessen (or maybe a delicatessen store
> also selling glasses).

http://www.openstreetmap.org/node/2217707756 - Khai Tri is a Vietnamese
bookshop in Paris, whose best known feature is the bánh mì sandwiches
stand at the back of the shop... For now in Openstreetmap it is only a
bookshop.

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

Re: [Tagging] Tagging data where position is not yet known

[Jean-Marc Liotier]

On Sun, 3 Sep 2017 22:35:04 +0100
 wrote:
> [..]
> I want to know how you feel about adding the market and water_pump
> data that does not yet exist on the map. In Africa the existence of a
> market and/or a water_pump is not only important information for the
> locals, it is important information for any medical or humanitarian
> teams carrying out any assessment or intervention in the area. I wish
> to add this data to the map near the name of the community with a
> fixme stating that the existence has been confirmed but the location
> is not yet known. The fact that it is there will be spotted by
> subsequent mappers and hopefully they will be able to move it to it’s
> correct location.

Others before you have not been shy of doing this - some of them
deliberately, sometimes with ugly blunt imports (*cough*schools in
Mali*cough*) and others just because the imagery they had years ago was
much worse than what we had today. So, there is a lot of precedent for
that.

The fixme (something like "Approximate location, in the viccinity of
this village") is of course a must. Beyond that, my opinion is that the
approximate POI should be clustered around the place=* so that they
appear to mean "this exists somewhere in this village" instead of
having them placed at random positions around where one might think
they are actually precisely there.

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

Re: [Tagging] shop=fashion shop=boutique

[Jean-Marc Liotier]

I still don't understand the need for anything other than shop=clothes
used with assorted modifiers. Fashion is subjective and I do not see
why exclusive distribution channels should be tagged differently as
they are essentially clothes shop with no price tags and an attitude.

shop=car covers both the average Volskwagen dealership and the workshop
that sells handmade locally built overpriced exotics with golden urinal
that you never heard of. Why should it be different for clothes ?

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

Re: [Tagging] shop=fashion

[Jean-Marc Liotier]

(late message because antispam rejected before)

On 2017-08-29 19:27, Severin Menard wrote:
>
> In French-speaking African countries, this generic word is massively
> used for the most generic shop by far: a small convenience store,
> selling food and non food items all over the walls, up to the
> ceiling, where you ask at a desk what you want. This makes it a kind
> of kiosk, even if many are not separate shops but taking one part of
> the basement of a building. And they are not chic at all. And they
> are very, very numerous: in a large city you find one every 50 or 100
> meters. For sure there are more African boutiques in the world than
> the boutiques of hand-made fashion clothes. Of course, new African
> contributors in these countries logically use shop=boutique for their
> own cultural reality so some streets in Africa are full of
> false-cognates.  

Here is what Séverin is talking about: http://overpass-turbo.eu/s/rkV
I guarantee that every single one of these shop=boutique in the Dakar
Peninsula are these shop=(convenience|kiosk) that most French-speaking
West-Africans name "boutique". We regularly correct them but they
sprout even faster - so much that it may indeed be argued that we
should go with the flow.

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

Re: [Tagging] Power Tower Landuse = ?

[Jean-Marc Liotier]

On Fri, 30 Jun 2017 12:37:52 +0900
John Willis  wrote:
>
> Which landuse is appropriate for power towers? 
> 
> here is a picture of some of the towers I am talking about. In this
> case, most are in or adjacent to a substation.The giant red-white
> towers in the picture are common in my area, and run across our
> region. they use a large 25mx25m piece of land for their base. I am
> talking about these towers when they are by themselves, in farmland
> or residential areas. 
> 
> The giant power towers have a mappable (usually fenced) landuse - the
> tower bases are usually near some kind of access road, and the land
> for towers is as large as a housing plot. Farmers do not farm under
> the base, even if there isn’t a fence, making it a separate landuse
> from whatever is around it. 
> 
> Somewhat related, micromapped solar panel installations [..]

And mobile network base stations, typically the same sort of fenced
square with a mast or a lattice tower, and a small shelter for network
& power equipement.

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

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Jean-Marc Liotier]

(Sent again, this time without all the cc: which probably are the
cause of the previous attempt being held in the listserv's spam filters...
After eleven hours I guess it won't be delivered to the list so I resend)

On Fri, 24 Mar 2017 19:08:13 +0100
yo paseopor  wrote:
>
> I would start a "definitive thread" with all the options, all the
> possibilities, all the points of view, all the information and then,
> passing all to the wiki with a votting or aproved by list complete
> proposal.

Well, heres is an attempt... At some point one may wish to paste it
into a wiki page. In cc: the participants in the threads recently
discussing this subject.

So, here is a summary of the methods that, after discussion here, seem
to have some traction among participants for the mapping of "stop"
restrictions and similar restrictions such as "give_way" and
"traffic_signals". This is about the restriction, not the sign that
advertises it. It applies to two-ways way, in cases other than an
all-ways restriction. I omitted some methods mentioned which seem too
ambiguous, too heavy on processing, lacking current use or all of the
above.


1- highway=stop+direction=forward node on the way to an intersection

Documented at https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
and https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way

Advantages:
- Only one additional tag
- Uses the widely used direction=* tag

Disadvantages:
- To be unambiguous, must be tagged on a non-intersection node
  adjacent to the intersection to which it applies
- Only good for covering simple cases: complex case require
  a more powerful method such as the relation (type:enforcement)
- direction=* is also used for cardinal directions, so two
  semantic fields coexist within the same tag


2- highway=stop+stop:direction=forward node on the way to an
  intersection

Documented at
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

Advantages:
- Only one additional tag
- Uses the *:direction=* scheme which is widely used for
  traffic_signals:direction=* and stop:direction=* and might
  therefore be unified later. Also used for railway signals.
- Cognate to the way Kendzi3D models signs

Disadvantages:
- To be unambiguous, must be tagged on a non-intersection node
  adjacent to the intersection to which it applies
- Only good for covering simple cases: complex case require
  a more powerful method such as the relation (type:enforcement)


3- relation (type:enforcement)
Documented at https://wiki.openstreetmap.org/wiki/Relation:enforcement

Advantages:
- The only method to unambiguously covers all cases
- Few additional tagging steps: creating the relation and adding a
  couple members covers the simple case
- Compatible with the node bearing the highway=* restriction being
  either on the way or elsewhere at the actual location of the sign

Disadvantages:
- A couple more additional tagging steps compared to
  the other methods
- It is a relation (relations are perceived as not
  beginner-friendly, and some consumers don't grok them)

My opinion is that method #3 must be promoted but current practice
hints that it might have to coexist with one of the two others (or both
if no convergence consensus emerges).

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

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Jean-Marc Liotier]

On Mon, 27 Mar 2017 14:08:55 +0200
Topographe Fou  wrote:
>
> When you say direction=forward I assume it is forward/backward and
> not other direction values.

Yes.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Fri, 24 Mar 2017 07:22:44 -0700
Tod Fitch  wrote:
>
> It is not clear what we have gained by spitting the original topic
> into multiple parts.

Nothing... Had I been aware of the other thread I would probably not
have started this one !

Oh well... 'git merge' for mailing list messages ?

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Fri, 24 Mar 2017 00:15:41 +0100
yo paseopor <yopaseo...@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer
> <dieterdre...@gmail.com> wrote:  
> > > On 23 Mar 2017, at 17:23, Jean-Marc Liotier <j...@liotier.org>
> > > wrote:
> > >
> > > - highway=stop+direction=forward node on the incoming way... Only
> > >  covers the simple case but covers it simply  
> 
> I prefer the subkey :forward / :backward because then we save one
> pair of key=value we can use to put the future unification of the
> meaning of traffic signs groups.

I was thinking about unifying using direction=* for all of them
starting now... But well - yours is an alternate way, which I find
acceptable too.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Thu, 23 Mar 2017 21:03:47 +0100
Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> > On 23 Mar 2017, at 17:23, Jean-Marc Liotier <j...@liotier.org> wrote:
> > 
> > - highway=stop+direction=forward node on the incoming way... Only
> >  covers the simple case but covers it simply  
> 
> 
> while this might work often with stop signs it'll hardly work with
> maxspeed signs, because the changing maxspeed requires to split the
> highway, so that there would be 2 highways ending in the same node
> and forward would not be clear of which way.

Maxspeed is a way attribute... Some may tag the sign anyway - I'll let
them have their fun but it doesn't make any sense to me.

stop, give_way and traffic_signals on the other hand, they are nodes.

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Thu, 23 Mar 2017 16:31:47 +0100
Martin Koppenhoefer <dieterdre...@gmail.com> wrote:

> 2017-03-23 15:47 GMT+01:00 Jean-Marc Liotier <j...@liotier.org>:
> 
>> I'm not operating a routing system so maybe someone who is
>>   might offer his opinion on that point
> 
> in another thread a few days ago there was a comment by Daniel
> Hofmann who works at mapbox on OSRM:
> https://lists.openstreetmap.org/pipermail/tagging/2017-March/031727.html

Wow, thanks - how did I miss this thread... Well, the good news is
that the question of traffic sign direction modeling is in the air !

So, OSRM doesn't grok relations and doesn't process direction=*
either, nor any of its cousin tags - and the whole thread does not
mention anything else that does, with the exception of Kenzi3D which
does  direction=* ... Very well then: since there is very little
consumption to impact with the choice of a modeling method, I would say
that we are rather free to propose an Openstreetmapically correct way
and data consumers shall follow.

After reading the thread, it seems that our ideas here are not
unlike what has been discussed there.

So I stand by my current position, supporting either or both:

- relation (type: to be defined) including the highway=stop node and
  the incoming way with a from:forward or from:backward role...
  Universal but some consumers such as OSRM balk at processing relations

- highway=stop+direction=forward node on the incoming way... Only
  covers the simple case but covers it simply

I believe that boiling down the issue to just those two (and maybe live
with them both for an indeterminate duration) would significantly
improve over the current state.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

So, summing up the ideas expressed so far, in the example case of a stop
sign on a two-ways way (not an all-ways stop), we have:

1- highway=stop+direction=forward node on the way to an intersection
- Advantages: simple, uses the well-known direction=* tag, easy for
  routers to interpret
- Disadvantages: to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it
  applies, only good for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case
- My opinion: looks good to me for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case. Is the simple case common enough for this duplication
  to be a net benefit ?

2- highway=stop+stop:direction=forward node on the way to an
  intersection
- Advantages: simple, uses the stop:direction=* tag which is coherent
  with traffic_signals:direction=*
- Disadvantages: new tag, to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it applies
- My opinion: just like n°1 but with an exotic tag for no benefit...
  Discard this proposal !

2- highway=stop node on the way to an intersection, with the nearest
  intersection being the one to which the sign applies
- Advantages: simplest method
- Disadvantages: slight processing burden for the router which must find
  the closest intersection to guess which one it applies to
- My opinion: might be too ambiguous for the routing processor, but I'm
  not operating a routing system so maybe someone who is might offer
  his opinion on that point

3- highway=stop on the right of the way when looking towards the
  intersection to which the sign applies
- Advantages: very simple, records actual location of the stop sign
- Disadvantages: heavy processing burden for the router which must find
  the closest way to guess which one it applies to
- My opinion: way too much burden on the routing processor... But
  again, I'm not operating a routing system so maybe someone who is
  might offer his opinion on that point

4- highway=stop near the way, with a two-node way attached as a
  "direction arrow"
- Advantages: well, it sort of would work
- Disadvantages: way too much burden on the routing processor, heretical
  to the Openstreetmap way
- My opinion: heretical !

5- relation (type: to be defined) including highway=stop and
from:forward (the incoming way arriving at the stop - must be connected
to the stop)
- Advantages: only a couple more additional tagging steps compared to
  the other methods (creating the relation+a couple members).
  Compatible with the highway=stop being either on the way or near the
  way at the actual location of the sign
- Disadvantages: a couple more additional tagging steps compared to
  the other methods... And it is a relation (which is not
  beginner-friendly)
- My opinion: must be retained because it is the only one which
  unambiguously covers all cases. The only question is: is it valuable
  to have another simpler relationless method to cover the common
  simple case ?

My opinion summary: n°5 is a keeper... Do we need n°1 too ?

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

Re: [Tagging] Spillways

[Jean-Marc Liotier]

On Wed, 22 Mar 2017 09:12:02 +0100
Jean-Marc Liotier <j...@liotier.org> wrote:

> On Wed, 22 Mar 2017 12:56:49 +0700
> Dave Swarthout <daveswarth...@gmail.com> wrote:
> >
> > You could also add emergency=yes to the above or create a new tag,
> > emergency=spillway  
> 
> waterway=spillway
> spillway=emergency
> 
> https://taginfo.openstreetmap.org/tags/waterway=spillway#overview

I answered too fast... Later in the thread John offers
waterway=spillway + emergency=yes + surface=* which seem even better
because it uses the generic emergency=yes instead of creating a new
spillway=emergency

spillway=* would only become preferable if a taxonomy of spillways
exists (such as main, secondary, emergency etc.)

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

Re: [Tagging] Spillways

[Jean-Marc Liotier]

On Wed, 22 Mar 2017 12:56:49 +0700
Dave Swarthout  wrote:
>
> You could also add emergency=yes to the above or create a new tag,
> emergency=spillway

waterway=spillway
spillway=emergency

https://taginfo.openstreetmap.org/tags/waterway=spillway#overview

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

On Mon, 20 Mar 2017 13:47:46 -0400
Kevin Kenny  wrote:
>
> If there is a traffic signal at an intersection, the default is that
> traffic from any direction will be facing a signal.

Yes, but only in the case of tagging the traffic signals at the
intersection node.

If the traffic_signals tag is placed on a way node, then there is
ambiguity. A human observer might guess that it applies to traffic
directed to the nearest intersection - and one might even implement
that as an algorithm... But it is ambiguous at best.

> I don't think with the present state of data consumers, that there is
> necessarily a "right way" to do this. Ultimately, it will be the data
> consumers that will decide what the "right way" is: tag your
> STOP and YIELD signs correctly

Yes, users are ultimately right... And expressing themselves early will
save everyone some of the chaotic period that precedes the settling in
of perennial tags. Implementation rules but discussing it a little
beforehand is valuable.

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

[Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

traffic_signals:direction=* is used on 27278 highway=traffic_signals
objects:
https://taginfo.openstreetmap.org/tags/highway=traffic_signals#combinations

highway=stop is combined with a direction tag on about 77000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=stop#combinations

highway=give_way is combined with a direction tag on about 43000 objects
(direction=backward, direction=forward and the literal direction=*)
https://taginfo.openstreetmap.org/tags/highway=give_way#combinations

Given how widely used the direction tag is for highway=* signs, why
isn't it also applied to highway=traffic_signals ? Does
traffic_signals:direction=* bear additional meaning that direction=*
does not convey ?

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

Re: [Tagging] health_facility:type vs. health_facility_type

[Jean-Marc Liotier]

On 2016-09-28 13:56, Janko Mihelić wrote:

> Maybe send an automatic message to those 66 users to see if they agree with 
> the edit, and if most agree, change them all

Good idea... I don't know how to send a message to such a group of users
- is there functionality provided for that ?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface earth vs ground vs dirt

[Jean-Marc Liotier]

On 04/12/2016 08:29 PM, Martin Koppenhoefer wrote:

ground is a synonym for [..] without man made coating


As I tag heavily with surface=ground, this is indeed my definition. I 
use that when I tag from orbital imagery, when I'm certain that there is 
no man-made coating but I can't distinguish whether the surface is sand 
or raw dirt... My on-the-ground (pun intended) experience of the areas 
where I use this tag (mostly Senegal) tells me that it is usually either 
or a mix of the two that varies along the way. When I have visual 
evidence that the highway is at least packed dirt, then I use 'unpaved'.



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

[Tagging] natural=river_terrace : open or closed way ? JOSM Validator and OSM wiki disagree

[Jean-Marc Liotier]

I have been tagging a big bunch of natural=river_terrace in eastern
Senegal. The features that I have been tagging are ridges that follow
the course of a river in rocky terrain - not quite a canyon, but more
abrupt than a valley... I could have tagged them as natural=ridge but I
stumbled upon natural=river_terrace and since they are dependent
features of the river I thought it would be more appropriate and
http://wiki.openstreetmap.org/wiki/Tag:natural%3Driver_terrace seems to
agree.
Anyway, I tagged natural=river_terrace on open ways - the same way it is
normally done for natural=ridge. The JOSM Validator doesn't like that:
"natural type river_terrace - Unclosed way". But then, the
http://wiki.openstreetmap.org/wiki/Tag:natural%3Driver_terrace proposal
mentions that natural=river_terrace should not be used on areas - only
on ways.So, which is right ? Open way, closed way or both ?And should
natural=river_terrace even exist or should it be natural=ridge +
ridge=river_terrace ?

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

Re: [Tagging] building=yes for multiple building

[Jean-Marc Liotier]

On 03/16/2016 03:47 PM, joost schouppe wrote:
Is it OK to map multiple buildings as one closed line with the 
building=yes tag ? Or does building=yes imply it is one single building ?


building=yes is a single building.

I have encountered this problem a lot in Senegal. I talked with local 
mappers and I found the root cause: university GIS courses teach them to 
map "built-up zones" and they gravitate towards building=yes for that. 
We are pushing the message that it is not the right way to do it - that 
is what landuse=* is for and there are also some place=* such as 
place=city_block.



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

Re: [Tagging] AirBnB

[Jean-Marc Liotier]

On 03/19/2016 05:41 AM, Dave Swarthout wrote:
I'm looking for a consistent way to tag AirBnB locations. It's 
probably sufficient to tag them as tourism=guest_house


tourism=guest_house
guest_house=clandestine

Beside all the arguments previously expressed here, many owners use 
AirBnB as undeclared income and the last thing they want is fiscal 
authorities noticing that their property is a guest house.



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

Re: [Tagging] Wharf

[Jean-Marc Liotier]

On 2016-02-17 15:18, Malcolm Herring wrote:

> From the IHO Hydrographic dictionary:
> 
> breakwater. A structure protecting a shore area, HARBOUR, ANCHORAGE, or BASIN 
> from WAVES. See also FLOATING BREAKWATER.
> 
> jetty. In U.S. terminology, a structure, such as a WHARF or PIER, so located 
> as to influence CURRENT or protect the ENTRANCE to a HARBOUR or RIVER.
> In British terminology, a PIER, usually of solid construction, intended as a 
> berthing place for vessels. See DOCK, LANDING, WHARF.
> 
> mole. A massive structure of masonry or large stones serving as a PIER or 
> BREAKWATER, or both.
> 
> pier. A long, narrow structure extending into the water to afford a berthing 
> place for vessels, to serve as a promenade, etc. See also JETTY.
> 
> quay. A WHARF approximately parallel to the SHORELINE and accommodating ships 
> on one side only, the other side being attached to the SHORE. It is usually 
> of solid construction, as contrasted with the open pile construction usually 
> used for PIERS
> 
> wharf. A structure serving as a berthing place for vessels.

Thanks - that is quite authoritative ! 

It seems that the orientation related to the shore (natural=coastline,
waterway=riverbank etc.) is quite unambiguous:
- Orthogonal: pier- Alongside: quay 

Then we have a second dimension related to how the object is built:
- masonry
- concrete pile
- wood pile
- metal pile
- ... 

Though the main dichotomy is masonry vs. pile. 

And then a third dimension that expresses whether or not mooring is
possible - which is nicely expressed by the well-used mooring=* tag
which can be applied to all the objects concerned. 

We can already drop the Openstreetmap use of wharf, mole and jetty which
are ambiguous and/or redundant. Also, dock is a specific concept
(enclosed+varying water height) that is very adequately expressed by
waterway=dock - so let's get that one out of the way too. 

Orthogonal, masonry and no docking is the special case of
man_made=breakwater, an already well-used tag - mooring=no is implicit
here, though the external boundary structure of a harbour may be a
breakwater with a quay on its internal side... No problem for
Openstreetmap - tag a man_made=quay on the internal side. 

man_made=pier is quite good as it is now - except that it is often
assumed to be supported by piles... We learned that, while piles are the
most common case, other cases exist such as masonry. I believe it would
be perfect if we could complement man_made=pier with a tag for that. 

man_made=quay looks fine too and might also in some (rarer) cases
benefit from such a tag. 

Together with a few special cases such as man_made=breakwater and
waterway=dock, I believe that man_made=pier and man_made=quay,
complemented with mooring=* unambiguously cover all cases where a few
ambiguous and somewhat synonym tags are currently used. 

So, how should Openstreetmap express how the object is built ? I would
argue towards using the well-used material=* tag... I specifies only the
material and not the sort of construction, but material=wood,
material=masonry, material=metal etc. are common values that feel quite
fitting to how we want to describe piers and quays. 

And then once set on that path, we'll one day be able to sunset
man_made=mole, man_made=wharf and man_made=jetty.

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

Re: [Tagging] Wharf

[Jean-Marc Liotier]

On 2016-02-16 17:26, Malcolm Herring wrote:

> On 16/02/2016 14:26, Jean-Marc Liotier wrote: 
> 
>> "môle" - which is a much better translation for "wharf"
> 
> No it is not - a mole (also an english word) is a solid pier - it is 
> masonry/stone/concrete structure that is built on the seabed & has the 
> function of a pier. The important difference is that a mole projects from the 
> land like a pier, & is not part of the land like a wharf/quay.

>From what I just wen reading, it looks like you are right - alongside
vs. perpendicular is the key. 

So is a mole a special sort of pier ? Then definition of "pier" in
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier is wrong, as it
is not always "a raised walkway over water supported by pillars". So
man_made=pier + pier=wharf, or man_made=pier +
structure=masonry/stone/concrete or man_made=mole ? 

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

Re: [Tagging] Wharf

[Jean-Marc Liotier]

On 2016-02-16 15:46, Volker Schmidt wrote:

> Wharf (US English) and Quay (British English) seem to be equivalent and 
> describe a fixed structure that has land on one side and water on the other, 
> but the French môle or brise-lames is different: it is a structure that 
> protrudes into the water, but is normally narrow and often there is not even 
> a walkway on it.

Look at this plan of Dakar's harbour:
http://www.portdakar.sn/images/stories/design/plangeneral.pdf - "môle"
is most definitely "wharf" and not narrow at all. 
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Wharf

[Jean-Marc Liotier]

TL;DR: man_made=quay unless objections are raised. 

So I have a few nice harbour wharves to map... 

I found landuse=wharf but it is only used 37 times:
http://taginfo.openstreetmap.org/tags/landuse=wharf 

man_made=pier is almost certainly not the solution, as
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier is explicit about
its use "for a raised walkway over water supported by pillars" - which a
wharf isn't: a wharf is solid masonry. 

Ooops... I just found my solution while looking up details to document
my question - https://en.wikipedia.org/wiki/Wharf [1]says "the term
_quay_ is common in the United Kingdom, Canada, Australia, and many
other Commonwealth countries, and the Republic of Ireland, whereas the
term _wharf_ is more common in the United States". And indeed, looking
up "Quay" on Wikipedia redirects there - and the French language synonym
for wharf is "Quai" (though strangely it doesn't mention the French term
"môle" - which is a much better translation for "wharf"... I may have to
put that on my French Wikipedia TODO). 

So, anyway, unless objections are raised, I'll be tagging wharves as
man_made=quay areas and I'll update
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dquay [2]which is
obviously incomplete (Now who is the numbskull who wrote this page ?
Ooops - it is me). 

Links:
--
[1] https://en.wikipedia.org/wiki/Wharf
[2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dquay
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is a reference a name if it is actually used as a name on the ground ?

[Jean-Marc Liotier]

Thanks Martin, Tijmen & Shawn - I'm now feeding those opinions to our
French-language discussion... I'll report back on our conclusions. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Is a reference a name if it is actually used as a name on the ground ?

[Jean-Marc Liotier]

Hello from Senegal - talk...@openstreetmap.org has a question about 
which we would like tagging@openstreetmap.org's opinion before we settle 
it for good.


For residential streets, we have a well-known and documented naming 
scheme as follows:


- name=* bears the official name
- loc_name=* bears a local name, which is often an old name but what 
matters is that it is a locally well used name
- ref=* bears a government official universal reference, which 
abbreviates the district and suffixes it with a number (for example "GY-63")


So far, so good. Now, the problem is that not all streets have a name - 
actually most streets are unnamed, so value of the ref=* is actually 
what people use as a name... It is not a name but it is used as a name. 
If it quacks like a duck... So here is the dilemma:


On the one hand, the content of ref=* is not officially a name - so one 
might argue that it has no title to being the content of name=*


On the other hand, the content of ref=* is used as a name - so it may 
just as well be argued that it is legitimate as a name=* value.


So here is the proposal so far most popular with the 
talk...@openstreetmap.org crowd: if no proper name=* exists, then the 
value of ref=* is copied to name=* - but of course any name that might 
be surveyed at a later time will overwrite that.


What does tagging@openstreetmap.org think about that ?

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

[Tagging] Factory, works & other ways to describe industrial production sites and their products

[Jean-Marc Liotier]

 

With about 11k occurrences
(http://taginfo.openstreetmap.org/keys/industrial#overview),
[1]industrial=* is mostly used for oil infrastructure but also for other
sorts of industrial activities. 

factory=* only occurs 569 times - with various values:
http://taginfo.openstreetmap.org/keys/factory#overview [2] - I like
industrial=* better because it covers more than factories. 

man_made=works dominates with about 83k occurrences:
http://taginfo.openstreetmap.org/tags/man_made=works#overview [3] - its
problem is that it requires an additional tag to describe its nature,
such as product=* (1844 occurrences -
http://taginfo.openstreetmap.org/keys/product#overview [4]) [5] or
works:type (210 occurrences -
http://taginfo.openstreetmap.org/keys/works%3Atype#overview [6]) which
describes either the product or the type. 

Also, the power=* space is a world of its own and there are quite a few
industrial facilities in the man_made=* space such as 37k
man_made=wastewater_plant or 128k man_made=storage_tank
(http://taginfo.openstreetmap.org/keys/man_made#values) [7]. 

So, if we exclude the power=* world and the man_made=* description of
specific industrial objects, if we discount the marginal presence of
factory=* (which may perhaps be discouraged considering the dominance of
alternatives), that leaves us with either standalone industrial=* or the
combination of man_made=works with a complementary tag such as product=*
or works:type=* - which both have merits and popularity. 

So, what does tagging@openstreetmap.org thinks about that ? Is the
tagging of industrial production sites and their products ripe for
standardization ? Which way seems like the right one to you ? 

Links:
--
[1] http://taginfo.openstreetmap.org/keys/industrial#overview
[2] http://taginfo.openstreetmap.org/keys/factory#overview
[3] http://taginfo.openstreetmap.org/tags/man_made=works#overview
[4] http://taginfo.openstreetmap.org/keys/product#overview
[5] http://taginfo.openstreetmap.org/keys/product#values)
[6] http://taginfo.openstreetmap.org/keys/works%3Atype#overview
[7] http://taginfo.openstreetmap.org/keys/man_made#values)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover=trees definition

[Jean-Marc Liotier]

On 03/08/2015 09:20, christian.pietz...@googlemail.com wrote:
landcover=trees has it's origins in this proposal: 
http://wiki.openstreetmap.org/wiki/Proposed_features/landcover
The proposal wanted to seperate the phsyical landscape (landcover) 
from the cultural landscape (landuse). But the proposal never got the 
support it needed to get established.


A pity - I just happen to have a problem that this proposal would 
solve... Take a look at this charming corner of Normandy: 
http://binged.it/1ht3p7v


On the left, a dense urban location that is clearly landuse=residential. 
On the right, what is most definitely landuse=meadow. So what about the 
center ? We see residential buildings among a predominantly grass 
cover.  In other areas, I have seen this mapped as landuse=meadow - but 
it is wrong because it is actually used as a residential areal.


To me, it seems that mapping this area as a combination of 
landuse=residential and landcover=grass would be most fitting. I have 
thought about using the landuse=residential + natural=grass combination 
instead, but those lawns do not strike me as natural.


What do you all think ? Is this a good illustration of the need for 
landcover=* ?



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

Re: [Tagging] SHAPE_Leng, SHAPE_Area, GIS_ACRES

[Jean-Marc Liotier]

On 04/06/2015 11:09, John Willis wrote:

Is there anything wrong with correctly mapping the borders of the blobs of 
woods (and doubling the number of nodes) if its correct?
Nothing wrong there - in Europe, people have been improving on CORINE 
Land Cover polygons since the dawn of time.



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

Re: [Tagging] housenumber on node and area

[Jean-Marc Liotier]

On 27/05/2015 09:47, Martin Koppenhoefer wrote:

Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier j...@liotier.org:

Absent any information, tagging the plot is better than nothing. A building is 
better - and even better is the main entrance or an even finer scheme to 
separate entrance and postbox.

By using an area we can omit the repetition of the address on all pois inside 
this area.

Indeed, that seems like a case where area is superior.

There may be other ways to cover this case. Among them I stumbled upon 
the associatedAddress relation at 
http://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress#Relation_associatedAddress 
but I have no idea about its relevance - I am definitely out of my depth 
here...



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

Re: [Tagging] housenumber on node and area

[Jean-Marc Liotier]

On 27/05/2015 09:57, Daniel Koć wrote:

W dniu 27.05.2015 9:38, Jean-Marc Liotier napisał(a):

Also, the address must be unique - it must not be present on more than
one object, even if more than one POI exists at that address.
So there are exceptions to this rule: I know at least one example 
where the same address is given for two different retail/service 
buildings (~500 m in city along river is rather a big distance, and 
it's not a tagging mistake).
So now I understand why some information systems I know use for the 
address a primary key distinct from any of the address's components. 
Using a random primary key also makes the address still relatable across 
events such as street name change.



On 27/05/2015 09:48, Martin Koppenhoefer wrote:

Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier j...@liotier.org:

Also, the address must be unique
why? 
Relational integrity ? But after Daniel's remark above, I now believe I 
was mistaken in how I understood address uniqueness: the address object 
that must be unique but two addresses may have the same attributes.


When French telcos send each other messages to order construction of 
local loops, they mention an address identifier - the address attributes 
are accessory.



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

Re: [Tagging] housenumber on node and area

[Jean-Marc Liotier]

On 27/05/2015 09:07, Colin Smale wrote:
What are the use cases for an address? Is it as a routing target? A 
label or annotation for a building? or a property in a looser 
sense? Is it for the benefit of the postman? Or what?


As Christian Quest explained on talk-fr just minutes ago, an address is 
all that and more: a building, a cadastral plot, an entrance, a piece of 
equipment inside... But foremost it is an identifier - being at a 
specific geographic position comes second to that.


Absent any information, tagging the plot is better than nothing. A 
building is better - and even better is the main entrance or an even 
finer scheme to separate entrance and postbox... But as Christian said, 
learning to walk precedes learning to run - having an address at all is 
the essential step.


Also, the address must be unique - it must not be present on more than 
one object, even if more than one POI exists at that address.



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

Re: [Tagging] HOT: potential Helicopter landings leisure=common

[Jean-Marc Liotier]

On 05/11/2015 09:42 AM, Paweł Marynowski wrote:

2015-05-11 8:53 GMT+02:00 johnw jo...@mac.com mailto:jo...@mac.com:

I’m not about to add a aeroway=helipad to the field because it
could be used for emergency evacuations.


In Poland we use emergency=landing_site for this. Check Overpass Turbo 
rendering of occurrences - they are located mainly on football pitches 
or similar places.

http://taginfo.openstreetmap.org/tags/emergency=landing_site


In an emergency, the helicopter pilot will use any football pitch he 
fancies... Being an emergency helo pad is implicit to the soccer pitch's 
nature - so why the extra tag ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Jean-Marc Liotier]

On 19/03/2015 15:42, Jan van Bekkum wrote:
Proposal 7 - use a forum instead of 4 mailing lists and a wiki (was 
proposed earlier).


Then you'll have 4 sub-forums and a wiki.


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

Re: [Tagging] place=block vs. place=city_block (was: Buildings blocks)

[Jean-Marc Liotier]

Has anyone ever mentioned merging place=block and place=city_block ? I 
have found no mention of this question. Would the merging of those two 
tags for an apparently identical concept be beneficial ? Of course after 
extensive discussion (and I won't be the one advocating either of the 
two - as long as one is chosen...)


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

Re: [Tagging] [Talk-bf] Buildings blocks

[Jean-Marc Liotier]

On 11/03/2015 17:29, Martin Koppenhoefer wrote:

Am 11.03.2015 um 14:59 schrieb Jean-Marc Liotier j...@liotier.org:

I'd only use admin_level if this is really an administrative entity. place and 
admin are orthogonal.
Yes, thanks for reminding that - let's keep admin_level out of the way 
of this discussion.



Place=plot is fine if these are really one plot, otherwise I'd go for 
place=block or city_block
Sounds reasonnable to me: place=city_block and/or place=neighborhood (as 
I guess there may be cases where a city block is larger than a 
neighborhood - so let's not force an unnecessary hierarchy) and then at 
the lowest level the place=plot.


To people from francophone West Africa who might read this thread, the 
French translation for 'lot' is 'parcelle' - which may or may not be 
superposed to its administrative cousin, the 'parcelle cadastrale' which 
is the basis for the calculation of municipal taxes.



([city_block] will look a bit silly in villages and hamlets)
I thought about that - but then I found that while a block is a synonym 
for a city block, it is also an administrative division of some South 
Asian countries: 
https://en.wikipedia.org/wiki/Block_%28district_subdivision%29


Wow - looks like we are going to settle the place=block vs. 
place=city_block discussion too...


Also, https://en.wikipedia.org/wiki/City_block says the block is 
divided into lots and https://en.wikipedia.org/wiki/Land_lot says that 
'lot' and 'plot' are synonymous... So, well - it all seems to hold 
together nicely. Or maybe I have a bad case of confirmation bias...


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

Re: [Tagging] [Talk-bf] Buildings blocks

[Jean-Marc Liotier]

On 11/03/2015 18:04, althio wrote:


To Séverin,

For your particular case with your students and considering your time 
frame I would say:

IMO it is taggable, no need to avoid in OSM. Go ahead.
My preference is either place=block or place=plot. Pick as you wish 
and set the trend.




Why not use both ? The two illustration below illustrate quite well how 
the city_block is divided into plots:

https://upload.wikimedia.org/wikipedia/commons/b/be/City_block.PNG
http://i.imgur.com/jbIe1vB.png

And it will be a great pedagogical opportunity to explain that not every 
tag is rendered by the demo rendering openstreetmap.org but that it is 
nevertheless useful to use it because other renderers or users in 
general will be able to use it anyway.



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

Re: [Tagging] Buildings blocks

[Jean-Marc Liotier]

On 11/03/2015 12:22, Martin Koppenhoefer wrote:


2015-03-11 12:12 GMT+01:00 Severin Menard severin.men...@gmail.com 
mailto:severin.men...@gmail.com:


I would like to know if putting building blocks in OSM should be
avoided in all cases. I am currently teaching GIS students in
Dakar that have ben required to digitize only building blocks on
their area of study. Could this been done on OSM (and in that case
how to tag it, as for landuse=residential encompass all the areas
covered by building blocks and streets?) or always avoided? I did
not find the answer in the wiki.


There is no general answer to this question. My personal suggestion is 
to tag them with landuse=residential and not include the streets (if 
they're actually residential areas), or commercial, retail etc. 
according to what is there. You might also want to split the block 
into more than one landuse if it is required to better represent reality.


Is it actually the building blocks that they want to map ? Or the urban 
land plots that often form a unit of habitation in moderately dense 
African cities ? I suspect that this thread is about the latter.


I am somewhat active in mapping Senegal and I have witnessed many 
attempts to map the fine subdivisions of the urban fabric - the whole 
plot mapped as a building, just its limit mapped as a wall, just a name 
with no other attribute, a landuse, or quite a few other creative 
misguided combinations that show that people really want to map that 
even if the editor shows no preset to that effect.


Those not used to map Senegal can take a look at the following orbital 
imagery for illustrations of what I have in mind:

http://i.imgur.com/jbIe1vB.png
http://i.imgur.com/8BvdP30.png

As you can see, each block is subdivided into land plots - each with a 
courtyard and several buildings that usually all belong to an extended 
family. Those land plots have a strong significance and the frequent 
sighting of spontaneous attempts by to map them in various ways is 
testimony to that.


I do not yet have an answer to this requirement - it should obviously be 
mapped as an area but I have so far failed to select satisfactory 
attributes to model it. I believe that landuse=* is not suitable - in 
Senegal, as http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal 
recommends, the whole urban area is landuse=residential, so it is not 
available to map smaller subdivisions.


cc: Augustin who might be able to tell us about how this issue is 
perceived in Burkina Faso.


(The two images above are also provide good examples of one of my pet 
peeves: the Senegalese spaghetti way syndrome - this is entirely 
off-topic but having corrected so many of them over the years I just 
felt a strong need to share it with someone)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-bf] Buildings blocks

[Jean-Marc Liotier]

On 11/03/2015 13:25, althio wrote:

I do not have the answer but I wanted to look towards place=* tagged as area.


I like that approach - it will let us position this entity within the 
existing frame of concentric urban territorial subdivisions.



place=block [taginfo ~1 200 as area] [no wiki]
place=city_block [taginfo ~900 as area] [wiki documentation, mostly in
Stockholm, Sweden]


Too big: looking at http://i.imgur.com/jbIe1vB.png shows that the city 
block encompasses eight to ten of the entities we seek to tag - numbers 
may of course vary worldwide, but the hierarchy will be the same.



place=neighbourhood [taginfo ~7 000 as area] [wiki, requires name
according to documentation]


Too big - even more than the block since is a neighborhood might 
encompass several blocks.



place=plot [taginfo ~900 as area] [no wiki]


I like that one a lot - looks very promising to me !

And look at http://www.openstreetmap.org/way/287224897 - it looks like 
UNHCR in Jordan follows the same line of thinking:


addr:postcode=JORZARV06B10P10
admin_level=10
bid=B10
blocdesc=Block 10
boundary =administrative
gid=271
name=Plot 10
pid=P10
place=plot
refugee=yes
vid=V06
vildesc=Village 6

I object to admin_level=10 since 
http://wiki.openstreetmap.org/wiki/Tag:admin_level%3D10#11_admin_level_values_for_specific_countries 
most often uses that for place=neighbourhood but apart from that it 
looks very similar to what we want to model. I would rather chose 
admin_level=11 which is not documented - though it has 4355 occurrences 
(http://taginfo.openstreetmap.org/search?q=admin_level%3D11)


In the same reasoning I mentioned for not considering place=block and 
place=city_block, it has blocdesc=Block 10 (which incidentally has a 
strong smell of UNHCR proprietary tagging - someone tell them that 
place=block and place=city_block exist ?)


Let's look at how it looks like on the ground: 
http://i.imgur.com/Ai2KgcB.png - it is in a refugee camp, but I'm 
convinced it is the same concept (and the way the Syrian conflict is 
going, come back in five years and it will look exactly the same as the 
Senegal example).


Or look at Mama Muga's Plot in Kibera : 
http://www.openstreetmap.org/node/612007108 - definitely the concept we 
have been discussing, mapped as place=plot


As a bonus, it has some degree of kinship with the concept of 'cadastral 
plot' which is its more administrative cousin.


Color me convinced - place=plot has my vote !


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

Re: [Tagging] [OSM-talk] Quay

[Jean-Marc Liotier]

(This discussion originated on talk - crossposted to tagging on 
Malcolm's suggestion)


On 26/01/2015 21:16, Malcolm Herring wrote:

On 26/01/2015 19:23, Jean-Marc Liotier wrote:
http://wiki.openstreetmap.org/wiki/Proposed_features/Harbour#Quay 
mentions that a quay will normally be tagged as part of the 
coastline natural=coastline. Apart from that I found no clue 
anywhere else about how a quay should be tagged... Am I missing 
something ? Considering how well-used man_made=pier is, I am 
surprised that quays get such scant attention. man_made=quay anyone ? 
To quote the IHO dictionary: quay. A WHARF approximately parallel to 
the SHORELINE and accommodating ships on one side only, the other side 
being attached to the SHORE. It is usually of solid construction, as 
contrasted with the open pile construction usually used for PIERS.


So yes, your reasoning is correct  that section of the coastline that 
forms the quay could indeed be tagged man_made=quay.


Yes, this is about what I had in mind:
- Either take a section of natural=coastline and overload it with 
man_made=quay

- Or draw a dedicated man_made=quay way on top of a natural=coastline

I have no idea which one would be best. I lean towards the first one for 
easier editing - ways exactly on top of each other are difficult to select.



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

Re: [Tagging] Date of survey

[Jean-Marc Liotier]

On 12/23/2014 05:16 AM, Marc Gemis wrote:
On Mon, Dec 22, 2014 at 8:56 PM, Jean-Marc Liotier j...@liotier.org 
mailto:j...@liotier.org wrote:


On 12/22/2014 08:28 PM, Marc Gemis wrote:

I always use the tag combination source=survey ;
survey:date=year-month-day
as described on http://wiki.openstreetmap.org/wiki/Key:survey:date


Whether on the changeset or on the object - whichever is most
appropriate, automatically adding the current date as survey:date
whenever a source=survey is entered could be a nice optional
editor functionality.

Which would not help in my case, as I work for several days on the 
same survey.


Is a precise date necessary ? My use of the survey date could tolerate 
just recording year and month... What moves so fast that the precise day 
is important ? Some things I guess... But then wouldn't the current date 
be a decent default for most cases ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Street cabinet - Voting

[Jean-Marc Liotier]

On 17/11/2014 13:19, Martin Koppenhoefer wrote:


man_made=street_cabinet
is implicitly rejecting 'countryside cabinet' or cabinets in
motorways, parks, fields, train stations, airports and so on.


IMHO it is not. Don't read this overliterally.


Indeed - like 'Openstreetmap' which, as some may have noticed, is not 
actually all about streets...


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

Re: [Tagging] Feature proposal - Street cabinet - Voting

[Jean-Marc Liotier]

On 17/11/2014 15:14, althio forum wrote:

Martin, Jean-Marc, I appreciate the feedback. You are voicing some
good elements. I am not totally convinced yet about generic vs
specific. Fairly generic tag like 'man_made=cabinet' sounds very
sensible as first level. Furthermore I do feel other proposal I have
seen like 'street_' and 'technical_' are not necessary and not even
useful.

[Derailing a bit]
IMO it is a poor justification to compare a brand new tag (here
'street_cabinet') with the 10-year old established name of the project
'Openstreetmap'.

Even more... Historical justification is sometimes inevitable but
often it is rather unsatisfactory in my mind. [..]


I may have been stretching the 'Openstreetmap' case a bit. I agree with 
your arguments - my personal choice would be technical_cabinet. I 
nevertheless chose to approve the proposal because I considered this 
issue minor compared to all the work that went in organizing the 
scheme... The issue smelt a lot like bikeshedding to me and experience 
in free software projects shows that it is usually better to avoid focus 
on that. I may be wrong - it could also be a fundamental modeling issue 
that we will regret eternally.


One may have suspected a French telco etymological bias as we call those 
cabinets 'armoires de rue' - literally 'street cabinet'... But as the 
proposal's page history and its approval signatures show, the consensus 
is actually international. So for once, the French telco mafia is not to 
blame.



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

Re: [Tagging] aeroway=taxiway as area

[Jean-Marc Liotier]

On 08/29/2014 10:38 PM, Nelson A. de Oliveira wrote:

Why the value description table of
http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway states that
aeroway=taxiway should not be used on areas?

Is there a valid point for this ?


If you are going to perform airport routing (now that would be quite 
exotic), my understanding is that typical routing engines don't take 
surfaces into account in their calculations. Otherwise, just make sure 
that you are not confusing aeroway=taxiway with aeroway=apron - most 
airport surfaces that you might be tempted to model as surfaces are 
actually aprons rather than taxiways.


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

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Jean-Marc Liotier]

On 08/25/2014 11:09 PM, Lukas Sommer wrote:
In Ivory Coast, you have addresses like “in front of the XYZ 
crossroad” or “from XYZ crossroad 50 m towards the big fueling 
station”. Rather a sort of instructions for getting somewhere than an 
address in the european sense. Obviously “from XYZ crossroad 50 m 
towards the big fueling station” will be applied to various houses 
(usually, when you have arrived, you make a phone call to the person 
that you want to meet, and the person comes to the road to search you 
and help you with the last part of the way – I can guarantee you that 
this is very time-consuming ;-)


That said, people in quite a few African countries have a postal address 
(PO box in most cases) distinct from the address of their residence, so 
the problem of shoehorning directions in the standard address fields of 
European-designed software is side-stepped more often than not.



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

Re: [Tagging] Bitcoin ATM (amenity=atm | currency:XBT=yes)

[Jean-Marc Liotier]

On 09/06/2014 22:12, nounours77 wrote:
Go out and ask hundred people on the street what a ATM is - and 
everybody will answer you the same thing. [..]


ATM = Automatic Teller Machine... An electronic telecommunications 
device that enables the customers of a financial institution to perform 
financial transactions without the need for a human cashier, clerk or 
bank teller [..] Using an ATM, customers can access their bank deposit 
or credit accounts in order to make a variety of transactions such as 
cash withdrawals, check balances, or credit mobile phones 
(https://en.wikipedia.org/wiki/Automatic_Teller_Machine)


So an ATM that manages Bitcoin transactions is most definitely amenity=atm.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

[Jean-Marc Liotier]

Well... Private messages tell me that boules might be popular outside of 
France, so here is a translation for a more international debate...


According to http://wiki.openstreetmap.org/wiki/Tag:sport%3Dboules a 
petanque pitch (leisure=pitch) is:

sport=boules
boules=petanque
(375 nodes, 75 ways - http://overpass-turbo.eu/s/3op)

But according to http://wiki.openstreetmap.org/wiki/FR:Key:sport it is:
sport=boules
type=petanque
(607 nodes, 111 ways - http://overpass-turbo.eu/s/3oo)

Any opinions on a future harmonization of the tagging of boules game types ?


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

Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

[Jean-Marc Liotier]

On 15/05/2014 14:43, nounours77 wrote:

bowls=bowls | petanque | bocce | whatever


One could argue that locale=c would lead us toward using 'bowls' but on 
the other hand even the English-language Wikipedia article for bocce 
mentions that it is a ball sport belonging to the boules sport family 
thus hinting that 'boules' is the correct term for the main sport=* tag. 
The international spread of sport=boules validates that: 
http://overpass-turbo.eu/s/3oy


So I would lean toward:
leisure=pitch
sport=boules
boules=petanque|whatever


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

Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

[Jean-Marc Liotier]

On 15/05/2014 18:22, fly wrote:


Pretty much everyone has agreed that the type=* is being abused and that
chaining sport=boules;boules=petanque is cleaner so I'm going to correct
the 718 occurrences of sport=boules;type=petanque into
sport=boules;boules=petanque.

This would be an automatic edit and at least should be open for
discussion for more than some days.


Yes - I'll let it cool down for a while.


I might also do it for sport=boules;type=bocce which would become
sport=boules;boules=bocce.

There are 1093 occurrences of sport=boules;type=* :
http://overpass-turbo.eu/s/3oF

Well then why not use boules:type ?


From messages here, on talk and on talk-fr, there seem to be a 
consensus about namespace chaining such as sport=boules;boules=bocce. No 
one has offered sport=boules;boules:type=bocce - maybe because the 
boules namespace most probably won't expand into complexity that 
justifies subkeys.


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

Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

[Jean-Marc Liotier]

On 05/15/2014 06:41 PM, Martin Koppenhoefer wrote:

 2014-05-15 18:30 GMT+02:00 fly lowfligh...@googlemail.com
 mailto:lowfligh...@googlemail.com:

 Wikipedia makes a difference between boccia and bocce, even if it is
 just the italian name.


 the Italian wikipedia states that Boccia is Bocce for disabled
 people, the english WP says it is something very similar. I am no
 expert in this field but had always assumed that both are the same
 (bocce is the Italian plural of boccia). In doubt, leave it as it is.

I certainly don't intend to touch the values - just the tagging
scheme... I'll leave the boccia vs. bocce debate to talk-it !
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Optical telecomunication cable tagging

[Jean-Marc Liotier]

On 03/03/2014 22:13, François Lacombe wrote:

I've found a dozen of markers in the country around my home, like this :
http://www.infos-reseaux.com/photos/image/217-identification-telecom-trn

It identifies terrestrial optical fibre cables going underground 
between cities in France.


How should it be mapped in OSM ?


Those cables are not visible and therefore should not be mapped.

Being in charge of GIS projects for the fiber network of a major 
telecommunication operator, my opinion is that Openstreetmap will never 
achieve any useful view of optical networks: those cables are everywhere 
but their path is usually not visible from public right of ways.


I contribute to the mapping of high-voltage lines, which are major 
landmarks. I support the mapping of cabinets, which are minor urban 
landmarks. I understand that some may be willing to map 
telecommunications chambers, whose metal opening is visible on the 
surface. But spare yourself the pain of mapping underground cables - I 
guarantee it is a hopeless and useless endeavour.



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