Re: [Tagging] Tag destination vs. relation destination_sign

[Martin Vonwald]

2015-01-15 22:12 GMT+01:00 fly :

> Please, do not forget to mention direction:lanes*.
>

destination:lanes ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag destination vs. relation destination_sign

[Martin Vonwald]

2015-01-15 19:48 GMT+01:00 Lukas Sommer :

> To clarify the wiki a little bit more, I would also add to the
> key:destination page a sentence like “Where to use? Use destination=*
> on the highway (OSM way) after the position of the
> signpost/groundwriting.” And I would remove (as explained above) the
> three examples with the yellow/white signposts for being confusing.
> Thoughts?
>

I think you are right.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power networks European codification scheme

[François Lacombe]

2015-01-15 21:27 GMT+01:00 Ole Nielsen :

> I'm not sure how these codes could benefit OSM.


It's been a long time we need unique codes to identify infrastructure
features (or group of features) instead of their own OSM ID (when you
delete something and redraw it, the ID has changed, not the EIC code).
Finding an identification scheme at such a large scale is not so easy.

A second benefit is to talk the same language as other DB or systems
instead of creating our own way to distinguish objects.



> They seem to be mostly for use in transactions between entities such as
> TSO's and would have little public interest, even for power grid 'nerds'
> like me.
>

According to what is said above, I respectably disagree.


>
> Further, from where would you get these codes (with an odbl compatible
> license)? I have never seen such codes used on public websites of TSO's and
> power companies. And I don't think they label substations, power plants
> with such codes at the gates so you can't get them from surveys.
>

The EIC scheme is yet young.
The power market has been driven for years by a strong opendata movement
and it's possible to ask ENSTO-E to publish their codes under OdBL license.

The goal of my original question isn't to start publishing codes in OSM
immediately but to find the best key to do it and to be ready when the time
comes.


Cheers

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Cluster

[Lukas Sommer]

What you propose is an algorithm that does a sort of “guess”. For
doing some sort of guess, we don’t need to introduce a new relation.
That could be done also without a relation.

Introducing a new relation should lead to better data and more
well-structured information. There should be a certain gain in
information. This will work only if the relation proposal is really
clear. If not, probably it will happen the same things as with the
“site” relation (=there are “site” relations in the database, but
little software support for this).

I think that Никита has touched a very important question: Is there
inheritence? Means: Are tags on the relation also considered tags of
the members? And how to deal with conflicts? This is not as trivial as
it sounds. I’ll take some of your examples:

– “name=Schwedenhöhlen” + “natural=cave_entrance” on the relation.
“name=Schwedenhöhle 1…” + “natural=cave_entrance” on the nodes. Open
questions: What does the relation represent? A collection of cave
entrances? Or the caves themself? If it represents the caves themself,
the tag natural=cave_entrance does not seem to be too appropriate. If
it represents a collection of cave entrances, a rendering of the
general name might be useful. But it might be useful to render it
bigger than the individual names.

– “name=Schwedenhöhlen” on the relation. “name=Schwedenhöhle 1…” +
“natural=cave_entrance” on the nodes. You would have to go to the
nodes, interpretate them and use the same rendering style also for the
relation. Probably also not as trivial as it sounds. What, if not all
nodes does not have the same tag (example: a natural=cliff within this
group). Is this considered as error? Does this prevent the rendering?
Your proposal was was count: More natural=cave_entrance occurences
than natural=cliff occurences would make the relation render as a
natural=cave_entrance. For me, this does not look like an improvement
of the current data quality, but rather like a degradation of the data
quality. At least, I would suggest to treat such cases as “invalid”
relations which should be ignored by data consumers.

–  “name=Schönefelder Seen” + “natural=water” on the relation. No tags
at the member areas. Is the “name” tag propageted to the members? If
soo, we have the same problem like before: The name “Schönefelder
Seen” is not appropriate for them. If the “name” tag is _not_
propageted to the members, we have another problem: “natural=water”
has to be propageted to the members nevertheless; so we have some tags
that are propageted (natural=water) and others that are not propagated
(name=Schönefelder Seen), and we need rules how to determine which
tags are propageted and which tags are not propagated.

–  “name=Schönefelder Seen”  on the relation. “natural=water” at the
member areas. Members propagate their tags to the relation. So a
renderer can determine the color for rendering the name of teh
relation. Sounds easy for the “Schönefelder Seen”. But this solution
would create conflicts when applied to the caves, because the cave
relation members have also individual names, and these names would
conflict with the relation name.

All this is too complex for a catch-them-all algorithm. To get a good
rendering, you will probably need special algorithms for each type of
feature.

I understand that you want to have a simple and generic solution. But
I doubt that this will create any benefit in the real practice. And I
fear – if it is as generic as you propse – it will end up like the
“site” relation.

Your original idea was to give to give a common name to various
objects. So, logically, the relation could be limited for usage
together with the tag “name”: Something like type=common_name for
relations, together with name=* on the relation. The members have an
empty role. The members may not have any of the name*=* tags. All
members are requiered to have the same tags; otherwise the relation is
considered invalid. But even this is problematic: Imagine that you
have boat=yes at one of the “Schönefelder Seen” lakes and boat=no at
another of the “Schönefelder Seen” lakes. Imagine further a renderer
that renders the labels of lakes in different colours, depending if
the can be used by boats or not.

I think we need a special tagging for each of these features. But
type=cluster could help anyway. Introduce type=cluster for relations.
But use it only together with special tags like natural=group_of_lakes
– these special tags needs to be introduced also. type=cluster could
also be used together with the existing place=archipelago. So you
would have to make an own tagging decription for each feature (group
of lakes, group of cliffs …) and this leads to a clear documentation
and clear rules.

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Dan S]

2015-01-15 23:48 GMT+00:00 Friedrich Volkmann :
> On 15.01.2015 13:10, Dan S wrote:
>> The addrN scheme is really quite awkward
>
> Can you explain why you find it awkward?
>
> It seems to me that the displeasure felt with the addrN scheme is caused by
> a phenomenon called transference. Multiple addresses in the real world are
> awkward, but they do exist and we cannot change that annoying fact.
> Therefore, the negative feeling transfers to the tagging scheme that
> represents the awkward reality. The awkward reality cannot be defeatet, but
> its representation can.

I would give a different reason: I find it awkward because OSM's data
model, with a flat list of key=value tags, doesn't fit well to this
particular reality. A lovely data model would be hierarchical, where
our object could have an "addr" key containing two values, and those
two values would themselves each be a dictionary of "housenumber=Y
street=X ..." etc. That's why I find it awkward - but as I said, in my
opinion there isn't a non-awkward way to solve this!

Dan

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

Re: [Tagging] waterway=wadi problem

[Volker Schmidt]

Looking around in Wikipedia:
Wash = Arroyo  =  Barranca = Wadi = Rambla = normally dry river bed, often
subject to flash floods in case of upstream rain.

If we have the the established term wadi for this, why create additional
nearly synonymous tags?



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

[Tagging] Overhead signs (Überkopfwegweiser)

[Andreas Labres]

Hello,

I'd like to suggest an idea to map overhead signposts
("Überkopfwegweiser" in German):

Here is a photo of the sign to be mapped:

   http://commons.wikimedia.org/wiki/File:A23_Knoten_Kaiserm%C3%BChlen_1.JPG

To map:
Put a node on the way of the street exactly where the sign is located
and tag it something like this:

