ngle polygon and use a
single tag for "grass" and "forest". Live must be easy for the
contributors. And promoting a new key which may replace or be combined
or partially overlap the old "landuse" will be extremely confusing for
the non-experts. And this will be e
On Tue, Mar 31, 2015 at 6:55 AM, Jan van Bekkum wrote:
Not sure about the typo : is it "non-designated" or "non_designated" ?
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Fri, Mar 27, 2015 at 12:30 PM, Jan van Bekkum
wrote:
> Hi Pieren,
> I have mapped those myself only in cases other reasons
> existed to map than.
But this is not what the first section suggests:
"Beautiful place in the mountains, desert or at the beach - no
facilities, usual
asing tourists attendance (and littering).
The best location for wild camping is a beautiful and unique spot
which was never used before you and will never be used after your
night, no ?
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.ope
we'd
> introduce some mathematical logic in the process.
-1
The main criticism about "votes" is the "approved" status and the
small amount of participants, not percentage of approvals. So change
the status name and increase the quorum, not the opposite.
ortant. So something has to be changed.
Btw, I don't think that translations will help. Some proposals don't
have many feedbacks simply because the interest is not shared by a
large group.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ity", "Their sheer
beauty", "Remote sites "
which means potentially everywhere... imagine a similar proposal for
pissing on trees tagged as informal toilets ?
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
our "consensus". Removing
the "controversy" section will just give the false impression that
there is no controversy at all.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
er who can render all buildings or all
barriers in the same style, using a single rendering rule for all
types of buildings or barriers which wouldn't be possible with your
solution.
I'm not saying the current system is perfect, we made mistakes (like
the "tourism" categ
e create simple tags for
the average contributors, not to simplify routing software dev's life.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
tead of "goods" it could be
replaced by "fork" or "container" or "container_for_goods", just
enhancing the existing list following the same principle.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ap or a
fountain (functionality more important than the shape).
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
blocks more general tagging
> scheme for water sources.
I never said that. Although very hard, it is not impossible to
deprecate a tag in OSM. We just need real good arguments for it.
Pieren
___
Tagging mailing list
Tagging@o
ic space, it will be tagged
with "amenity=drinking_water". And for the same water tap inside or
near a cemetery, it will be tagged with "man_made=water_tap". How can
we explain that to newcomers ? why "amenity" in one case and
"man_made&
, I would
say we already have two committees for tagging scheme:
- the JOSM presets maintainers
- the DWG
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
d enforced the deprecation later, when the tag is moved to
the "adopted" sections. I'm not personnally a big supporter of the
amenity=drinking_water but I think the current proposal is not clear
enough compared to the existing tags.
Pieren
[1]
https://help.openstreetmap.org/questi
;standard operating procedure in some
areas" has to be interpreted carefully.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
have 10 amenity=public_bookcase:
http://taginfo.openstreetmap.org/tags/amenity=public_bookcase
Seeing the numbers and the rarety of such feature, I think you can add
your suggestion directly in your local editions and perhaps also in a
new section in the wiki (noticing it's coming after the
, floating on water or on wheels (caravan).
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
dary relation for Croatia either. But
anyway, here is what is documented on the wiki:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
and we see several countries with a level 3.
Anyway, you speak about a "name" and a "ref" for the relation. Since
when do we
to bad idea
to validate an import mistake in the wiki ;-)
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Fri, Nov 14, 2014 at 12:29 PM, johnw wrote:
> it is a subkey for the buildings, to go with building=civic.
My concern is about splitting a landuse polygon just to refine
information that could be stored on buildings themselves for instance.
Pie
y for
"landuse=residential" with "residential=home" or "residential=garage"
or "residential=toilets_in_the_garden"
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
which case you will have to invent a new tag for that.
I would prefer something like "level=roof" or "level=3". Just where
the parking(s) is in the building.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Wed, Nov 12, 2014 at 8:50 AM, Mateusz Konieczny wrote:
> No, unknown should be tagged as unknown. Even better - not tagged.
+1
We don't tag what is unknown.
Pierre
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/l
iction under
this bridge". Of course, anyone is free to come back and add more tags
like the physical height or the material and 3d shape of the bridge,
etc. But the most interesting information for apps checking clearance
(e.g. for routing) is there => no
rways, both MPH and knots are used. Usually MPH on canals and
> knots on rivers, though even this can depend on who the navigation authority
> is and how far back in history their statutes were written.
Okay, if the unit is not generalized, then my idea doesn't
ccepted for use with the SI"
(https://en.wikipedia.org/wiki/Knot_%28unit%29)
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
n
waterways is "knot" and the default "km/h" remains for highways and
railways ?
Pieren
[1] http://wiki.openstreetmap.org/wiki/Key:maxspeed
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
#x27;t. So the simple "maxheight=unsigned" or "unmarked"
or "whatever" is easier for the average contributor.
What you suggest is possible and could be automated. But it could be
done by the data consumers as well.
Pieren
___
T
is for me less
controversial than "maxheight=none" (even as a non native English
speaker). Although "maxheight" is the legal value (like all tags in
the category "access"), "none" is suggesting that there is no height
limit at all.
Pieren
mewhere here".
> Clearly they didn't known where that relative was buried. Often the search
> even terminates without success because there are simply too many graves
> to look at.
We could have the same discussion about names o
"
Third mistake : It is not strictly reserved for "notable" people and
can be used to name all graves in a cemetery (which might be forbiden
in some countries). Privacy is never mentionned. To solve this, you
could enforce a link to wikipedia because they are alrea
ve to be
careful about creating a database of named people (and their
relationship) when they are not celebrities. Even for dead people, it
can be conditioned to local legislation.
> I will be more than happy to find better solution to map graves like this
>
as
never been really discussed globally, I moved the wiki page back as a
proposal and would like to open a vote about this and get your
feedback here:
http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:person#Voting
Pieren
___
Tagging
others and never
reused. Or that your tag is used for something else. Or that your
description is too vague and open for wrong interpretation.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
the best choice that we have
to follow him...
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
e traffic
signals are also using their own nodes (thus different osm elements).
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ss database,
bypassing the restrictions of wikipedia. Something that could be
deleted without regret on both database and wiki.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ffic signal (with different names). So I would suspend this point
until a real case appears...
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
e osm db (using this "paved" key).
With the first option, the "paved" attribut can be inconsistent
between applications. With the second option, the "paved" attribut is
subject of personal interpretations from the contributors but this
could b
not tagging the data-consumer/renderer. Most of the contributors
don't care about the real oil station (or hotel or bank)
name/brand/operator refinements. We should consider the tag "name" as
the main key and tolerate that name duplicates brand/operator until
someone up
ag like
"amenity=brothel_even_if_it_is_not_legal_to_say_it_is_one" or
"brothel=dont_tell_anyone"
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
quot;surface" or "landcover" for that and most of them wouldn't agree
to draw different polygons or use several key to make such small
subtleties.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
DB should link to OSM
>objects
>- use wikipedia / wikidata links
Who can decide that wikidata is not an external ID which shouldn't be
stored in OSM ? Why wikidata couldn't link to OSM objects ?
Pieren
___
Tagging mailing list
Tagging@op
On Tue, Sep 16, 2014 at 8:53 PM, Lukas Sommer wrote:
> For the junction!
>
> For a named junction with a (not named) traffic signal: junction=yes +
> highway=traffic_signals. (Quite common on Korea – on the ground, not in the
> database.)
Ok, I improved the wiki about this
:http://wiki.openstree
?
highway=traffic_signal + junction=yes + name=* means that "name" is
for the junction or for the traffic signals ? And can we imagine a
case where the junction and the traffic signals are both named (and
possibly differently) ?
Pieren
___
Tagging m
smoothness for bicycles but others could interpret
this tag as simply good enough for pedestrians...
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
invent something better
> and it
> not as bad as say maxspeed:practical.
Do we have to choose between bad and worse ?
As already mentionned, the skater, biker or car driver will have a
totally different idea/view of what a "good" or "bad" smoothness is
for his means of tran
ight
>> be ok
> +1, I have in the past used for (much smaller and older) arches man_made=arch
+1 for man_made. "landmark" is too vague.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
once you understand the concept, it's easy. Of course, adding
explicitely that a street is not a oneway, especially in a dense area
with many oneways make sens. It's just telling the other contributors
that this particular attribut has been verified by someone. But don't
ask ot
ge common" is then don't use it. If we
start to delete all vague definitions in the wiki, we should better
start with "smoothness" :-)
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
es:leisure
http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
;, "retail", etc). It's not exclusive
(where another landuse polygon is normally). Also I remember the time
we always said that landuse is intended for small scale mapping, not a
parcel scale.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ly from a simple alphabetic order or key string. Not
something we can "program" easily.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ace_of_worship
rendering is for a building on the main map style. This could be fixed
by using a differente style/colour/transparency if the tag
"amenity=place_of_worship" is combined or not with a tag "building=*".
It's extremely sad and
your tag, the same feature may or may not be displayed on the
map, depending if you added your RENDER tag or not. Your proposal have no
chance to be adopted for these reasons.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Sat, Aug 23, 2014 at 12:25 PM, Martin Koppenhoefer
wrote:
> the space gets replaced by an underscore
+1
The problem is not to have a preference between underscore and hypen
but to know if our English colleagues can agree on the separator space
or hyphen.
Pie
I would modify the section [1] by replacing "it is recommended" by "it
is suggested" and adding at the end a note saying that a large part of
the community consider these two tags -smoothness and
maxspeed:practical - too subjective.
Pieren
(I also suspect the 12000 coming fro
t; forests without much human activity, either because they're
> protected or because they're far away from humans
So, after 7 or 8 years of confusion about 2 main tags for "forest",
the best idea now is to introduce a third one...
Pieren
___
s maybe also something for blinds). Someone on the other list
suggested to replace it by "road_markings=yes". Any other suggestions
about this and the information boards ?
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ithout any additional mandatory tags like
"location=underground" (correct me if I'm wrong but a cave is always
underground). That would not be immediately visible on the map but
data consumers requesting "all highway path in Poland" could also
safely ignore this
the local community about your intentions. It is
not politics but basic courtesy.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
untry specific (but could be summarized in a "per
country" wiki page like we do for admin_levels)
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
that amenity=place_of_worship is
always rendered as a building even when it could be a bigger area
(like for schools).
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
If you don't understand that a collection of "all bus routes from
operator XYZ in my city" is not different than a collection of "all
McDonald's restaurants in my town", then I cannot argue any more. And
if we tolerate the first, we can
when people are contribution
around them.
@Frank I agree that the wiki should formalize the practice but not all
practices in OSM have to be followed.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
have a predefined list of (master) routes but
only a list of path "segments".
But again, like "all bus routes in a town" or "all motorways in a
country", you should be able to retrieve the whole list of smaller
routes and junctions with an appropria
t; linking smaller
route segments together. It's even worse here since the same long
route is modelized twice in the database...
The bicycle network example shows that the nodes are finally on both
types of relations. This could be simplified with a tag like
"network:name".
Shall I continue ?
Pieren
[1] http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Network
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ship is combined or not with a "building=*" tag.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
, and post them to the Belgian, Dutch and German mailing
> lists and forums.
I think this single list and the wiki, instead of ten local lists and
forums, is more appropriate, no ?
I don't have preconception about such relation, if someone find a
valid argument/example which
is question related to the "network" relation ?
> Another problem is for routes that form the connection between 2 networks.
> Right now, they are placed in the 2 network relations. How would you tag the
> network names for them ?
Create
work_name".
I don't see the point with "network:operator" where "operator" is
already used. But tell me if you know an example where the network
operator is differente from the hiking route operator belonging to
this network...
Pieren
([1]):
"Our database is a spatial database; this means that it has intrinsic
knowledge about the location of objects. If you want to know about all
footways in East Anglia, simply pass in a bounding box of East Anglia
and request all footways, and the collection is made for you
on-the-fly.&qu
r all cycle routes that belong to the
"D-Netz". However, there are a lot of other national cycle routes as
well. "
Plus some attached relations examples very explicite.
As raised in the "discussion" page, is that not exactly breaking the
"relations are not categories&
I think here you just try to compensate the missing 'z' component in
OSM. I don't see any problem to have over two elements on the same
position if they have different "ele" or "layer" values.
Pieren
___
Tagging mai
the z order reflected more
the real world. We can blame Google for many things but, at least,
they render tunnels below the buildings... If you don't like
buildings, than make it frankly and remove them completely from the
style.
Pieren
___
Taggi
tive. Forget the "smoothness" tag
please. We might replace it by the 4wd tag (but it's only a partial
solution) or another passable tag (for city car, 4wd, mtb, etc)
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists
On Wed, Jul 2, 2014 at 8:46 PM, Georg Feddern wrote:
> Did you consider buildings that are - at least partly - raised on
> pillars/columns with a pedestrian area underneath?
I think such buildings should have a tag "layer", no ?
Pieren
___
rks premiered in the buildings we map.
OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?
Pieren
[1] http://wiki.open
viding the building operator only through the
"wikipedia:operator" where most of the data consumers are simply
looking for the "operator" tag. I discover a semantic shift where
traditional OSM tags are slowly replaced by wikipedia contributors
eyes and habits.
Pieren
On Sun, Jun 29, 2014 at 7:11 PM, Lukas Sommer wrote:
> Am I right?
FYI, we had a recent discussion about roundabouts controlled by
traffic lights on this list:
http://gis.19327.n5.nabble.com/Signal-controlled-roundabouts-td5808587.html
Pie
ted. The
result for such mapping will be an excessive segmentation of the
highways only for historical purpose (would be the same if someone
changes the "surface" tag every 10 meters). I would suggest to map
such things on historical map projects.
Pieren
__
? or "flow_direction=both" and "oneway=no" ? About
"flow_direction=none", then you water stream/canal/pipe is not a water
stream/pipe/canal (change the primary tag).
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
tags "addr:*"
plus the POI "name". We don't have to duplicate the POI name into
"addr:housename".
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ag equally both types of junctions
([1]). To avoid confusion, we could use a specific tag like
"junction=traffic_circle" (already 33 in taginfo) (then we could
discuss about the "oneway=yes" implied or not). But I don't think that
routing applications are checking right-of-way&#x
We don't call it a bridge.
"location=overground" is enough.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
After a quick search:
http://web.archive.org/web/20011218005945/http://www.kwtv.com/news/strange/ixl.htm
it seems that the name **is** an abbreviation (and "for what" is
lost), in which case you don't have to expand it. (perhaps add a tag
"note" to exp
On Wed, Jun 18, 2014 at 10:43 AM, Pieren wrote:
Btw, we also have some special cases like this one:
http://www.openstreetmap.org/#map=19/47.20880/-1.58741&layers=N
where a tramway is crossing the roundabout. It's a normal roundabout
(not a traffic circle) excepted that traffic lights
omphe" in Paris is one of these junctions which are today the
exceptions ([1]).
Pieren
[1] http://www.openstreetmap.org/way/184551793
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
for a junction...
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
ht also be interpreted as
> "glass door", "wooden door", ...)
>
>
-1
where is the difference between door=* and door_type=* ? very confusing for
newcomers.
I would prefer a "door=yes/hinged/sliding/..." + "automatic=yes" or
"manua
why the "maxspeed=:"
was not simply a "maxspeed=" since OSM is a spatial db and
knows in which country the way is.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
If the whole building is a shop, I see no reason to not reuse the same
OSM polygon for both features (the building and the shop). However, if
the shop is not the unique entity, like apartments/flats on upper
floors, I also recommended in the past to use a node.
Pieren
ways ?
And what will be next ? delete all "oneway=no" because it's useless most of
the time ?
Pieren
To André, I did not reply to your last message in our private conversation
because I was simply not able to understand your argume
On Tue, May 27, 2014 at 5:55 PM, Martin Koppenhoefer
wrote:
> I see, for this you'd most probably need a new boundary type (if it isn't
> the same as your administrative boundaries).
+1
type=boundary + boundary=?
Pieren
___
Tagg
gon relation (splitting the existing landuse) or you just
collect the sum of existing landuses ?
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Thu, May 15, 2014 at 2:23 PM, Matthijs Melissen
wrote:
> Some more strange cases:
We could create an additional role (e.g. "capital") when the
"admin_centre" is not the capital (and only in this case to avoid
unnecessa
ugh
> that it's possible to harmonise, so long as the nations can agree :)
+1
I don't like the key "location=*" for the same reasons.
Pieren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
"place(s)" to be linked. The risk if we
don't specify a limit is that contributors will use it to link "all"
places within the boundary (making a substitute of the infamous
"is_in" tag).
Pieren
___
Tagging mailing list
1 - 100 of 605 matches
Mail list logo
