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

[Ineiev]

On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote:
> 
> you could use polygons (e.g. 2 distinct multipolygons, one for each
> address), and add a note to inform your fellow mapping colleagues that the
> overlap is intended (note is not needed but nice).

I think this solution has an essential advantage: distinct
multipoligons with single addr:housenumbers can go do distinct
associatedStreet relations. you can't do it with addrN:; and
the mapper may want to use associatedStreet e.g. because
it provides a way to specify parallel addresses in different
languages (I believe, this feature is used in countries like Ukraine).

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

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

[Eugene Alvin Villar]

Hello,

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.

~Eugene

[1] https://manilabay.newworldhotels.com/en/contact-us/
[2] https://www.securitybank.com/map/?region=24
[3] http://www.ayalamuseum.org/contact-us/
[4] http://taginfo.openstreetmap.org/keys/addr%3Astreet%3Acorner
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic philosophy of OSM tagging

[johnw]

> On Jan 15, 2015, at 8:33 PM, Mateusz Konieczny  wrote:
> 
> > 4 lane ‘tertiary" road that handles 5 times the vehicle traffic, traveling 
> > on to connect with 2 major trunk roads -  
> > intersects the narrow two lane “secondary road”  that is one of the small 
> > roads coming down from the “suburbs” into the city
> 
> Interesting. I was unaware about so drastic changes in meaning of tag by 
> editors. This one cripples Japanese road data - 
> and I am unsure what could be done about it.


http://www.openstreetmap.org/edit#map=20/36.33615/139.21688 


The “secondary road” I speak of (I was mistaken, it isn’t a primary).  To the 
north, it was recently widened (again) and nice, but below rt. 17, if it didn’t 
have a shield # - it would be an unclassified road (as it doesn’t even have a 
center line and a very awkward turn at a narrow level crossing). 



http://www.openstreetmap.org/edit#map=19/36.40643/139.07303 
 

The “tertiary” road intersection. it connects the primary and the trunk 
intersection to the west (rt 17 / 6), and then (after being secondary for a 
block) meets a “primary road” is tertiary again for several KM as it heads down 
to the rt 50 trunk road and on to “primary” rt 2. This kind of situation occurs 
a lot in cities where old roads meet new bypass roads. I had tagged and 
retagged it as a secondary, but reverted it to tertiary because I have decided 
to follow the OSM:JA rules in this case (after writing my long-winded example).

http://wiki.openstreetmap.org/wiki/Japan_tagging 


They follow their shield system, which places roads into categories which often 
do line up as you expect, but in cities, where there are newer major roads that 
connect the older ones, or in old neighborhoods that are bypassed by newer 
roads, it does not represent the road system very well sometimes.  Notice there 
is no mention of the road size or traffic flow consideration - just shield 
numbers. 

http://www.openstreetmap.org/edit#map=16/36.9819/139.3064 
 

One of the roads in my region, Gunma Route 1, runs through what is now the 
largest national park in Japan, and some pieces are completely closed to all 
public road traffic (it is not continuous), besides the park shuttle bus. I 
assumed I could drive on it (as it is labeled as a primary road, no tolls), and 
drove up there to find (a) it is a narrow service road and (b) roped off, and 
only the park shuttle bus is allowed in (as opposed to private busses and 
taxis, as with other “limited access” park roads in Japan).  I re-tagged the 
private section as a service road, and hastily made the park entrance months 
ago.  it still has it’s ref=1. 



Honestly I don’t mind them being screwed up (besides the rt1, because you 
cannot drive on it whatsoever) - because it is the way that Japanese people 
expect maps to be presented to them. They have pretty rigid ways of 
representing maps - and they have adapted OSM to fit their national mapping 
scheme and expectations:

The two unconnected sections of rt. 1 -  the thin yellow portions are not 
drivable by the public, but still labeled as primary regional roads because of 
the shield type/number. 
http://www.mapion.co.jp/m/basic/36.93219243_139.3159987_5/t=print/size=640x740/icon=home,139.31599869871812,36.93219243059891/
 

 

The “tertiary” intersection 
http://www.mapion.co.jp/m/basic/?t=print&lat=36.4033877201575&lon=139.0776209799907&scl=9&icon=home,139.0776209799907,36.4033877201575/
 



As you can see, rendered width of the roads is the defining feature of use 
(check Google Maps, it uses Zenrin data up close to show the width too) and the 
classification below “trunk" is less important,  whereas in OSM, the 
classification is most important.  The width and standards of most roads 
changes drastically as they go along, and rendering the width change is easer 
than reclassifying the roads section by section to reflect changing road 
standards (width, traffic volume, shoulder, curve radius, expected hazards, 
etc). 


BTW - the way Mapion renders different neighboorhoods, borders, and other 
things are quite interesting, especially as it drastically changes with the 
zoom level. 
http://www.mapion.co.jp/m/36.43371388_139.05561388_8/v=m1:群馬県前橋市関根町28/ 

 might have some good ideas for -carto in the future. 


Javbw


___
Ta

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

[johnw]

> On Jan 15, 2015, at 8:43 PM, Janko Mihelić  wrote:
> 
> 2015-01-15 12:23 GMT+01:00 Andrew Shadura  >:
> On 15 January 2015 at 03:02, johnw mailto:jo...@mac.com>> 
> wrote:
> > The proposal seems to be a good solution to this problem.
> 
> This particular proposal seems to be a terrible solution to this
> problem. It requires changes to the software, and the tagging scheme
> is ugly as hell. At the same time, there's much simpler and better
> solution: placing address nodes inside the building polygon. This is
> already used, supported by any sort of software which can process
> regular OSM address tags, and it's not as ugly as addrN:.
> 
> With addrN:*=* it's clear that the same place has two addresses. If there are 
> two nodes, it seems like there are two places (Two entrances, two apartments, 
> two rooms), each with it's own address. AddrN* is clearly superior in this 
> aspect. 
> 

+1  Why have two pins for the same (exact) place. If this was the case that a 
building had multiple addresses because it had multiple named locations or 
multiple names entrances or whatnot, such as two offices or two gates, then 
yea, two pins would be appropriate. But that doesn’t seem to be the case.  

 This seems to be a a single building that itself has two contrasting 
addresses. why tag the same thing twice? that seems counter-intuitive. We 
already have like what, how many different name fields and alt names and 
official names and everything - but addr2 requires a split - though it’s the 
same address for the same place in the same location? 

Especially if this tag is already in use in regions where this unique thing 
occurs - lets document it so it doesn’t get out of hand or get fragged so 
support for it becomes truly PITA. 

Javbw


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

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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Friedrich Volkmann]

On 15.01.2015 23:10, Tobias Knerr wrote:
> I feel this is far too generic. Imagine a renderer which wants to show
> names of lakes at zoom 12, cliff formations at zoom 14, and cave systems
> at zoom 16. If all these are simply a type=cluster + name=*, then that
> becomes difficult. There needs to be a clear indication of what type of
> feature we are dealing with, not just a name.

In order to display a name, the renderer needs to know a position. In order
to calculate a position, it needs to iterate through the relation members.
While iterating, it can sum up their types and counts. Say, if two mampers
are lakes, five are natural=cliff, and one is a cave, the natural=cliff
members make up the majority, and the cluster can be handled as a cluster of
cliffs, thus rendered at zoom level 14 and higher.

Another idea is to propagate the name to the members and then treat each
member individually.

Of course any ot these algorithms only works when it is implemented, but
this not too difficult. If the algorithm is not implemented, nothing evil
happens. The name is just invisible, as is already right now without the
relation.

-- 
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 - RFC - addrN:*

[Friedrich Volkmann]

On 15.01.2015 17:29, Serge Wroclawski wrote:
> As I examine it, it serves one very specific purpose, which is a
> building with two addresses.

It can also be applied to other areas (e.g. parcels) or nodes (e.g. shop
nodes). Of course, the common crux is the existence of two or more
equivalent addresses.

> In my experience, this setup is often (not always) associated with a
> building with two entrances, each associated with an address.
> 
> 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.

> The other way I see these entrances used in real life is that one
> business or residence within a building uses one address, while
> another uses a different one.
> 
> Here again, a POI would be more accurate and easier to parse.

Yes.

> This leaves us with the scenario with a building which has both
> addresses associated with any entrance.

Yes, that case is the main reason for the proposal.

> So here we essentially a list of values.
> 
> To that end, I don't see why we can't use the existing OSM list value
> separator, the semicolon, so the address is:
> 
> addr=val1;val2;val3
> 
> This is advantageous to data users because without this, they would
> have to look for N arbitrary tags, as in addr, add2, add3, etc.
> 
> 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. There is an addr:city=* key for the city, an
addr:postcode=* key for the postcode, an addr:street=* key, and
addr:housenumber=* key, and others. One complete address is therefore
represented by a whole set of keys. So if you use list separators, you have:

addr:city=val1;val2;val3
addr:postcode=val4;val5;val6
addr:street=val7;val8;val9
addr:housenumber=val10;val11;val12

This is possible, but error-prone, particularly with longer address parts:

addr:city=New York;
Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch; Ho Chi Minh City
addr:postcode=14324;45345,343;5645
addr:street=Red Street; Rue Morgue; Blue Street: Green Street
addr:housenumber=1;4;3;2;4

How long do you take to spot the errors? How will applications handle that data?

And if one of the addresses really lacks one of the address parts (e.g. no
street in case of a conscription number), you end up with an empty list
element, e.g.:

leading separator:
addr:street=;Rue Morgue; Blue Street; Green Street