overhead-sign=|| Brno, Gänserndorf, Stadlau [A23]; | Praha [A23]; / Kagran [B3];
> Ölhafen Lobau

* with the arrows represented by:

|     up arrow
/     slight right arrow
>     turn right arrow
\     slight left arrow
<     turn left arrow

* the text indicates the text that is written on the sign
  (the text should match any destination= tags given on exits)

* refs are given within square brackets [...]

* a semiconlon ; separates the arrows

This gives a router the possibility to show a drawing of
the sign, depending on the direction:

heading Brno:
+---+
| Brno,... [A23]|
|^^   ^ />  |
|||   |//   |
+---+

heading Praha:
+---+
|  Praha [A23]  |
|   ^   ^  ^/>  |
|   |   |  |   //   |
+---+

heading Kagran:
+---+
|  Kagran [B3]  |
|   ^   ^   ^/   >  |
|   |   |   |   /   /   |
+---+

heading Ölhafen Lobau:
+---+
|  Ölhafen Lobau|
|  ^   ^   ^/   >   |
|  |   |   |   /   /|
+---+

(this ASCII art should of course be a drawing with "real"
arrows, nice ref-shields and so on)

Of course this should match the information given in any lane tags,
but it gives the exact position of the sign and it works without
the need of lane tags! That way it should be much easier for
routing app developers to implement hints which lane to use.
For the driver, it's simpler to match the sign given by the app
with the real sign.

/al


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

Re: [Tagging] Basic philosophy of OSM tagging

[Pieren]

On Thu, Jan 15, 2015 at 9:13 PM, Kotya Karapetyan  wrote:

> There will be a tagging
> committee: It will maintain the official OSM tagging scheme.

Historical contributors and leaders will tell you that there is no
"official committee" in OSM. But, to be a litle provocative, I would
say we already have two committees for tagging scheme:
- the JOSM presets maintainers
- the DWG

Pieren

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

Re: [Tagging] Tagging a corner address with addr:street:corner=*

[Friedrich Volkmann]

On 16.01.2015 05:28, Eugene Alvin Villar wrote:
> In my country (Philippines), many corner addresses are specified with the
> intersecting street instead of (or in addition to) the house or building
> number. This actually makes sense because the house numbers are not
> immediately obvious when looking at a map, but intersections are quite easy
> to spot leading to easier (manual) navigation.
> 
> Here are three examples of actual addresses (with the corner address part
> highlighted):
> 
> 1. New World Manila Bay Hotel[1]: 1588 *Pedro Gil cor. M.H. Del Pilar*,
> Manila, Philippines, 1004
> 
> 2. Security Bank - Malabon branch[2]: #2 *Rizal Avenue corner Manapat St.*
> Metro Manila 1473
> 
> 3. Ayala Museum[3]: *Makati Avenue corner De La Rosa Street*, Greenbelt
> Park, Makati City 1224
> 
> In line with this, our local community has decided to mark the intersecting
> street with the addr:street:corner=* tag (already in use more than 1200
> times[4]) as a natural extension to the established addr:street=* tag.
> 
> I was wondering if the prevalence of corner addresses are also found in
> other countries, and if so, what the OSM communities in those countries do
> to tag these addresses. I hope that we can establish the use of the
> addr:street:corner=* tag or something similar.

http://taginfo.openstreetmap.org/keys/addr:street:corner#map

It does not look as if that key is used anywhere outside the Philippines.

Here in Austria, we sometimes use corner addresses informally, when verbally
(e.g. on the phone) arranging an appointment, or when describing how to find
a certain shop. But these discriptions are not considered addresses. They
are never used officially. There are two reasons:
- Corner addresses are much longer than street + housenumber.
- Corner addresses are ambiguous if there's more then 1 building or estate
adjacent to the junction. A T-shaped junction has 2 corners adjacent to it,
a "+" shaped corner even 4.

Anyway, if corner addresses are in use in your country, you need a tag for them.

I don't like the addr:street:corner key because it contains a second colon
for no obvious reason. addr:street:corner is not really a subkey of
addr:street. I would consider a tag name like addr:street_corner or just
addr:corner or using a tag for each street (addr:street=* + addr:street1=*).
However, it is probably too late to change that, given that the
addr:street:corner key is already in use. So I suggest to just document it
on http://wiki.openstreetmap.org/wiki/Key:addr, maybe with some reference to
the Philippines concerning usage and origin of the tag.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature proposal - Voting - Water tap

[Pieren]

On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan  wrote:

> As of today, a total of 16 votes have been submitted, 11 of them are
> approvals. Since 2 weeks have passed and the required number of votes
> (15) has been reached, I have closed the voting and will proceed with
> clean up.

Sorry but you could extend the period of feedbacks. 7 of the 11
positive "votes" came before the 13th january when I posted my
comments about the possible issues (and the discussion forwarded here
which probably drew more attention to more people). After this date
the trend was much more balanced. You say you are aware of the clash
with amenity=drinking_water but you don't explain how you will avoid
this in your cleanup. You also agree that we need a rework but your
proposal is just increasing the difficulties than solving them in the
future. Now, for a water tap in the public space, it will be tagged
with "amenity=drinking_water". And for the same water tap inside or
near a cemetery, it will be tagged with "man_made=water_tap". How can
we explain that to newcomers ? why "amenity" in one case and
"man_made" on the other ? what is implied about potability ? etc

Pieren

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Markus Lindholm]

On 16 January 2015 at 01:04, Friedrich Volkmann  wrote:
> We can discuss its pros and cons, but I
> think the main message is that multiple addresses are mapped differently all
> over the world. Every country has its local OSM community which concoct
> their own tagging rules. The result is database full of tags that are
> understood by the local mappers, maybe by local applications too, but not by
> mappers or applications from other countries. We really need some unifying
> tagging scheme suitable for all kinds of addresses worldwide.

What we don't need is yet another special case mapping scheme like addrN

Have you had the time to look at the existing relation of type=provides_feature
http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature
and how you can use it to associate multiple addresses to a building.

/Markus

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

Re: [Tagging] Basic philosophy of OSM tagging

[moltonel 3x Combo]

On 14/01/2015, Warin <61sundow...@gmail.com> wrote:
> Are 'we' tagging for
>
> What things are? eg highways
> OR
> What things are used for? eg amenity

Why does it have to be one exclusive_or the other ? Both what things
are and what they are used for is important. There's normally always a
way to tag both, even if the tags to do that can be a bit bysantine.
New tags may want to focus on one aspect or the other, there's no hard
rule.

The highway tag is a poor example for the nature/use dichotomy. The
interpretation differs by country (hopefully not within a country).
Some countries place more importance on use (amount and type of
traffic...) than on nature (surface, width...). Other countries adhere
rather strictly to the national road refs, even if the road changes
classification for purely administrative reasons (so neither nature
nor use). What the highway tag is a good example of, is the organic
evolution of osm's tagging system.

One good example of nature vs use is church buildings reconverted to
shops/pubs/tourist offices (all 3 can be seen in Dublin) and
place_of_worships in various incongruous buildings. The building tag
is now clearly documented as pertaining to the nature of things, but
this hasn't always been the case and a lot existing building tags have
dubious values.

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

Re: [Tagging] waterway=wadi problem

[Richard Z.]

On Thu, Jan 15, 2015 at 11:41:26AM +0900, johnw wrote:
> I strongly disagree. A wadi is usually only an active river through very rare 
> flash flood events, and almost never any other time.  Entire biomes are 
> defined by the presence of (and situated in) a wadi. 
> 

