On 14.03.2014 15:51, Fernando Trebien wrote:
> This is a small issue that came up recently in Brazil. In my
> understanding, the layer tag has no specific meaning other than to
> specify a rendering order.
That is a common misconception by people who worked with graphics editing
software such as P
Wayside shrines and crosses are quite common here in Austria, and probably
in other parts of Europe too. They are mounted on posts (or pillars,
walls...) made of various materials (wood, stone...), or on trees. When
mounted on trees, I use a tag combination of historic=wayside_cross (or
_shrine) wi
My proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup
has been in RFC state for a year, and the only comment from other users was
a personal message concerning the licence of my photos. So it seems that
there are no objections, and that we should proceed to voting.
On 12.07.2014 01:01, Martin Koppenhoefer wrote:
>> Am 12/lug/2014 um 00:27 schrieb Friedrich Volkmann :
>>
>> My proposal
>> http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup
>> has been in RFC state for a year
>
>
> Maybe a whol
On 12.07.2014 09:59, Christoph Hormann wrote:
> Most of these are from the Antarctica import [1] where they mostly
> comply with the definition quite well although in some part areas have
> a thin, patchy scree cover.
>
> The Corine natural=rock areas on the other hand are not
> natural=bare_ro
On 12.07.2014 08:25, malenki wrote:
> When a proposal just sits in a wiki and doesn't get spread actively by
> it's author on OSM channels (forums, mailing lists) it doesn't get much
> attention. Even /when/ it is spread a lot of people (I included)
> often prefer to let it be.
Unfortunately, I am
On 25.07.2014 11:16, Mateusz Konieczny wrote:
> I propose to reduce inventing new landuses and start making subcategories
> whenewer possible.
>
> Recently I encountered landuse=plant_nursery, landuse=salt_pond,
> landuse=greenhouse_horticulture and landuse=mine.
>
> I think that all of them are
On 16.07.2014 13:52, John Packer wrote:
> I saw on the wiki there was some changes on pages related to religious
> landuse.
> It seems there is this tag that was documented only recently (but has around
> 1500 uses, mostly on Europe), and is called landuse=religious
I also wondered about that add
On 09.07.2014 20:15, Brad Neuhauser wrote:
> In the US, most of these sort of things are markers where people died in
> accidents. Wikipedia calls them "roadside memorials"
> (https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be
> the most common term in the US.
These exist
On 31.07.2014 17:17, Jesse B. Crawford wrote:
> As a perhaps helpful example, near my old home in Portland, OR, USA there
> was a "retreat" facility operated by the catholic diocese. It featured
> extensive grounds that you might call a park, except that they were fenced
> and intended for religiou
On 31.07.2014 11:54, Marc Gemis wrote:
> Didn't JOSM include landuse=religion in the latest version ?
An editor bug sounds like a good explanation for the occurencies of that
erroneous tag in the database.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wie
On 12.07.2014 09:59, Christoph Hormann wrote:
> Based on this it would probably not be a good idea to mechanically
> re-tag these to natural=bare_rock but this is something that should be
> discussed at the appropriate place (i.e. in imports). In my opinion
> these areas would need manual revie
On 01.08.2014 14:31, Mateusz Konieczny wrote:
> 2014-08-01 12:36 GMT+02:00 Friedrich Volkmann <mailto:b...@volki.at>>:
>
> On 31.07.2014 11 :54, Marc Gemis wrote:
> > Didn't JOSM include landuse=religion in the latest version ?
>
> An editor bug
http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup
Voting starts. It's now only about a wiki cleanup, because the recent thread
"convert imported natural=rock areas to bare_rock" made me drop the part
concerning data cleanup.
--
Friedrich K. Volkmann http://www.vol
On 14.08.2014 07:29, Mateusz Konieczny wrote:
> I added to http://wiki.openstreetmap.org/wiki/Cave#Tagging_in_OSM how
> these may be mapped
Given that you want to discuss wiki changes, you should start the discussion
before you actually do the changes. You should also refer to this mailing
list th
On 14.08.2014 12:40, Mateusz Konieczny wrote:
> Note, I am not a native speaker - maybe it sound terrible
You might find correct translations on
http://www.uisic.uis-speleo.org/lexuni.html.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
On 14.08.2014 13:18, Dan S wrote:
>>> I think that it is an obvious idea, but wiki claimed that "At the moment
>>> there just a
>>> tag to map the entrance to a cave." despite fact that existing tags fit
>>> well.
>>
>> No, they do not fit. Caves are complex three-dimenional structures. In most
>
On 14.08.2014 16:54, Richard Z. wrote:
>> Maybe not completely obvious, but I would agree with Janko. In my opinion,
>> a "tunnel" is man-made, while a "cave" is not.
>
> whether or not man-made is not the biggest problem.
>
> The big problem with tunnel=yes or tunnel=cave is that they only would
On 23.08.2014 23:52, Tod Fitch wrote:
> When looking into how to render them I have become aware of an alternative
> tagging of waterway=wadi as mentioned at
> http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwadi
That page was created in 2013, probably to document existing usage (12000 by
now)
On 20.08.2014 10:18, Holger Jeromin wrote:
> Andreas Labres wrote on 20.08.2014 04:10:
>> On 19.08.14 23:17, fly wrote:
>>> but 265-267 is wrong
>
> Read as "tagging 265-267 alone is wrong".
>
>> Disagree. addr:housenumber is the official number given to that building.
>> And if
>> it's "265-267
On 18.08.2014 22:36, Janko Mihelić wrote:
> What happens when the same entrance has two housenumbers, each from its own
> street? I'm sure this exists somewhere.
The housenumber belongs on the building or building part, not the
entrance(s). When a building (part) has two equivalent addresses, use
On 20.08.2014 13:44, SomeoneElse wrote:
> On 20/08/2014 12:38, Mateusz Konieczny wrote:
>> Currently only weakest reason to use this tag are described. I propose to
>> add "Typically it is used on ways legally dedicated to specific modes of
>> travel
>> by a law or by the rules of traffic." as desc
On 18.08.2014 17:10, Pieren wrote:
> I'm afraid that the main problem here is not the use "location" or
> "layer" or "cave" but "highway=path". This tag was created for
> multiple vehicles ways, not exclusive to a transportation like
> footways or cycleways. Currently the wiki tries to reflect this
On 24.08.2014 13:31, Christian Quest wrote:
> In that case, how should application resolve housenumbers ?
> What tagging do you propose to allow it ?
I wrote down some thoughts here:
http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses
...although I do now prefer addr2:* instead
On 30.08.2014 13:54, Paul Hartmann wrote:
> there have been requests to include the tag smoothness=* in the JOSM presets
> [1]. Everywhere the user can fill in surface=*, we would add an additional
> option for smoothness=*. Apart from the value (excellent, good, ...) we
> would include the explana
https://wiki.openstreetmap.org/wiki/Proposed_features/cliff_clarification
This is to refine/cleanup the definition of natural=cliff in the Wiki, in
order to make that existing map feature usable for applications.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1
On 03.09.2014 14:25, Zecke wrote:
> Currently in OSM we have two tags to describe some kind of slope that also
> get rendered in the mapnik chart and a couple of others:
> natural=cliff
> embankment (in the form man_made=embankment (feature) and embankment=yes
> (attribute))
>
> Is this categorisa
On 04.09.2014 16:46, Zecke wrote:
> I'm dealing with spoil heaps. These are man_made but that's not the problem
> here.
For spoil heaps, man_made=spoil_heap has been suggested. They have little in
common with embankments.
> A spoil heap is often partially
> limited by more or less steep slopes. I
On 04.09.2014 17:12, Martin Koppenhoefer wrote:
> > There's the question whether "natural" is appropriate as there are
> > also man made steep slopes.
>
> I think that we do not need that kind of differenciation. There are also
> man
> made water areas and trees, and we are doing
On 04.09.2014 21:24, Friedrich Volkmann wrote:
> On 04.09.2014 17:12, Martin Koppenhoefer wrote:
>> I agree in so far as from one point of view we could have a tag that only
>> describes the shape without referring to natural or man_made (who or why
>> something is t
On 04.09.2014 21:19, Zecke wrote:
> Spoil heaps can be mapped as unclosed lines when they
> are attached to a (natural) mountain. Then only the visible part of the
> contour will be mapped as a line
This does not sound right. Spoil heaps are areas and should be mapped as
such, or abstracted to a
On 18.09.2014 01:01, Dave F. wrote:
> On 17/09/2014 22:44, Daniel Koć wrote:
>> We (in Polish forum) think, that changing landuse=grass into natural=grass
>> would make better tagging scheme, since grass is seldom a "landuse" (like
>> the tree is natural=tree, not the amenity or something else). H
On 18.09.2014 08:24, Martin Koppenhoefer wrote:
>> Il giorno 18/set/2014, alle ore 07:57, Friedrich Volkmann ha
>> scritto:
>>
>> Say, how does landcover=grass differ
>> from surface=grass?
>
> I agree that in this case it doesn't make a difference, bes
On 13.10.2014 12:12, Lukas Sommer wrote:
> I would add the requirement that the highways/railways/paths that go over a
> bridge have to share a node with the outline area.
This does not work for multi-layer bridges. As I commented on my vote, I
prefer layer=1;2 over the ugly bridge-relation. It's
On 10.10.2014 18:35, fly wrote:
> There is no vote needed. If a tag is in common use we can still mark it
> approved.
Some do that mistakenly, but the correct status is: "In use"
The number of occurrences needed to mark a tag "in use" is highly disputed.
That's why voting should be started as soon
On 17.10.2014 15:11, Martin Koppenhoefer wrote:
> "mountains related"
> - a cave doesn't have to be in the mountains
> - a cliff doesn't have to be in the mountains
> - a "glacier" is water related and temperature related, but it doesn't
> require mountains
> - a rock can't only be found in the mou
On 17.10.2014 15:49, Friedrich Volkmann wrote:
> On 17.10.2014 15:11, Martin Koppenhoefer wrote:
>> "mountains related"
>> - a cave doesn't have to be in the mountains
>> - a cliff doesn't have to be in the mountains
>> - a "glacier"
On 17.10.2014 15:40, Lukas Sommer wrote:
> The downside is that in the example the cycleway would loose the connection
> with the bridge area. While humans can understand that this is probably
> another layer of the same bridge, it will be more difficult for software to
> determine that this cyclew
On 17.10.2014 16:29, Martin Koppenhoefer wrote:
> a cave entrance isn't a landform.
There are several similar terms, like "georelief elements". I don't know
which one fits best. Anyway, these consist of one or more of:
full forms
hollow moulds
flat forms
A cave is a hollow mould, thus a landform
On 20.10.2014 17:45, Martin Koppenhoefer wrote:
> I propose to put beach in landforms and cave in water-related. Also
> coastline could go into landforms. And moor into landforms. And mud in
> water-related. What about putting fell into landforms? ...
Most known caves are dry. I know because I hav
On 24.10.2014 20:53, Tom Pfeifer wrote:
> I stumbled over some maxheight=none tags on motorways, that did not even
> pass under a bridge. I found that this is the most frequent value of
> maxheight (2889 of 41474).
[...]
> For bridges without sign, there is no recommendation in the English wiki,
>
On 25.10.2014 01:10, Kytömaa Lauri wrote:
> Personally, i use maxheight = x + maxheight:physical=x for these, but saying
> that signs are the only thing that can be tagged gives bad data.
I did not say that signs are the only thing that can be tagged. I said that
we should map what we see. When
On 04.11.2014 14:04, Mateusz Konieczny wrote:
> I think that natural=arete should be rather subtag of natural=ridge
> (natural=ridge; ridge=arete).
This discussion comes late. Both natural=ridge and natural=arete have been
approved by voting just 2 years ago. And I think that there's nothing wrong
On 29.10.2014 13:08, Pieren wrote:
> On Mon, Oct 27, 2014 at 8:21 PM, Friedrich Volkmann wrote:
>
>> (...) But when we see nothing, it's plain wrong to add something to the
>> database.
>
> But it's a common practice today in OSM. It seems you missed the lo
On 05.11.2014 10:28, Martin Koppenhoefer wrote:
> there is a subtle difference, in that it is very common in OSM to trace from
> aerial imagery without any survey, and in these cases you obviously won't be
> able to enter names. Therefor streets without names in OSM but with names in
> the real wor
On 05.11.2014 10:01, Martin Koppenhoefer wrote:
> arguably it is not too late, there are only 450 uses of arete by now (and
> 17K+ ridges).
450 uses are quite a lot for a feature that is constantly ignored by renderers.
For the same reason, I suppose that some of the 17K+ ridges were created by
On 05.11.2014 07:19, Mateusz Konieczny wrote:
> And it is not just because with the second solution new values
> for main tag will quickly appear (see building=*).
This doesn't matter in this particular case, because natural=ridge and
natural=arete were approved at the same time.
> With second
>
On 05.11.2014 12:23, Richard Z. wrote:
> Another reason I don't like current arete/ridge state is that some ridges are
> very long - and they may be partially arete and ridge in different segments.
> Having a way that is tagged partially as natural=ridge and partially as
> natural=arete seems like
On 24.11.2014 22:54, fly wrote:
> Do we recommend any order ? youngest to oldest ?
name=
alt_name=;;...
...because data consumers certainly use these in the same order. Two examples:
1) Rendering: Say, there's space for one alternative name in parentheses.
The renderer may take the shortest valu
On 26.11.2014 18:23, Brian Quinion wrote:
> At the moment nominatim supports
>
> alt_name_[0-9]+:=
>
> for alt names
>
> I've added this to the wiki
Please don't document values supported by single applications. The wiki
should represent values which are in use in the database, or approved by v
On 24.11.2014 12:57, Martin Koppenhoefer wrote:
> We are currently trying on the Italian mailing list to get a good tagging
> for the ZTL (zona a traffico limitato - limited traffic zone), which do
> exist in various Italian cities and are not "LEZ" (low emmission zones)
> because the latter accord
On 06.12.2014 19:06, Mateusz Konieczny wrote:
> There is a proposed tag man_made=adit that is a good idea. But I think that it
> would be better to use man_made=adit_entrance for adit entrances - too make it
> clear and obvious what should be tagged and to make it closer to
> natural=cave_entrance
On 08.12.2014 18:01, Christopher Hoess wrote:
> An adit is the entrance to a mine in the way a lobby is an entrance to a
> building; you could still have a lobby entrance without committing a solecism.
[...]
> There's nothing wrong with tagging the adit itself, but that should be
> applied to the u
This is about a new attribute for administrative devisions.
http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
On 17.12.2014 16:47, Brad Neuhauser wrote:
> Sorry, the German examples don't mean much to me. Do the examples below show
> what you're proposing?
>
> name=Chicago, admin_title=city, admin_level...
> name=California, admin_title=state, admin_level
Exactly.
--
Friedrich K. Volkmann htt
On 17.12.2014 16:56, Martin Koppenhoefer wrote:
> isn't this already covered by name and its variants?
> e.g.
> name="Bezirk Zwettl"
> short_name="Zwettl"
>
> or
> name="Zwettl"
> official_name="Bezirk Zwettl" ?
No, because the official name is just "Zwettl". But in most cases when you
talk about
On 17.12.2014 22:08, Andreas Goss wrote:
> So what do you do with Berlin? State? City? "Stadtstaat" (Citystate)?
As far as I can see, Berlin is a Bundesland and a Gemeinde. So you should
have one boundary relation for each level. If you decide to use a boundary
relation for the top level only, adm
On 17.12.2014 23:23, Colin Smale wrote:
> In the UK "designation=" is in wide usage for this. I don't know if it is
> typically a UK thing (it wouldn't surprise me) but local governments
> sometimes have the right to change their "style" - for example a "civil
> parish" can choose autonomously to c
On 18.12.2014 14:00, Martin Koppenhoefer wrote:
> the official name AFAIK is "Land Berlin"
Sounds good. So it's admin_title=Land, then.
> As far as I can see, Berlin is a Bundesland and a Gemeinde.
>
> The term "Bundesland" is of mostly colloquial use, the official term is
> "Land", so it is
On 18.12.2014 16:44, Martin Koppenhoefer wrote:
> In Berlin there is no such thing like a "Gemeinde" there are the "Bezirke"
> divided into "Ortsteile", and while the first do correspond roughly to
> Landkreisen (regarding the number of inhabitants) they don't have the power
> (they are indeed not
On 18.12.2014 17:25, Martin Koppenhoefer wrote:
> yes, legally it's "Einheitsgemeinde", but that's maybe not a title...
> The "Land" has the title "Stadtstaat", and of course it's also
> "Bundeshauptstadt".
>
> Which one should go into "admin_title" and why?
Have a look at Gemeinde Gutenbrunn:
ht
On 20.12.2014 09:42, Janko Mihelić wrote:
> I like maxspeed:variable=* simply because it lets you use maxspeed=* in its
> original sense. Maxspeed=signals robs you of that original tag and routers
> now have to dig deep into tags to understand the real maxspeed.
Is it too much of a challenge for r
On 22.12.2014 10:32, Martin Koppenhoefer wrote:
> What about "Marktgemeinde Gutenbrunn" (that's what they call themselves on
> their official homepage)?
No, that's advertising language, they are showing off their market right in
order to impress their visitors and to attract investors.
--
Friedr
On 22.12.2014 20:03, jgpacker wrote:
> This suggestion was added to the page having as a goal machine-readability,
> however the suggestion that was there before the page was changed also seems
> to be machine-readable.
[...]
> What do you guys think?
I think that source tags (as well as note tags
On 23.12.2014 21:39, Rainer Fügenstein wrote:
> I'm rather thinking of something machine-readable, enabling the editor
> to warn the user in case he/she is about to change high precision
> data.
There are quite a couple of editors. Most certainly, some of them will not
implement the feature.
Also
On 23.12.2014 17:57, Tom Pfeifer wrote:
> I would consider that a non-issue as you said, for those reasons:
>
> - When it comes to GPS traces on objects that don't move (*), the
> beauty of crowdsourcing is on our side. The collection of
> traces over a longer time creates a cloud of traces wh
On 23.12.2014 17:37, Rainer Fügenstein wrote:
> mapper A, by means of DGPS, MilStd GPS, crystal ball etc., is able to
> achieve an accuracy of, say, a few centimeters and uses it to add new
> nodes (POIs) to OSM.
>
> some time later, mapper B with his/her ancestors mechanical GPS device
> (*), ach
On 27.12.2014 16:20, Andreas Goss wrote:
>> What's wrong with sport=fitness and leisure=sports_centre?
>
> Persoanlly I think it would result in all kind of facilities being tagged
> like this, even though it's not the primary purpose. For example someone
> posted a User Diary entry about rowing c
I notice a quicky increasing number of oneway=no tags on roads, probably due
to editors offering some flashy list box for the oneway key. I wonder what's
next. bridge=no, tunnel=no...?
I find these information-less tags annoying, because you have to browse a
long list of bogus tags on each object
On 29.12.2014 04:51, Bryan Housel wrote:
> Yes, `amenity` please. A gym is something people want to know about when
> traveling, just as much as other tourist stuff, food, lodging, etc.
Then you should advocate tourism=fitness_centre.
I prefer the leisure key, because fitness is something you d
On 29.12.2014 04:25, Clifford Snow wrote:
> Sport isn't a physical tag, where a baseball field is. I think the same
> applies to fitness centers. You can survey a fitness center. Not a sport. As
> a kid, I played baseball in a vacant lot.
I agree that sport=* cannot be used on its own. It is an at
On 02.09.2014 15:32, Friedrich Volkmann wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/cliff_clarification
>
> This is to refine/cleanup the definition of natural=cliff in the Wiki, in
> order to make that existing map feature usable for applications.
There's n
On 04.12.2014 10:31, Kotya Karapetyan wrote:
> For me, English common sense says a 'water source' could be a river,
> lake, spring etc...
> the portability of water is not a measure of its source (where it comes
> from) but its purity...
>
> So I'd think the key should be
>
>
On 28.12.2014 17:45, Mateusz Konieczny wrote:
>> "you'd probably want to discuss that over at
>> https://github.com/openstreetmap/iD/issues";
>
> I thought that https://github.com/openstreetmap/iD/issues/2220 will fix this
> problem.
Maybe that's why most of the oneway=no I checked come from Potl
I was going to write a proposal for relation type=cluster
(http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster). Looking for
real-world examples, I noticed that there's a relation type=group for the
Great Lakes (id=1124369).
What do you like better? type=group or type=cluster?
--
Fried
On 07.01.2015 02:43, John Willis wrote:
> I think there is a big difference between a 5 story tall net (held up by
> massive poles) and a fence. If it was a 5 story tall fence or wall, we'd call
> it a building or a dam or something.
I would call it a fence or wall anyway. What is your minimum h
On 07.01.2015 04:55, John Willis wrote:
> What's the difference between an alley and a motorway besides width?
A motorway starts with a motorway sign, at least in central Europe.
> Something about a giant flowing net 5 stores tall visible for kilometers away
> and a pice of netting used to hold
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,
be
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:hou
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 ar
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
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
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
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
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
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
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,
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
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
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
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
On 16.01.2015 05:28, Eugene Alvin Villar wrote:
> In my country (Philippines), many corner addresses are specified with the
> intersecting street instead of (or in addition to) the house or building
> number. This actually makes sense because the house numbers are not
> immediately obvious when loo
On 16.01.2015 10:10, Lukas Sommer wrote:
> What you propose is an algorithm that does a sort of “guess”. For
> doing some sort of guess, we don’t need to introduce a new relation.
> That could be done also without a relation.
Look at the examples. You cannot represent the data without a relation.
On 16.01.2015 17:04, Serge Wroclawski wrote:
>> There is an addr:city=* key for the city,
>
> Is there a building in your dataset that lives in two cities?
No. I used a bogus example just to demonstrate the syntax.
> And here's where we simply say:
>
> addr=val1;val2;val3
>
> If you're in Nort
On 16.01.2015 11:40, Markus Lindholm wrote:
> What we don't need is yet another special case mapping scheme like addrN
>
> Have you had the time to look at the existing relation of
> type=provides_feature
> http://wiki.osm.org/wiki/Relations/Proposed/Provides_feature
> and how you can use it to a
On 16.01.2015 05:48, Ineiev wrote:
> 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 neede
On 18.01.2015 09:18, Andrew Shadura wrote:
> Oh no, why one more proposal?
Sorry, my fault. Dmitry did it first.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Tagging mailing list
Tagging@open
On 17.01.2015 23:47, Eugene Alvin Villar wrote:
> But imagine for a minute that you are back in
> the 1990s (without GPS) in a third-world country and you only have a paper
> map. If you are given a restaurant to visit with an address such as #45
> Ayala Avenue, you would, in the worst case, go dow
On 18.01.2015 22:23, Markus Lindholm wrote:
> I think that comes down to how addresses are viewed, either as a
> proper feature in their one right or as an attribute to some other
> feature.
Yes, that's the crux.
> I think addresses are proper features, so a distinct address
> should be found onl
On 19.01.2015 09:57, Andrew Shadura wrote:
> Dmitry, this isn't true. Conscription number/street number is just a
> special sort of an address, it's not like two totally separate
> addresses. Yes, you can use a part of it to address a building
> (conscription number + optional street + optional loc
1 - 100 of 242 matches
Mail list logo