or two consecutive separators:
addr:street=Red Street; ; Blue Street; Green Street

or a trailing separator:
addr:street=Red Street; Rue Morgue; Blue Street; Green Street;

With the addrN scheme, these addresses would be represented like this:

addr:city=New York
addr:postcode=14324
addr:street=Red Street
addr:housenumber=1

addr2:city=Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch
addr2:postcode=45345
addr2:street=Rue Morgue
addr2:housenumber=4

addr3:city=...
...

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

-- 
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] waterway=wadi problem

[johnw]

That’s all of San Diego - the storm drain system is so anemic - I’ve 
hydroplaned my car down the freeway (“Surfing interstate 5”), and forded a few 
“intermittent” rivers before I moved to Japan. here in Japan, torrential rain 
is really a non-issue most of the time - whereas a few cm of rain in Southern 
California means death on the roads and flooding underpasses. maybe it’s all 
the bald tires, oily roads, and people going 30-40km/h over what they should be 
driving.  One wonders.  ^_^

Javbw

> On Jan 16, 2015, at 9:27 AM, Eugene Alvin Villar  wrote:
> 
> Given the current discussion, I wonder if roads that are usually flooded 
> during heavy rainfall should be also be tagged as waterway=river/stream and 
> intermittent=yes. ;-)
> 
> On Fri, Jan 16, 2015 at 7:27 AM, John F. Eldredge  > wrote:
> I would recommend expanding the definition of "intermittent streams" to 
> include not only streams that have a regular, seasonal water flow but also 
> streams in desert areas that exist only when a rare storm comes along. The 
> topography is the same, the tendency of water to run downhill is the same, 
> only the frequency of rainfall is different.
> 
> -- 
> John F. Eldredge -- j...@jfeldredge.com 
> "Darkness cannot drive out darkness; only light can do that. Hate cannot 
> drive out hate; only love can do that." -- Martin Luther King, Jr.
> 
> 
> 
> 
> On January 15, 2015 3:13:38 AM Christoph Hormann  > wrote:
> 
> On Thursday 15 January 2015, johnw wrote:
> >
> > A wadi is a place where flash floods occur. It is not an intermittent
> > river - it isn’t really seasonally wet, and doesn’t provide any real
> > expectation that water will be present (except deep underground) -
> > because they are located in places where rain itself is unexpected
> > for most of the year.
> 
> Well - that would be a useful concept of a wadi but it has two problems:
> 
> * current use of the tag is very different from that, you can see that
> quite well when you look at the taginfo map:
> 
> https://taginfo.openstreetmap.org/tags/waterway=wadi#map 
> 
> 
> the uses in Europe for example are probably almost always seasonal.
> 
> * sporadic waterflow is very difficult to determine for the mapper.
> This is especially true for northern Africa where climate got a lot
> drier in the last few thousand years and as a result there are many
> permanently dry valleys that still look like being formed by waterflow
> but that have not seen significant waterflow in the last hundred years.
> 
> My suggestion would probably be to stop rendering waterway=wadi in a way
> implying waterflow, encourage mappers to use intermittent/seasonal
> where this is known and reserve waterway=wadi - despite the then
> misleading key - for valleys where waterflow is unknown.
> 
> --
> Christoph Hormann
> http://www.imagico.de/ 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> ___
> 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

[johnw]

> On Jan 15, 2015, at 6:13 PM, Christoph Hormann  wrote:
> 
> On Thursday 15 January 2015, johnw wrote:
>> 
>> A wadi is a place where flash floods occur. It is not an intermittent
>> river - it isn’t really seasonally wet, and doesn’t provide any real
>> expectation that water will be present (except deep underground) -
>> because they are located in places where rain itself is unexpected
>> for most of the year.
> 
> Well - that would be a useful concept of a wadi but it has two problems:
> 
> * current use of the tag is very different from that, you can see that 
> quite well when you look at the taginfo map:
> 
> https://taginfo.openstreetmap.org/tags/waterway=wadi#map
> 
> the uses in Europe for example are probably almost always seasonal.
> * sporadic waterflow is very difficult to determine for the mapper.  
> This is especially true for northern Africa where climate got a lot 
> drier in the last few thousand years and as a result there are many 
> permanently dry valleys that still look like being formed by waterflow 
> but that have not seen significant waterflow in the last hundred years.
> 
> My suggestion would probably be to stop rendering waterway=wadi in a way 
> implying waterflow, encourage mappers to use intermittent/seasonal 
> where this is known and reserve waterway=wadi - despite the then 
> misleading key - for valleys where waterflow is unknown.
> 

if it is the case that wadis are 

- not following my definition of a wadi

- not currently tagged on wadis


Then spitting off waterway=wash is the best idea, because 

- it is a defined geographic feature 

- is labeled and well known in the regions they exist, and are easy to tell 
apart to regional mappers. 

- and most importantly (to me) has a much different connotation than 
“intermittant stream” 

- more accurately describes the world as it exists. 

However all those tags in Africa and the Americas are probably correctly tagged.

I bet cleanup of this tag will require some re-tagging, or a much broader 
definition of wadi - which would turn it into an intermittent  or seasonal 
stream/river, so what’s the point of having the tag then…

thanks for the useful data/map.


> -- 
> Christoph Hormann
> http://www.imagico.de/
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] waterway=wadi problem

[Eugene Alvin Villar]

Given the current discussion, I wonder if roads that are usually flooded
during heavy rainfall should be also be tagged as waterway=river/stream and
intermittent=yes. ;-)

On Fri, Jan 16, 2015 at 7:27 AM, John F. Eldredge 
wrote:

> I would recommend expanding the definition of "intermittent streams" to
> include not only streams that have a regular, seasonal water flow but also
> streams in desert areas that exist only when a rare storm comes along. The
> topography is the same, the tendency of water to run downhill is the same,
> only the frequency of rainfall is different.
>
> --
> John F. Eldredge -- j...@jfeldredge.com
> "Darkness cannot drive out darkness; only light can do that. Hate cannot
> drive out hate; only love can do that." -- Martin Luther King, Jr.
>
>
>
>
> On January 15, 2015 3:13:38 AM Christoph Hormann 
> wrote:
>
>  On Thursday 15 January 2015, johnw wrote:
>> >
>> > A wadi is a place where flash floods occur. It is not an intermittent
>> > river - it isn’t really seasonally wet, and doesn’t provide any real
>> > expectation that water will be present (except deep underground) -
>> > because they are located in places where rain itself is unexpected
>> > for most of the year.
>>
>> Well - that would be a useful concept of a wadi but it has two problems:
>>
>> * current use of the tag is very different from that, you can see that
>> quite well when you look at the taginfo map:
>>
>> https://taginfo.openstreetmap.org/tags/waterway=wadi#map
>>
>> the uses in Europe for example are probably almost always seasonal.
>>
>> * sporadic waterflow is very difficult to determine for the mapper.
>> This is especially true for northern Africa where climate got a lot
>> drier in the last few thousand years and as a result there are many
>> permanently dry valleys that still look like being formed by waterflow
>> but that have not seen significant waterflow in the last hundred years.
>>
>> My suggestion would probably be to stop rendering waterway=wadi in a way
>> implying waterflow, encourage mappers to use intermittent/seasonal
>> where this is known and reserve waterway=wadi - despite the then
>> misleading key - for valleys where waterflow is unknown.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=wadi problem

[johnw]

as far as I am aware, a wash, an arroyo, and a wadi are functionally the same. 
It is mostly a separation of language - where the words wash, arroyo, and wadi 
are basically the same functional thing, however Wadi and arroyo, in some 
regions, also have a wider definition that includes other valley definitions. 

as it might be confusing to have three tags for the same thing (A lot of washes 
in California have Spanish names using the word Arroyo (“Arroyo Seco Del 
Diablo” ) and we have a de facto established tag with wadi, it seems like 
making three tags for the same functional item is overkill - as long as we 
preface that whatever it is being tagged functionally be a “wadi", not one in 
name only.

That seems like a small caveat to avoid confusion between 3 tags. 

If avoiding that confusion at all costs means 3 tags, then lets make three tags 
- waterway=arroyo, waterway=wash, waterway=wadi and the different nuances 
between what really defines the tag can be spelled out on each page, and 
regional taggers can find a tag they are familiar with.


I spelled out my definition of a wadi on the waterway=wadi talk page. 
http://wiki.openstreetmap.org/wiki/Talk:Tag:waterway%3Dwadi 


I look forward to further input, especially anyone who lives in a region with 
things called "wadis" - as my experience is with “washes" in California.

Javbw. 


> On Jan 15, 2015, at 6:09 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> 
> 
>> Am 15.01.2015 um 05:27 schrieb John Willis :
>> 
>> I'm really surprised you were "shot down" from using wadi when it is the 
>> most applicable tag for the item, 
> 
> 
> sometimes the most applicable tag is not sufficiently well describing/ 
> distinguishing a feature and it is better to introduce a new tag that fits 
> 100%
> 
> To me, the Term "wadi" is quite specific for certain waterways that occur in 
> a certain region of the world. We can decide whether we'd want to use it 
> anyway everywhere for "similar" (or partly similar) features or if we 
> introduce other, dedicated  tags on the same level of specificity for these 
> features. Why not having a tag waterway=wash, or are those really the same 
> than a "wadi"?
> 
> 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] Feature Proposal - RFC - addrN:*

[Clifford Snow]

On Thu, Jan 15, 2015 at 4:04 PM, Friedrich Volkmann  wrote:

> This exact approach is new to me. 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.
>