how about reading wikipedia?
<<
Wadi (Arabic: وادي‎ wādī) is the Arabic term traditionally referring to a 
valley. In some cases, it may refer to a dry (ephemeral) riverbed that contains 
water only during times of heavy rain or simply an intermittent stream.
>>

I consider a wadi a geologic feature. In addition to the above wadis are 
expected 
to carry underground water.

Richard


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

Re: [Tagging] Feature proposal - Voting - Water tap

[Marc Gemis]

So what is the solution ?

amenity=non_drinking_water ?

It seems that amenity=drinking_water is cut into stone and we will never be
able to change this tag, although it obviously blocks more general tagging
scheme for water sources.

regards

m.



On Fri, Jan 16, 2015 at 11:16 AM, Pieren  wrote:

> On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan 
> wrote:
>
> > As of today, a total of 16 votes have been submitted, 11 of them are
> > approvals. Since 2 weeks have passed and the required number of votes
> > (15) has been reached, I have closed the voting and will proceed with
> > clean up.
>
> Sorry but you could extend the period of feedbacks. 7 of the 11
> positive "votes" came before the 13th january when I posted my
> comments about the possible issues (and the discussion forwarded here
> which probably drew more attention to more people). After this date
> the trend was much more balanced. You say you are aware of the clash
> with amenity=drinking_water but you don't explain how you will avoid
> this in your cleanup. You also agree that we need a rework but your
> proposal is just increasing the difficulties than solving them in the
> future. Now, for a water tap in the public space, it will be tagged
> with "amenity=drinking_water". And for the same water tap inside or
> near a cemetery, it will be tagged with "man_made=water_tap". How can
> we explain that to newcomers ? why "amenity" in one case and
> "man_made" on the other ? what is implied about potability ? etc
>
> Pieren
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic philosophy of OSM tagging

[moltonel 3x Combo]

On 16/01/2015, Pieren  wrote:
 Historical contributors and leaders will tell you that there is no
> "official committee" in OSM. But, to be a litle provocative, I would
> say we already have two committees for tagging scheme:
> - the JOSM presets maintainers
> - the DWG

AFAIK the DWG's influence on tags is fairly light. But all the editors
(not just josm), the renderings (especially the "default" mapnik one,
but also the specialized 3d and indoor ones), the search engines
(Nominatim), the routers (OSRM) all carry a lot of weight. Anybody
spending time on the wiki and mailing lists (and to a lesser degree
also on forum, irc, help, etc) carry some weight too.

Of course not everybody has the same weight... But that crowd is
varied enough that there's IMHO no reason to fear one overreaching
commitee.

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

Re: [Tagging] Ethnic shops

[moltonel 3x Combo]

On 15/01/2015, Eric Sibert  wrote:
> Hi all,
>
> I'm wandering on how to tag shops that are offering services with
> specific ethnic orientation. For instance:
> - convenience specialized for Italian, Portuguese, Chinese products...
> - clothes typical from one country/area
> - hairdresser for African people although non African may also want to
> find it for braids

I've recently tagged a shop=convenience, convenience=polish. You'll
find a handfull of other examples of convenience=* clothes=*
hairdresser=* on taginfo.

The usage is very low (especially considering the number of polish
convenience stores in Ireland for example), but that's the best I
could find.

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

Re: [Tagging] Tag destination vs. relation destination_sign

[fly]

Am 16.01.2015 um 09:31 schrieb Martin Vonwald:
> 
> 2015-01-15 22:12 GMT+01:00 fly  >:
> 
> Please, do not forget to mention direction:lanes*.
> 
> 
> destination:lanes ;-)

Thanks, yes.

Was tagging directions and writing about destination:lanes.

cu


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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Friedrich Volkmann]

On 16.01.2015 10:10, Lukas Sommer wrote:
> What you propose is an algorithm that does a sort of “guess”. For
> doing some sort of guess, we don’t need to introduce a new relation.
> That could be done also without a relation.

Look at the examples. You cannot represent the data without a relation.

There may still be some guessing involved in the interpretion of the data,
but it's less guessing than without the relation.

> Introducing a new relation should lead to better data and more
> well-structured information. There should be a certain gain in
> information. This will work only if the relation proposal is really
> clear. If not, probably it will happen the same things as with the
> “site” relation (=there are “site” relations in the database, but
> little software support for this).

The lack of software support for site relations has 2 reasons:
1) chaotic definition
2) lazy renderer developers

We certainly cannot influence (2), but I tried to make the proposal as clear
and straightforward as possible, thereby improving on (1).

> I think that Никита has touched a very important question: Is there
> inheritence? Means: Are tags on the relation also considered tags of
> the members?

No!

> And how to deal with conflicts? This is not as trivial as
> it sounds. I’ll take some of your examples:
> 
> – “name=Schwedenhöhlen” + “natural=cave_entrance” on the relation.
> “name=Schwedenhöhle 1…” + “natural=cave_entrance” on the nodes.

That's a tagging error. It's like a church tagged highway=motorway. There's
no point in pondering over that.

> – “name=Schwedenhöhlen” on the relation. “name=Schwedenhöhle 1…” +
> “natural=cave_entrance” on the nodes. You would have to go to the
> nodes, interpretate them and use the same rendering style also for the
> relation. Probably also not as trivial as it sounds. What, if not all
> nodes does not have the same tag (example: a natural=cliff within this
> group). Is this considered as error? Does this prevent the rendering?
> Your proposal was was count: More natural=cave_entrance occurences
> than natural=cliff occurences would make the relation render as a
> natural=cave_entrance. For me, this does not look like an improvement
> of the current data quality, but rather like a degradation of the data
> quality.

When you dig into interpretations and algorithms, things start looking
complex. This is not specific to type=cluster relations. Take a simple
building=yes. It becomes more complex as soon as it is accompanied by other
tags. It becomes even more complex when you think about label placement and
collision. Not to mention generalisation (e.g. simplification at lower zoom
levels). You could end up running out screaming just because of a simple
building=yes tag.

I suggest we make a clear distinction between tagging (i.e. the formal
representation of data) and how to use these tags in applications (i.e.
algorithms, rendering rules, data mining etc.). There's mapping (data
providers) on one side, and applications (data consumers) on the other side.
OSM data and wiki definitions serve as the interface. That interface is what
the tagging mailing list is all about. Our goal here is to work on the
interface. We don't need to dig to much into mapping processes or
application internals. We just need to provide an interface that all can
work with. My sample algorithms just prove that it is possible to work with
the interface. It's up to develpers to actually use those algorithms, or
other algorithms, or no algorithms at all.

So when you just look at the proposal and forget about algorithms, the
proposal provides a fairly clear-cut interface. Tags on the relation refer
to the group as a whole, and tags on the members refer to the individual
members. It could not be more simple.

> At least, I would suggest to treat such cases as “invalid”
> relations which should be ignored by data consumers.

This restriction would not only complicate things a lot, it would also make
almost all uses "invalid". Let's stay with the Schwedenhöhlen example. The
individual Schwedenhöhlen have different cave:ref=* and different cave
lengths. That would already make the group invalid.

> –  “name=Schönefelder Seen” + “natural=water” on the relation. No tags
> at the member areas.

Tagging error. You may do this with a multipolygon relation, but not with a
cluster relation.

