could reliably and correctly provide these informations in OSM,
and I would love to see if one day in the future this might be
implemented in OSM…
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org
As key:evacuation_route is currently almost exclusively used on
relations anyway, it might make more sense to deprecate this tag and
instead define a new value for route=* on type=route relations (and
than add all the refinements that you propose)…
--
Lukas Sommer
The wiki page for https://wiki.openstreetmap.org/wiki/Key:ele says it
has to be in meters, not in feets.
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
or to guide the user to avoid a very common error.
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Voting at
https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information
is open.
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
to ask questions if things are unclear!
Best regards
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
better, more detailed, what
missing language information means for Unicode text strings, and how
an example use case could look like. However, it will take some time
until the new proposal will be ready…
2017-05-23 18:02 GMT, Lukas Sommer :
> There haven’t been further suggestionsn in the last t
There haven’t been further suggestionsn in the last time. So now
voting is open for “Language information for name” at
https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name
--
Lukas Sommer
___
Tagging mailing list
This is still in RFC phase. Current state after discussion at the Wiki
talk page is using name:language (similiar structure like the yet
existing name:left and name:right) as key.
Lukas
2017-05-05 11:51 GMT, Lukas Sommer :
> Feature Proposal - RFC - Language information for name
>
> URL
unclear!
Best regards
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
was thinking about a new tag that could give us the necessary
language information for the “name” tag. Something like TAGNAME=es to
express that the “name ” tag is in spanish…
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https
ngs. Humans are messy. Unless the API starts validating
> entries, entries will vary in format, even if we officially say that "46 C"
> is the official format. But software can parse and normalize numbers.
>
> That said: temperature=___ is a problematic tag regardless of the
&g
l to have only the part about distances (and not the part about
weight). But dropping the rest of the content makes things confusing.
2015-04-03 9:25 GMT, Lukas Sommer :
>> I'd ask the following be excluded ?
>> cm (used in the clothing and foot ware trades ..not an OSM thing )
&
g else).
2015-04-03 9:16 GMT, Lukas Sommer :
>>> So please move it to the “Proposal/” namespace.
>> That's not possible for a working template,
>
>> Note the template is not USED,
>
> And it should also not be used, because it’s just your personal
> proposal for
gt;
>
> The majority of existing tags have a summary of the Map_Features/Units
> embedded on their own pages.
> That's a good thing for tl;dr readers.
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
> It's not a contradiction, it's a proposal.
So please move it to the “Proposal/” namespace.
2015-04-03 8:01 GMT, Lukas Sommer :
> The default unit is _not_ always “meters”. There are tags where the
> default unit is “meters” (e. g. width) and there are others where th
an centred tagging",
>> with parsers left to make conversion to computer readable units. It also
>> promotes explicit numbers (e.g. 20 m) over implicit ones ( e.g. 20 ).
>> Given the variety of unit styles already in the database, this see
/wiki/Tag:highway%3Dconstruction
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
made
> visible. I have done this for my custom Garmin maps and find it a real
> asset.
>
> Here is a photo of such a shop in my neighborhood:
> https://commons.wikimedia.org/wiki/File%3ABarreled_fuel_shop.jpg
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai
Hello.
In the discussion about the proposal about type=traffic_signals_group
it was suggested to use the term “set” instead of “group”. So I’ve
adapted the wiki page of the proposal and I’ve moved it to
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_set
--
Lukas Sommer
>
> So - I am against any of proposed changes.
+1
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
quate palm and "broadleaved". Mappers are mapping
> palms
> very frequently, and having this key name I think would reduce confusion.
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
t to a single intersection?
>>>
>>> And possibly some thought to where a length of road (many
>>> intersections) or a district wide coordination of traffic signals
>>> occurs? If the name 'traffic signals group' is taken what name would
Hello.
This is a request for comments for the proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group
The original author is Sanderd17. With the consent of him, I did some
supplementing. Thanks to Sanerd17!
Unlike the proposal “Proposed features/Traffic Signals” of Lu
al mapping when we have low-resolution
>> imagery to work from.
>>
>
> Agree. As for the Wiki editing, I too hope it doesn't lead to a storm.
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Trav
ed to implement the area type to offer
> proper presets.
>
> cu fly
>
> _______
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
here. Wouldn’t it be more useful to have to have the same rules
for _all_ values of the key “building=*”?
--
Lukas Sommer
PS: By the way: In the german wiki, most pages for the individual
values do _not_ allow usage on nodes.
___
Tagging mailing list
g this during voting is only possible when you have the
agreement of all these who votes with “yes” so far. As in the meantime
more people have voted, that get’s complicate …
Best regards
Lukas Sommer
___
Tagging mailing list
Tagging@ope
I know that I’m a little late with this comment – I missed this while
reading the proposal. Sorry.
Maybe that’s something that can be changed in the prososal – if
current voters agree?
2015-02-09 17:29 GMT, Lukas Sommer :
> I would strongly recommend to not use type=traffic_signals because
w.openstreetmap.org/#map=18/48.06123/7.81258
> [3] https://www.openstreetmap.org/#map=19/47.98530/7.82814
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
--
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
normal live.
So I think it’s important to have a clearly defined default unit, and
this default unit should be °C. Nevertheless, I think it is a good
idea to encourage people to tag “with” the unit.
Lukas Sommer
2015-02-05 0:53 GMT+00:00 Dave Swarthout :
> For clarification, the Kel
better for traffic signal systems. Currently, I tend
to come up with a proposal for a relation for traffic signal system
names – which would not interfer with Lukas Schaus’ proposal. @Javbw
Do you have some feedback from the japanese community? What do they
think about the usage of a relation?
Lukas
I think this can be a useful new tag.
And I think it makes sense to define explicitly some things in the
documentation. Things like
– use always (or use never) “Saint”: “Saint Paul” vs “Paul”.
– write the name of the dedication always in the local language (Or
always in latin? Could become very co
> No! Flood prone means that they are expected to be flooded from time to
> time. Nothing about the design.
So you would have to tag also each wadi, each river and each lake
because this area is covered with water? Maybe the terms “designed”
and “expected” are missleading. But the question is: How
be flooded.
Lukas Sommer
2015-01-20 4:09 GMT+00:00 johnw :
> I think using flood_prone on places designed to handle water (like a ford)
> is incorrect. The sections of a freeway that are closed off during flooding
> (a lane is closed because storm waters cannot properly drain away, or
>
I’ll wait until monday with the change …
Lukas Sommer
2015-01-16 12:35 GMT+00:00 fly :
> Am 16.01.2015 um 09:31 schrieb Martin Vonwald:
>>
>> 2015-01-15 22:12 GMT+01:00 fly > <mailto:lowfligh...@googlemail.com>>:
>>
>> Please, d
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.
Introducing a new relation should lead to better data and more
well-structured information. There should be a certain g
signposts for being confusing.
Thoughts?
Lukas Sommer
2015-01-11 15:48 GMT+00:00 Martin Vonwald :
> 2015-01-10 19:40 GMT+01:00 Lukas Sommer :
>>
>> +1. Key:destination for the simple cases the the relation for the
>> complex cases seems fine for me.
>
>
> I'll wait un
direct EU instituion – and also some
non-EU countries like Macedonia are members).
Cheers
Lukas
Lukas Sommer
2015-01-15 10:08 GMT+00:00 François Lacombe :
> Hi Friedrich,
>
> Ok for the upper case.
>
> I would prefer ref:eu:eic since I'm not sure entsoe isn't used i
_after_ a signpost/groundwriting. If this is correct, the examples
with the yellow and white signposts on the wiki page are confusing
(tagging a motorway_link makes no sense here), and I would recommand
to remove these three examples.
Lukas Sommer
2015-01-10 17:40 GMT+01:00 Marc Gemis :
> I
But we have also yet an existing tag water=pond for ponds. We would
have to change the defination for this tag from “a pond”
to “a pond – but not if this is a pond that serves for fishing” –
sounds complicate …
Lukas Sommer
2015-01-04 20:20 GMT+01:00 Janko Mihelić :
> 2015-01-04 19:55 GMT+01
PS: About 57% of the key “flood_prone” is “flood_prone=yes”. About 42%
of the key “flood_prone” is “flood_prone=no”. About 80% of the
elements with the flood_prone key are in 15 km × 15 km area in
Jakarta.
Lukas Sommer
2014-12-28 20:32 GMT+01:00 Lukas Sommer :
> Hello.
>
> In OSM there
related floods?
– Only supplementary tagging of highway=*? Or independent OSM elements
(areas)? Or both? Probably both makes sense.
Suggestions?
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo
2014-12-16 23:42 GMT+01:00 François Lacombe :
>> I think there is a big difference between "operator" and "usage": the latter
>> is most probably intended to be a formal tag with a limited, well defined
>> set of values, while the former is a free text field with any value possible.
>> Mixing up "
this.
cu
Lukas Sommer
2014-12-01 23:38 GMT+00:00 François Lacombe :
> Hi Lukas,
>
> I don't like this : railway guys introduced usage without any namespace.
> Why should power introduce one ?
>
> usage=* is a common tag. The proposal isn't introducing power:location
Maybe we could use a key with a namespace: “power:usage=*” or something
else. Keeping is separate from the railway usage could give us more
clairity.
Lukas Sommer
2014-11-24 15:24 GMT+00:00 François Lacombe :
> Hi Rainer and thank you.
>
> I didn't spend time yet on the upda
Or would it be better – if a consens is difficult – to wait until a general
resolution for the problem “one key with more than one value” has come up?
Lukas Sommer
2014-11-29 5:03 GMT+00:00 Brian Quinion :
> On 29 Nov 2014 00:26, "Lukas Sommer" wrote:
> >
> >
goal: ask software to stop using the not-accepted solution.
Thoughts?
Lukas Sommer
2014-11-27 15:21 GMT+00:00 Erik Johansson :
>
> On Wed, Nov 26, 2014 at 6:23 PM, Brian Quinion <
> openstreet...@brian.quinion.co.uk> wrote:
>
>> On 25 November 2014 at 13:30, althio forum
Okay, so I would place a hint at the corresponding wiki page …
Lukas Sommer
2014-11-23 18:46 GMT+00:00 Zecke :
> Am 23.11.2014 18:20, schrieb Lukas Sommer:
>
>> Would a feature proposal be a good way to get there?
>>
> No need to do so. The semi-colon is the accepted
“alt_name_1=name1”+“alt_name_2=name2”.
However, the discussion didn’t lead to something “official”.
I think it could be useful to have a clear documentation on the wiki about
which solution is the preferred one.
Would a feature proposal be a good way to get there?
Lukas Sommer
PS: Me to, I would prefer
We have finally 12 votes: 11 times “yes” and 1 time “no”. I think this
could be considered as approved …
Lukas
Lukas Sommer
2014-11-02 7:57 GMT+00:00 Lukas Sommer :
> Hello.
>
> After commenting period, now is starting the voting for the junction
> (only) taggin
this
as area.
Lukas
Lukas Sommer
2014-11-11 13:51 GMT+00:00 Martin Koppenhoefer :
>
> 2014-11-11 14:45 GMT+01:00 Lukas Sommer :
>
>> The proposal is only about allow “junction=yes” on areas. All other stuff
>> stays without changes.
>
>
>
> Would you mind explai
The proposal is only about allow “junction=yes” on areas. All other stuff
stays without changes.
Lukas Sommer
2014-11-11 12:08 GMT+00:00 Richard Z. :
> On Tue, Nov 11, 2014 at 11:08:56AM +0000, Lukas Sommer wrote:
> > Just as a reminder: Voting is still open at
&g
Just as a reminder: Voting is still open at
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
Lukas
Lukas Sommer
2014-11-02 7:57 GMT+00:00 Lukas Sommer :
> Hello.
>
> After commenting period, now is starting the voting for the junction
> (only
Hello.
After commenting period, now is starting the voting for the junction (only)
tagging at
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https
for the simple sections and move the existing
nodes with junction=yes to highway=junction. However, I’m open for both
solutions…
Lukas
Lukas Sommer
2014-10-21 16:00 GMT+00:00 fly :
> Am 18.10.2014 08:45, schrieb Lukas Sommer:
> > Hello.
> >
> > The combined proposal for
://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
which takes into account the comments which have been made during the
previous voting.
Best regards
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https
Okay, we have 9 votes:
- 5 times approve
- 3 times oppose
- 1 time obstain
I suppose this is not enough?
Lukas Sommer
2014-09-28 14:48 GMT+00:00 Lukas Sommer :
> Hello.
>
> After discussion and some modifications of the proposal, here a request
> for voting on “Tagging for compl
> Second sentence in the section Tagging -> Bridges with one level:
"Connect all OSM ways running over that bridge to the outline."
Sorry, I missed this.
Perfect!
Lukas
Lukas Sommer
2014-10-13 10:34 GMT+00:00 Martin Vonwald :
> Hi!
>
> 2014-10-13 12:12 GMT+02:00 Lu
I like this proposal.
I would add the requirement that the highways/railways/paths that go over a
bridge have to share a node with the outline area.
Lukas Sommer
2014-10-10 14:44 GMT+00:00 Mateusz Konieczny :
> man_made=bridge as proposed on
> http://wiki.openstreetmap.or
Hello all.
At
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
there is still a proposal for complex junctions and traffic signal systems
in voting process. Participation is appreciated ;-)
Regards
Lukas
Lukas Sommer
2014-09
What would also be no problem, because you can give an individual name=*
tag to each node with highway=traffic_signals and another name=* tag to the
area.
Lukas Sommer
2014-09-30 18:56 GMT+00:00 fly :
> Am 30.09.2014 14:34, schrieb Lukas Sommer:
> >> If there is a need to tag tr
Oh, sorry, Pieren was faster… ;-)
Lukas Sommer
2014-09-30 12:34 GMT+00:00 Lukas Sommer :
> > If there is a need to tag traffic signal names and junction names on the
> same node, then the logical solution is junction:name=* and
> traffic_signals:name=*. Or in differe
bly not a
real-world case.
Lukas Sommer
2014-09-30 12:21 GMT+00:00 Janko Mihelić :
> 2014-09-29 23:45 GMT+02:00 Lukas Sommer :
>
>> The case of Japan is different. In Japan, the name belongs to the
>> _traffic signal_, and _not_ to the junction. We need to distinguish this
when we distinguish between th:junction_area and
kr:junction_area - because here we have two values for the same feature.
While the tagging has a certain focus on some asian countries, I would
prefer to keep this country-independent.
Lukas Sommer
2014-09-29 21:37 GMT+00:00 Никита :
> > Th
> Can you please provide examples how to draw area for more complicated
junctions?
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
Lukas Sommer
2014-09-29 3:14 GMT+00:00 Никита :
> Not enough examples, I cannot vo
Oh, sorry, I missed this:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
Lukas Sommer
2014-09-28 20:47 GMT+00:00 Mateusz Konieczny :
> A link is missing.
>
> 2014-09-28 16:48 GMT+02:00 Lukas Sommer :
>
>>
.
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
> There is not much documentation on the wiki. The only thing that I found
> was a statement at
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice that says that
> highway=service is wrong, but everything else is okay.
>
>
> highway=service & service=alley sounds really good to me - paralle
to the mapper to decide)
Example: If the main road is secondary, the frontage road must be one of
“tertiary” or “unclassified” or “residential”.
Could this be a useful guide?
Lukas Sommer
2014-09-23 7:23 GMT+00:00 Satoshi IIDA :
>
> If you got any communication loss during the cont
>
> No tags on the shared nodes - just shared nodes.
>
>
What is IMHO a quite bad idea for two reasons:
– It’s unlikely that there will be software supporting features when there
is no tag.
– You would introduce a concurrent solution to a node
highway=traffic_signals. I do not think that it’s a goo
are nodes with the walkways and other
pedestrian oriented ways, as the signal would be part of their routing as
well.
Here, I agree. I assumed that people would do so automatically, but I’ll
also add it on the wiki page.
Lukas Sommer
2014-09-21 21:30 GMT+00:00 John Willis :
> It should be pr
> So the nodes where the signals_area intersects the highways is where the
signals would normally be mapped for complex intersections?
Not exactly. It would be difficult to do so if you have really complex
junctions with really many individual traffic signals and you want to catch
all of them – a
to _not_ tag the individual traffic
signals for Japan.
As described in the proposal, the area is simply drawn around the
approximative area that is affected by the traffic signals. It encloses
everything, but shares nodes only with the incoming and outgoing highways.
Lukas Sommer
2014-09-20 16:45
,
which can be practical. Means:
Korea:
– simple: junction=yes
– complex: junction=junction_area
Japan:
– simple: highway=traffic_signals
– complex: highway=traffic_signals_area
I’ve updated the proposal page on the wiki.
Lukas Sommer
2014-09-19 18:32 GMT+00:00 Lukas Sommer :
> Some ran
traffic_signals=* which seems to have either another meaning
– highway=traffic_signal_system_area (quite long)?
Lukas Sommer
2014-09-19 18:27 GMT+00:00 Lukas Sommer :
>
> Again, I do not see the point in introducing here a new tag. Using the
>> existing junction=yes in Korea and the exis
> Again, I do not see the point in introducing here a new tag. Using the
> existing junction=yes in Korea and the existing highway=traffic_signals in
> Japan – just not only on nodes but extending it also also on closed ways
> (=areas) – should be fine.
>
Okay, here I have to correct myself. It ma
> Differentiated tagging is needed for differentiated rendering. "junction"
> vs "Signal". a single signal icon needs to be rendered in Japan for
> intersections.
>
But that is yet working perfectly with the current tagging!
In Korea, we have yet thousands of nodes with junction=yes and name=*,
=traffic_signals would also be problematic because in Japan you
can have named traffic signals on straight road, for pedestrian crossing
, and there is not any road junction.
Lukas
Lukas Sommer
2014-09-18 19:31 GMT+00:00 fly :
> Am 18.09.2014 21:29, schrieb fly:
> > Am 18.09.2014 16:07
So far, highway=traffic_signal is only defined for nodes and there are
> only few ways and fewer relations.
>
Correct.
>
> Also in favour of separation I would prefer to use junction=* with
> name=* and only highway=traffic_signal with name if it is only a single
> light (e.g. the case with a na
> how do you tag a named junction with a traffic signal ?
> highway=traffic_signal + junction=yes + name=* means that "name" is
> for the junction or for the traffic signals ?
For the junction!
For a named junction with a (not named) traffic signal: junction=yes +
highway=traffic_signals. (Quite
(junction=yes and highway=traffic_signals) independently, but guards the
difference between both. This was the intention…
Lukas Sommer
2014-09-16 14:49 GMT+00:00 Satoshi IIDA :
>
> > The name belongs to the junction and not to the traffic_signal, or am I
> wrong ?
> In Japan,
>
> Would it not be more straight forward to use junction=traffic_signal in
> Japan and only use highway=traffic_signal for the real lights ?
>
Hm, I’m not sure. It could separete clearly the individual traffic signals
from the traffic signal system/the covered area. The downside would be that
we
Okay, I’ve tried to work out more in detail idea 4. Please considere
https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
and make comments.
Lukas Sommer
2014-09-02 4:50 GMT+00:00 Satoshi IIDA :
>
> Hello from Japan,
>
&
Okay, I’ve tried to update the old wiki pages (multilanguage names etc.)
Lukas Sommer
2014-09-15 10:47 GMT+00:00 johnw :
> Missed that in August. Great to see it is being discussed at any level.
>
>
> On Sep 14, 2014, at 12:21 AM, Satoshi IIDA wrote:
>
>
> wow!
>
cation to the wiki? (I would
volonteer to do so.)
Lukas
Lukas Sommer
2014-08-30 2:33 GMT+00:00 Paul Johnson :
> On Fri, Aug 29, 2014 at 6:55 PM, Tobias Knerr wrote:
>
>> On 29.08.2014 21:16, Paul Johnson wrote:
>> > Destinations are supposed to be relations, and the
antee
you that this is very time-consuming ;-)
Best regards
Lukas Sommer
2014-08-25 15:21 GMT+00:00 Simon Poole :
>
>
> Am 25.08.2014 16:46, schrieb fly:
> .
> >
> > Did you have a look at the three existing proposals about complex
> > junctions ?
>
. Particularly if you are mapping in one of the concerned
countries please participate at the discussion at
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
Lukas Sommer
___
Tagging
“name” tag in the relation and the nodes where the
ways cross as members in the relation.
– Could we maybe simply draw an area around the junction, sharing nodes
with the incoming/outgoing ways? Less clean than a relation, but easier to
use.
Lukas Sommer
2014-07-24 16:07 GMT+00:00 Dan S :
>
is difficult for turn-to-turn navigation
software. So, how can we solve this?
Lukas Sommer
2014-07-24 15:29 GMT+00:00 Christian Quest :
> Have you looked at http://wiki.openstreetmap.org/wiki/Key%3Ajunction
>
> "*junction*=yes <http://wiki.openstreetmap.org/wiki/Tag:junctio
re the ways cross. How can we get a clean and reliable tagging
here, which is suitable for rendering and turn-to-turn navigation?
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Thanks for the clarification!
2014-06-30 9:11 GMT, Martin Koppenhoefer :
> 2014-06-29 19:11 GMT+02:00 Lukas Sommer :
>
>> How do I tag correct a Hamburger roundabout/throughabout/cut-through (see
>> http://en.wikipedia.org/wiki/Roundabout#Hamburger_roundabout.2Fthroughabout.2Fcu
where appropriate).
Am I right?
Lukas Sommer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
95 matches
Mail list logo