Address schemes that users can easily understand. If AddrN is approved, the
address wiki page needs to be updated to clearly show the difference
between multiple addresses in a building with multiple entrances and a
building with multiple addresses for the same entrance. (If I understand
the proposal correctly.) Possibly add something like "rarely used."




-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Friedrich Volkmann]

On 15.01.2015 17:08, Florian Schäfer wrote:
> in Czech Republic they have a similar problem: They have so called
> conscription numbers, which are unique in the whole city and
> additionally the normal housenumbers.
> They use the key addr:streetnumber (675,742× used) for the number unique
> within the street, addr:conscriptionnumber (2,632,784× used) for the
> number unique within the city and addr:housenumber for both separated by
> a slash (tagging for the renderer?!).
> 
> It's most likely not a solution to the problem you want to solve, where
> one house has two housenumbers unique within a street as far as I
> understand. But probably it's good to know about this similar problem.

This exact approach is new to me. 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.

-- 
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] waterway=wadi problem

[John F. Eldredge]

I would recommend expanding the definition of "intermittent streams" to 
include not only streams that have a regular, seasonal water flow but also 
streams in desert areas that exist only when a rare storm comes along. The 
topography is the same, the tendency of water to run downhill is the same, 
only the frequency of rainfall is different.


--
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness; only light can do that. Hate cannot 
drive out hate; only love can do that." -- Martin Luther King, Jr.




On January 15, 2015 3:13:38 AM Christoph Hormann  wrote:


On Thursday 15 January 2015, johnw wrote:
>
> A wadi is a place where flash floods occur. It is not an intermittent
> river - it isn’t really seasonally wet, and doesn’t provide any real
> expectation that water will be present (except deep underground) -
> because they are located in places where rain itself is unexpected
> for most of the year.

Well - that would be a useful concept of a wadi but it has two problems:

* current use of the tag is very different from that, you can see that
quite well when you look at the taginfo map:

https://taginfo.openstreetmap.org/tags/waterway=wadi#map

the uses in Europe for example are probably almost always seasonal.

* sporadic waterflow is very difficult to determine for the mapper.
This is especially true for northern Africa where climate got a lot
drier in the last few thousand years and as a result there are many
permanently dry valleys that still look like being formed by waterflow
but that have not seen significant waterflow in the last hundred years.

My suggestion would probably be to stop rendering waterway=wadi in a way
implying waterflow, encourage mappers to use intermittent/seasonal
where this is known and reserve waterway=wadi - despite the then
misleading key - for valleys where waterflow is unknown.

--
Christoph Hormann
http://www.imagico.de/

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




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

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

[Michael Kugelmann]

On 15.01.2015 Andrew Shadura wrote:

At the same time, there's much simpler and better
solution: placing address nodes inside the building polygon.

+1.


Cheers,
Michael.

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

[Tagging] Cooperation between depts.

[Daniel Koć]

W dniu 15.01.2015 23:35, Warin napisał(a):


 What I'm after is a 'guide' rather than strict rules. Strict rules
won't encourage people to map things. Consistent tags, tools that are
easy to understand and use will encourage people as they don't have to
understand complex things.


For me strictness is not a big issue - but more coherence is.

In Wikipedia we have two editors (edit rich text/edit markup text), 
discussion pages for objects and tagging rules - all that included 
in-site and that helps. Now in OSM we need more of that attitude: I mean 
some form of cooperation between "default tagging", "editing", 
"searching" and "default rendering" depts. Not the strict one, but 
seeing the whole picture, not only one's own part.


Recently added commenting the changestes, as well as trying to collect 
common icons and common imagery set for editors are nice steps in this 
direction. The project will always stay decentralized and will have 
fuzzy borders, but more coordination will benefit even casual, detached 
mappers.


--
Mambałaga

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

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

[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.

-- 
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 - RFC - addrN:*

[Friedrich Volkmann]

On 15.01.2015 12:53, Martin Koppenhoefer wrote:
> you could use polygons (e.g. 2 distinct multipolygons, one for each
> address), and add a note to inform your fellow mapping colleagues that the
> overlap is intended (note is not needed but nice).

That still separates the feature from its address, not in a topographical
sense, but in the sense that tags for one feature are fragemented to
multiple OSM objects.

I wonder why multiple addresses are so loathed while multiple objects or
even multiple relations for the same purpose are considered ok.

-- 
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 - RFC - addrN:*

[Friedrich Volkmann]

On 15.01.2015 12:23, Andrew Shadura wrote:
> This particular proposal seems to be a terrible solution to this
> problem. It requires changes to the software,

Come on, this change is a five-minute task.

Every new feature requires changes to software. If you abolished all new
features for that reason, OSM would be a blank white map.

> and the tagging scheme is ugly as hell.

Please explain why you find it ugly.

> At the same time, there's much simpler and better
> solution: placing address nodes inside the building polygon. This is
> already used, supported by any sort of software which can process
> regular OSM address tags, and it's not as ugly as addrN:.

See the wiki (proposal and talk page) why this isn't sufficient.

BTW: You should vote after start of voting, not before discussion has even
started. You are obviously so biased that you don't care at all for other
opinions or facts.

-- 
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] Tagging Digest, Vol 64, Issue 52

[Warin]

On 16/01/2015 7:21 AM, tagging-requ...@openstreetmap.org wrote:

Date: Thu, 15 Jan 2015 21:13:11 +0100
From: Kotya Karapetyan
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Basic philosophy of OSM tagging
Message-ID:

Content-Type: text/plain; charset=UTF-8

Hi Marc,


>By forced rules: you mean a committee that decides what gets mapped and how
>?
>So when I want to map something now, I have to file a request to the
>committee to start looking for a new tag. And if they like the request they
>come back within a few months with a proposal. And this committee is
>all-knowing, so they know all the exceptions in the different countries ? So
>I don't have to ask for an update when they misunderstood me ?

My vision was more along these lines. There will be a tagging
committee: It will maintain the official OSM tagging scheme. Mapping
will not be changed w.r.t. the current situation. The tagging
functionality as such will remain as it is, however:


'We' already have a 'system' of similar attributes.
The 'official tags' have wiki pages
The mapers can use tag that have no wiki pages

Having a 'committee' will not change the use of unofficial tags.. so 
tags that don't get approved by the 'committee' will simply be used 
anyway. Poor tags would probably go through a committee too, and 
probably reject 'good' tags as well. Consider the 'committee' to be this 
loose group of people here, that constantly changes and needs no 
selection, election but simply exists on the good intentions of the 
members. Much like the rest of OSM.


---
Someone said 'pick your battles'. I don't see it that way. I seek 
information. Hopefully it will help with future proposed tags. Not 
seeking to 'win' nor 'loose'. Nor change things directly with this subject.


---
What I'm after is a 'guide' rather than strict rules. Strict rules won't 
encourage people to map things. Consistent tags, tools that are easy to 
understand and use will encourage people as they don't have to 
understand complex things.


I could pick on a few tags that I think would be better placed 
elsewhere. But that is from my perspective and attitude. I'd like your 
perspective and attitude on how tags should be organised. In particular 
the top level tags ...





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

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

[Friedrich Volkmann]

On 15.01.2015 22:37, Clifford Snow wrote:
> As far as I can understand, this issue only really becomes a problem with
> tagging an amenity, shop, office, etc. It made me wonder how the business
> advertises and get mail. I can't imagine businesses using two different
> addresses. Then again I've never lived anywhere with this problem. Has
> anyone asked the business owners which address they use? 
> 
> Rather than add to the tagging scheme, I think we should first try to
> understand it from the business viewpoint.

I worked as a postman in Vienna for some months and I can confiirm that
businesses as well as private residents get mail with different addresses.
In that context I should add that some businesses get mail to PO boxes which
do not relate to a street or housenumber. Therefore, my original proposal
incorporated an addr:pob=* key as well. I left that out in the new proposal
to decrease complexity, as people vote against everything they do not fully
understand.

-- 
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 - RFC - Cluster

[Tobias Knerr]

On 15.01.2015 02:02, Friedrich Volkmann wrote:
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
> 
> This is for grouping features that are more or less of the same kind. See
> examples.

I feel this is far too generic. Imagine a renderer which wants to show
names of lakes at zoom 12, cliff formations at zoom 14, and cave systems
at zoom 16. If all these are simply a type=cluster + name=*, then that
becomes difficult. There needs to be a clear indication of what type of
feature we are dealing with, not just a name.

Generally, I prefer relation types like "building", "bridge" or even
"street" over vague types like "cluster", "multiobject" or "collection"
that try to be applicable to everything and too often fail to be a
perfect fit for anything.

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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Friedrich Volkmann]

On 15.01.2015 13:23, Janko Mihelić wrote:
> IMHO we don't even need a relation. All islands can have the same  tag
> cluster:archipelago=*. If data consumers find a tag that starts with
> "cluster:" they can group all elements that have the same
> cluster:archipelago.

Within what radius? And what if you want to tag old names, spanish names
etc.? Do they go to cluster:old_archipelago=*, cluster:archipelago:es=* etc?
On every island?

> It's the same as streets in a city. How do you know if
> two segments of a street are the same street? They have the same name.

And they have a common node! (or a common node with a segment with the same
name and a common node...)

-- 
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 - RFC - addrN:*

[Clifford Snow]

On Thu, Jan 15, 2015 at 4:10 AM, Dan S  wrote:

> I was thinking about this solution too. The addrN scheme is really
> quite awkward so it'd be nice to recommend something like simply
> having two nodes/multipolygons with exactly the same overlapping
> geometry. However, this gets horrible too: if both of the addresses
> refer to a pub, should both objects be amenity=pub? (No!) Should they
> be grouped under a relation which holds amenity=pub other properties?
> Maybe, but that's getting just as awkward as addrN... It looks like
> there's a problem to be solved, and none of the solutions is pleasant.
> Hence I abstain ;)
>

As far as I can understand, this issue only really becomes a problem with
tagging an amenity, shop, office, etc. It made me wonder how the business
advertises and get mail. I can't imagine businesses using two different
addresses. Then again I've never lived anywhere with this problem. Has
anyone asked the business owners which address they use?

Rather than add to the tagging scheme, I think we should first try to
understand it from the business viewpoint.

If the business only uses one of the addresses, then the problem is solved
with two nodes, ideally inside a building polygon.

Clifford


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic philosophy of OSM tagging

[David Bannon]

On Thu, 2015-01-15 at 18:07 +0100, Michał Brzozowski wrote:

> Some people in Poland (the ones who never browse community forums)
> maniacally tag every dirt road as highway=track, even if it should be
> residential+unpaved 

Thats is a case of "tagging for the renderer" I'm afraid. They do that
because they want to see the map show the unpaved-ness (sorry) of the
road. Clearly wrong but you can understand why they do it.

I have had my say on the topic many times as has many other people.

It does, IMHO, highlight one more aspect of this philosophy question.
People map and want to see the data they enter used in some way. That
"seeing" is an essential part of the feedback loop. We need to consider
that when looking at how people choose (or invent) tags.

David





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

Re: [Tagging] Tag destination vs. relation destination_sign

[fly]

Actually the signs alone make it difficult, we need good pictures with
the road and signs.

Often it is tagged on highway=*_link but for sure there are other cases.

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

cu fly

Am 15.01.2015 um 19:48 schrieb 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?
> Lukas Sommer
> 
> 
> 2015-01-11 15:48 GMT+00:00 Martin Vonwald :
>> 2015-01-10 19:40 GMT+01:00 Lukas Sommer :
>>>
>>> +1. Key:destination for the simple cases the the relation for the
>>> complex cases seems fine for me.
>>
>>
>> I'll wait until monday and if up to then nobody complains, I'll update the
>> wiki as mentioned before.


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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Friedrich Volkmann]

On 15.01.2015 11:23, Martin Koppenhoefer wrote:
> this is quite generic what has advantages (apllicable to everything) and
> disadvantages (it might often not be clear, to what property the
> "clustering" refers).

What do you mean by "property"? Can you describe an example?

> I wonder if it wouldn't make more sense to use the
> approach of islands / archipelago, i.e. have a dedicated, explicit and
> specific tag for the "combined feature" (e.g. several natural=island/islet
> can be together in a multipolygon relation which is tagged 
> natural=archipelago).

Multipolygons require areas. You cannot use them to group nodes (e.g. cave
entrances) or lines (e.g, cliffs).

> In your examples, there could be tags for several lakes:
> natural=lacustrine_district / lake_district or maybe "series_of_lakes"
> (didn't find a good English word for "DE:Seengruppe").
> 
> Didn't find a good one neither for DE:Höhlengruppe (maybe just plural 
> "caves"?)
> 
> DE:Felsengruppe could translate to "natural=range_of_rocks"
> (maybe also the caves could be "range_of_caves"??)

I guess that while writing your message you altready noticed that the number
of new tags would become gigantic.

-- 
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] Power networks European codification scheme

[Ole Nielsen]

I'm not sure how these codes could benefit OSM. 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.


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.


Ole

On 14/01/2015 21:54, François Lacombe wrote:

Hi all,

I've just discovered a document published by ENTSO-E which is the
European authority for power Transmission System Operators (like RTE in
France or TenneT in Germany :
https://www.entsoe.eu/about-entso-e/inside-entso-e/member-companies/Pages/default.aspx)

This document summarizes a couple of principles for power system
elements codification.
http://clients.rte-france.com/htm/fr/vie/telecharge/EIC-Reference%20Manual%20v4r4.pdf

I think it would be great to introduce the key ref:EU:EIC to tag
transmission power lines, power plant or transmission power substation
with it.
These codes seem to be unique all around Europe and they would allow us
to sustainably identify a lot of features (instead of using the OSM ID
only).

I only found one instance of eic_code=* on taginfo which actually
concern a feature located in Czech Republic (they do have a wikipedia
page for it http://cs.wikipedia.org/wiki/EIC_k%C3%B3d)

If everyone agree about the key, I may add it to the Power Transmission
Refinement proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement


All the best

*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



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

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

On Thu, Jan 15, 2015 at 6:07 PM, Michał Brzozowski  wrote:
> Also, I think that editor presets makers should really implement *all*
> approved tags (barring some specialized stuff like OSM-3D, indoor
> mapping etc) because not featuring a tag makes some people tag things
> not exactly correctly, just to map it.

+1.

I would also like us to discuss a possibility of making the tagging
scheme more error-proof. A couple of issues to address:
1) Conflicting tags should be prevented by means of software.
2) Suggested tags functionality should be implemented.
3) Official tag description should be automatically taken from the
formal approved tagging scheme and shown in the mapping tool, to
minimize misunderstanding. Full tag description stays in the wiki to
include examples, photos, context etc.
4) Invalid tag values should be automatically identified and warnings
should be shown.

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

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

Hi Marc,

> By forced rules: you mean a committee that decides what gets mapped and how
> ?
> So when I want to map something now, I have to file a request to the
> committee to start looking for a new tag. And if they like the request they
> come back within a few months with a proposal. And this committee is
> all-knowing, so they know all the exceptions in the different countries ? So
> I don't have to ask for an update when they misunderstood me ?

My vision was more along these lines. There will be a tagging
committee: It will maintain the official OSM tagging scheme. Mapping
will not be changed w.r.t. the current situation. The tagging
functionality as such will remain as it is, however:
1) Software designers can use the official scheme to implement tools
for mapping, display, and routing.
2) The committee will review the existing tags to avoid conflicts, and
decide what tags are to be deprecated, where to adjust official
definition etc.
3) The short formal description of the tags is included in the scheme.
4) The committee has the final word in approving the tags (just to
remove the mess with existing discussion-voting process).
5) Mappers can still implement and use tags as now, however they
should be reviewed by the committee to get into the official scheme.

So something similar to how HTML standard is maintained by W3C:
Google, Microsoft and Mozilla can do and do whatever they like in
their browsers and online tooling, but there is an official standard
based on some proposals. The software developers do not have to stick
to the official scheme, but it helps make things more consistent.

Cheers,
Kotya

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

Re: [Tagging] Basic philosophy of OSM tagging

[Marc Gemis]

Good idea,

Building further on this idea: Right now the main problem we have with iD
in Belgium is that we have better, more recent aerial imagery that cannot
be used in iD. They are working on that but until a new version is released
new mappers might realign house with old images from Bing. It would be nice
that each country could create messages that are displayed when you start
editing in their area. So even experienced mapper could be informed about
news from the local community.


Coming back to the unpaved residential roads vs. tracks: Wouldn't that be
solved by having a map that displays the difference between a paved
residential road, unpaved and track? I know this has been discussed before.



On Thu, Jan 15, 2015 at 8:39 PM, Michał Brzozowski 
wrote:

> On Thu, Jan 15, 2015 at 6:30 PM, Marc Gemis  wrote:
>
> > Maybe it's way too easy to start mapping. Maybe you should first follow a
> > course on how to map before making your first edit. During this course
> you
> > can learn about the good mapping habits in your country. But this is
> > probably also not a popular measure.
>
> Some time ago I thought "let's be realistic" and that iD, our go-to
> editor for newbie mappers, could show some task-oriented
> mini-tutorials. Like "I want to map a / change..." so it would show
> relevant remarks (that is, like "When drawing buildings, do not place
> the outline on the roof, move it to the base. Remember to rectify
> corners if the building if applicable" and so on). A large quantity of
> mappers are, as the HDYC site ranks them, "hit-and-run mappers" that
> only map 5 or 20 edits and get bored - or just OSM is superbly mapped
> in their area (:
>
> If you can't beat them (iD), join them...
>
> Michał
>
> ___
> 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

[Michał Brzozowski]

On Thu, Jan 15, 2015 at 6:30 PM, Marc Gemis  wrote:

> Maybe it's way too easy to start mapping. Maybe you should first follow a
> course on how to map before making your first edit. During this course you
> can learn about the good mapping habits in your country. But this is
> probably also not a popular measure.

Some time ago I thought "let's be realistic" and that iD, our go-to
editor for newbie mappers, could show some task-oriented
mini-tutorials. Like "I want to map a / change..." so it would show
relevant remarks (that is, like "When drawing buildings, do not place
the outline on the roof, move it to the base. Remember to rectify
corners if the building if applicable" and so on). A large quantity of
mappers are, as the HDYC site ranks them, "hit-and-run mappers" that
only map 5 or 20 edits and get bored - or just OSM is superbly mapped
in their area (:

If you can't beat them (iD), join them...

Michał

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

Re: [Tagging] Tag destination vs. relation destination_sign

[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?
Lukas Sommer


2015-01-11 15:48 GMT+00:00 Martin Vonwald :
> 2015-01-10 19:40 GMT+01:00 Lukas Sommer :
>>
>> +1. Key:destination for the simple cases the the relation for the
>> complex cases seems fine for me.
>
>
> I'll wait until monday and if up to then nobody complains, I'll update the
> wiki as mentioned before.
>
> bg,
> 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] Basic philosophy of OSM tagging

[Marc Gemis]

On Thu, Jan 15, 2015 at 6:07 PM, Michał Brzozowski 
wrote:

> Some people in Poland (the ones who never browse community forums)
> maniacally tag every dirt road as highway=track, even if it should be
> residential+unpaved (Like short named streets at suburbs)
>

so how would this be solved by more formal rules ? The wiki now already
discribes how to tag such a road.
If people insist on taking the wrong value in the editor, you cannot do
much about it. In controlled environments you can fire the employee if they
don't map by the rules, in OSM you can only block 1 user account after a
long process. Are there any other crowd-sourced maps ? Otherwise it would
be difficult to find examples of how others do it.

Maybe it's way too easy to start mapping. Maybe you should first follow a
course on how to map before making your first edit. During this course you
can learn about the good mapping habits in your country. But this is
probably also not a popular measure.

I  like your idea of editors adding more tags in their presets, but it
doesn't necessarily have to be the approved ones. Some non approved tags
are used more. So, all the ones with significant usage according to taginfo
should be included.

The more I learn about the tag-approval process, the less suitable it seems
to me for an every growing community. Maybe 10 votes was a lot in the early
days, now it is peanuts. This morning I just thought about it and it is
pretty easy to set up 10 accounts and vote in favour of any tag I like.
Same is true for no-votes. There is no control over who votes... Not that
it was misused in this way yet.

Regarding the tagging:

is it important that there are 100's of amenities on the toplevel ? What's
the problem with that ? I really don't care what the key is under which
e.g. place_of_worship can be found, it could as well have been "aaa001". I
just hope that the editor allows me to look for place of worship and offer
me the right tag. I there anyone browsing all amenities ? On the wiki I
just search for the value and hope to get the right page.

We should have better tools to find the tags we need, the schema is less
important. Someone is working on a tool to show all similar tags, using
synonyms etc. that seems very promising to me

regards

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

Re: [Tagging] Basic philosophy of OSM tagging

[Michał Brzozowski]

Yes. As much as all this "you can use any tags you want" creates an
environment open for innovation, it creates a horrible mess when you
use it without coordination and on existing features.
Also, no-one seems to ask a question "How it that problem solved in
other maps?" when proposing tags or other solutions.
No need to re-invent the wheel. Look how others do it and you may find
an elegant or just practical solution.

Some people in Poland (the ones who never browse community forums)
maniacally tag every dirt road as highway=track, even if it should be
residential+unpaved (Like short named streets at suburbs) Another
prevalent  thing is tagging every place such as out-patient clinic as
amenity=hospital.
Lack of discipline is very annoying because correcting these is a
Sisyphean task.

Also, I think that editor presets makers should really implement *all*
approved tags (barring some specialized stuff like OSM-3D, indoor
mapping etc) because not featuring a tag makes some people tag things
not exactly correctly, just to map it.

Michał

On Thu, Jan 15, 2015 at 5:08 PM, Kotya Karapetyan  wrote:
> Now that the water_tap proposal discussion is over, I'd like to join
> this important discussion.
>
> My opinion: Since OSM is a *map*, we should *map* things. That means,
> we should tag what actually exists on the planet, not what is implied.
> Sometimes things are tagged in real life. For example, motorways are
> marked with special traffic signs, therefore we can tag a road as
> motorway. In other cases, we should use common sense to call the
> things by their names. I am usually asking myself: How would I explain
> to a tourist how to find his way? I will use something like "Pass by
> ..." or "You will see ...". This "..." is then the name (hence tag) to
> be used.
>
> A good example of the contrary is amenity=drinking_water. Though the
> original intention is clear, I believe the solution is suboptimal: a
> tourist wouldn't know what to search for (since it is not drinking
> water but rather its source that is actually visible in a given
> place). A mapper may also have hard times identifying whether a
> specific water source provides potable water or not.
>
> So, my answer would be we should map what the things *appear to be*.
> Taking the example of Japanese roads, I would also add "with
> reasonably common knowledge". It does leave some space for
> uncertainty, but this uncertainty is also present in real life, so it
> can appear in OSM as well.
>
>
> Warin's question also identifies a problem I'd like to discuss. There
> seem to be no "formal" agreements on how to create OSM. Things are
> documented in the wiki, which is subject to uncontrolled changes and
> no review and which is not always read by the mappers. Data is then
> used by software development companies in the way they find
> reasonable, without any foundation for consistency. It may be cultural
> but I am looking for some sort of more robust, maybe even enforced,
> agreements. They may be subject to changes, but their mere existence
> would help. What do you think?
>
>
> Cheers,
> Kotya
>
>
>
>
> On Wed, Jan 14, 2015 at 1:28 AM, Warin <61sundow...@gmail.com> wrote:
>> This comes from the tap discussion but has implications elsewhere.
>>
>> What is the basic philosophy of OSM tagging at the top level?
>>
>> Are 'we' tagging for
>>
>> What things are? eg highways
>>
>> OR
>>
>> What things are used for? eg amenity
>>
>> 
>> Explanation? By example;
>>
>> Highways are used for transport so would be better tagged as
>> transport=motorway, sub tags for vehicles etc.
>>
>> OR
>>
>> amenity=drinking_water would be better tagged as water=blubber
>>
>> --
>> Is there an FAQ on this? Or has this never been documented/though of?
>> Have fun with this  :)
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Ethnic shops

[Eric Sibert]

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

...

cuisine=* is used for restaurant and may be suitable for convenience  
but not really for clothes or hairdresser.


Any suggestion is welcome.

Eric



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

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

[Florian Schäfer]

Am 15.01.2015 um 17:26 schrieb Andrew Shadura:
> On 15 January 2015 at 17:08, Florian Schäfer  wrote:
>> Hello Friedrich,
>> in Czech Republic they have a similar problem: They have so called
>> conscription numbers, which are unique in the whole city and
>> additionally the normal housenumbers.
>> They use the key addr:streetnumber (675,742× used) for the number unique
>> within the street, addr:conscriptionnumber (2,632,784× used) for the
>> number unique within the city and addr:housenumber for both separated by
>> a slash (tagging for the renderer?!).
> This isn't actually a problem in CZ and SK at all. Conscription number
> and street number are used by Nominatim, but they're intentionally not
> rendered. Housenumber tag is left to be used as human-readable house
> number (sometimes it's two numbers separated by a slash, sometimes
> it's only one which is more appropriate in the specific context).
Yes, with "problem" I meant "solution for shortcomings of the original
Karlruhe schema", that was badly worded.



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

Re: [Tagging] Basic philosophy of OSM tagging

[Marc Gemis]

By forced rules: you mean a committee that decides what gets mapped and how
?
So when I want to map something now, I have to file a request to the
committee to start looking for a new tag. And if they like the request they
come back within a few months with a proposal. And this committee is
all-knowing, so they know all the exceptions in the different countries ?
So I don't have to ask for an update when they misunderstood me ?

wrote this half-seriously, half-jokingly

regards

m

On Thu, Jan 15, 2015 at 5:08 PM, Kotya Karapetyan 
wrote:

> Now that the water_tap proposal discussion is over, I'd like to join
> this important discussion.
>
> My opinion: Since OSM is a *map*, we should *map* things. That means,
> we should tag what actually exists on the planet, not what is implied.
> Sometimes things are tagged in real life. For example, motorways are
> marked with special traffic signs, therefore we can tag a road as
> motorway. In other cases, we should use common sense to call the
> things by their names. I am usually asking myself: How would I explain
> to a tourist how to find his way? I will use something like "Pass by
> ..." or "You will see ...". This "..." is then the name (hence tag) to
> be used.
>
> A good example of the contrary is amenity=drinking_water. Though the
> original intention is clear, I believe the solution is suboptimal: a
> tourist wouldn't know what to search for (since it is not drinking
> water but rather its source that is actually visible in a given
> place). A mapper may also have hard times identifying whether a
> specific water source provides potable water or not.
>
> So, my answer would be we should map what the things *appear to be*.
> Taking the example of Japanese roads, I would also add "with
> reasonably common knowledge". It does leave some space for
> uncertainty, but this uncertainty is also present in real life, so it
> can appear in OSM as well.
>
>
> Warin's question also identifies a problem I'd like to discuss. There
> seem to be no "formal" agreements on how to create OSM. Things are
> documented in the wiki, which is subject to uncontrolled changes and
> no review and which is not always read by the mappers. Data is then
> used by software development companies in the way they find
> reasonable, without any foundation for consistency. It may be cultural
> but I am looking for some sort of more robust, maybe even enforced,
> agreements. They may be subject to changes, but their mere existence
> would help. What do you think?
>
>
> Cheers,
> Kotya
>
>
>
>
> On Wed, Jan 14, 2015 at 1:28 AM, Warin <61sundow...@gmail.com> wrote:
> > This comes from the tap discussion but has implications elsewhere.
> >
> > What is the basic philosophy of OSM tagging at the top level?
> >
> > Are 'we' tagging for
> >
> > What things are? eg highways
> >
> > OR
> >
> > What things are used for? eg amenity
> >
> > 
> > Explanation? By example;
> >
> > Highways are used for transport so would be better tagged as
> > transport=motorway, sub tags for vehicles etc.
> >
> > OR
> >
> > amenity=drinking_water would be better tagged as water=blubber
> >
> > --
> > Is there an FAQ on this? Or has this never been documented/though of?
> > Have fun with this  :)
> >
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Serge Wroclawski]

The idea, if I understand it, is to allow for some arbitrary number of
values for an address.