> –  “name=Schönefelder Seen”  on the relation. “natural=water” at the
> member areas. Members propagate their tags to the relation. So a
> renderer can determine the color for rendering the name of teh
> relation. Sounds easy for the “Schönefelder Seen”. But this solution
> would create conflicts when applied to the caves, because the cave
> relation members have also individual names, and these names would
> conflict with the relation name.

This is a normal label placement conflict. Nothing to worry about. Renderers
handle that billions of times.

> I understand that you want to have a simple and generic solution. But
> I do

Re: [Tagging] Ethnic shops

[Martin Koppenhoefer]

2015-01-16 13:29 GMT+01:00 moltonel 3x Combo :

> I've recently tagged a shop=convenience, convenience=polish. You'll
> find a handfull of other examples of convenience=* clothes=*
> hairdresser=* on taginfo.
>


I suggest to use a more specific key that already tells in its name what it
is about, and that allows for tagging several orthogonal properties. The
current values for convenience (in total only used 11 times) are:
http://taginfo.openstreetmap.org/keys/convenience#values

yes
russian
mall
pet
polish
variety_store
african
wine;honey;rice;pastery;book

so basically there is no system, and the values make it hard if not
impossible to understand what is actually tagged.

I have found these in taginfo:

ethnicity (total use 65)
http://taginfo.openstreetmap.org/keys/ethnicity

origin (used more often, but has the same problem then "convenience", it is
mixed up with different concepts)
http://taginfo.openstreetmap.org/keys/origin#values

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

Re: [Tagging] Basic philosophy of OSM tagging

[Mateusz Konieczny]

Note also massive influence of JOSM validator and other
rule-checker tools.

2015-01-16 13:14 GMT+01:00 moltonel 3x Combo :

> On 16/01/2015, Pieren  wrote:
>  Historical contributors and leaders will tell you that there is no
> > "official committee" in OSM. But, to be a litle provocative, I would
> > say we already have two committees for tagging scheme:
> > - the JOSM presets maintainers
> > - the DWG
>
> AFAIK the DWG's influence on tags is fairly light. But all the editors
> (not just josm), the renderings (especially the "default" mapnik one,
> but also the specialized 3d and indoor ones), the search engines
> (Nominatim), the routers (OSRM) all carry a lot of weight. Anybody
> spending time on the wiki and mailing lists (and to a lesser degree
> also on forum, irc, help, etc) carry some weight too.
>
> Of course not everybody has the same weight... But that crowd is
> varied enough that there's IMHO no reason to fear one overreaching
> commitee.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power networks European codification scheme

[François Lacombe]

I've already introduced the ref:ERDF:gdo key for French power codification
scheme.

As suggested, ref:entsoe:eic would stand for European power codification
scheme.
The power transmission proposal had been updated
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Codification_schemes_worldwide


Cheers

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2015-01-16 10:05 GMT+01:00 François Lacombe :

> 2015-01-15 21:27 GMT+01:00 Ole Nielsen :
>
>> I'm not sure how these codes could benefit OSM.
>
>
> It's been a long time we need unique codes to identify infrastructure
> features (or group of features) instead of their own OSM ID (when you
> delete something and redraw it, the ID has changed, not the EIC code).
> Finding an identification scheme at such a large scale is not so easy.
>
> A second benefit is to talk the same language as other DB or systems
> instead of creating our own way to distinguish objects.
>
>
>
>> They seem to be mostly for use in transactions between entities such as
>> TSO's and would have little public interest, even for power grid 'nerds'
>> like me.
>>
>
> According to what is said above, I respectably disagree.
>
>
>>
>> Further, from where would you get these codes (with an odbl compatible
>> license)? I have never seen such codes used on public websites of TSO's and
>> power companies. And I don't think they label substations, power plants
>> with such codes at the gates so you can't get them from surveys.
>>
>
> The EIC scheme is yet young.
> The power market has been driven for years by a strong opendata movement
> and it's possible to ask ENSTO-E to publish their codes under OdBL license.
>
> The goal of my original question isn't to start publishing codes in OSM
> immediately but to find the best key to do it and to be ready when the time
> comes.
>
>
> Cheers
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ethnic shops

[Volker Schmidt]

This, and already the existing tagging for restaurant cuisine have a basic
flaw. They only work in a few countries of the West.
If you think about it, most likely al restaurants in China would have to
have cuisine=chinese, or all grocery stores in Marocco would have to be
labelled convenience=north_african or whatever.
Basically you want to label restaurants/shops only if they offer something
different from what's the typical local fare.

I have no proposal, I am just observing.



On 16 January 2015 at 13:45, Martin Koppenhoefer 
wrote:

>
> 2015-01-16 13:29 GMT+01:00 moltonel 3x Combo :
>
>> I've recently tagged a shop=convenience, convenience=polish. You'll
>> find a handfull of other examples of convenience=* clothes=*
>> hairdresser=* on taginfo.
>>
>
>
> I suggest to use a more specific key that already tells in its name what
> it is about, and that allows for tagging several orthogonal properties. The
> current values for convenience (in total only used 11 times) are:
> http://taginfo.openstreetmap.org/keys/convenience#values
>
> yes
> russian
> mall
> pet
> polish
> variety_store
> african
> wine;honey;rice;pastery;book
>
> so basically there is no system, and the values make it hard if not
> impossible to understand what is actually tagged.
>
> I have found these in taginfo:
>
> ethnicity (total use 65)
> http://taginfo.openstreetmap.org/keys/ethnicity
>
> origin (used more often, but has the same problem then "convenience", it
> is mixed up with different concepts)
> http://taginfo.openstreetmap.org/keys/origin#values
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=wadi problem

[Volker Schmidt]

I now notice that I read the German Wikipedia entry for Wadi, which is
plainly different form the English one. My fault.
The English Wikipedia defines Wadi mainly as a valley, wheras the German on
as a normally dry water course.


On 16 January 2015 at 13:02, Richard Z.  wrote:

> On Thu, Jan 15, 2015 at 11:41:26AM +0900, johnw wrote:
> > I strongly disagree. A wadi is usually only an active river through very
> rare flash flood events, and almost never any other time.  Entire biomes
> are defined by the presence of (and situated in) a wadi.
> >
>
> how about reading wikipedia?
> <<
> Wadi (Arabic: وادي‎ wādī) is the Arabic term traditionally referring to a
> valley. In some cases, it may refer to a dry (ephemeral) riverbed that
> contains water only during times of heavy rain or simply an intermittent
> stream.
> >>
>
> I consider a wadi a geologic feature. In addition to the above wadis are
> expected
> to carry underground water.
>
> Richard
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ethnic shops

[Dan S]

That's not a flaw - you've already given the solution in your own email:

> Basically you want to label restaurants/shops only if they offer something
> different from what's the typical local fare.




