has originally
been defined for clocks:
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dclock#Support
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
On 05/08/2010 18:52, vclaw wrote:
> On 05/08/2010 17:03, Tobias Knerr wrote:
>> I suggest a more generic approach for the mounting/anchor information -
>> a key like this could be used for lots of different features, such as
>> post boxes, clocks, waste bins or vending machine
ed again too soon?
No, you bring up JOSM's search box, type "addr:street"=TheStreetName
and change them all at once.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
On 19.08.2010 17:09, Simone Saviolo wrote:
> 2010/8/19 Tobias Knerr :
>> On 19.08.2010 16:27, Simone Saviolo wrote:
>>> So, if the name of a street is changed for whatever reason, I have to
>>> go through the, maybe, several hundreds of house numbers on that way,
&g
On 19.08.2010 18:28, Tom Chance wrote:
> On 19 August 2010 16:54, Tobias Knerr <mailto:o...@tobias-knerr.de>> wrote:
>
> Basic address editing, however, requires more knowledge if implemented
> using relations - which is bad, because editing addresses is one of the
&
A and C to make it easier to distinguish in software?
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
ect #1), there is an atm (object #2), and
object #2 is /within/ object #1. I think that creating an atm node
within a bank polygon perfectly represents this situation.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
highway=footway/path just as with sidewalks,
but a different subtag (footway=crossing or path=crossing instead of
footway=sidewalk) for the crossing ways.
Maybe you or someone else can suggest a better naming - I care about
being able to distinguish the crossing wa
iki and I believe that all waterways
around me have consistently been created using that convention.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
he intention of unsuspecting
mappers who used natural=tree without looking up a definition - because
the meaning seemed completely obvious to them.
A failure to adapt the wiki definition to majority use by removing the
"lone or significant" limitation would start an eternal struggle against
t
out even an attempt to reach consensus that this mass edit
should be performed.
For the record, I think that the denotation=cluster tag is a bad idea.
It's vague, overlaps with the other values of denotation and doesn't add
any information that wasn't there before.
Tobias Knerr
[1
g the definition
more attractive than trying to increase acceptance of the definition. If
the definition itself is considered decent, however, educating mappers
and fixing existing errors can be a more appealing option.
Tobias Knerr
___
Tagging
oon as
applications using the tag become more widespread, people will notice
the (then visible) errors and start to correct them.
Tobias Knerr
* Or any other application that behaves wrong, of course.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
ersial than the rest, or at least for different reasons - , so I
wonder why it's in the same proposal.
I don't think I'll map control devices anytime soon (or ever), though,
so I'm going to just ignore that section.
Tobias Knerr
e surface key,
though - such as trees. So maybe a new key would be useful anyway, but
just for those things that aren't covered by surface?
Generally, I'd very much appreciate a key that only describes what's
there, with nothing else (such as what's supposed to be
intained and paved ways.
Because the difference between ways that would currently be tagged as a
"path" can be very significant, it makes sense to split small informal
footpaths into their own highway category.
Tobias Knerr
___
Tagging ma
a burden.
If it's one of the tagging issues that need extended discussion, that
discussion should take place where others can participate asynchronously
and where the results are more permanently available.
Tobias Knerr
___
Tagging ma
should only replace
"url" for those cases where the URL is the official website for the
tagged feature.
Similarly, the "wikipedia" key should partially replace "url", for those
cases where the URL is a Wikipedia link, and "image" should be used for
URLs of
ly be used for routing, but could reasonably
be drawn as a linear way. Would the same surface material on the
basketball court next to it (clearly an area, not linear) be tagged
differently?
Tobias Knerr
___
Tagging mailing list
Tagging@openstre
enerator (and
that's what the original version of the English page did, and all
translations still do) would just ensure that the new tag cannot gain
traction, no matter whether it's better than the old one or not.
Tobias Knerr
___
Tag
t;language".
This process means that once popular applications actually use some set
of tags, usage will - with few exceptions - gradually become less
varied. And this effect will only become more pronounced with the
current popularization of editor presets.
Tobias Knerr
_
an also use positive or negative percentages as
values to more precisely indicate the way's steepness.
Tobias Knerr
[1] http://wiki.openstreetmap.org/wiki/Key:incline
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
well-explored algorithmic task.
I can support the proposal if (and only if) it is made clear that site
relations are only to be used where simpler tools aren't sufficient.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
but also things like names (it's not
entirely uncommon for building parts to have names of their own that are
not the same as the name of the entire building).
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Please voice your opinion in the vote on the "Tree rows" proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_rows
natural=tree_row, used on a way, describes a line of trees.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists
and 2), but aren't quite the same as 3).
Apparently, designation has the same purpose as 3), providing a more
human-readable tagging than the proposed extension to traffic_sign=* for
a subset of the cases covered by traffic_sign=*.
Is this correct?
Tobias Knerr
_
te something like "the tag shop=florist is equivalent to the
'Red Flower' label as defined by SMSB 2011-31337". But that still
doesn't mean that renderers have to use the standardized symbol.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
d information. This is where a node is the
appropriate solution until more detailed data becomes available.
Accepting both nodes and areas to accommodate different detail levels of
data is good practice for other features, e.g. those in the shop and
amenity cat
ea".
>> I also suggest to allow nodes for parking spaces.
[...]
> good argument. i changed the proposal accordingly.
Nice, thanks.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
is the simplest solution for mapping the presence of
sidewalks. However, sidewalk ways are the simplest solution for also
mapping attributes and connectedness of sidewalks.
Tobias Knerr
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
And, contrary to your experiences, my
impression is that the implicit flow direction around here is almost
always correct.
So, as always, the problem is the lack of a migration strategy for
existing data conforming to the current conventions.
Tobias Knerr
___
ki/Proposed_features/Conditions_for_access_tags
> if there aren't, i'd like to suggest something like
>
> maxspeed:hgv=50 mph
> maxspeed:goods=50 mph
This precisely matches the syntax suggested by the proposal above. :)
Tobias Knerr
__
On 2011-04-26 14:06, Richard Welty wrote:
> On 4/26/11 2:11 AM, Per Lindström wrote:
>> maxspeed values without unit is in km/h, and should be entered without
>> suffix.
>> If the speed is in mph the unit should be added. For more information see
>> http://wiki.openstreetmap.org/wiki/Key:maxspeed
>
On 15.10.24 at 16:29, Michael Tsang wrote:
I have checked the wiki again and the difference is between an area and
a room is the former is not walled, while the latter is walled, and it
says nothing about the access.
You're correct that the only difference between indoor=area and
indoor=room
Voting has started for the proposal “One-way for pedestrians”:
https://wiki.openstreetmap.org/wiki/Proposal:One-way_for_pedestrians
You can find the discussion on the RfC here:
https://community.openstreetmap.org/t/rfc-feature-proposal-one-way-for-pedestrians/118192
(I'm forwarding this message
On 07.03.25 at 21:46, Kevin wrote:
Great point! Perhaps a role can be added as `support`? That way, one (or
multiple) supports can be added to the relation, and each can have their own
characteristics (such as mast, pole, street light, bollard, etc.?)
I like the idea of an optional member wit
On 07.03.25 at 18:55, Christian Müller wrote via Tagging:
EACH ELEMENT SHOULD BE TAGGED AS A NODE WHERE THEY ARE IN THE WORLD, EVEN IF
THAT MEANS OVERLAPPING NODES.
From a data organization point this is a bad idea, because
a) the same information (lat/lon) is stored multiple times
needless
On 06.03.25 at 20:46, thigpen--- wrote via Tagging:
MAST RELATION
As one of the few data consumers who is already evaluating whether
objects are attached to other objects (for 3D rendering purposes), I'm
naturally interested in the topic.
Your approach does seem narrow in that it only works
401 - 438 of 438 matches
Mail list logo