That's an important goal as we increase the number of addresses in OSM.

I do have some questions/concerns about this specific proposal.

As I examine it, it serves one very specific purpose, which is a
building with two addresses.

In my experience, this setup is often (not always) associated with a
building with two entrances, each associated with an address.

In that scenario, I'd much prefer to see two nodes, each with their
address, and each tagged as an entrance.

The other way I see these entrances used in real life is that one
business or residence within a building uses one address, while
another uses a different one.

Here again, a POI would be more accurate and easier to parse.

This leaves us with the scenario with a building which has both
addresses associated with any entrance.

So here we essentially a list of values.

To that end, I don't see why we can't use the existing OSM list value
separator, the semicolon, so the address is:

addr=val1;val2;val3

This is advantageous to data users because without this, they would
have to look for N arbitrary tags, as in addr, add2, add3, etc.

What benefit does this proposal have over simply using a list separator?

- Serge

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

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

[Andrew Shadura]

On 15 January 2015 at 17:08, Florian Schäfer  wrote:
> Hello Friedrich,
> in Czech Republic they have a similar problem: They have so called
> conscription numbers, which are unique in the whole city and
> additionally the normal housenumbers.
> They use the key addr:streetnumber (675,742× used) for the number unique
> within the street, addr:conscriptionnumber (2,632,784× used) for the
> number unique within the city and addr:housenumber for both separated by
> a slash (tagging for the renderer?!).

This isn't actually a problem in CZ and SK at all. Conscription number
and street number are used by Nominatim, but they're intentionally not
rendered. Housenumber tag is left to be used as human-readable house
number (sometimes it's two numbers separated by a slash, sometimes
it's only one which is more appropriate in the specific context).

-- 
Cheers,
  Andrew

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

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

[Florian Schäfer]

Hello Friedrich,
in Czech Republic they have a similar problem: They have so called
conscription numbers, which are unique in the whole city and
additionally the normal housenumbers.
They use the key addr:streetnumber (675,742× used) for the number unique
within the street, addr:conscriptionnumber (2,632,784× used) for the
number unique within the city and addr:housenumber for both separated by
a slash (tagging for the renderer?!).

It's most likely not a solution to the problem you want to solve, where
one house has two housenumbers unique within a street as far as I
understand. But probably it's good to know about this similar problem.

floscher

Am 15.01.2015 um 02:46 schrieb Friedrich Volkmann:
> 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.
>




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

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

Now that the water_tap proposal discussion is over, I'd like to join
this important discussion.

My opinion: Since OSM is a *map*, we should *map* things. That means,
we should tag what actually exists on the planet, not what is implied.
Sometimes things are tagged in real life. For example, motorways are
marked with special traffic signs, therefore we can tag a road as
motorway. In other cases, we should use common sense to call the
things by their names. I am usually asking myself: How would I explain
to a tourist how to find his way? I will use something like "Pass by
..." or "You will see ...". This "..." is then the name (hence tag) to
be used.

A good example of the contrary is amenity=drinking_water. Though the
original intention is clear, I believe the solution is suboptimal: a
tourist wouldn't know what to search for (since it is not drinking
water but rather its source that is actually visible in a given
place). A mapper may also have hard times identifying whether a
specific water source provides potable water or not.

So, my answer would be we should map what the things *appear to be*.
Taking the example of Japanese roads, I would also add "with
reasonably common knowledge". It does leave some space for
uncertainty, but this uncertainty is also present in real life, so it
can appear in OSM as well.


Warin's question also identifies a problem I'd like to discuss. There
seem to be no "formal" agreements on how to create OSM. Things are
documented in the wiki, which is subject to uncontrolled changes and
no review and which is not always read by the mappers. Data is then
used by software development companies in the way they find
reasonable, without any foundation for consistency. It may be cultural
but I am looking for some sort of more robust, maybe even enforced,
agreements. They may be subject to changes, but their mere existence
would help. What do you think?


Cheers,
Kotya




On Wed, Jan 14, 2015 at 1:28 AM, Warin <61sundow...@gmail.com> wrote:
> This comes from the tap discussion but has implications elsewhere.
>
> What is the basic philosophy of OSM tagging at the top level?
>
> Are 'we' tagging for
>
> What things are? eg highways
>
> OR
>
> What things are used for? eg amenity
>
> 
> Explanation? By example;
>
> Highways are used for transport so would be better tagged as
> transport=motorway, sub tags for vehicles etc.
>
> OR
>
> amenity=drinking_water would be better tagged as water=blubber
>
> --
> Is there an FAQ on this? Or has this never been documented/though of?
> Have fun with this  :)
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Никита]

You should include tag this meaning "enable/disable inheritance
(propagation) of tags to all its memebers". This is main difference
between Relation:street and Relation:associatedStreet.
Sometimes you need this feature, but sometimes not.
1. inherit tags from parent relation
2. don't
3. unspecified

Also you need tag to suppress all tags that are used at its members in
order to keep data consistent (name=* is different for relation, who do you
trust?)
1. trust relation
2. trust members
3. unspecified

Many mappers fail to realise need in separate tag for this and countlessly
fight "we don't need addr:street=*", "we don't need
Relation:associatedStreet" at tagging list and wiki pages.

2015-01-15 16:23 GMT+04:00 Janko Mihelić :

> 2015-01-15 11:23 GMT+01:00 Martin Koppenhoefer :
>
>>
>>  I wonder if it wouldn't make more sense to use the approach of islands /
>> archipelago, i.e. have a dedicated, explicit and specific tag for the
>> "combined feature" (e.g. several natural=island/islet can be together in a
>> multipolygon relation which is tagged natural=archipelago).
>>
>
> IMHO we don't even need a relation. All islands can have the same  tag
> cluster:archipelago=*. If data consumers find a tag that starts with
> "cluster:" they can group all elements that have the same
> cluster:archipelago. It's the same as streets in a city. How do you know if
> two segments of a street are the same street? They have the same name.
>
> Archipelago isn't so much an entity in itself. It is just an attribute of
> the islands it is consisted of.
>
>
> ___
> 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

[Kotya Karapetyan]

Dear all,

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.

I appreciate all the discussion and help from your side (it was my
first proposal, so I didn't know exactly how it should be carried
out).

To those who voted against the proposal: Thanks to you too for
consideration. There was a bunch of remarks concerning the clash
between amenity=drinking_water and this proposal. As the discussion in
this list has shown, those who voted in support of this proposal have
been aware of the clash. The reason to introduce the new value was not
to solve all water-related problems but to close the unfortunate gap
provoking incorrect or improvised tagging. No better solution could
have been identified during the extended and long discussion. So
please consider this situation as a compromise.

There was also a remark that the water tags should be reviewed. I
fully support this idea. Let's start at the current Warin's discussion
https://lists.openstreetmap.org/pipermail/tagging/2015-January/020941.html.

Cheers,
Kotya



On Sun, Jan 11, 2015 at 11:58 AM, Kotya Karapetyan
 wrote:
> Dear all,
>
> This is a kind reminder that the voting is ongoing at
> https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting
>
> Cheers,
> Kotya

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

Re: [Tagging] Power networks European codification scheme

[Lukas Sommer]

Hello.

I think it is a good idea to introduce a new key for this.

I would recommand not to use “EU” (or “eu”) within the key. While the
fundation of this organization was based on EU laws, it is not
directly part of the administration of the EU (not part of the
European Commision and also not a direct EU instituion – and also some
non-EU countries like Macedonia are members).

Cheers

Lukas
Lukas Sommer


2015-01-15 10:08 GMT+00:00 François Lacombe :
> Hi Friedrich,
>
> Ok for the upper case.
>
> I would prefer ref:eu:eic since I'm not sure entsoe isn't used in any other
> part of the world.
> Furthermore, the E of EIC stands for ENTSO-E.
>
> A more complete solution would be ref:eu:entsoe_eic
>
>
> Cheers
>
> François Lacombe
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux
>
> 2015-01-15 7:18 GMT+01:00 Friedrich Volkmann :
>>
>> On 14.01.2015 21:54, François Lacombe wrote:
>> > I think it would be great to introduce the key ref:EU:EIC to tag
>> > transmission power lines, power plant or transmission power substation
>> > with it.
>> > These codes seem to be unique all around Europe and they would allow us
>> > to
>> > sustainably identify a lot of features (instead of using the OSM ID
>> > only).
>>
>> Please no upper case letters in key names.
>> And I am not sure about the "EU" part. Shouldn't it be ref:entsoe:eic (or
>> just ref:eic) rather than ref:eu:eic?
>>
>> --
>> 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
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Janko Mihelić]

2015-01-15 11:23 GMT+01:00 Martin Koppenhoefer :

>
>  I wonder if it wouldn't make more sense to use the approach of islands /
> archipelago, i.e. have a dedicated, explicit and specific tag for the
> "combined feature" (e.g. several natural=island/islet can be together in a
> multipolygon relation which is tagged natural=archipelago).
>

IMHO we don't even need a relation. All islands can have the same  tag
cluster:archipelago=*. If data consumers find a tag that starts with
"cluster:" they can group all elements that have the same
cluster:archipelago. It's the same as streets in a city. How do you know if
two segments of a street are the same street? They have the same name.

Archipelago isn't so much an entity in itself. It is just an attribute of
the islands it is consisted of.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Markus Lindholm]