2015-01-16 13:23 GMT+00:00 Volker Schmidt :
> This, and already the existing tagging for restaurant cuisine have a basic
> flaw. They only work in a few countries of the West.
> If you think about it, most likely al restaurants in China would have to
> have cuisine=chinese, or all grocery stores in Marocco would have to be
> labelled convenience=north_african or whatever.
> Basically you want to label restaurants/shops only if they offer something
> different from what's the typical local fare.
>
> I have no proposal, I am just observing.
>
>
>
> On 16 January 2015 at 13:45, Martin Koppenhoefer 
> wrote:
>>
>>
>> 2015-01-16 13:29 GMT+01:00 moltonel 3x Combo :
>>>
>>> I've recently tagged a shop=convenience, convenience=polish. You'll
>>> find a handfull of other examples of convenience=* clothes=*
>>> hairdresser=* on taginfo.
>>
>>
>>
>> I suggest to use a more specific key that already tells in its name what
>> it is about, and that allows for tagging several orthogonal properties. The
>> current values for convenience (in total only used 11 times) are:
>> http://taginfo.openstreetmap.org/keys/convenience#values
>>
>> yes
>> russian
>> mall
>> pet
>> polish
>> variety_store
>> african
>> wine;honey;rice;pastery;book
>>
>> so basically there is no system, and the values make it hard if not
>> impossible to understand what is actually tagged.
>>
>> I have found these in taginfo:
>>
>> ethnicity (total use 65)
>> http://taginfo.openstreetmap.org/keys/ethnicity
>>
>> origin (used more often, but has the same problem then "convenience", it
>> is mixed up with different concepts)
>> http://taginfo.openstreetmap.org/keys/origin#values
>>
>> cheers,
>> Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Feature proposal - Voting - Water tap

[Janko Mihelić]

I don't get how amenity=drinking_water is a problem. It is just a tag with
a wider meaning. "man_made=water_tap+drinking_water=yes" is a special type
of "amenity=drinking_water", as is "natural=spring+drinking_water=yes" or
some other combination.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Overhead signs (Überkopfwegweiser)

[Marc Gemis]

do you know the :lanes suffix ? See e.g. the last example on
http://wiki.openstreetmap.org/wiki/Key:destination
and combine this with turn:lanes for the arrows

regards

m

On Fri, Jan 16, 2015 at 10:19 AM, Andreas Labres  wrote:

> Hello,
>
> I'd like to suggest an idea to map overhead signposts
> ("Überkopfwegweiser" in German):
>
> Here is a photo of the sign to be mapped:
>
>
> http://commons.wikimedia.org/wiki/File:A23_Knoten_Kaiserm%C3%BChlen_1.JPG
>
> To map:
> Put a node on the way of the street exactly where the sign is located
> and tag it something like this:
>
> overhead-sign=|| Brno, Gänserndorf, Stadlau [A23]; | Praha [A23]; / Kagran
> [B3];
> > Ölhafen Lobau
>
> * with the arrows represented by:
>
> |     up arrow
> /     slight right arrow
> >     turn right arrow
> \     slight left arrow
> <     turn left arrow
>
> * the text indicates the text that is written on the sign
>   (the text should match any destination= tags given on exits)
>
> * refs are given within square brackets [...]
>
> * a semiconlon ; separates the arrows
>
> This gives a router the possibility to show a drawing of
> the sign, depending on the direction:
>
> heading Brno:
> +---+
> | Brno,... [A23]|
> |^^   ^ />  |
> |||   |//   |
> +---+
>
> heading Praha:
> +---+
> |  Praha [A23]  |
> |   ^   ^  ^/>  |
> |   |   |  |   //   |
> +---+
>
> heading Kagran:
> +---+
> |  Kagran [B3]  |
> |   ^   ^   ^/   >  |
> |   |   |   |   /   /   |
> +---+
>
> heading Ölhafen Lobau:
> +---+
> |  Ölhafen Lobau|
> |  ^   ^   ^/   >   |
> |  |   |   |   /   /|
> +---+
>
> (this ASCII art should of course be a drawing with "real"
> arrows, nice ref-shields and so on)
>
> Of course this should match the information given in any lane tags,
> but it gives the exact position of the sign and it works without
> the need of lane tags! That way it should be much easier for
> routing app developers to implement hints which lane to use.
> For the driver, it's simpler to match the sign given by the app
> with the real sign.
>
> /al
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[Janko Mihelić]

As for newcomers, I think editors like iD should hide the intricacies of
the tagging system anyway. If you click "drinking water" it puts
"amenity=drinking_water". But then it offers you all types of drinking
water, like "a tap, a spring, bottled water in a vending machine, a hose, a
well" and if you choose "a tap" it puts man_made=water_tap +
drinking_water=yes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[Pieren]

On Fri, Jan 16, 2015 at 1:06 PM, Marc Gemis  wrote:

> amenity=non_drinking_water ?

Or "amenity=non_drinkable_water" + a subtag describing the object

> It seems that amenity=drinking_water is cut into stone and we will never be
> able to change this tag, although it obviously blocks more general tagging
> scheme for water sources.

I never said that. Although very hard, it is not impossible to
deprecate a tag in OSM. We just need real good arguments for it.

Pieren

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

Re: [Tagging] Feature proposal - Voting - Water tap

[althio althio]

I didn't follow every bits of the discussion, so sorry for
interrupting. Sorry also if my proposals are out of scope or already
reviewed. Maybe a fresh view can help.

@Marc amenity=drinking_water // amenity=non_drinking_water
It feels like a good start and compromise.
Either can be associated with a more physical feature that represents
an outlet of a water network.

A few tagging examples...

any point with drinking water:
amenity=drinking_water
+ [opt] man_made=*

a well:
man_made=water_well
+ [opt] amenity=drinking_water/non_drinking_water

a tap:
man_made=water_tap
+ [opt] amenity=drinking_water/non_drinking_water

a water point:
man_made=water_tap or man_made=water_point or man_made=water_supply or ...
+ [opt] amenity=drinking_water/non_drinking_water
* currently exists amenity=water_point ... I find it a bad tag, this
one I would consider to maybe deprecate and link as a equivalent
amenity=water_point <=> amenity=drinking_water + man_made=[to_be_chosen]

and it should not implies drinking_water=yes.

a fountain for cultural / decorational / recreational purposes [often
not suitable for drinking]:
amenity=fountain
(man_made=fountain is maybe more logical... and here 2x amenity can clash)
* if it is drinking water, a workaround would be two features, ideally
a node amenity=drinking_water within an area (however small)
amenity=fountain. Some fountains are also detailed with an area of
natural=water.

toilets with drinking water
amenity=toilets and amenity=drinking_water as two features (2 nodes or
area+node)

drinking fountain
amenity=drinking_water
+ [opt] man_made=* (man_made=fountain if there is a need?)



Either way, the slightly conflicting tag are
amenity=[non_]drinking_water and drinking_water=yes/no.
They should be linked and treated together in algorithms.
I think amenity=drinking_water is a valuable tag because it is useful
to people. It makes sense to use it alone.
drinking_water=yes alone on a node makes less sense IMO.

water_point and water_tap should not assume

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

Re: [Tagging] Feature proposal - Voting - Water tap

[François Lacombe]

I don't think the drinkable quality of water should be the prime criteria
to tag water sources (or a reason to use amenity=*)
A fountain will striclty have the same external and internal design either
the water is drinkable or not.

This data should be introduced with a tag drinkable=yes/no or any other
values giving information about the drinkable quality of water for humans.

I agree with the approach of Althio on man_made.

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2015-01-16 15:50 GMT+01:00 althio althio :

