Re: [Tagging] Basic philosophy of OSM tagging

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

Re: [Tagging] waterway=wadi problem

> 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 n

Re: [Tagging] waterway=wadi problem

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

Re: [Tagging] Feature Proposal - RFC - Cluster

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 name

Re: [Tagging] Power networks European codification scheme

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

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

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 a

Re: [Tagging] Feature Proposal - RFC - Cluster

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

Re: [Tagging] Power networks European codification scheme

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

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

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

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 b

Re: [Tagging] Basic philosophy of OSM tagging

> 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 i

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

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 ug

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

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 buildi

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

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 c

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

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 addr

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

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 requ

Re: [Tagging] Feature Proposal - RFC - Cluster

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 relatio

Re: [Tagging] Power networks European codification scheme

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 d

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

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 f

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

Re: [Tagging] Basic philosophy of OSM tagging

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, motorw

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

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

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

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) fo

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

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 b

Re: [Tagging] Basic philosophy of OSM tagging

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-kno

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

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

[Tagging] Ethnic shops

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 wan

Re: [Tagging] Basic philosophy of OSM tagging

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 othe

Re: [Tagging] Basic philosophy of OSM tagging

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

Re: [Tagging] Tag destination vs. relation destination_sign

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

Re: [Tagging] Basic philosophy of OSM tagging

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

Re: [Tagging] Basic philosophy of OSM tagging

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 w

Re: [Tagging] Basic philosophy of OSM tagging

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

Re: [Tagging] Basic philosophy of OSM tagging

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, ju

Re: [Tagging] Power networks European codification scheme

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 neve

Re: [Tagging] Feature Proposal - RFC - Cluster

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 would

Re: [Tagging] Tag destination vs. relation destination_sign

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 litt

Re: [Tagging] Basic philosophy of OSM tagging

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 tha

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

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

Re: [Tagging] Feature Proposal - RFC - Cluster

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

Re: [Tagging] Feature Proposal - RFC - Cluster

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

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

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 ne

Re: [Tagging] Tagging Digest, Vol 64, Issue 52

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-

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

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 reas

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

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,

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

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 a

[Tagging] Cooperation between depts.

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 strictne

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

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

Re: [Tagging] waterway=wadi problem

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,

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

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

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

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

Re: [Tagging] waterway=wadi problem

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

Re: [Tagging] waterway=wadi problem

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 stream

Re: [Tagging] waterway=wadi problem

> 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 (

Re: [Tagging] waterway=wadi problem

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 S

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

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 addr

Re: [Tagging] Feature Proposal - RFC - Cluster

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 b

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

> 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

Re: [Tagging] Basic philosophy of OSM tagging

> 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 “

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

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

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

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