On 15 January 2015 at 12:43, Janko Mihelić  wrote:
> 2015-01-15 12:23 GMT+01:00 Andrew Shadura :
>>
>> On 15 January 2015 at 03:02, johnw  wrote:
>> > The proposal seems to be a good solution to this problem.
>>
>> This particular proposal seems to be a terrible solution to this
>> problem. It requires changes to the software, and the tagging scheme
>> is ugly as hell. At the same time, there's much simpler and better
>> solution: placing address nodes inside the building polygon. This is
>> already used, supported by any sort of software which can process
>> regular OSM address tags, and it's not as ugly as addrN:.
>
>
> With addrN:*=* it's clear that the same place has two addresses. If there
> are two nodes, it seems like there are two places (Two entrances, two
> apartments, two rooms), each with it's own address. AddrN* is clearly
> superior in this aspect.

For an absolute majority of cases it should be enough with address
nodes that resides inside a building polygon. If their really is a
need to explicitly associate multiple addresses to a single building
then use the provides_feature relation.
http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature

/Markus

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

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

[Dan S]

2015-01-15 11:53 GMT+00:00 Martin Koppenhoefer :
>
> 2015-01-15 12:43 GMT+01:00 Janko Mihelić :
>>
>> With addrN:*=* it's clear that the same place has two addresses. If there
>> are two nodes, it seems like there are two places (Two entrances, two
>> apartments, two rooms), each with it's own address. AddrN* is clearly
>> superior in this aspect.
>
> you could use polygons (e.g. 2 distinct multipolygons, one for each
> address), and add a note to inform your fellow mapping colleagues that the
> overlap is intended (note is not needed but nice).

I was thinking about this solution too. The addrN scheme is really
quite awkward so it'd be nice to recommend something like simply
having two nodes/multipolygons with exactly the same overlapping
geometry. However, this gets horrible too: if both of the addresses
refer to a pub, should both objects be amenity=pub? (No!) Should they
be grouped under a relation which holds amenity=pub other properties?
Maybe, but that's getting just as awkward as addrN... It looks like
there's a problem to be solved, and none of the solutions is pleasant.
Hence I abstain ;)

Best
Dan

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

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

[Martin Koppenhoefer]

2015-01-15 12:43 GMT+01:00 Janko Mihelić :

> With addrN:*=* it's clear that the same place has two addresses. If there
> are two nodes, it seems like there are two places (Two entrances, two
> apartments, two rooms), each with it's own address. AddrN* is clearly
> superior in this aspect.



you could use polygons (e.g. 2 distinct multipolygons, one for each
address), and add a note to inform your fellow mapping colleagues that the
overlap is intended (note is not needed but nice).

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

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

[Andreas Labres]

On 15.01.15 12:23, Andrew Shadura wrote:
> This particular proposal seems to be a terrible solution to this problem. It
> requires changes to the software, and the tagging scheme is ugly as hell. At
> the same time, there's much simpler and better solution: placing address nodes
> inside the building polygon. This is already used, supported by any sort of
> software which can process regular OSM address tags, and it's not as ugly as
> addrN:. 

100% agreed.

/al

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

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

[Janko Mihelić]

2015-01-15 12:23 GMT+01:00 Andrew Shadura :

> On 15 January 2015 at 03:02, johnw  wrote:
> > The proposal seems to be a good solution to this problem.
>
> This particular proposal seems to be a terrible solution to this
> problem. It requires changes to the software, and the tagging scheme
> is ugly as hell. At the same time, there's much simpler and better
> solution: placing address nodes inside the building polygon. This is
> already used, supported by any sort of software which can process
> regular OSM address tags, and it's not as ugly as addrN:.
>

With addrN:*=* it's clear that the same place has two addresses. If there
are two nodes, it seems like there are two places (Two entrances, two
apartments, two rooms), each with it's own address. AddrN* is clearly
superior in this aspect.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Basic philosophy of OSM tagging

[Mateusz Konieczny]

> 4 lane ‘tertiary" road that handles 5 times the vehicle traffic,
traveling on to connect with 2 major trunk roads -
> intersects the narrow two lane “secondary road”  that is one of the small
roads coming down from the “suburbs” into the city

Interesting. I was unaware about so drastic changes in meaning of tag by
editors. This one cripples Japanese road data -
and I am unsure what could be done about it.

2015-01-15 9:13 GMT+01:00 johnw :

> I’m a newcomer, and somewhat of a noob, But I’ll take a crack at it.:
>
>  **   We are drawing existence, and tagging purpose, usage, and metadata -
> with a varying balance of importance between those 3 things. **
>
> There are some caveats - it needs to stay put for a long time, and it
> needs to be such a size that a point, way, area, or relation can be used to
> accurately enough describe it’s existence (tagging poodles is out of the
> question, unfortunately, and a point cannot accurately define a road).
>
> A road exists, and we then tag what purpose the road has. It’s usage and
> construction informs it’s classification and descriptor tags, and it’s
> name, ref and other metadata are tagged, along with it’s meta-meta data of
> what system the road belongs to in a larger context (relations).
>
> usually for man-made features, what exists is there because it’s purpose
> is why it exists. Things get fuzzy in edge cases when something is reused
> (eg: a business in an old church building), but so many things are fragile
> enough that disuse means destruction and repurposing of the land - or its
> current disuse and decay are the tags to use when showing that it exists
> (for the time being).
>
> Trouble arises since we all should use the same tag values and
> definitions, which is somewhat impossible because taggers are tagging the
> world as they feel it exists (and what purpose it has), and at the detail
> level they are comfortable or familiar with, which gives rise to issues
> between taggers, and between regions, as people from different regions see
> the world and define their world a bit differently.
>
> an overly long example:
>
> For example, here in Japan, they have a relatively rigid definition in OSM
> of what a primary and secondary road are - which in many cases has
> absolutely nothing to do with construction or usage. for the most part,
> they have no bearing to if they are truly primary or secondary roads, but
> if they are legally a certain type of road for political reasons (who
> maintains them, who owns them) - in some cases they are old, narrow, and
> meandering roads that used to be a major route (100 years ago) - but are
> now bypassed by newer and newer “bypass" roads meant exclusively for cars,
> with modern standards (like I would find in California).  Most bypass roads
> are considered “tertiary” - only because they are not in the same legal
> classification as the older, more “important” roads - though they are
> better in almost every single measurable way than the road they are
> bypassing.
>
> There is a “primary” road near my house that is thinner than many alleys
> (less than 2.5m in one spot) , has an awkward level crossing impassible by
> trucks, bridged over by the trunk road (it doesn’t connect), and I wouldn’t
> recommend using it for any reason. The nearby “tertiary” and secondary
> roads are a superior choice - and connect to the trunk roads - and even
> have painted center line(!) -  the OSM:JA definition of a tertiary road -
> which doesn’t apply to the secondary or primary roads.
>
> Similarly, Large primary roads legally take turns at intersections (they
> are almost never straight inside a city), and even though the road itself
> continues on straight in an identical manner (lanes, width, traffic,
> standards, etc), it becomes a tertiary road - and then intersects with
> several narrow, underused secondary roads! The larger, 4 lane ‘tertiary"
> road that handles 5 times the vehicle traffic, traveling on to connect with
> 2 major trunk roads -  intersects the narrow two lane “secondary road”
> that is one of the small roads coming down from the “suburbs” into the city.
>
> But this is the way Japanese people *expect* their maps to be portrayed,
> so I have to accept that this balance of metadata (the ref # on the sign)
> is more important to them than usage when it comes to road classification
> above unclassified.
>
> In other places, the primary road I mentioned would be classified as an
> “unclassified” road, and the tertiary as a primary - but it is inconsistent
> with what Japanese mappers expect, so “shoganai” - it can’t be helped.
>
>
> Figuring out this *balance* between purpose, usage, and metadata is a
> difficult, almost impossible task - not to mention how to organize the tags
> in a human usable and machine parseable manner (go-go tagging mailing
> list!), but the sentence seems to encapsulate OSM pretty well. :
>
>  **   We are drawing existence, and tagging purpose, usage, and metadata -
> with a varyin

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

[Andrew Shadura]

On 15 January 2015 at 03:02, johnw  wrote:
> The proposal seems to be a good solution to this problem.

This particular proposal seems to be a terrible solution to this
problem. It requires changes to the software, and the tagging scheme
is ugly as hell. At the same time, there's much simpler and better
solution: placing address nodes inside the building polygon. This is
already used, supported by any sort of software which can process
regular OSM address tags, and it's not as ugly as addrN:.

-- 
Cheers,
  Andrew

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

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

[Volker Schmidt]

> I never heard of alt_addr:*. Where is it documented?
>

 I could not find any documentation either. I only found it on taginfo by
analogy to alt_name.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Power networks European codification scheme

[Martin Koppenhoefer]

2015-01-15 11:08 GMT+01:00 François Lacombe :

> A more complete solution would be ref:eu:entsoe_eic




my suggestion is to use the more vocal and less susceptible to confusion
form:

ref:energy_identification_code=*

rather than the cryptic abbreviation. No need to add an "eu" into this
(implicit IMHO). If you fear confusion with other energy identification
codes you could extend it to

ref:energy_identification_code:entsoe=*

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

Re: [Tagging] Feature Proposal - RFC - Cluster

[Martin Koppenhoefer]

2015-01-15 2:02 GMT+01:00 Friedrich Volkmann :

> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
>
> This is for grouping features that are more or less of the same kind. See
> examples.
>
> No, this is not the same as a site relation. See the respective comment in
> my proposal. It is hard to compare to the site relations proposal anyway,
> because it is full of contradictions and it lacks valid examples. See my
> comments there. Please view my proposal independent of the site relation
> proposal. The type=cluster proposal aims for simplicity and usability, and
> I
> hope that we can proceed to real voting at some point.




this is quite generic what has advantages (apllicable to everything) and
disadvantages (it might often not be clear, to what property the
"clustering" refers). I wonder if it wouldn't make more sense to use the
approach of islands / archipelago, i.e. have a dedicated, explicit and
specific tag for the "combined feature" (e.g. several natural=island/islet
can be together in a multipolygon relation which is tagged
natural=archipelago).

In your examples, there could be tags for several lakes:
natural=lacustrine_district / lake_district or maybe "series_of_lakes"
(didn't find a good English word for "DE:Seengruppe").

Didn't find a good one neither for DE:Höhlengruppe (maybe just plural
"caves"?)

DE:Felsengruppe could translate to "natural=range_of_rocks"
(maybe also the caves could be "range_of_caves"??)

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

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

[Friedrich Volkmann]

On 15.01.2015 08:41, Volker Schmidt wrote:
> What's the difference to alt_addr:xxx
> (http://taginfo.openstreetmap.org/search?q=alt_addr#keys), apart from the
> fact that addrN is used more frequently?

I never heard of alt_addr:*. Where is it documented?

It seems that alt_addr:* allows only one alternate address. addrN allows for
more.

You cannot use semicolon notation as in alt_name=*, because alt_name is one
independent tag while alt_addr:* is a set of tags.

> Other point: I know that in the UK addresses may have two alternative forms:
> house name or  number. This would also fall in this category and could be
> mentioned in the proposal page.

This is already well known and documented on various wiki pages. I want to
keep the proposal concise and focus on what's new.

-- 
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] Power networks European codification scheme

[François Lacombe]

Hi Friedrich,

Ok for the upper case.

I would prefer ref:eu:eic since I'm not sure entsoe isn't used in any other
part of the world.
Furthermore, the E of EIC stands for ENTSO-E.

A more complete solution would be ref:eu:entsoe_eic


Cheers

*François Lacombe*

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

2015-01-15 7:18 GMT+01:00 Friedrich Volkmann :

> On 14.01.2015 21:54, François Lacombe wrote:
> > I think it would be great to introduce the key ref:EU:EIC to tag
> > transmission power lines, power plant or transmission power substation
> with it.
> > These codes seem to be unique all around Europe and they would allow us
> to
> > sustainably identify a lot of features (instead of using the OSM ID
> only).
>
> Please no upper case letters in key names.
> And I am not sure about the "EU" part. Shouldn't it be ref:entsoe:eic (or
> just ref:eic) rather than ref:eu:eic?
>
> --
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Cluster