> I didn't follow every bits of the discussion, so sorry for
> interrupting. Sorry also if my proposals are out of scope or already
> reviewed. Maybe a fresh view can help.
>
> @Marc amenity=drinking_water // amenity=non_drinking_water
> It feels like a good start and compromise.
> Either can be associated with a more physical feature that represents
> an outlet of a water network.
>
> A few tagging examples...
>
> any point with drinking water:
> amenity=drinking_water
> + [opt] man_made=*
>
> a well:
> man_made=water_well
> + [opt] amenity=drinking_water/non_drinking_water
>
> a tap:
> man_made=water_tap
> + [opt] amenity=drinking_water/non_drinking_water
>
> a water point:
> man_made=water_tap or man_made=water_point or man_made=water_supply or ...
> + [opt] amenity=drinking_water/non_drinking_water
> * currently exists amenity=water_point ... I find it a bad tag, this
> one I would consider to maybe deprecate and link as a equivalent
> amenity=water_point <=> amenity=drinking_water + man_made=[to_be_chosen]
>
> and it should not implies drinking_water=yes.
>
> a fountain for cultural / decorational / recreational purposes [often
> not suitable for drinking]:
> amenity=fountain
> (man_made=fountain is maybe more logical... and here 2x amenity can clash)
> * if it is drinking water, a workaround would be two features, ideally
> a node amenity=drinking_water within an area (however small)
> amenity=fountain. Some fountains are also detailed with an area of
> natural=water.
>
> toilets with drinking water
> amenity=toilets and amenity=drinking_water as two features (2 nodes or
> area+node)
>
> drinking fountain
> amenity=drinking_water
> + [opt] man_made=* (man_made=fountain if there is a need?)
>
>
>
> Either way, the slightly conflicting tag are
> amenity=[non_]drinking_water and drinking_water=yes/no.
> They should be linked and treated together in algorithms.
> I think amenity=drinking_water is a valuable tag because it is useful
> to people. It makes sense to use it alone.
> drinking_water=yes alone on a node makes less sense IMO.
>
> water_point and water_tap should not assume
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[Pieren]

On Fri, Jan 16, 2015 at 4:03 PM, François Lacombe
 wrote:

> A fountain will striclty have the same external and internal design either
> the water is drinkable or not.

Here you join the other thread about "philosophy of tagging". Some
people describe an object, others describe a service. You see a
fountain or a tap and you don't care much if water is drinkable or not
(you prioritize the object description above its functionality). But
many other contributors, bikers for instance, want to find drinkable
water points along the route and don't care if it's a tap or a
fountain (functionality more important than the shape).

Pieren

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Serge Wroclawski]

On Thu, Jan 15, 2015 at 8:29 PM, Friedrich Volkmann  wrote:

>> In that scenario, I'd much prefer to see two nodes, each with their
>> address, and each tagged as an entrance.
>
> What you prefer certainly depends on your needs. Adresses on entrances are
> fine for routing, maybe for visual representation too, but if you want to
> run a script generating a list of building sizes and addresses, you need
> addresses on buildings.

I'll explain how we dealt with this issue in NYC later in the mail.

>> What benefit does this proposal have over simply using a list separator?
>
> A list separator is fine as long as there is only one key. Unfortunately,
> there is no simple addr=* key.

The addr key can be used on its own to denote a complete address,
without using subkeys. The subkeys are preferable in most cases since
they can be used to construct the keys themselves, but are not
strictly necessary.

> There is an addr:city=* key for the city,

Is there a building in your dataset that lives in two cities?

> an  addr:postcode=* key for the postcode

Postcode's an interesting one- but again, in actuality, do you have a
building that has two postcodes?

> an addr:street=* key, and addr:housenumber=* key, and others.

These are the two we care most about in this discussion.

And here's where we simply say:

addr=val1;val2;val3

If you're in North America or a European country, it would be something like

 

Let's say 123 Foo and 567 Bar

addr:123 Foo;567 Bar

We can omit the city because the city is the same (if you have a real
life counter example, please show me) and we can omit the postalcode
for the same reason.

> Here you do not need to count semicolons, neither do applications. You can
> check address for address. Which solution do you like better?

Maybe I'm mistaken, but it's my understanding that this solution is to
address the exceptions in the data.

I live in New York City, and we do have some buildings with multiple
addresses, so this isn't a theoretical for me. We already dealth with
this.


There will be some exceptions, but not many. Even in a city like New
York City, with over a million buildings (litterally), the number of
multi-addressed buildings which we
In most cases, going back to your first question, the solution was to
use naked address nodes placed inside the building polygon.

You asked how one would retrieve addresses from a data processing
perspective. The answer is that in these cases, you *might* want to
use some kind of building relation, and then you'd have the building
as a relation and the nodes inside it, but what we did in NYC is to
simply add naked address nodes inside the building polygon.

This adds an extra step in data retrival, but it's not that bad.

As an aside, it may be useful for someone to create some kind of an
API or SDK on top of OSM to make it easy to retrieve these broad
categories of data which may be represented in different ways.

- Serge

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

Re: [Tagging] waterway=wadi problem

[Tod Fitch]

Since we are supposed to use British English, I decided to look up wadi in my 
old paper edition of the Oxford English Dictionary (can we trust that more than 
Wikipedia?):

"Wadi or Wady [Arabic: وادي‎ wādī] In certain Arabic speaking countries, a 
ravine or valley which in the rainy season becomes a watercourse; the stream or 
torrent running through such a ravine."

Apparently first used in English literature in 1839 by the way.

So it seems it could either be the valley or the actual intermittent 
watercourse. In that respect the term "wash" in the U.S. southwest is more 
specific as it is only applied to the intermittent watercourse. My impression 
from Southern California is that arroyo can be the valley/ravine as well as the 
actual watercourse, so that might match the OED definition of wadi more than 
"wash" does.

Tod

On Jan 16, 2015, at 5:36 AM, Volker Schmidt wrote:

> I now notice that I read the German Wikipedia entry for Wadi, which is 
> plainly different form the English one. My fault. 
> The English Wikipedia defines Wadi mainly as a valley, wheras the German on 
> as a normally dry water course. 
> 
> 
> On 16 January 2015 at 13:02, Richard Z.  wrote:
> On Thu, Jan 15, 2015 at 11:41:26AM +0900, johnw wrote:
> > I strongly disagree. A wadi is usually only an active river through very 
> > rare flash flood events, and almost never any other time.  Entire biomes 
> > are defined by the presence of (and situated in) a wadi.
> >
> 
> how about reading wikipedia?
> <<
> Wadi (Arabic: وادي‎ wādī) is the Arabic term traditionally referring to a 
> valley. In some cases, it may refer to a dry (ephemeral) riverbed that 
> contains water only during times of heavy rain or simply an intermittent 
> stream.
> >>
> 
> I consider a wadi a geologic feature. In addition to the above wadis are 
> expected
> to carry underground water.
> 
> Richard
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature proposal - Voting - Water tap

[althio althio]

It seems that Pieren and I agree on most points.

@François
Maybe drinkable water is a very special case... but here service/use
is much more important than object/feature. The ability to find this
water on a map or from any data consumer is useful. It can even be
essential to many people from hikers and bikers to inhabitants and
humanitarian NGO where water is in short supply.

Also consider the possibility of a open data import of geolocalised
water points. We should import them for added value even if the
supporting physical man_made=* is unknown.

You must tag what you know and what is useful.
man_made=water_[object] is useful.
amenity=drinking_water/non_drinking_water is useful.

Let's tag one or the other and both when we can. For me there is no
conflict or hierarchy between these two keys.

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

Re: [Tagging] Basic philosophy of OSM tagging

[althio althio]

"Kotya Karapetyan"
> 2) Suggested tags functionality should be implemented.

I have seen that in the Android editor Vespucci.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging road illumination quality

[Volker Schmidt]

