Dne 19.3.2014 11:08, Pieren napsal(a):
On Tue, Mar 18, 2014 at 8:24 PM, Petr Morávek [Xificurk] p...@pada.cz
wrote:
I don't see anything wrong with using addr:place even on the address
points that do have street name.
It's like addr:country. It's not wrong to duplicate the information
Dne 19.3.2014 15:51, Serge Wroclawski napsal(a):
On Wed, Mar 19, 2014 at 6:30 AM, Petr Morávek [Xificurk] p...@pada.cz
wrote:
Oh, here we go again... You are wrong. It's nothing like addr:country,
it's not duplicating any information, and the polygon approach is not
applicable.
I would
Dne 18.3.2014 16:48, fly napsal(a):
addr:place is wrong as its meaning is twisted using it this way.
Is it? In what way exactly?
Just to be sure, we're on the same page, please take a look at the
explanation of terms I've send to imports mailing list.
Best regards,
Petr Morávek aka Xificurk
Dne 18.3.2014 19:49, Martin Koppenhoefer napsal(a):
2014-03-18 17:52 GMT+01:00 Petr Morávek [Xificurk] p...@pada.cz
mailto:p...@pada.cz:
addr:place is wrong as its meaning is twisted using it this way.
Is it? In what way exactly?
addr:place should be used instead
Dne 4.10.2013 13:18, Tobias Knerr napsal(a):
Am 04.10.2013 08:24, schrieb Werner Poppele:
Waelder mit natural=wood sind nach meinem Verstaendnis Urwaelder,
Waelder im Hochgebirge oder Waelder in Nationalparks usw.
Dein Verständnis ist insofern richtig, als es der derzeit herrschenden
Hello,
I have a few questions regarding tagging admin boundaries and places. It
seems to me that these tagging schemes overlap a bit and I would like to
discuss it and possibly reach some kind of consensus about how to Do It
Right.
1) Polygon vs point for Populated urban areas (place=city,
Peter Wendorff wrote:
There are two big differences between CSS and the proposed relation stuff.
1) The inventors of CSS provided a working implementation for core CSS
features
2) For a considerably long time css was used only very sparse and most
of the time with a html4 styling fallback.
Johan Jönsson wrote:
Sorry if I am getting to theoretical on the subject of how to write tags.
I was wondering about the reason for this tag,
*is it to explain the languages in the tag name:
(if, like in your bruxelles-brussel example, is two names I guess that the
order is important)
Tobias Knerr wrote:
On 02.08.2012 12:56, MilošKomarčević wrote:
name=* without any context of what language is recorded in it is one of the
biggest fallacies of OSM i18n and needs to be addressed.
You need to realize, though, that mappers in areas where only one
language is commonly used
Hello Peter,
you have raised interesting question, so I'll try to address at least
some of the questions regarding editor support and describe it from my
point of view (as user of Merkaartor).
Peter Wendorff wrote:
The point is to keep the correct, even if deprecated work of local
mappers
Hello,
I've summarized [1] the ideas that were recently discussed in talk@
regarding the names, their different language mutations, ...
I would like to hear some comments, additional pros/cons I could not
think of myself, etc.
Although I was arguing for the don't repeat yourself solution, I can
Johan Jönsson wrote:
lang=language_code is supposed to tell what languages that are used in the
tag name=place_name
May I propose to use lang:name=language_code instead of lang=language_code
(or is it name:lang=language_code)
I don't like name:lang simply because it conflicts with the
Frederik Ramm wrote:
Tools must serve mappers. Everything in OSM must be geared towards
making contribution easy for mappers. Anything else is secondary;
consumers are totally unimportant.
I think, this is the point on which we fundamentally disagree.
Consumers and data usability is important
Hello Chris,
please, do not put words into my mouth. I did not call you or any other
OSM contributor a monkey. And I did not call any consumer super
important. If you think, I did, I kindly ask you to read my email again
and more carefully.
Chris Hill wrote:
most people who make grand
Peter Wendorff wrote:
If you rise a flag for the consumers side and decrease the mapping
useability with that, these mappers will go away - and afterwards most
probably the data consumers will follow, because there's no (updated)
data any more in a reasonable quality and quantity.
I did not
Kytömaa Lauri wrote:
Petr Morávek [Xificurk] wrote:
2) A relation exists with member ways without ref tag. This means that
the route is essentially mapped and any further editor is correcting
errors, that he found. Then someone comes and adds a ref tag to one of
the ways - why?
He drove
Peter Wendorff wrote:
Am 31.07.2012 10:33, schrieb Petr Morávek [Xificurk]:
If he knows for sure, that on that road from point A to point B is
ref=42 and not ref=56 as the OSM data says, then the user should fix
it as I wrote in previous email. Remove the ways from the current
relation
Hello,
first of I'm sorry for a bit longer mail, but this is just another
example of what gets me worried about the future of OSM.
This thread is another one of those, where someone came to discuss a
specific problem and proposed a solution, a solution that changes a few
old things. I fear that
Hi Peter,
Peter Wendorff wrote:
I think, this would lead to a situation where the error count doesn't
decrease, but the remaining errors aren't detectable any more.
Having refs only on relations means for a data consumer: I have to use
this data and I have no idea if it's correct - I have to
Tobias Knerr wrote:
If two instances are created at least somewhat independently*
This is a really bold assumption. I'm having a hard time to imagine a
real-life scenario, where this is true.
On the other hand, I can imagine scenarios where the cross-check will
fail simply, because someone who
Peter Wendorff wrote:
I'm not talking about data duplication in the meaning of I add my data
twice in different ways, but about redundant (not duplicate) data in
the meaning of Sven added his data there not nowing that it's possible
here too; I add the data here - and you can check if we both
Martin Koppenhoefer wrote:
Am 20. Februar 2012 14:21 schrieb Volker Schmidt vosc...@gmail.com:
There is consensus that the key
height is describing the height of the structure from the ground to
the top.
+1 (I think there is no other way of doing it)
well, you could say that height is
Josh Doe napsal(a):
On Tue, Aug 30, 2011 at 11:01 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
There is a 'new' (formalized) proposal for place=neighbourhood.
More details here:
http://wiki.openstreetmap.org/wiki/Proposed_features/place%3Dneighbourhood
Waiting for comments
Martin Koppenhoefer napsal(a):
Well, personally I would be glad if we could change the definition to
something like smallest inhabited entity in the division hierarchy of
larger settlement.
I would like to use this tag for rural areas, i.e. named parts of
villages, because place=suburb sounds
Hello,
I would like to open the discussion about determining the admin_level of
administrative boundaries in Europe according to NUTS/LAU division.
Though this probably of interest only for people from EU, I don't think
there is any better mailing list for this.
There are several countries with
Martin Koppenhoefer napsal(a):
2011/9/6 Petr Morávek [Xificurk] xific...@gmail.com:
as I've stated during voting, I don't think water=* is much of an
improvement in tagging scheme of water bodies. I'm still curious - how
do you tag natural lake that is used as a reservoir of water?
I'd go
Hello,
as I've stated during voting, I don't think water=* is much of an
improvement in tagging scheme of water bodies. I'm still curious - how
do you tag natural lake that is used as a reservoir of water? The
existence of man-made or natural water body and its usage by man kind
are simply two
Personally, I think of capital=* as a quick and dirty way to mark the
capitals mainly of countries (and states). To tag the centre of a lower
administrative level, add it as admin_centre role into the appropriate
relation. No need to re-invent the wheel ;-)
Petr
Colin Smale napsal(a):
I'm not
Ralf Kleineisel napsal(a):
On 01/02/2011 05:42 PM, Robert Elsenaar wrote:
This was a expected answer. I frequently try to discover the reason OSM
mappers accepting this anarchistic rule of NOT having tagging rules at all.
What are the advantages for this?
I prefer this over being told
Ulf Lamping napsal(a):
First of all, please repeat a hundred times on the blackboard: There's
no such thing as a deprecated tag in OSM. Especially not, if the new
proposal is only a few weeks old ;-)
Sure there are deprecated tags in OSM - it doesn't mean that they are
not used in the database
Ulf Lamping napsal(a):
Am 22.11.2010 22:28, schrieb Petr Morávek [Xificurk]:
Ulf Lamping napsal(a):
First of all, please repeat a hundred times on the blackboard: There's
no such thing as a deprecated tag in OSM. Especially not, if the new
proposal is only a few weeks old ;-)
Sure
Ulf Lamping napsal(a):
Am 16.11.2010 13:51, schrieb M∡rtin Koppenhoefer:
2010/11/16 Ulf Lampingulf.lamp...@googlemail.com:
So what is the *exact* problem with surface?
it extents the usage of surface as attribute for routable entities to
all kind of entities, therefore reducing simplicity
M∡rtin Koppenhoefer napsal(a):
I set up a proposal for a new key landcover.
http://wiki.openstreetmap.org/wiki/Proposed_features/landcover
It deprecates very few old values (mud and sand from natural, grass
from landuse).
Thank you very much for writing this down, this is exactly what OSM
M∡rtin Koppenhoefer napsal(a):
2010/11/16 John Smith deltafoxtrot...@gmail.com:
I've already been tagging beaches and other areas as surface=sand, how
does using landcover make this any better?
I agree that in this case it is the same. For trees it is different.
surface=tree doesn't make
John Smith napsal(a):
On 22 May 2010 20:13, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote:
2010/5/19 Petr Morávek [Xificurk] xific...@gmail.com:
I see your point... I think the wiki definition of
landuse=recreation_ground is a bit in conflict with common sense (like
the leisure=garden
Liz napsal(a):
On Sat, 15 May 2010, Petr Morávek [Xificurk] wrote:
and the last,
most puzzling is landuse=basin An area of water that drains into a
river
wow, there are some pretty huge ones of those
like the Amazon basin
the Lake Eyre basin
the Mississipi basin
Stephen Hope napsal(a):
2010/5/19 Petr Morávek [Xificurk] xific...@gmail.com:
landuse=recreation_ground OR landuse=residential - do you know any
garden that is outside those two areas?
Formal gardens/landscaping around commercial and public buildings?
The gardens at a parliament house
Hi,
I had finally some time to write down some proposal of sub-tagging for
leisure=garden as discussed earlier.
http://wiki.openstreetmap.org/wiki/Proposed_features/Garden_specification
Since I'm no big gardener any comments and suggestions are more than
welcomed.
Regards,
Petr Morávek
M∡rtin Koppenhoefer napsal(a):
Thanks for putting this up. I would actually try to reduce some of it
to the necessary:
The most common form of garden, located in proximity to a residence,
usually private access only. The main purpose is usually relaxation
activities. - I would delete The
Roy Wallace napsal(a):
On Fri, May 14, 2010 at 1:20 AM, John Smith deltafoxtrot...@gmail.com wrote:
leisure=garden
garden=residential
Much better. This clearly means you are tagging a particular *type* of garden.
I don't see in what sense is this better - your own remark 'someone
lives in
Roy Wallace napsal(a):
2010/5/10 Petr Morávek [Xificurk] xific...@gmail.com
Until there is a better solution I'll use the
proposed scheme of landuse='residential' + residential='garden'.
FWIW, I don't like that. Look at residential=garden...someone lives
in the garden?
Well, yes :) You
I really really don't think it is a good idea to degrade the
leisure='garden' tag to mark everything from a castle garden,
dendrological garden (with or without public access), or e.g. small
Japanese garden belonging to a tea-house, to the extreme case of plain
cut grass in some backyard. Such a
M∡rtin Koppenhoefer napsal(a):
2010/5/6 Petr Morávek [Xificurk] xific...@gmail.com:
To the proposed solutions in this thread:
* highway=pedestrian, area=yes - It doesn't really make sense to me to
tag private fenced and _green_ areas by highway tag.
sure, for green areas it isn't
43 matches
Mail list logo
