On 17/09/2016 16:05, Colin Smale wrote:
So saying you can only map these short restrictions by creating a
route relation for the whole length sounds a bit excessive to me.
I never said any such thing.
Router relations are preferable so many reasons. Disappointing you're
unaware of that.
Da
Sorry if I misinterpreted you. I understand all about route relations,
but the fact remains they are not in place everywhere. They are not
essential for navigation, but oneway restrictions are.
If you are so disappointed that I am unaware of the so many reasons why
route relations are preferable
On 17/09/2016 23:08, Colin Smale wrote:
Martin, are you suggesting to drop the convention for the way direction
that it goes with the flow? Or are you OK with oneway=reverse?
Values such as "yes", "forward", "reverse", "-1", etc are all
meaningless to those who actually navigate the waterways.
Malcom, the values for "oneway" and all the "forward" and "backward"
subkey business are geometric directions related to the order of the
nodes in the OSM way, and not (always) linked to geographical concepts.
Nobody navigates based on raw OSM data, on the roads or on the water.
The values have to
On 9/18/2016 1:11 AM, Michael Tsang wrote:
the use of name=* key on a public transport route is considered an abuse
(unless the route has a real name). However, without abusing the name tag, the
life is difficult for both the mapper and the user.
I proceed with the 'abuse'. It's one thing t
> On Sep 18, 2016, at 09:00, tagging-requ...@openstreetmap.org wrote:
>
> How could the concept of upstream and downstream be applied to canals
> and lakes?
Open, and non-flowing waterways have a direction of buoyage, that can be
interpreted as direction of flow. This system is defined per cou
> On Sep 18, 2016, at 10:50, Aun Johnsen wrote:
>
>
>> On Sep 18, 2016, at 09:00, tagging-requ...@openstreetmap.org wrote:
>>
>> How could the concept of upstream and downstream be applied to canals
>> and lakes?
>
> Open, and non-flowing waterways have a direction of buoyage, that can be
>
sent from a phone
> Il giorno 18 set 2016, alle ore 12:00, Malcolm Herring
> ha scritto:
>
> Values such as "yes", "forward", "reverse", "-1", etc are all meaningless to
> those who actually navigate the waterways. As Aun said, the commonly
> understood terms are "upstream" & "downstream".
On 18/09/2016 11:14, Colin Smale wrote:
the values for "oneway" and all the "forward" and "backward" subkey
business are geometric directions related to the order of the nodes in
the OSM way,
This is a dangerous dependency - if the way is reversed by another
mapper, the all "oneway" tags becom
sent from a phone
> Il giorno 18 set 2016, alle ore 16:35, Malcolm Herring
> ha scritto:
>
> This is a dangerous dependency - if the way is reversed by another mapper,
> the all "oneway" tags become invalid.
common osm editing software is caring for these dependencies and suggesting to
r
Maybe, but it's a dependency that has existed for years. It is understood by
"most mappers" (I know this is a generalisation) and is supported to some
extent by many editing and other tools.
//colin
On 18 September 2016 16:35:44 CEST, Malcolm Herring
wrote:
>On 18/09/2016 11:14, Colin Smale w
On 18/09/2016 15:35, Malcolm Herring wrote:
On 18/09/2016 11:14, Colin Smale wrote:
the values for "oneway" and all the "forward" and "backward" subkey
business are geometric directions related to the order of the nodes in
the OSM way,
This is a dangerous dependency - if the way is reversed by
sent from a phone
> Il giorno 18 set 2016, alle ore 07:11, Michael Tsang ha
> scritto:
>
> How should we cope with the situation like this
use the "note" key
cheers,
Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstr
On 18/09/2016 15:35, Malcolm Herring wrote:
This is a dangerous dependency - if the way is reversed by another
mapper, the all "oneway" tags become invalid.
All tags depend on other tags. If any tag is changed from being correct,
data will become "invalid"
Dave F.
___
On 2016-09-18 16:00, Martin Koppenhoefer wrote:
sent from a phone
Il giorno 18 set 2016, alle ore 07:11, Michael Tsang mailto:mikl...@gmail.com>> ha scritto:
How should we cope with the situation like this
use the "note" key
Or the "description" key, if it is something that may be usefu
Thank you Dave and sorry if I've been so strict :-).
FYI: I've made the fix, plus some others to clean a little bit the
tunnel values. Everything is explained here:
*
http://wiki.openstreetmap.org/wiki/Automated_edits/LeTopographeFou#.23002_-_Typos_with_tunnel.3Dbuilding_passage
*
http://w
On 9/18/2016 11:28 AM, Craig Wallace wrote:
use the "note" key
Or the "description" key, if it is something that may be useful for the
end user, ie displaying in an app.
Neither note nor description display when browsing an OSM changeset.
___
Tag
sent from a phone
> Il giorno 18 set 2016, alle ore 19:44, Mike N ha scritto:
>
> Neither note nor description display when browsing an OSM changeset.
maybe this can be fixed, at least note is displayed in josm in case name is void
cheers,
Martin ___
2016-09-18 19:44 GMT+02:00 Mike N :
> On 9/18/2016 11:28 AM, Craig Wallace wrote:
>
>> use the "note" key
>>>
>>
>> Or the "description" key, if it is something that may be useful for the
>> end user, ie displaying in an app.
>>
>
> Neither note nor description display when browsing an OSM change
On 11.09.2016 12:46, Dave F wrote:
But it's *not a tunnel*
Before there was any dedicated tag for it, many people mapped it as
tunnel=yes, so people definitely appear to intuitively consider it
tunnel-like. (Perhaps that's also a language issue, not sure.)
That's why the new value was also
On 17.09.2016 23:07, Warin wrote:
lit=yes
lit:intensity=dim/ambient/day_light
lit:type=led/halogon
lit:layer=0/1/2
Before you invent a detailed tagging schema from scratch, consider
basing this on the light_source schema instead:
http://wiki.openstreetmap.org/wiki/Proposed_features/Key:light
21 matches
Mail list logo