I would like to enter illumination quality for bicycle infrastructure
(cycleways) in OSM.
This is unfortunately a thorny issue, as there is no easy way to measure in
an objective way the quality of the illumination.
Has anyone already looked into this?
I could invent something along the lines of the smoothness tag, which in my
view faces a similar problem of not being objectively quantifiable.
I am thinking of something like lit=no|yes|poor|sufficient|good

Obviously, if it were to work for cycle paths it could also be use for
other highways.

Any suggestions welcome

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

Re: [Tagging] waterway=wadi problem

[Richard Z.]

On Fri, Jan 16, 2015 at 08:23:33AM -0800, Tod Fitch wrote:
> Since we are supposed to use British English, I decided to look up wadi in my 
> old paper edition of the Oxford English Dictionary (can we trust that more 
> than Wikipedia?):
> 
> "Wadi or Wady [Arabic: وادي‎ wādī] In certain Arabic speaking countries, a 
> ravine or valley which in the rainy season becomes a watercourse; the stream 
> or torrent running through such a ravine."
> 

also
http://en.wiktionary.org/wiki/%D9%88%D8%A7%D8%AF%D9%8A

- valley. 

> So it seems it could either be the valley or the actual intermittent 
> watercourse. In that respect the term "wash" in the U.S. southwest is more 
> specific as it is only applied to the intermittent watercourse. My impression 
> from Southern California is that arroyo can be the valley/ravine as well as 
> the actual watercourse, so that might match the OED definition of wadi more 
> than "wash" does.

I think we should look at how wadi is used in Arabic and decide if the feature 
is
somehow interesting - and if the "correct" usage is compatible with prevalent 
usage
in OSM

https://www.google.de/search?q=%D9%88%D8%A7%D8%AF%D9%8A&safe=off&hl=ar&tbm=isch&gbv=1&sei=TlS5VKm5EOia7AbVvIDYCQ

To me it looks too much like a synonym for valley, not sure if we need that.
But maybe we need natural=valley?

Richard

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Will Phillips]

I support using the addrN:* tagging proposed here in the specific 
situation where a single residence or business has multiple addresses. 
Note I am not referring to a building with multiple occupiers, but a 
single addressee with more than one address. In England I have never 
encountered this situation for residential addresses, but have done so 
very occasionally for shops and other businesses.


Here is an example:
http://www.openstreetmap.org/way/290380382

In cases like this there is probably only one 'official' address, but if 
the available sources are contradictory it is desirable to record both. 
This situation sometimes arises when a business decides their official 
address is confusing and they then invent another one which they think 
is clearer for people trying to find them.


I think it's rarely a good idea to add the same feature twice, which is 
the obvious alternative for tagging this. I dislike the idea of using 
relations for multiple addresses because it's over-complicating things: 
a lot of mappers find relations confusing.


I do not support using addrN:* tagging for the common case of multiple 
occupancy buildings. It simply does not work in a lot of cases, because 
different businesses in one building also require different names and 
other tags and I don't think we want to start using name:2=* office:2=*, 
and so on, to distinguish them.


Cheers,
Will

On 15/01/2015 01:46, Friedrich Volkmann wrote:

http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN

I once made a proposal for multiple addresses, which I think was fairly
eleborate, but too complex. This is now a simplified version, and hopefully
more acceptable. This tagging scheme is already in use (e.g. > 7000
occurances of addr2:housenumber), but unfortunately limited to one country
or so, due to a lack of international communication and documentation. I
hope that this proposal will get it a wider audience, and that application
support will subsequently improve.




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

Re: [Tagging] Tagging road illumination quality

[Frederik Ramm]

Hi,

On 01/16/2015 06:18 PM, Volker Schmidt wrote:
> This is unfortunately a thorny issue, as there is no easy way to measure
> in an objective way the quality of the illumination.

Indeed. I would suggest mapping the individual light sources instead.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Tagging road illumination quality

[Volker Schmidt]

The light sources' positions often have little to do with the real
illumination effect.
In many cases, in my city, cycle paths (in reality they all are mixed-use
pedestrian and bicycle with priority by law to pedestrians) have been
produced by converting former sidewalks. The lamp posts are those installed
for street illumination and often are interspersed with street-side trees.
Hence the effective illumination on the foot-cycle path is patchy. The only
way to judge it is to cycle by night and see.
The reason why this comes up now is that we want to map the cycling
infrastructure as it really is, with the aim of producing the data for a
critical map of the cyclability of Padova. All other parameters are already
taggable, the illumination quality not yet.

On 16 January 2015 at 20:14, Frederik Ramm  wrote:

> Hi,
>
> On 01/16/2015 06:18 PM, Volker Schmidt wrote:
> > This is unfortunately a thorny issue, as there is no easy way to measure
> > in an objective way the quality of the illumination.
>
> Indeed. I would suggest mapping the individual light sources instead.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] POIs with mixed assortment/services

[Daniel Koć]

W dniu 16.01.2015 14:23, Volker Schmidt napisał(a):


Basically you want to label restaurants/shops only if they offer
something different from what's the typical local fare.

I have no proposal, I am just observing.


Of course we don't want to tag every feature if it's obvious, but as the 
database is growing and the project is maturing, we start noticing some 
things are not that obvious and the need to record more details grows.


A good example of it would be tagging scheme 
building=church+amenity=place_of_worship instead of just 
building=church, because not every church is used as such and not every 
place of worship is a building.


We were discussing tagging shops with mixed assortment on polish forum 
back in October ( http://forum.openstreetmap.org/viewtopic.php?id=27327 
) and the draft was written according to that discussion:


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

Example shop with different things would look like this:

shop=convenience
shop:stock:bread=yes
shop:stock:newspaper=yes
shop:stock:vegetables=yes
shop:stock:meat=yes
shop:stock:alcohol=no

But there can be also some services:

amenity=cafe
amenity:service:tea=yes
amenity:stock:tea=yes

Note that we shouldn't tag simply as shop:stock=bread, because in OSM 
the key (shop:stock here) can't have more than one value.


Over the time I am mapping for OSM, I have collected a few objects that 
are mixed in very strange ways. I would say it's about a few percent of 
all POIs and it sounds like they are a not interesting corner cases. But 
when I want to go for a dinner, I don't care if it's served in a 
restaurant or in a confectionery (real life example!). The same for 
coffee - if you really want to drink one, you can go for a full-featured 
amenity=cafe, but you can also buy worse quality coffee in the local 
convenience shop or at the gas station.


So I think we have a solution also for the ethnic shops.