[Dave Swarthout]

I encourage you to proceed with this proposal. It is, to my mind, long
overdue. Currently, tags that are placed on a relation do not propagate to
its members, which is a major shortcoming in my opinion. I have been
frustrated many times by this: tagging a named icefield containing
individually named glaciers, naming a tennis complex with more than one
cluster of courts, and as in one example from your proposal, naming a
cluster of lakes that have no individual names, only a name for the whole
group.

On Thu, Jan 15, 2015 at 9:26 AM, Friedrich Volkmann  wrote:

> On 15.01.2015 02:40, Michael Kugelmann wrote:
> > I for myself would put all related objects inside a multipart relation
> and
> > add the attributes (key/values) to that relation. For my understanding
> > that's at least one thing what multipart relations are for... (except for
> > e.g. making holes into areas)
>
> Do you refer to this proposal:
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Multipart ...?
>
> --
> 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
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=wadi problem

[Christoph Hormann]

On Thursday 15 January 2015, johnw wrote:
>
> A wadi is a place where flash floods occur. It is not an intermittent
> river - it isn’t really seasonally wet, and doesn’t provide any real
> expectation that water will be present (except deep underground) -
> because they are located in places where rain itself is unexpected
> for most of the year.

Well - that would be a useful concept of a wadi but it has two problems:

* current use of the tag is very different from that, you can see that 
quite well when you look at the taginfo map:

https://taginfo.openstreetmap.org/tags/waterway=wadi#map

the uses in Europe for example are probably almost always seasonal.

* sporadic waterflow is very difficult to determine for the mapper.  
This is especially true for northern Africa where climate got a lot 
drier in the last few thousand years and as a result there are many 
permanently dry valleys that still look like being formed by waterflow 
but that have not seen significant waterflow in the last hundred years.

My suggestion would probably be to stop rendering waterway=wadi in a way 
implying waterflow, encourage mappers to use intermittent/seasonal 
where this is known and reserve waterway=wadi - despite the then 
misleading key - for valleys where waterflow is unknown.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] waterway=wadi problem

[Martin Koppenhoefer]

> Am 15.01.2015 um 05:27 schrieb John Willis :
> 
> I'm really surprised you were "shot down" from using wadi when it is the most 
> applicable tag for the item, 


sometimes the most applicable tag is not sufficiently well describing/ 
distinguishing a feature and it is better to introduce a new tag that fits 100%

To me, the Term "wadi" is quite specific for certain waterways that occur in a 
certain region of the world. We can decide whether we'd want to use it anyway 
everywhere for "similar" (or partly similar) features or if we introduce other, 
dedicated  tags on the same level of specificity for these features. Why not 
having a tag waterway=wash, or are those really the same than a "wadi"?

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

Re: [Tagging] Basic philosophy of OSM tagging

[johnw]

I’m a newcomer, and somewhat of a noob, But I’ll take a crack at it.:

 **   We are drawing existence, and tagging purpose, usage, and metadata - with 
a varying balance of importance between those 3 things. **

There are some caveats - it needs to stay put for a long time, and it needs to 
be such a size that a point, way, area, or relation can be used to accurately 
enough describe it’s existence (tagging poodles is out of the question, 
unfortunately, and a point cannot accurately define a road). 

A road exists, and we then tag what purpose the road has. It’s usage and 
construction informs it’s classification and descriptor tags, and it’s name, 
ref and other metadata are tagged, along with it’s meta-meta data of what 
system the road belongs to in a larger context (relations). 

usually for man-made features, what exists is there because it’s purpose is why 
it exists. Things get fuzzy in edge cases when something is reused (eg: a 
business in an old church building), but so many things are fragile enough that 
disuse means destruction and repurposing of the land - or its current disuse 
and decay are the tags to use when showing that it exists (for the time being). 

Trouble arises since we all should use the same tag values and definitions, 
which is somewhat impossible because taggers are tagging the world as they feel 
it exists (and what purpose it has), and at the detail level they are 
comfortable or familiar with, which gives rise to issues between taggers, and 
between regions, as people from different regions see the world and define 
their world a bit differently. 

an overly long example: 

For example, here in Japan, they have a relatively rigid definition in OSM of 
what a primary and secondary road are - which in many cases has absolutely 
nothing to do with construction or usage. for the most part, they have no 
bearing to if they are truly primary or secondary roads, but if they are 
legally a certain type of road for political reasons (who maintains them, who 
owns them) - in some cases they are old, narrow, and meandering roads that used 
to be a major route (100 years ago) - but are now bypassed by newer and newer 
“bypass" roads meant exclusively for cars, with modern standards (like I would 
find in California).  Most bypass roads are considered “tertiary” - only 
because they are not in the same legal classification as the older, more 
“important” roads - though they are better in almost every single measurable 
way than the road they are bypassing. 

There is a “primary” road near my house that is thinner than many alleys (less 
than 2.5m in one spot) , has an awkward level crossing impassible by trucks, 
bridged over by the trunk road (it doesn’t connect), and I wouldn’t recommend 
using it for any reason. The nearby “tertiary” and secondary roads are a 
superior choice - and connect to the trunk roads - and even have painted center 
line(!) -  the OSM:JA definition of a tertiary road - which doesn’t apply to 
the secondary or primary roads.

Similarly, Large primary roads legally take turns at intersections (they are 
almost never straight inside a city), and even though the road itself continues 
on straight in an identical manner (lanes, width, traffic, standards, etc), it 
becomes a tertiary road - and then intersects with several narrow, underused 
secondary roads! The larger, 4 lane ‘tertiary" road that handles 5 times the 
vehicle traffic, traveling on to connect with 2 major trunk roads -  intersects 
the narrow two lane “secondary road”  that is one of the small roads coming 
down from the “suburbs” into the city. 

But this is the way Japanese people *expect* their maps to be portrayed, so I 
have to accept that this balance of metadata (the ref # on the sign) is more 
important to them than usage when it comes to road classification above 
unclassified. 

In other places, the primary road I mentioned would be classified as an 
“unclassified” road, and the tertiary as a primary - but it is inconsistent 
with what Japanese mappers expect, so “shoganai” - it can’t be helped. 


Figuring out this *balance* between purpose, usage, and metadata is a 
difficult, almost impossible task - not to mention how to organize the tags in 
a human usable and machine parseable manner (go-go tagging mailing list!), but 
the sentence seems to encapsulate OSM pretty well. :

 **   We are drawing existence, and tagging purpose, usage, and metadata - with 
a varying balance of importance between those 3 things. **

Javbw.


> On Jan 14, 2015, at 9:28 AM, Warin <61sundow...@gmail.com> wrote:
> 
> This comes from the tap discussion but has implications elsewhere.
> 
> What is the basic philosophy of OSM tagging at the top level?
> 
> Are 'we' tagging for
> 
> What things are? eg highways
> 
> OR
> 
> What things are used for? eg amenity
> 
> 
> Explanation? By example;
> 
> Highways are used for transport so would be better tagged as 
> transport=motorway, sub t