On 21.01.2015 03:59, Никита wrote:
You don't know regexes and theory behind them. [...] There always pattern
that will broke your regex.
E.g.?
You will never teach your ugly hacks to to OSM users.
Probably because these are for developers, not for users.
--
Friedrich K. Volkmann
On 19.01.2015 10:05, Paul Johnson wrote:
This seems like a problem better handled by indoor mapping individual suites
inside a building http://wiki.openstreetmap.org/wiki/Indoor_Mapping,
unless I'm fundamentally missing the concept and this is about buildings who
have multiple addresses valid
On 19.01.2015 10:41, Andrew Shadura wrote:
On 19 January 2015 at 11:08, Friedrich Volkmann b...@volki.at wrote:
That's wrong, as I've already explained in another message. When you write a
letter to an address in Austria using a conscription number, you MUST omit
the street name. Otherwise
On 19.01.2015 10:54, Andrew Shadura wrote:
This problem is already solved by bare address nodes.
You have been refuted numerous times by counter examples and other facts
(e.g. POIS, undefined scope of address nodes), but you still repeat your
postulates like an automat.
--
Friedrich K.
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
On 19.01.2015 11:10, Andrew Shadura wrote:
If your country has effectively abolished conscription numbers, this
is one thing. Another this is how they work in countries where they're
used all the time. In my country, both numbers are used concurrently
and together with street name, and this
On 19.01.2015 11:16, Andrew Shadura wrote:
All of issues you mentioned can be solved by software and actually are
solved already.
I am eager to see your proof.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
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 only
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
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 down
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
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 needed but
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 North
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
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 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
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
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
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
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
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
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
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
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,
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
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
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 a
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?
--
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
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 Potlatch. I
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 do
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
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 no more discussion going
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 clubs
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 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 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 which
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
(*),
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.
--
Friedrich
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
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:
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,
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 call
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 Land
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 even
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 Bezirk Zwettl
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
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 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 according
On 26.11.2014 18:23, Brian Quinion wrote:
At the moment nominatim supports
alt_name_[0-9]+:language_code=name
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
On 24.11.2014 22:54, fly wrote:
Do we recommend any order ? youngest to oldest ?
name=most common name
alt_name=second most common name;third most common name;...
...because data consumers certainly use these in the same order. Two examples:
1) Rendering: Say, there's space for one alternative
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 world
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 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 a
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 b...@volki.at 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 long
discussions about noname=yes
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 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 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 have
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 mountains
-
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 is water related and temperature related, but it doesn't
require mountains
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 cycleway
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 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 as
On 18.09.2014 08:24, Martin Koppenhoefer wrote:
Il giorno 18/set/2014, alle ore 07:57, Friedrich Volkmann b...@volki.at ha
scritto:
Say, how does landcover=grass differ
from surface=grass?
I agree that in this case it doesn't make a difference, besides that surface
is typically used
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). How do
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 categorisation
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 fine
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 there). But I wouldn't recommend
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
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,
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, then
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 described on
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 in the
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 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
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
caves there are
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 ever
get
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
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 religious or
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
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
On 01.08.2014 14:31, Mateusz Konieczny wrote:
2014-08-01 12:36 GMT+02:00 Friedrich Volkmann b...@volki.at
mailto:b...@volki.at:
On 31.07.2014 11 tel:31.07.2014%2011:54, Marc Gemis wrote:
Didn't JOSM include landuse=religion in the latest version ?
An editor bug sounds like
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 here
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 overly
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
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_rock,
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 no
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
On 12.07.2014 01:01, Martin Koppenhoefer wrote:
Am 12/lug/2014 um 00:27 schrieb Friedrich Volkmann b...@volki.at:
My proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/natural%3Drock_cleanup
has been in RFC state for a year
Maybe a whole year is a bit long...
3 comments
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)
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
On 09.08.2013 23:19, Tobias wrote:
I wonder if there is already a tag to describe a place where you can put
stuff to others to share. For example you have read a book and do not
need it anymore, but do not want to throw it away. In a Bücherregal -
I guess it is translated a tradeoff - you can
101 - 200 of 225 matches
Mail list logo