The only one real problem left is how to tag such a shop with mixed 
goods if you can't really tell what is the core of its business - but 
maybe shop/amenity/craft/*=yes would be sufficient then.


--
Mambałaga

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

Re: [Tagging] Tagging road illumination quality

[Dan S]

Hi -

Yes, it's useful to go beyond lit=yes and lit=no. Some of those
suggestions such as "poor" and "sufficient" are too subjective, as I
think you already acknowledge. Not only are they value judgments but
they depend on the user's perspective and needs, so please do try to
avoid them.

Some of the existing values, rarely used, are "indirect", "partial",
"sparsely", "limited". It would be nice if we could grow some
consensus on useful values to use. In my experience sparse lighting is
common (and very different from full street lighting). One
possibility: something like lit=0.5 for a highway which is lit
sparsely (or light is obstructed) so that it is effectlvely lit along
50% of its length...?!

Best
Dan


2015-01-16 20:27 GMT+00:00 Volker Schmidt :
> The light sources' positions often have little to do with the real
> illumination effect.
> In many cases, in my city, cycle paths (in reality they all are mixed-use
> pedestrian and bicycle with priority by law to pedestrians) have been
> produced by converting former sidewalks. The lamp posts are those installed
> for street illumination and often are interspersed with street-side trees.
> Hence the effective illumination on the foot-cycle path is patchy. The only
> way to judge it is to cycle by night and see.
> The reason why this comes up now is that we want to map the cycling
> infrastructure as it really is, with the aim of producing the data for a
> critical map of the cyclability of Padova. All other parameters are already
> taggable, the illumination quality not yet.
>
>
> On 16 January 2015 at 20:14, Frederik Ramm  wrote:
>>
>> Hi,
>>
>> On 01/16/2015 06:18 PM, Volker Schmidt wrote:
>> > This is unfortunately a thorny issue, as there is no easy way to measure
>> > in an objective way the quality of the illumination.
>>
>> Indeed. I would suggest mapping the individual light sources instead.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Tag destination vs. relation destination_sign

[Lukas Sommer]

I’ll wait until monday with the change …
Lukas Sommer


2015-01-16 12:35 GMT+00:00 fly :
> Am 16.01.2015 um 09:31 schrieb Martin Vonwald:
>>
>> 2015-01-15 22:12 GMT+01:00 fly > >:
>>
>> Please, do not forget to mention direction:lanes*.
>>
>>
>> destination:lanes ;-)
>
> Thanks, yes.
>
> Was tagging directions and writing about destination:lanes.
>
> cu
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Ethnic shops

[John Willis]

Sent from my iPhone

> On Jan 16, 2015, at 10:54 PM, Dan S  wrote:
> 
> That's not a flaw - you've already given the solution in your own email:
> 
>> Basically you want to label restaurants/shops only if they offer something
>> different from what's the typical local fare.


Exactly - here in japan, the local restaurant type of ramen, soba, cutlet, 
sushi, dango, yakisoba, okonomiyaki, etc would all have their own cuisine tags 
(probably in Japanese) as that what people search for. There are also ethnic 
shops - Philippine restaurants and shops, Peruvian restaurants ad shops, etc 
for the local foreigners. 
I think there should be ethnic=*, Nationality=* , or culture=*tag that can be 
used for any feature when it is a feature of the place to esperate it from the 
country it is in. , or focuses on goods and services from a specific place. 
(Greman car repair?)

There are Philippine dance clubs in my area, plastered with flags. - but the 
word Philippine is not in the title of the club, but it is a big part of the 
shop identity.

Similarly, Korean BBQ and Japanese BBQ are very similar - but often the shops 
will differentiate based on nationality - but they are all (to Japanese people, 
at least) BBQ. 

If I search BBQ, it would be nice to see them all, or "Korean BBQ" and get just 
the Korean ones. I'm not sure how the tag space searches are handled. 

In San Diego, there is a basically just "Japanese" or "sushi" restaurants, and 
Japanese markets. There is a small "all things bright and British" shop in my 
hometown, plastered with big Union Jack flag - a culture=British might be 
useful. 

Javbw

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

Re: [Tagging] waterway=wadi problem

[Tod Fitch]

Since the current term wadi can mean something more than the actual 
watercourse, why not drop it and use "ephemeral=yes" or 
"intermittent=ephemeral" on waterway=* to indicate that it carries water much 
less often than a waterway tagged with "intermittent=yes"?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[Kotya Karapetyan]

Hi all,

1. I apologize for closing the proposal during this discussion. It was
not due to ignorance. For some reason, Gmail doesn't show all emails
from this mailing list. (I Googled for it a couple of times, but
couldn't find anything. Does anyone have a clue?) The last email I saw
was Warin's answer to Pieren's questions from 13 January. No response
appeared in my Gmail, so I went on with the standard procedure and
closed the proposal. Today, after reading a seemingly disconnected
post from althio, I went to check the tagging list archive and
discovered all emails from yesterday and today.

2. Having said this, I would like to draw your attention to the fact
that people who currently actively oppose the proposal have not
participated in a 4-month discussion, where most of the current
concerns were raised and analysed. At the same time, those who
participated earlier don't join the current discussion. I could
understand if they found it a waste of time and, honestly, I don't
understand why you guys were silent for so long. Pieren indeed posted
one comment in the discussion page, to which I answered and haven't
received any further feedback until now (3 months later).

3. Someone mentioned that other discussions took more than a year. I
haven't decided to close the discussion after 4 months. It simply
converged and actually someone else proposed to go for voting (thus
the group was >1 person, Marc :)).

So this discussion once again shows the problems in the current
proposal process.

4. To cool things down: Even if the participants of the re-started
discussion all vote against the proposal, it will still leave the
result intact (it would add Marc, Althio and Janko if they haven't
voted and bring the result to 11:8). However, if a better solution is
proposed, I'll be happy to go on and vote for deprecating the current
tag and introducing a better one.

That was on the process. Now, to the actual discussion:

5. If I understand right, the main concern of the water_tap opponents
is the conflict between man_made=water_tap and amenity=drinking_water.
I wonder why no concern is raised about the drinking_water key. It
provides the full "functionality" of amenity=drinking_water and more
(since it allows the "no" and "conditional" values as well as the
"legal" subtag). So there is a direct conflict but I haven't seen any
proposal to deprecate drinking_water=*.

6. I find amenity=non_drinking_water a poor solution in general: it
implies that the mapper knows that water is non-potable. This is not
always the case. Not only it may not be known (marked); people may
have different attitude to the same kind-of-potable water source.
Non_drinking_water also doesn't indicate whether the water may be made
potable. Note that this is asymmetric to amenity=drinking_water, which
is *always* potable.

7. Personally, I believe drinking_water=* is a much better solution
than amenity=drinking_water:
7.1) The source of drinking water (which, I fully agree, is important
for a lot of users) may not be a dedicated amenity, and still be very
useful: e.g. a public toilet in a well-developed country can provide
access to drinking water, but it's not an amenity=drinking_water, it
is amenity=toilet. Marking one thing with two amenity nodes is
possible but (1) it's a workaround rather than a nice solution; (2) I
think many people, especially tourists from less developed countries,
may not even understand such tagging and will be looking for a
dedicated amenity.
7.2) Drinking water may come in a huge variety of forms, for many of
which there are dedicated tags. If you care about water-deprived
tourists or NGOs, you should also think about water_well, water_point,
spring, toilet, water and landuse tags. All of them are potentially
"hiding" potable water from users, and most of them are not amenities.
This means that if a tourist wants to find the nearest source of
potable water, all these objects should be tagged with
drinking_water=yes and the map users should search for this tag rather
than for amenity=drinking_water. Therefore I would start a separate
discussion on how to make sure that all sources of potable water are
tagged with drinking_water=yes.

8. Most importantly: The water_tap tag was initiated to solve a
specific problem without causing any additional conflicts, namely to
provide the means to tag water taps *independent* from whether water
is potable or not. That is to map an object, for which there is
currently no means in OSM at all. After some discussion and attempts
to find alternative tagging, the current proposal was found to be an
optimal compromise because:
8.1) it is under man_made (there was a suggestion to make it an
amenity), meaning that it can be used together with
amenity=drinking_water to specify the type of the source;
8.2) it is very similar in all ways to man_made=water_well (again, I
haven't seen any doubts on that one), so it should look logical to
mappers;
8.3) it provides good means to tag a water source wh