streets).
3) Higher level, more abstract features can be handled more easily.
4) With appropriate editor (eg. JOSM with Relation Toolbox) it is no more
difficult to learn than drawing a square.
10) Relations just make sense.
Lukáš Matějka (LM_1)
2013/4/12 Martin Vonwald
> Hi!
>
>
Could there not be something else than a generator=* in a role of a
generator?
LM_1
2013/4/9 Martin Vonwald
> Hi again :-)
>
> 2013/4/9 François Lacombe
>
>> This is where I still don't understand you: why do I need to specify that
>>> a feature XXX has the ro
more abstract features - lanes,
streets being represented by relations. That way the routing database would
not be alonside it, but would be directly contained in it. The drawback
being more processing required to mine useful routing data from the
database.
LM_1
2013/4/7 Martin Atkins
> On
lanes. If not some more detailed scheme would have to be used -
mapping streets as areas. Eventually that will be the only viable option
city centres currently mapped in high detail with only the streets being
overly simplified...
Lukáš Matějka (LM_1)
2013/4/7 Martin Atkins
>
> Hi all,
Is there any distinction for direction of the sign?
LM_1
2012/11/20 Jo :
> I'm mapping them as highway=stop as a node of the way, just before where it
> crosses the main road. I would map a traffic_sign=stop as a node next to the
> road. But that just makes it harder to work with
/routers seem to be a natural point
of unification (There are not many features rendered by the main
Mapnik style that are not widely mapped...).
LM_1
2012/8/26 Ilari Kajaste :
> On 26 August 2012 10:42, Markus Lindholm wrote:
>> We're not supposed to map for the renderer nor the r
That makes sense, especially if there already is
backrest=left|right|middle|none.
LM
2012/8/5 Peter Wendorff :
> Am 05.08.2012 18:10, schrieb LM_1:
>
>> For direction of the benches mapped as ways I would use analogous*
>> rule to cliffs and retaining walls, that is: If you hold
of the way.
*Lower retaining walls could actually be used as benches
LM_1
2012/8/5 Tobias Knerr :
> Komяpa wrote:
>>
>>> PS: Same with amenity=bench [2]
>>
>> I found linear amenity=bench quite useful for micromappning and 2.5D
>> rendering:
>>
>>
What about this:
Let's have fully qualified hierarchical names, something like
landcover=vegetation:herbaceous:grass, landcover=herbaceous:herbs or
landcover=vegetation:trees:coniferous
That woudld allow precise specification as well as "something green
grows there".
Mappers would understandably no
away because
data model is not perfect. But they might omit a feature or ten. I
started contributing because osm maps were more detailed and precise
than any other. Therefore I believe that the better map comes with osm
watermark the more contributors the project gains.
Lukáš Matějka (LM_1)
2012
Let's not forget that this debate was started by naming disputes in Ukraine.
I would vote for option 2 myself, but if that would be found
impossible, I could agree with Tobias.
LM
2012/8/2 Tobias Knerr :
> "Petr Morávek [Xificurk]" wrote:
>> Tobias Knerr wrote:
>>> You need to realize, though, th
/31 Pieren :
> On Tue, Jul 31, 2012 at 10:41 PM, LM_1 wrote:
>> Actually almost any proposal containing relations is criticised from
>> this perspective (relations being too complex/complicated for
>> mappers).
>
> If you explain OSM to an average newcomer, not a geek or
n osm tagging).
Today's renderers support landuse=gras and do not support landcover=anything.
That being the reasons for landuse=* domination it is hardly enough to
proclaim it the better way.
LM_1
2012/7/31 Pieren :
> On Tue, Jul 31, 2012 at 8:39 PM, Johan Jönsson wrote:
>> There are
(LM_1)
2012/7/31 Philip Barnes :
> This thread has prompted me to look at the ferry routes around the UK,
> and why only certain one are working.
>
> The biggest problems I have found, and so far fixed, are not the ferry
> routes themselves but the access within the ports. A lot of acce
d
Potlatch choose is not my decision.
For all the rest Petr Morávek wrote, I fully agree with him.
Lukáš Matějka (LM_1)
2012/7/31 Richard Fairhurst :
> Petr Morávek [Xificurk] wrote:
>> This is actually not an argument against any tagging proposal,
>> but argument for improving rel
applies to the whole area/facility site relation would
be the place for ratings.
That is because one object should not be influenced by nearby objects
in tagging (adding prefixes and similar.
LM_1
2012/7/26 Johan Jönsson :
> Sometimes there is a discussion on how to tag differnt kind of awards
rtantly OSM should not censor its data even if there is
potential for abuse. (surveillance cameras for crime planning,
detailed road maps for attack forces coordination, police using
uploaded gps tracks to find locations where cars are likely to exceed
speed limits... )
Lukáš Matějka (LM
it or document
alternative but not ignore it. After a time it is likely that some
(one) standard evolves. That would be quite not possible when nobody
would document whatever they map before there is a consensual
standard.
LM_1
2012/6/2 Russ Nelson :
> Steve Bennett writes:
> > A
I would choose semicolon, because it is used already (even if not
actually supported)
LM_1
Dne 4. dubna 2012 23:16 yvecai napsal(a):
> Hi,
>
> What is the best way to 'separate' values?
> I think about piste:grooming='classic;skating' or 'classic+skating&#x
e relative directions to get to the
location - this is not an address and should not be tagged as one.
Lukáš Matějka (LM_1)
Dne 30. března 2012 10:11 Martin Koppenhoefer
napsal(a):
> What about the established tag "addr:full"? This was intended for
> cases like
Without willing to interfere in this discussion about the true nature
of seemingly similar roundish street features, I'd like to point out
that ending a line with a pentagonal or hexagonal approximation of a
circle is actually less work than adding a tag on the last node (extra
5 or 6 clicks compar
That seems to be almost philosophical question about a perfect tag. I
prefer more structured approach, like you proposed for bathing.
LM
2012/3/12 Johan Jönsson :
> LM_1 writes:
>> 2012/3/11 Johan Jönsson goteborg.cc>:
>> > leisure=bandstand is a good tag.
>> >
right?
>
> There could be some controversy if one instead want one tag for all small
> pavilions, garden-kiosks, gazebos out there. building=pavilion
>
> If one would want one tag for all music-playing places, leaisure=music_venue
> or leisure=music.
Thi
The value for building key should be the type of the building, not its
current use. A church remians church even after islam takes over and
its used as a mosque or vice versa (Pécs). Villa is different from
apartments or bungalow, but all are usually used for residential
purposes. There are poly-fu
might actually one of the legal limitations that are least
arbitrary and most often supported by (bridge) hard reality.
Lukáš Matějka (LM_1)
2012/2/26 Mike Valiant :
>
>> Originally there was little mention of any of them tags depicting
>> purely legal restrictions. Even access/*=no wa
Hi
2012/2/21 Frederik Ramm :
> Hi,
>
>
> On 02/20/2012 10:59 PM, LM_1 wrote:
>>
>> The possibility of free tags is great, but once some tagging style
>> proves as usable (and better than any other),
>
>
> ... which will never be the case ...
I know, it is a
ree
>
> Overall: be careful at forcing a new tagging scheme, where a different one
> is in favour of the majority, and don't change documentation, as long as
> that's the case.
>
> regards
> Peter
>
> Am 20.02.2012 22:59, schrieb LM_1:
>
>> 2012/2/20 Chris
it should become a
standard and used exclusively (or be challenged by a better one
later).
Lukáš Matějka (LM_1)
2012/2/20 Chris Hill :
> On 19/02/12 23:38, Steve Bennett wrote:
>>
>> On Mon, Feb 20, 2012 at 2:53 AM, Chris Hill wrote:
>>>
>>> I do not agree with the who
I would not do that or care for such information, but why not...
There is no "too far"
LM_1
2012/2/20 Nathan Edgars II :
> Would it be reasonable to map custom personal mailboxes that are essentially
> public art (e.g. in the shape of a manatee)? Or is this goi
>From what has been written here it seems that elevation clearly does
not contain buildings.
Frederik Ramm:
> You would normally put a natural=peak tag next to the tower anyway.
> Or if you don't, then attach "ele" to the bench near the base of the
> tower or so ;)
Most peaks with some constructi
Generelly yes, but if there is a tower on the summit, there is not
really any other way.
Lukáš
2012/2/20 Frederik Ramm :
> Hi,
>
>
> On 02/20/2012 01:06 PM, LM_1 wrote:
>>
>> As I understand it option a) is correct. If put on a building it would
>> mean that the
there the elevation is unchanged. Now what if you
cover this building with earth to look more natural? How thick layer
of earth is required for the elevation to change?
But these cases will be uncommon and I still vote for a)
Lukáš Matějka (LM_1)
2012/2/20 Martin Koppenhoefer :
> On the German ML
The place is right, but:
Why?
What good would that change bring?
Lukáš Matějka (LM_1)
2012/2/19 Amanda :
> hello!
>
> new here. don't know if it's the right place to address this issue, sorry if
> i'm mistaken..
>
> my suggestion is: MAN
can live with
Beijing, but 北京 is not helpful at all.
Of course this name should be generally used by users of the language,
not just translation.
Survey (of language use) should be as good source for language
translations, as it is for mapping.
Lukas (LM_1)
2012/1/30 Craig Wallace :
> On 30/01/2
; How would it solve the case of river bifurcation if the river merges
> together (river island, the same river flows on both sides)?
>
> How would it solve similar case of streets (lanes for different
> directions split for some time and later merge together)?
>
> Thanks for a
ve similar case of streets (lanes for different
directions split for some time and later merge together)?
Thanks for answering these questions
Cheers
Lukas (LM_1)
2012/1/26 sly (sylvain letuffe) :
> Hi,
>
> I'd like your opinions on the following proposal :
>
> http://wiki.o
Actually both highway=crossing and railway=crossing mark a place where
you can meet different type of traffic (pedestrian-car, car-train,
pedestrian-train...)
LM_1
2012/1/20 Martijn van Exel :
> Good question. I just noticed that the other day while using the
> presets window. I'd sa
That is what I am saying - access=no is useful as a generic value to
make exceptions (like foot=yes) from.
LM_1
2012/1/16 Ben Johnson :
>
>
> On 16/01/2012, at 6:45, LM_1 wrote:
>
>>> Given that absolutely everything on the planet is accessible by at least
>>> so
your photos:
N1 - if it can be considered a bridge at all it should have separate
value, eg. bridge=zip_line
N2 - suspended bridge, if it should be more specifiic something like
bridge=suspension:[simple; underspaned; stressed _ribbon;
suspended_deck; self_anchored...] could be used
Lukas (LM_1
t - it is easier than excluding each use
individually.
access=no alone is really not usable. Maybe for paths in places of
nuclear explosions.
LM_1
2012/1/15 Ben Johnson :
> On 13/01/2012, at 23:34, Michael Krämer wrote:
>
>>> If you'd read what I was replying to, you'd see th
2012/1/9 Volker Schmidt :
> Hmmm.
>
> man_made=dovecote
> historic=yes
>
> This combination would indicate that the building was a dovecote at some
> point, but is no longer in use, wouldn't it?
>
> Without "historic" it would still be in use, I suppose.
>
> I am surprised that this is such a rare
train - no matter if it is a person or a gift
package or a goods container...
The problem with your proposal is that it does not say much, in fact
it is very incomplete. If you improve it, I will be glad to support
it.
LM_1
2012/1/4 Michael Wickert :
> Hi Polyglot,
>
> sorry for answerin
/proximity/biometric/...
Cheers
Lukas (LM_1)
2012/1/5 Peter Wendorff :
> Hi Andreas.
> I didn't vote (yet), because I'm a little bit ambiguous about it.
> On the one hand I like detail mapping and even indoor mapping ideas, but -
> and here is the (or at least one) comment you reques
tower:riser=yes seems good and in need it could be enhanced with yes
being replaced by power, telecommunication etc. For basic processing
it is simple (any value but "no" means some sort of riser) if more
precise info is needed, the information is there.
LM_1
2011/12/14 Владимир
44 matches
Mail list logo
