Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

From: Paul Allen  
Sent: Saturday, 12 May 2018 05:49
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tagging of one-way cycle lanes

 

On Fri, May 11, 2018 at 8:06 PM, Paul Johnson  > wrote:

 

None of these three things are a problem now, except that the omission of 
bicycle lane tagging orthagonal to other lanes gives off by x problems for lane 
guidance, where x is the number of bicycle lanes.

 

All three of them will become problems if you have your way.  Almost every 
other mapper, apart from yourself, does not

see an "off by x" problem here because almost every other mapper sees "lanes" 
as meaning car lanes only.

 

Actually, it is a problem “right now” already, because all lanes= tagged with 
the “PJ lane count” are wrong and probably need a fixme applied to have a local 
mapper verify the correct count on the ground and fix them…

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Allen]

On Fri, May 11, 2018 at 8:06 PM, Paul Johnson  wrote:

>
> None of these three things are a problem now, except that the omission of
> bicycle lane tagging orthagonal to other lanes gives off by x problems for
> lane guidance, where x is the number of bicycle lanes.
>

All three of them will become problems if you have your way.  Almost every
other mapper, apart from yourself, does not
see an "off by x" problem here because almost every other mapper sees
"lanes" as meaning car lanes only.

"Hard to fix" isn't an excuse for leaving it wrong now that it's already a
> problem and only going to get worse as more bicycle facilities are built.
>

As people keep patiently trying to explain to you, it isn't wrong now and
it's not a problem.  What would be wrong,
VERY wrong, is your fix to something that isn't currently broken which
would result in it being very broken.

This isn't like Linux where releases are co-ordinated and people can choose
which release of which kernel in
which distro to install/upgrade to without affecting anybody else.  This
isn't like yum or apt or some other package
manager knowing that to update X it also has to update Y.  This isn't like
adding ESMTP extensions in a
backward-compatible way to SMTP with "EHLO".  This is like decreeing that
every mail server in the world
switch from SMTP/ESMTP to incompatible PJMTP (Paul Johnson Mail Transfer
Protocol) but without any
co-ordination whatsoever over a period of decades, so that for the entire
transition period there will be
miscommunication between servers running different protocols.

People keep telling you the correct way to handle a count of cycle lanes
but you keep insisting on a broken
solution.  Hint: when everybody else is marching out of step but you, the
problem is with you.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

On Fri, May 11, 2018, 12:50 Paul Allen  wrote:

>
> At which point in that long transition should editors switch?  And when
> should
> renderers switch?  And when should routeing algorithms switch?
>

None of these three things are a problem now, except that the omission of
bicycle lane tagging orthagonal to other lanes gives off by x problems for
lane guidance, where x is the number of bicycle lanes.

"Hard to fix" isn't an excuse for leaving it wrong now that it's already a
problem and only going to get worse as more bicycle facilities are built.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Allen]

On Fri, May 11, 2018 at 6:16 PM, Paul Johnson  wrote:

> This honestly sounds more of gatekeeping through laziness than an actual
> barrier.
>
> It does not sound that way to me.  It sounds to me like there is a very
real problem in
redefining, in an INCOMPATIBLE way, a tag which has been used 7,972,733
times.

There is no magic wand that can do an automatic global edit because EACH
INDIVIDUAL USE must be checked ON THE GROUND to see if the current
value is retained under the new definition or if it must be changed.

None of those manual changes are going to happen overnight. This means that
there will be a period of time, probably YEARS, when consumers can't be
sure of
what they're getting.  Actually, it will take years for 90% changeover and
decades
to catch it all.

At which point in that long transition should editors switch?  And when
should
renderers switch?  And when should routeing algorithms switch?

This proposal is MADNESS.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

The only way to do it properly is

- define a new tag "lanes_for_all_transportation_modes"
- deprecate lanes (during this period data-consumers should use
"lanes_for_all_transportation_modes" and fallback on "lanes" if the
former is not there)
- wait until all highways with a lanes tag also have
"lanes_for_all_transportation_modes"
- drop "lanes"-tag
- rename "lanes_for_all_transportation_modes" to "lanes"-tag

but that is only if you want a definition for lanes that no non-OSM'er
understand. As pointed out before, traffic rules and most people
understand lane as something on which you can drive with a car.

m.

On Fri, May 11, 2018 at 7:16 PM, Paul Johnson  wrote:
> This honestly sounds more of gatekeeping through laziness than an actual
> barrier.
>
> On Fri, May 11, 2018, 11:25 Tod Fitch  wrote:
>>
>>
>> > On May 11, 2018, at 8:40 AM, Paul Johnson  wrote:
>> >
>> > Why the almost religious doctrine level of resistance to change?  Even
>> > the Linux kernel rewrites entire subsystems from time to time when a
>> > superior approach comes around.
>>
>> The difference between having a small group of core developers who are all
>> communicating with one another lead by a single individual (Linux kernel)
>> and a community of tens of thousands, maybe millions, of contributors with a
>> multitude of different communication channels and with no single leader
>> (OSM). Changing core features/functionality in the former is much easier
>> than in the later.
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

This honestly sounds more of gatekeeping through laziness than an actual
barrier.

On Fri, May 11, 2018, 11:25 Tod Fitch  wrote:

>
> > On May 11, 2018, at 8:40 AM, Paul Johnson  wrote:
> >
> > Why the almost religious doctrine level of resistance to change?  Even
> the Linux kernel rewrites entire subsystems from time to time when a
> superior approach comes around.
>
> The difference between having a small group of core developers who are all
> communicating with one another lead by a single individual (Linux kernel)
> and a community of tens of thousands, maybe millions, of contributors with
> a multitude of different communication channels and with no single leader
> (OSM). Changing core features/functionality in the former is much easier
> than in the later.
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Removing helpful information in wiki pages

[Paul Allen]

I'm not on the DWG.  I'm just a mapper who reads this mailing list.

On Fri, May 11, 2018 at 5:22 PM, Thilo Haug  wrote:

> would you say this picture is "off topic" ?
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:
> aeroway%3Dspaceport=1519060#Pictures
>

Yes.  WILDLY off topic.  Totally irrelevant to the content of the page.

The images of the launchpad, landingpad, hangar and runway are helpful to
distinguish exactly
what is meant by those values for aeroway=*.

The images below them are in no way relevant to aeroway=*.  Even you know
that because you pass
them off as "background information."  But they're not.  They do not help
understand the aeroway tag at
all.

I'd also say your rant on this mailing list is similarly off-topic.  Having
been told, politely, that your
irrelevant images were not appreciated, you posted your tedious
back-and-forth argument here
in the hope that somebody would take your side.

This is all purely my own opinion as an ordinary mapper with no connection
to the DWG.  But I have
to say that if I'd been the DWG member dealing with you I'd have found it
very, VERY difficult
to be as polite with you as he was.  Come to that, I'm finding it difficult
to be polite with you here.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

The first reference to tagging lanes for cyclist on the lanes page is
made here: 
https://wiki.openstreetmap.org/w/index.php?title=Key%3Alanes=revision=648732=648729
by PeterIto

My interpretation is that he writes that cycle lanes should be mapped
as cycleway=lane (and thus not be included in the lanes-count).
So perhaps you should contact him to ask why he came up with this
definition (besides the arguments we gave above) ?


On Fri, May 11, 2018 at 5:50 PM, Paul Johnson  wrote:
> On Fri, May 11, 2018, 03:58  wrote:
>>
>> I've never gotten any validation errors when correctly tagging a road with
>> cycle lanes (that is, e.g. for a "normal" 2-way road: lanes=2,
>> cycleway=lane, and :lanes:forward and :lanes:backward tags with 2 values
>> each).
>
>
> cycleway=* is not lane tagging, you're just not tagging the lanes, so you've
> made tags that are syntactically correct and passes a validator, but in
> error by omission compared to ground truth.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Tod Fitch]

> On May 11, 2018, at 8:40 AM, Paul Johnson  wrote:
> 
> Why the almost religious doctrine level of resistance to change?  Even the 
> Linux kernel rewrites entire subsystems from time to time when a superior 
> approach comes around.

The difference between having a small group of core developers who are all 
communicating with one another lead by a single individual (Linux kernel) and a 
community of tens of thousands, maybe millions, of contributors with a 
multitude of different communication channels and with no single leader (OSM). 
Changing core features/functionality in the former is much easier than in the 
later.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

Is OsmAnd interpreting the lanes tag correctly in the presence of
cycle lanes when it is tagged like you do ?

On Fri, May 11, 2018 at 5:48 PM, Paul Johnson  wrote:
> On Fri, May 11, 2018, 03:27 Marc Gemis  wrote:
>>
>> > The definitions of what a lane is for these two tags are different.
>> > That's fine. They don't have to be the same.
>>
>> it would help though that validators and QA tools would not really
>> warn about the difference. Now people might start wondering whose
>> right.
>
>
> I believe the editors and the data consumers are already getting it right.
> The problem isn't the tool chain that handles completionist mapping
> correctly, the problem is omissionist documentation encouraging omissionist
> mapping.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

On Fri, May 11, 2018 at 5:40 PM, Paul Johnson  wrote:

>
> Why the almost religious doctrine level of resistance to change?  Even the
> Linux kernel rewrites entire subsystems from time to time when a superior
> approach comes around.

typically such a thing is done in 2 phases (e.g. Java language)
announce that the old API is deprecated and offer the new one in
parallel. Then, after a grace period, drop the old API.
This change is well announced, and it is clear which results you might
expect with the old and the new API.

Now apply this to the lanes-tag: Day A it means only "full width". The
next day it means all lanes, but none of the objects with this tag are
updated. Now, people will revisit those places one-by-one and update
the value. But perhaps some mappers did not read the new definition
and keep adding lanes-tag according to the old definition for awhile.

Now try to find out what the meaning is of the lanes tag on any random
object in the DB. Will you be successful ? I hardly doubt so.

There is no problem adding a new "lanes_for_all_vehicles"-tag, as
everyone using that tag knows that they have to count the cycle lanes
and perhaps pedestrian lanes as well.

Changing the meaning of a tag or value is impossible since the data
will not tell you whether it is put in the database according to the
old or the new definition. We have this problem even at this moment
(since you apply another definition than many other mappers), but we
can refer you, new mappers and  data consumers to the wiki page and
say this is how it should be done. We do not wilfully introduce
ambiguity in the interpretation of tags.

regards

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

On Fri, May 11, 2018, 03:58  wrote:

> I've never gotten any validation errors when correctly tagging a road with
> cycle lanes (that is, e.g. for a "normal" 2-way road: lanes=2,
> cycleway=lane, and :lanes:forward and :lanes:backward tags with 2 values
> each).
>

cycleway=* is not lane tagging, you're just not tagging the lanes, so
you've made tags that are syntactically correct and passes a validator, but
in error by omission compared to ground truth.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

On Fri, May 11, 2018, 03:27 Marc Gemis  wrote:

> > The definitions of what a lane is for these two tags are different.
> That's fine. They don't have to be the same.
>
> it would help though that validators and QA tools would not really
> warn about the difference. Now people might start wondering whose
> right.
>

I believe the editors and the data consumers are already getting it right.
The problem isn't the tool chain that handles completionist mapping
correctly, the problem is omissionist documentation encouraging omissionist
mapping.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

On Fri, May 11, 2018, 02:56 Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. May 2018, at 06:44, Marc Gemis  wrote:
> >
> > When the "lanes" tag was introduced the community choose to only count
> the "full width segments for motorised traffic".
>
>
> what is the definition for “full width”? Is a road with 1,8 width lanes=0?
> width=2.4? Given that maximum vehicle width is 2,50 it would seem sane to
> assume full width to be at least 3,00 m.
>

The MUTCD allows motor vehicle lanes to be as narrow as 9'0" for low speed
applications like alleyways and residential streets. Meanwhile, new
on-street bike lanes in Tulsa and Portland that I've seen built in the last
couple years are a minimum of 7'0" plus at least a 2'0" buffer, but because
streets in the 30-40 mph range have to have 11'0" or wider lanes, often
it's a 7'0" bike lane with buffers to encourage riding down the middle of
that space, further from the door zone or faster traffic.

Width is a pretty lousy criteria for excluding lanes, especially when lane
width tagging is a thing.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Johnson]

On Fri, May 11, 2018, 01:56  wrote:

> > From: Marc Gemis 
> > Sent: Friday, 11 May 2018 14:44
> >
> > When the "lanes" tag was introduced the community choose to only
> > count the "full width segments for motorised traffic". Perhaps
> > because traffic law in some countries (e.g. Belgium [1]) define
> > them that way. So people started using the tag that way and data
> > consumers started writing software depending on that definition.
> >
> > Perhaps it would have been better to count cycle lanes as well,
> > but we did not. For me, this means that with a tag as popular
> > as lanes, we cannot alter the definition later on. It would mean
> > that we have to retag a lot of objects and that tagging habits
> > have to change. Furthermore, the tag would be useless for data
> > consumers until we declare all lanes-tags to be updated to the
> > new definition.
>
> THAT is exactly the point I've been trying to make. The definition of the
> lanes tag predates the introduction of the :lanes suffix by many years. It
> has always been defined as "number of full width lanes for motorized
> traffic. Given then widespread use of this tag it's basically impossible to
> simply change it's definition.
>

Why the almost religious doctrine level of resistance to change?  Even the
Linux kernel rewrites entire subsystems from time to time when a superior
approach comes around.

>
> Furthermore, I do not know anyone that, when shown this picture:
>
>
> https://www.google.com.au/maps/@-27.218495,153.0061827,3a,66.8y,204.86h,78.18t/data=!3m4!1e1!3m2!1s2DBegIPPNP78TmCjslUavA!2e0
>
> and asked, "is that a 2 lane or a 4 lane street" would say that it's a 4
> lane street.


That is a four lane street, the curb lanes are obviously bike lanes, even
without scrolling back to the intersection thanks to the shoulderline along
tbe curb and the narrow lane width.

Similar here:
>
>
> https://www.google.com.au/maps/@-27.2305921,153.0252325,3a,66.8y,285.94h,79.82t/data=!3m4!1e1!3m2!1sWt2KhVfIcF3-YzMzGE1xFQ!2e0
>
> Nobody I know would tell me that is a 3 lane road.
>

Correct, hard shoulder.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Philip Barnes]

On Fri, 2018-05-11 at 11:57 +0200, Martin Koppenhoefer wrote:
> 2018-05-11 11:36 GMT+02:00 Philip Barnes :
> > 
> > Roads with a width less than 4.5m do not have lane markings. I live
> > in a rural area where there are a lot of such roads and tag these
> > using the width tag. I would only use lanes if there are painted
> > lanes on the road. 
> 
> 
> i.e. you would remove lanes tags in cases where the markings have
> disappeared due to missing maintenance? Would you split roads before
> intersections to add lanes tags close to traffic lights where there
> are markings, so you could remove the lanes tags from the parts where
> there aren't? How long would you say a segment of missing markings
> has to be in order to merit splitting the highway and removing the
> lanes tag?

I am thinking mostly of rural roads that are less than the width to
have lanes, to tag these as having two lanes would be wrong and
misleading as, whilst they have a 60 mph speed limit and that speed is
achievable you will expect to have to slow down and take care when
passing other traffic. You also need to slowdown on bends as visibility
is limited.

They are not advisable as through routes for large vehicles.

It is common for other rural roads, whilst mostly 2 lanes to drop in
width where they encounter restrictions, such as bridges. I map the bridge 
sections with width.

Phil (trigpoint)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-11 14:04 GMT+01:00 Martin Koppenhoefer :

> sent from a phone
>
> > On 11. May 2018, at 14:35, Javier Sánchez Portero 
> wrote:
> >
> > similar for the other two streets. With the proposed relation, I would
> create a relation with this tags
> >
> > type=address
> > addr:housenumber=1-25
> > addr:postcode=10018
> > addr:street=West 33rd Street
>
>
> I would consider not adding the address tags to the relation because
>
a) you could have features with several postcodes (imagine entrances on
> different streets)
>

Then you will have different relations, one per entrance.


> b) addr:housenumber=1-25 is not telling you which housenumbers it contains
> (better would be a list of all housenumbers)
>

It tells you what you find labelled in the entrance, what you can check on
place. If you have some features with individual housenumbers use the
addresses relation to avoid repeat the common tags and you can form the
(probably incomplete) list of house numbers for that entrance from the
addr:housenumber present in the members. If you only look at the entrance
and see "1-25" you can't know if it refers to 1,3,5,...,25 or 1,2,3,...,25.
In this case, if you don't have features inside that repeat partially or
fully the address you don't need the relation. Put the tags in the entrance
and done.


> c) it is duplicating the addresses with respect to the individual plaques
>

There is no duplicate. What I want to express is that the common addr:*
tags of the features with that address and the entrance/plaque will be in
the relation and NOT in the members. The members will have the addr:tags
that differs (usually none, in some cases addr:housenumber maybe addr:unit
or addr:door). Refining a bit the example the addr:housenumber=1-25 could
be in the entrance node instead of the address relation (easier for the
renderer).


> The address should be inherited from the members
>

This don't resolve the inconsistency problem. See the three different
postalcode values for the number 350 of the 5th Avenue in the query below.

https://overpass-turbo.eu/s/yJ0

Javier
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2018, at 15:11, Marc Gemis  wrote:
> 
> Martin, in case of the absence of lane markings, does one have to use
> flashing lights to change "virtual" lanes ?


Romans make very sparse use of turn indicators in general, compared to German 
traffic, you only need them for some kind of infractions like turning from the 
straight on lane ;-)

Cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

we have some crossings with 4 lanes where the driving direction is
south/north/south/north (we drive on the right hand side normally, so
it should have been south/south/north/north). They did this so left
turning traffic is not blocking the left turning traffic from the
other side. This can not be modelled with the current lane tagging.

Martin, in case of the absence of lane markings, does one have to use
flashing lights to change "virtual" lanes ?

regards

m

On Fri, May 11, 2018 at 3:03 PM, Paul Allen  wrote:
> On Fri, May 11, 2018 at 1:25 PM,  wrote:
>
>> The real world is never as nice and tidy as the data models we try to make
>> of it.
>
>
> Indeed.  Many years ago I encountered two places in the UK (one in Scotland,
> one in
> England) where a road which had three lanes across its width had the left
> lane for
> north-south, the right lane for south-north and the middle lane changed
> (indicated by traffic lights) according to the time of day.  This was to
> accommodate rush
> hour where mornings would see more traffic toward the town centre and
> afternoons
> more traffic away from it.
>
> The Golden Gate Bridge in the US does something similar but in a more
> dynamic
> way.  https://www.youtube.com/watch?v=-MeQnStAH0U
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2018, at 14:35, Javier Sánchez Portero  
> wrote:
> 
> similar for the other two streets. With the proposed relation, I would create 
> a relation with this tags
> 
> type=address
> addr:housenumber=1-25
> addr:postcode=10018
> addr:street=West 33rd Street


I would consider not adding the address tags to the relation because 
a) you could have features with several postcodes (imagine entrances on 
different streets)
b) addr:housenumber=1-25 is not telling you which housenumbers it contains 
(better would be a list of all housenumbers)
c) it is duplicating the addresses with respect to the individual plaques 

The address should be inherited from the members


Cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Paul Allen]

On Fri, May 11, 2018 at 1:25 PM,  wrote:

The real world is never as nice and tidy as the data models we try to make
> of it.
>

Indeed.  Many years ago I encountered two places in the UK (one in
Scotland, one in
England) where a road which had three lanes across its width had the left
lane for
north-south, the right lane for south-north and the middle lane changed
(indicated by traffic lights) according to the time of day.  This was to
accommodate rush
hour where mornings would see more traffic toward the town centre and
afternoons
more traffic away from it.

The Golden Gate Bridge in the US does something similar but in a more
dynamic
way.  https://www.youtube.com/watch?v=-MeQnStAH0U

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

sent from a phone

On 11. May 2018, at 14:25,  
 wrote:

>> If 3 vehicles drove side by side (which is the 
>> typical situation there, not counting the psv lane), which one would be 
>> "outside" the lanes?
> 
> The middle one clearly, it's half way in each of the official lanes.


sounds logical, but it is strange: assume 2 cars driving on the right side of 
the road (as required by the traffic code) side by side, now a third car 
overtakes, which is completely legal if there is sufficient room, regardless of 
lanes. Why should this put the law abiding driver of the middle car in a 
suspicious condition? Now imagine this is not one car, but lots.


> 
>> while I still agree, following this concept would mean to count 
>> lanes based on situations somewhere else, not? 
> 
> In the absence of any signs that would indicate such a change, it depends on 
> the width of the road.



> 
> In that case, if there is a clear point where the width of the road changes, 
> that's the split point.
> 


+1



> If the chance is gradual, take the midway point.


this IMHO is not compatible with the verifiability criterion 



> 
> If there is no noticeable change in the width of the road, assume the number 
> of lanes in traffic flow direction remains constant up to the point where it 
> clearly is indicated by road markings to be different.
> 
> Assuming you have high enough resolution imagery, use JOSM and the "lane and 
> road attributes" mapstyle, then specify your lane widths in detail using 
> width:lanes at the points where the lanes are clearly marked. 
> 
> Adjust the geometry of the way to try and fit it into the available road 
> surface along its way. Then work outwards in both directions from the points 
> where you know the lane count for sure based on road markings, you will 
> clearly see if there are places where you need to increase or decrease the 
> lane widths. 
> 
> If you need to decrease the land width below about 2.5m to make it fit, 
> that's a strong indication that you have too many lanes from that point on. 
> If you have to increase the land width much beyond 3-3.5m, AND further down 
> the road are more lanes than you currently have, it's probably time to 
> increase the lane count.


Seems workable, but the result would still be questionable WRT verifiability. 
At this point it seems most sane to omit the lanes tagging in the absence of 
road markings and indicate just a width (if only they hadn’t set up this psv 
lane recently it would be cleaner)


cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-11 10:53 GMT+01:00 Martin Koppenhoefer :

> May be it would be good to have a relation to keep in only one place an
>> address and link there the affected elements: entrances, buildings, POI's
>> and area for this address. This would be necessary only for some cases like
>> a building with many addresses/POI's. The simplest use cases would be done
>> as usual. Looking the history of the associated_street and street relation
>> may be this idea is too controversial so opinions are appreciated.
>>
>
> We could add relations to model which addresses belong to which POI (and
> this would also work for multiple addresses for one POI), but it really
> isn't the same as stating the address the POI is _using_, because it might
> "have" several entrances (and windows) with addresses but use only part of
> them (i.e. we would need roles to say which addresses lead to the POI, and
> which is the "official" address of it, the one on it's website, business
> register, receipt, advertising etc.). This would be a lot of relations for
> something that can be easily modelled by adding the address property as
> used by the POI to the object and be done. From the relation you will not
> be able to construct actual address strings like "Foo Street 33-35" because
> this could mean things like "33A, 33B, 33C, 35" or "33, 34, 35", or "33,
> 35", etc.
>
> Even for simple cases, I would like to tag whether they are representing
> an entrance (entrance=yes/main or barrier=gate) or not (entrance=no, these
> are either windows or former entrances now closed or potential future
> entrances, and on top of this, situations that shouldn't get a housenumber
> according to current legislation, but already have one). I am also
> interested in adding details like level=1 (I see the absence of level as
> level=0 and the default, but add level=1 for first floor entrances. This is
> useful to understand situations where the sequence of numbers seem "odd" on
> the map, but actually are accurate).
>
> Cheers,
> Martin
>


The kind of relation I have in mind is a type=address relation with the
usual tags for an address (addr:*). A quick sketch of the members could be

* role=plaque, cardinality=0-1 for a node near where the house number
plaque is located. This member will be present only if exists a plaque with
the number. This node could have the entrance=*, barrier=*, door=*,
wheelchair=*, etc. tags if the plaque is associated to an entrance or not,
like in [1]
* role=to define, cardinality=0-many for the features related to this
address. This could be buildings, features like shops, a landuse area, etc.

Generally the current schema will still be used. The address relation will
be necessary only for this:

* If you have many features associated to an address and you can't draw the
actual limits of a enclosing area to put the address or you want to use a
node for the reasons mentioned. Then we will have one relation.
* If you have many addresses for a feature. Then you will have as many
relations as plaques found. The case of the official address you mention
could be stated in the role.

Lets see a real world example, like the Empire State Building [2]. We have
one address in the building footprint and many others in nodes you can see
inside the footprint (and even two of them outside, making it hard to
associate them). The 350 of 5th Avenue it's repeated in many POI's. This
give to inconsistency: **there are three different addr:postcode values**.
It would be solved moving the addr:* tags to one relation with the POI's as
members.

The building have the number 2 in the West 34th Street, with the next
building having the 22 housenumber. Similar for the West 33rd Street, and
in the 5th Avenue the building is between 326 and 362 housenumbers, so I
think that the building have many housenumbers associated in each street.
Only to clarify the example, we can confirm this at [3], this entrance give
access to housenumbers 1 to 25. With the actual scheme, to improve this I
would move the address node [4] to this point with the entrance=main tag
and using addr:housenumber=1-25 and similar for the other two streets. With
the proposed relation, I would create a relation with this tags

type=address
addr:housenumber=1-25
addr:postcode=10018
addr:street=West 33rd Street

With the entrance, building and POI's (when present) as members. Each POI
could have tagged their individual addr:housenumber=n. The consumer will
get the full address for a POI from:

* The addr:housenumber of it (only present the addr:* tags that differs
from the parent address relation
* The addr:* tags of the parent address relations
* Can complete it with the name or addr:housename of the building if it's
only one.

The final number of relations needed will be one for entrance with plaque.
I think it could be possible three, one for each street.

[1] https://goo.gl/maps/yTDHWbVuRWF2
[2] https://www.openstreetmap.org/way/34633854
[3] 

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

> From: Martin Koppenhoefer  
> Sent: Friday, 11 May 2018 21:45

> while I would generally agree with the idea of having officially 3 lanes, 
> I would have thought that lanes would have to be painted on the road, not 
> just indicated by signs. 

Under the strict reading of the definition on the wiki, probably. The real 
world is never as nice and tidy as the data models we try to make of it. The 
road is designed to have 2 lanes (plus a psv lane). That's made clear by the 
sign. That they never bothered to mark it on the road surface (or it got lost 
after a repaving maybe) doesn't really change that.

> If 3 vehicles drove side by side (which is the 
> typical situation there, not counting the psv lane), which one would be 
> "outside" the lanes?

The middle one clearly, it's half way in each of the official lanes.

> while I still agree, following this concept would mean to count 
> lanes based on situations somewhere else, not? What if the lane 
> count changes between the intersections (indeed happens), where 
> would you split the highway if no lanes are painted?

In the absence of any signs that would indicate such a change, it depends on 
the width of the road.

If the number of marked lanes at the intersections differs, it's very likely 
that the width of the road will also be different. 

In that case, if there is a clear point where the width of the road changes, 
that's the split point.

If the chance is gradual, take the midway point.

If there is no noticeable change in the width of the road, assume the number of 
lanes in traffic flow direction remains constant up to the point where it 
clearly is indicated by road markings to be different.

Assuming you have high enough resolution imagery, use JOSM and the "lane and 
road attributes" mapstyle, then specify your lane widths in detail using 
width:lanes at the points where the lanes are clearly marked. 

Adjust the geometry of the way to try and fit it into the available road 
surface along its way. Then work outwards in both directions from the points 
where you know the lane count for sure based on road markings, you will clearly 
see if there are places where you need to increase or decrease the lane widths. 

If you need to decrease the land width below about 2.5m to make it fit, that's 
a strong indication that you have too many lanes from that point on. If you 
have to increase the land width much beyond 3-3.5m, AND further down the road 
are more lanes than you currently have, it's probably time to increase the lane 
count.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

2018-05-11 13:24 GMT+02:00 :

> I would tag that as:
>
>
>
> oneway=yes
>
> lanes=3
>
> lanes:psv=1
>
> vehicle:lanes=yes|yes|no
>
> psv:lanes=yes|yes|designated
>
> parking:lane:left=parallel
>
> parking:condition:left=ticket
>
> sidewalk=both
>
>
>
> This sign clearly defines how many lanes there are and that it’s a psv
> lane (not just a bus lane):
>
>
>
> https://www.google.com.au/maps/@41.8976885,12.4654864,
> 3a,17.5y,4.9h,90.2t/data=!3m6!1e1!3m4!1sPA9cA6SFCm4EvIHqGgo-
> -Q!2e0!7i13312!8i6656
>
>
>
>

while I would generally agree with the idea of having officially 3 lanes, I
would have thought that lanes would have to be painted on the road, not
just indicated by signs. If 3 vehicles drove side by side (which is the
typical situation there, not counting the psv lane), which one would be
"outside" the lanes?




> The road markings near the intersection also make it clear how many lanes
> there are :
>
>
>
> https://www.google.com.au/maps/@41.8994254,12.4643407,
> 3a,66.8y,356.59h,86.38t/data=!3m4!1e1!3m2!1sOEpzRTQFWoZi-4BndvycFg!2e0
>
>
>
> (the leftmost lane here was the parking lane, which is not included in
> lanes=x)
>
>
>


while I still agree, following this concept would mean to count lanes based
on situations somewhere else, not? What if the lane count changes between
the intersections (indeed happens), where would you split the highway if no
lanes are painted?

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

I would tag that as:

 

oneway=yes

lanes=3

lanes:psv=1

vehicle:lanes=yes|yes|no

psv:lanes=yes|yes|designated 

parking:lane:left=parallel

parking:condition:left=ticket

sidewalk=both

 

This sign clearly defines how many lanes there are and that it’s a psv lane 
(not just a bus lane):

 

https://www.google.com.au/maps/@41.8976885,12.4654864,3a,17.5y,4.9h,90.2t/data=!3m6!1e1!3m4!1sPA9cA6SFCm4EvIHqGgo--Q!2e0!7i13312!8i6656

 

The road markings near the intersection also make it clear how many lanes there 
are :

 

https://www.google.com.au/maps/@41.8994254,12.4643407,3a,66.8y,356.59h,86.38t/data=!3m4!1e1!3m2!1sOEpzRTQFWoZi-4BndvycFg!2e0

 

(the leftmost lane here was the parking lane, which is not included in lanes=x)

 

The parking tags probably need some more information, but I can’t read the 
signs on streetview, so that’s a job for a field survey.

 

From: Martin Koppenhoefer  
Sent: Friday, 11 May 2018 20:46
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tagging of one-way cycle lanes

 

I would also find it misleading to tag situations with lanes=2 where there is a 
painted bus lane and the rest of the carriageway (wide enough for 2-3 lanes) 
has no separations, like here:
https://www.google.com.au/maps/@41.8987442,12.4647371,3a,75y,156.28h,56.34t/data=!3m6!1e1!3m4!1sWEPSOplLQldMLooamvppkQ!2e0!7i13312!8i6656



Cheers,

Martin



OT: 

these are obviously not representative pictures of the road as they have 
probably been taken in the hottest period when everyone had left the city for a 
few days,

usual conditions are like this 
https://static.fanpage.it/wp-content/uploads/sites/2/2018/04/traffico-roma3-300x225.jpg

and in case of problems something like this 
https://www.ilmessaggero.it/photos/HIGH/83/38/2098338_trafficoroma.jpg

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases

[Marc Gemis]

both a and b are very unlikely imho.
c can be solved by any editor (the application not the person)

On Fri, May 11, 2018 at 12:04 PM, Martin Koppenhoefer
 wrote:
>
>
> 2018-05-11 10:16 GMT+02:00 Marc Gemis :
>>
>> >
>> > this tagging only works in the case of one way streets or separate
>> > carriageways, otherwise it is not clear to which direction the tags apply
>> > (you have to look for the closest intersection and guess, which will often
>> > work but isn’t a real solution)
>>
>> This is no longer true,  OsmAnd now has support for the direction tag on
>> stop
>> signs: https://github.com/osmandapp/Osmand/issues/2885
>>
>
>
> this was about "conceptually impossible", there is nothing OSMAnd can do
> about it.
>
> It might use a "best guess" approach, but it isn't a defined modelling and
> risks breaking any time because
> a) someone might split the road at the node, so that there are 2 ways using
> the node
> b) someone might add a new way to the node
> c) someone might reverse the way (and would likely not be notified about
> nodes)
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service:vehicle: prefix

[Thilo Haug OSM]

Hello all,

instead of discussing everything from scratch,
let's create a general guideline for shop suffixes.
There has already been a former short dicussion
with some nice examples, but no productive outcome :

General namespace (syntax) for shops :
https://lists.openstreetmap.org/pipermail/tagging/2017-September/033385.html

Proposal :
https://wiki.openstreetmap.org/wiki/Proposed_features/shop_subtags

Please write your input to the proposal's discussion page,
otherwise everyone has to search all the old emails in the tagging
mailing list's archive.

Cheers,
Thilo

Am 06.05.2018 um 22:07 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 6. May 2018, at 14:27, Bryan Housel  wrote:
>>
>> Hey all, this is something I added to iD because we can’t support reusing 
>> the `service=*` tag to also store values for vehicle services.  
>
> introducing undocumented and formerly unused tags via preset without any 
> discussion or proposal process is something I didn’t expect from the main 
> osmf endorsed editor. Are there more tags that have been introduced this way, 
> and if yes, have they been documented in the meantime?
>
>
> Cheers,
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

I would also find it misleading to tag situations with lanes=2 where there
is a painted bus lane and the rest of the carriageway (wide enough for 2-3
lanes) has no separations, like here:
https://www.google.com.au/maps/@41.8987442,12.4647371,3a,75y,156.28h,56.34t/data=!3m6!1e1!3m4!1sWEPSOplLQldMLooamvppkQ!2e0!7i13312!8i6656


Cheers,
Martin


OT:
these are obviously not representative pictures of the road as they have
probably been taken in the hottest period when everyone had left the city
for a few days,
usual conditions are like this
https://static.fanpage.it/wp-content/uploads/sites/2/2018/04/traffico-roma3-300x225.jpg
and in case of problems something like this
https://www.ilmessaggero.it/photos/HIGH/83/38/2098338_trafficoroma.jpg
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access=disabled

[Martin Koppenhoefer]

2018-05-11 5:18 GMT+02:00 Nick Bolten :

> > I would expect a dedicated parking space for disabled drivers to have
> room for a ramp. AFAIK it is required by the standard specification (in
> Germany, likely in the EU).
>
> I can guarantee you, that is not universal.
>


you are right :)

I guess if there isn't sufficient room authorities will prefer to have a
disabled parking space with limited usability rather than no disabled
parking space at all.

While you will typically have to fulfill the requirements defined by the
standards for a new construction (in order to get a building permit, but
maybe depending on the local building authorities policies), there can
still occur situations which don't completely satisfy them.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

A lot of residential roads here don’t have markings, like here:

 

https://www.google.com.au/maps/@-27.2131302,153.0260346,3a,55y,45.38h,68.9t/data=!3m4!1e1!3m2!1sci60ZE7unqEW6wDOP9Gh6Q!2e0

 

But they are clearly intended to be 2 lane roads. (Which can be seen from the 
reflectors that are sometimes in the middle of the road and the fact that ty do 
have lane markings in some places, e.g. at the T intersection.

 

I would (and have) tagged such roads with lanes=2.

 

From: Martin Koppenhoefer  
Sent: Friday, 11 May 2018 19:57
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tagging of one-way cycle lanes

 

2018-05-11 11:36 GMT+02:00 Philip Barnes  >:



Roads with a width less than 4.5m do not have lane markings. I live in a rural 
area where there are a lot of such roads and tag these using the width tag. I 
would only use lanes if there are painted lanes on the road. 

 

i.e. you would remove lanes tags in cases where the markings have disappeared 
due to missing maintenance? Would you split roads before intersections to add 
lanes tags close to traffic lights where there are markings, so you could 
remove the lanes tags from the parts where there aren't? How long would you say 
a segment of missing markings has to be in order to merit splitting the highway 
and removing the lanes tag?

Cheers,

Martin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access=disabled

[Martin Koppenhoefer]

2018-05-11 1:48 GMT+02:00 Warin <61sundow...@gmail.com>:

> On 11/05/18 09:01, Martin Koppenhoefer wrote:
>
> i.e. it is forbidden to cross the parking by foot if you are not disabled?
>
> and if an area is tagged amenity=parking, access=customers ... same
> problem.
>


while it is somehow true, it is less of a practical problem, because anyone
is a potential customer. You don't have to actually buy something on order
to be a "customer" for the question of access. If I were to define
rendering rules, I would generally allow access to access=customers
entities and would clearly not allow access to objects with access=no,
disabled=yes objects if the user is not disabled=yes.




>
> according to the wiki, agricultural, forestry, customers etc. are _values_
> for access tags:
> https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values
> (agricultural is also a vehicle class though).
>
>
> And some are using disabled as a value too... which was my suggestion ..
> see the subject of the thread.
> Too me this is a logical extension of the present system of use ..
>


to me it is not logical, because you either are "disabled" or not, it is
like a vehicle class, not a mode you sometimes conform to and sometimes not
(like delivery or destination). In other words, it is like "agricultural=*"
not like "*=agricultural".



>
>
> "disabled" are a class of users (see "by use"):
> https://wiki.openstreetmap.org/wiki/Key:access#Access_tag_values
>
>
> This is 'documented"? Ha. Look at the page for the 'documentation'. I have
> no idea what it is at all
> https://wiki.openstreetmap.org/wiki/Key%3Adisabled
>


this is a stub, you can find the docu on the page I linked above, or "see
also" on this page.


Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases

[Martin Koppenhoefer]

2018-05-11 10:16 GMT+02:00 Marc Gemis :

> >
> > this tagging only works in the case of one way streets or separate
> carriageways, otherwise it is not clear to which direction the tags apply
> (you have to look for the closest intersection and guess, which will often
> work but isn’t a real solution)
>
> This is no longer true,  OsmAnd now has support for the direction tag on
> stop
> signs: https://github.com/osmandapp/Osmand/issues/2885
>
>

this was about "conceptually impossible", there is nothing OSMAnd can do
about it.

It might use a "best guess" approach, but it isn't a defined modelling and
risks breaking any time because
a) someone might split the road at the node, so that there are 2 ways using
the node
b) someone might add a new way to the node
c) someone might reverse the way (and would likely not be notified about
nodes)

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

2018-05-11 11:36 GMT+02:00 Philip Barnes :

>
>
> Roads with a width less than 4.5m do not have lane markings. I live in a
> rural area where there are a lot of such roads and tag these using the
> width tag. I would only use lanes if there are painted lanes on the road.



i.e. you would remove lanes tags in cases where the markings have
disappeared due to missing maintenance? Would you split roads before
intersections to add lanes tags close to traffic lights where there are
markings, so you could remove the lanes tags from the parts where there
aren't? How long would you say a segment of missing markings has to be in
order to merit splitting the highway and removing the lanes tag?

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key: starting=yes ??

[Peter Elderson]

Thanks @Martin, thanks @Mateusz.

I will document this for the dutch hiking project, suggesting the role
start.
For hiking, stop, stop_start  and end are same as start. I think I will use
the role for a few trails. I will have to discipline JOSM validator though.
It complains about a template that doesn't know the role start.



2018-05-11 11:33 GMT+02:00 Martin Koppenhoefer :

> 2018-05-11 11:22 GMT+02:00 Peter Elderson :
>
>> Well, in a roundtrip there are often multiple designated starting points
>> with a parking lot, information panels, bus stop or railway statin nearby,
>> toilets. These designated starting points are commonly shown on paper maps
>> and tourist maps, and present themselves as starting points.
>>
>> I do not see how this is recorded by adding ways.
>>
>
>
>
> I agree it is worth tagging (if objectively observable / signposted), and
> agree with Mateusz it has to be part of the route relation, not a node. My
> suggestion would be to add a node (or more if needed) to the route relation
> with the role "start" or "starting_point".
> There are already 3476 role "start" in route relations by the way:
> https://taginfo.openstreetmap.org/relations/route#roles
>
> And I have found some docu in the wiki:
> https://wiki.openstreetmap.org/wiki/Talk:Key:roundtrip
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dfitness_trail
>
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Martin Koppenhoefer]

2018-05-11 10:40 GMT+02:00 Javier Sánchez Portero :

> In Spain, there isn't a relation one-to-one between entrances and
> addresses, but it's pretty common to have a building with more than one
> address. They may be a building with access from different streets or a
> building (maybe with a housename) and some consecutive numbers (even or
> odd) in the same street. For this reason many people (me included) are
> mapping addresses as nodes pinpointing the house number plaques found at
> street level. Most of the time they are associated to an entrance, but not
> always. We put a node in the building footprint (if it's only one) or in
> the parcel limit when many buildings share the address and there are a
> visible barrier as delimiter. I think that this method reflect best the
> reality, gather more information and is best for micromapping.
>
> I don't like the duplication of information, prone to be inconsistent
> between the address in the entrance and in the multiple POI's that could be
> inside the building or area.
>


IMHO these inconsistencies often are useful to see that the POI (or the
housenumber) is not positioned well. If you don't add address information
to a POI and don't have an area with address information where it is
included, you don't have this information.



> May be it would be good to have a relation to keep in only one place an
> address and link there the affected elements: entrances, buildings, POI's
> and area for this address. This would be necessary only for some cases like
> a building with many addresses/POI's. The simplest use cases would be done
> as usual. Looking the history of the associated_street and street relation
> may be this idea is too controversial so opinions are appreciated.
>


We could add relations to model which addresses belong to which POI (and
this would also work for multiple addresses for one POI), but it really
isn't the same as stating the address the POI is _using_, because it might
"have" several entrances (and windows) with addresses but use only part of
them (i.e. we would need roles to say which addresses lead to the POI, and
which is the "official" address of it, the one on it's website, business
register, receipt, advertising etc.). This would be a lot of relations for
something that can be easily modelled by adding the address property as
used by the POI to the object and be done. From the relation you will not
be able to construct actual address strings like "Foo Street 33-35" because
this could mean things like "33A, 33B, 33C, 35" or "33, 34, 35", or "33,
35", etc.

Even for simple cases, I would like to tag whether they are representing an
entrance (entrance=yes/main or barrier=gate) or not (entrance=no, these are
either windows or former entrances now closed or potential future
entrances, and on top of this, situations that shouldn't get a housenumber
according to current legislation, but already have one). I am also
interested in adding details like level=1 (I see the absence of level as
level=0 and the default, but add level=1 for first floor entrances. This is
useful to understand situations where the sequence of numbers seem "odd" on
the map, but actually are accurate).


Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Philip Barnes]

On 11 May 2018 08:58:16 BST, Marc Gemis  wrote:
>If you were not trying to tag this situation, but explain it to your
>non-OSM friends, would you say that there are 2 lanes in that picture
>?
>At least in Belgium a lane is defined by having some white markings on
>the ground. If there are no markings, there is only 1 lane. I do not
>know how it is defined in other countries. From what Thorsen wrote in
>this thread, I think it's the same in Australia.
>
Same in the UK. 

Roads with a width less than 4.5m do not have lane markings. I live in a rural 
area where there are a lot of such roads and tag these using the width tag. I 
would only use lanes if there are painted lanes on the road. 

Phil (trigpoint) 



>m.
>
>On Fri, May 11, 2018 at 9:45 AM, Martin Koppenhoefer
> wrote:
>>
>>
>> sent from a phone
>>
>> On 11. May 2018, at 05:49, Marc Gemis  wrote:
>>
>> It's just historically that "lanes" (the tag alone) is only for
>motorised
>> traffic.
>>
>>
>>
>> I agree with Paul, it has always bothered me to have this
>inconsistency in
>> the definitions.
>>
>> What would you say about unsigned lanes? This is/was a frequent
>situation in
>> Rome, where there are basically huge areas of asphalt (2-4 lanes)
>without
>> lane markings, or only with lane markings before traffic lights (and
>people
>> not respecting them oftentimes). In recent years they have begun to
>remove
>> the ambiguity by painting more lanes and adding more “channeling”
>> infrastructure like traffic islands and guards rails, but you can
>still find
>> a lot of “wild” situations. Would you agree it is ok to estimate a
>number in
>> the absence of markings, or would you prefer something like width=12
>> lanes=no (or maybe 1)?
>>
>> e.g.
>>
>https://www.instantstreetview.com/@41.888713,12.480457,180.97h,-11.28p,1.54z
>>
>>
>> Cheers,
>> Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

2018-05-11 9:58 GMT+02:00 Marc Gemis :

> If you were not trying to tag this situation, but explain it to your
> non-OSM friends, would you say that there are 2 lanes in that picture
> ?
> At least in Belgium a lane is defined by having some white markings on
> the ground. If there are no markings, there is only 1 lane. I do not
> know how it is defined in other countries. From what Thorsen wrote in
> this thread, I think it's the same in Australia.
>


I would count the lanes as used by the cars, if there are typically 3 or 4
cars driving side by side, I would call this a 3-4 lanes road, also in the
absence of road markings.


Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key: starting=yes ??

[Martin Koppenhoefer]

2018-05-11 11:22 GMT+02:00 Peter Elderson :

> Well, in a roundtrip there are often multiple designated starting points
> with a parking lot, information panels, bus stop or railway statin nearby,
> toilets. These designated starting points are commonly shown on paper maps
> and tourist maps, and present themselves as starting points.
>
> I do not see how this is recorded by adding ways.
>



I agree it is worth tagging (if objectively observable / signposted), and
agree with Mateusz it has to be part of the route relation, not a node. My
suggestion would be to add a node (or more if needed) to the route relation
with the role "start" or "starting_point".
There are already 3476 role "start" in route relations by the way:
https://taginfo.openstreetmap.org/relations/route#roles

And I have found some docu in the wiki:
https://wiki.openstreetmap.org/wiki/Talk:Key:roundtrip
https://wiki.openstreetmap.org/wiki/Tag:route%3Dfitness_trail


Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key: starting=yes ??

[Peter Elderson]

Well, in a roundtrip there are often multiple designated starting points
with a parking lot, information panels, bus stop or railway statin nearby,
toilets. These designated starting points are commonly shown on paper maps
and tourist maps, and present themselves as starting points.

I do not see how this is recorded by adding ways.

Wouldn't call it very important either, but I do think it's useful and tied
to observable objects and places.



2018-05-11 11:00 GMT+02:00 Mateusz Konieczny :

> 11. May 2018 10:52 by pelder...@gmail.com:
>
> if anything, it should be a role in the relation, not a tag on the node.
> Right?
>
>
> but IMHO it is utterly unimportant, it is already recorded by adding ways
>
>
> and obviously, it is property of route, not road/path so if added it should
>
> be in relation
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key: starting=yes ??

[Mateusz Konieczny]

11. May 2018 10:52 by pelder...@gmail.com :


> if anything, it should be a role in the relation, not a tag on the node. 
> Right? 
>




but IMHO it is utterly unimportant, it is already recorded by adding ways




and obviously, it is property of route, not road/path so if added it should

be in relation

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key: starting=yes ??

[Mateusz Konieczny]

11. May 2018 11:00 by matkoni...@tutanota.com :


> 11. May 2018 10:52 by > pelder...@gmail.com > 
> :
>
>
>> if anything, it should be a role in the relation, not a tag on the node. 
>> Right? 
>>
>
>
>
>
> but IMHO it is utterly unimportant, it is already recorded by adding ways
>




ops, I missed "roundtrip" - sorry. It makes sense to record this.
 

>
> and obviously, it is property of route, not road/path so if added it should
>
> be in relation
>
>

 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

I've always been editing using JOSM and using the "lane and road attributes" 
mapstyle for visualization (which is pretty much the only editor/map style I'm 
aware of that has support for the large majority of lane related tags, making 
it pretty much the defacto standard implementation given the the majority of 
the relevant proposals never went to voting).

I've never gotten any validation errors when correctly tagging a road with 
cycle lanes (that is, e.g. for a "normal" 2-way road: lanes=2, cycleway=lane, 
and :lanes:forward and :lanes:backward tags with 2 values each).

If there are any validation tools that would complain about this situation, 
then they are broken and the bug needs to be reported.

> -Original Message-
> From: Marc Gemis 
> Sent: Friday, 11 May 2018 18:26
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] tagging of one-way cycle lanes
> 
> > The definitions of what a lane is for these two tags are
> different. That's fine. They don't have to be the same.
> 
> it would help though that validators and QA tools would not really
> warn about the difference. Now people might start wondering whose
> right.
> 
> m.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] key: starting=yes ??

[Peter Elderson]

Hi
In the Netherlands, I find a key starting=yes, to tag one or more nodes in
a route relation for a walking roundtrip as a starting point. Seems to me
that, if anything, it should be a role in the relation, not a tag on the
node. Right?
The dutch wiki page about this recommends using a node tagged as
information point, that's ok I think.

If so, it probably would not hurt to remove the tags, correct the dutch
documentation and maybe suggest using a role instead?

-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] address property vs. housenumber as a feature

[Javier Sánchez Portero]

2018-05-09 22:41 GMT+01:00 Martin Koppenhoefer :

> Is there a way to indicate a housenumber is a feature, vs. a property?
>
> In many places, housenumbers refer to buildings or sites, and you might
> omit addresses on contained features (because you can hope for inheritance
> from the containing address object). Unfortunately the situation in Italy
> is a bit different in this regard, as housenumbers are assigned to
> entrances (either site or building) and even potential entrances.
>
> This leads to the common situation that the same housenumber appears
> multiple times (on the entrance as a feature and on the contained features
> like businesses as an address property). Businesses being accessible
> through different housenumbers is not a rare exception but rather common.
> They deal with it differently: while some list all or a bunch of the
> numbers as their address, others choose one (often but not always the main
> entrance).
>
> If you map the POI as an area, you might often be able to represent the
> numbers that are part of the area (unless they are not on the ground floor,
> or the building is not directly on the street hence the number is typically
> at a gate on the site perimeter). Still most people (including myself)
> don’t map small businesses in shared buildings as areas, so duplicated
> address information is common.
>
> Some of my fellow mappers are dealing with this by adding the poi
> information to the entrance, but this is unsatisfactory because of several
> reasons:
>
> - it can only deal with cases where one number is for one business, it
> doesn’t work for multiple entrances or numbers and it doesn’t work for
> shared entrances (one number for several pois)
>
> - it is topologically wrong (the poi is not on the perimeter, neither
> inside nor outside, it is inside). The poi is also not the same as the
> entrance, if you add entrance=* it is an entrance and should not get other
> tags for a different object (the poi) like name etc.
>
> Thoughts?
>
> Cheers,
> Martin
>
> sent from a phone
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


In Spain, there isn't a relation one-to-one between entrances and
addresses, but it's pretty common to have a building with more than one
address. They may be a building with access from different streets or a
building (maybe with a housename) and some consecutive numbers (even or
odd) in the same street. For this reason many people (me included) are
mapping addresses as nodes pinpointing the house number plaques found at
street level. Most of the time they are associated to an entrance, but not
always. We put a node in the building footprint (if it's only one) or in
the parcel limit when many buildings share the address and there are a
visible barrier as delimiter. I think that this method reflect best the
reality, gather more information and is best for micromapping.

I don't like the duplication of information, prone to be inconsistent
between the address in the entrance and in the multiple POI's that could be
inside the building or area. May be it would be good to have a relation to
keep in only one place an address and link there the affected elements:
entrances, buildings, POI's and area for this address. This would be
necessary only for some cases like a building with many addresses/POI's.
The simplest use cases would be done as usual. Looking the history of the
associated_street and street relation may be this idea is too controversial
so opinions are appreciated.

Cheers, Javier
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

> The definitions of what a lane is for these two tags are different. That's 
> fine. They don't have to be the same.

it would help though that validators and QA tools would not really
warn about the difference. Now people might start wondering whose
right.

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

I'm not sure why we are wasting any time on discussing possible changes to the 
definition of the lanes tag her. 

The tag goes back to pretty much the start of OSM and is in widespread usage. 
Any change in definition that fundamentally changes what value goes into the 
key given a specific situation is basically impossible at this point. Otherwise 
you end up with a mix of tags where the value means one thing and where the 
value means another thing, with no way to distinguish the two, making the tag 
completely useless.

The lanes tag is what it is, which is essential "if you show picture of the 
street to your average person (which has nothing to do with OSM), how many 
lanes would that person say the picture shows".

The lanes=x tag has its definition of what a lane is _for purpose of this tag_. 
That definition has remained and will remain unchanged.

The :lanes suffix has its definition of what a lane is _for purpose of this 
tag_. That definition has remained and will remain unchanged.

The definitions of what a lane is for these two tags are different. That's 
fine. They don't have to be the same.

> -Original Message-
> From: Marc Gemis 
> Sent: Friday, 11 May 2018 17:58
> To: Tag discussion, strategy and related tools
> 
> Subject: Re: [Tagging] tagging of one-way cycle lanes
> 
> If you were not trying to tag this situation, but explain it to
> your non-OSM friends, would you say that there are 2 lanes in that
> picture ?
> At least in Belgium a lane is defined by having some white markings
> on the ground. If there are no markings, there is only 1 lane. I do
> not know how it is defined in other countries. From what Thorsen
> wrote in this thread, I think it's the same in Australia.
> 
> m.
> 
> On Fri, May 11, 2018 at 9:45 AM, Martin Koppenhoefer
>  wrote:
> >
> >
> > sent from a phone
> >
> > On 11. May 2018, at 05:49, Marc Gemis 
> wrote:
> >
> > It's just historically that "lanes" (the tag alone) is only for
> > motorised traffic.
> >
> >
> >
> > I agree with Paul, it has always bothered me to have this
> > inconsistency in the definitions.
> >
> > What would you say about unsigned lanes? This is/was a frequent
> > situation in Rome, where there are basically huge areas of
> asphalt
> > (2-4 lanes) without lane markings, or only with lane markings
> before
> > traffic lights (and people not respecting them oftentimes). In
> recent
> > years they have begun to remove the ambiguity by painting more
> lanes and adding more “channeling”
> > infrastructure like traffic islands and guards rails, but you can
> > still find a lot of “wild” situations. Would you agree it is ok
> to
> > estimate a number in the absence of markings, or would you prefer
> > something like width=12 lanes=no (or maybe 1)?
> >
> > e.g.
> > https://www.instantstreetview.com/@41.888713,12.480457,180.97h,-
> 11.28p
> > ,1.54z
> >
> >
> > Cheers,
> > Martin
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases

[Marc Gemis]

>
> this tagging only works in the case of one way streets or separate 
> carriageways, otherwise it is not clear to which direction the tags apply 
> (you have to look for the closest intersection and guess, which will often 
> work but isn’t a real solution)

This is no longer true,  OsmAnd now has support for the direction tag on stop
signs: https://github.com/osmandapp/Osmand/issues/2885

This is part of OsmAnd 2.9. I saw it advertised and wondered how they
implemented it.


regards

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

It will probably depend on traffic code/law in each country.
According to wikipedia [1] it's normally between 2.5 and 3.5 m
AFAIK when a lane is smaller, and thus not suitable for trucks and
cars with caravans, it has to be indicated by a traffic sign.
For me full width means that a car (which has to be smaller than 2 m,
not ?) can drive over it, without blocking cars in other lanes.


[1] https://nl.wikipedia.org/wiki/Rijstrook

p.s. this discussion should have been taking to a different thread, as
we are now hijacking the OP's tread on "tagging of one-way cycle
lanes".

On Fri, May 11, 2018 at 9:55 AM, Martin Koppenhoefer
 wrote:
>
>
> sent from a phone
>
>> On 11. May 2018, at 06:44, Marc Gemis  wrote:
>>
>> When the "lanes" tag was introduced the community choose to only count the 
>> "full width segments for motorised traffic".
>
>
> what is the definition for “full width”? Is a road with 1,8 width lanes=0? 
> width=2.4? Given that maximum vehicle width is 2,50 it would seem sane to 
> assume full width to be at least 3,00 m.
>
> Ciao, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2018, at 04:01, Paul Johnson  wrote:
> 
> Your from way would be the way those signs are facing, and the TO ways would 
> be all the ways you would have to stop at the sign before proceeding to enter 
> (ie, all of them except the way for the right turn).


exactly, I thought you didn’t  need a “to” way like for turn restrictions 
because you will have to stop in any case or yield for any other way.
I didn’t know there were jurisdictions where you didn’t have to stop at a stop 
sign when turning right (if I understood you correctly)

cheers,
Martin 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Marc Gemis]

If you were not trying to tag this situation, but explain it to your
non-OSM friends, would you say that there are 2 lanes in that picture
?
At least in Belgium a lane is defined by having some white markings on
the ground. If there are no markings, there is only 1 lane. I do not
know how it is defined in other countries. From what Thorsen wrote in
this thread, I think it's the same in Australia.

m.

On Fri, May 11, 2018 at 9:45 AM, Martin Koppenhoefer
 wrote:
>
>
> sent from a phone
>
> On 11. May 2018, at 05:49, Marc Gemis  wrote:
>
> It's just historically that "lanes" (the tag alone) is only for motorised
> traffic.
>
>
>
> I agree with Paul, it has always bothered me to have this inconsistency in
> the definitions.
>
> What would you say about unsigned lanes? This is/was a frequent situation in
> Rome, where there are basically huge areas of asphalt (2-4 lanes) without
> lane markings, or only with lane markings before traffic lights (and people
> not respecting them oftentimes). In recent years they have begun to remove
> the ambiguity by painting more lanes and adding more “channeling”
> infrastructure like traffic islands and guards rails, but you can still find
> a lot of “wild” situations. Would you agree it is ok to estimate a number in
> the absence of markings, or would you prefer something like width=12
> lanes=no (or maybe 1)?
>
> e.g.
> https://www.instantstreetview.com/@41.888713,12.480457,180.97h,-11.28p,1.54z
>
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2018, at 06:44, Marc Gemis  wrote:
> 
> When the "lanes" tag was introduced the community choose to only count the 
> "full width segments for motorised traffic".


what is the definition for “full width”? Is a road with 1,8 width lanes=0? 
width=2.4? Given that maximum vehicle width is 2,50 it would seem sane to 
assume full width to be at least 3,00 m.

Ciao, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases

[Mateusz Konieczny]

10. May 2018 21:03 by ru...@vfn-nrw.de :


> What do you think about the relation-approach designed by AMDmi3:
>




Relations are generally horrible to edit. 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2018, at 05:49, Marc Gemis  wrote:
> 
> It's just historically that "lanes" (the tag alone) is only for motorised 
> traffic.


I agree with Paul, it has always bothered me to have this inconsistency in the 
definitions. 

What would you say about unsigned lanes? This is/was a frequent situation in 
Rome, where there are basically huge areas of asphalt (2-4 lanes) without lane 
markings, or only with lane markings before traffic lights (and people not 
respecting them oftentimes). In recent years they have begun to remove the 
ambiguity by painting more lanes and adding more “channeling” infrastructure 
like traffic islands and guards rails, but you can still find a lot of “wild” 
situations. Would you agree it is ok to estimate a number in the absence of 
markings, or would you prefer something like width=12 lanes=no (or maybe 1)?

e.g. 
https://www.instantstreetview.com/@41.888713,12.480457,180.97h,-11.28p,1.54z


Cheers,
Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[osm.tagging]

> From: Marc Gemis  
> Sent: Friday, 11 May 2018 14:44
> 
> When the "lanes" tag was introduced the community choose to only 
> count the "full width segments for motorised traffic". Perhaps 
> because traffic law in some countries (e.g. Belgium [1]) define 
> them that way. So people started using the tag that way and data 
> consumers started writing software depending on that definition.
>
> Perhaps it would have been better to count cycle lanes as well, 
> but we did not. For me, this means that with a tag as popular 
> as lanes, we cannot alter the definition later on. It would mean 
> that we have to retag a lot of objects and that tagging habits 
> have to change. Furthermore, the tag would be useless for data 
> consumers until we declare all lanes-tags to be updated to the 
> new definition. 

THAT is exactly the point I've been trying to make. The definition of the lanes 
tag predates the introduction of the :lanes suffix by many years. It has always 
been defined as "number of full width lanes for motorized traffic. Given then 
widespread use of this tag it's basically impossible to simply change it's 
definition. 

This has also been specifically brought up _and a resolution decided upon_ 
during the proposal process for :lanes suffix:

https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag

Furthermore, I do not know anyone that, when shown this picture:

https://www.google.com.au/maps/@-27.218495,153.0061827,3a,66.8y,204.86h,78.18t/data=!3m4!1e1!3m2!1s2DBegIPPNP78TmCjslUavA!2e0

and asked, "is that a 2 lane or a 4 lane street" would say that it's a 4 lane 
street.

Similar here:

https://www.google.com.au/maps/@-27.2305921,153.0252325,3a,66.8y,285.94h,79.82t/data=!3m4!1e1!3m2!1sWt2KhVfIcF3-YzMzGE1xFQ!2e0

Nobody I know would tell me that is a 3 lane road.

Cheers,
Thorsten



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP

[osm.tagging]

A few comments:

* I don't think this should "obsolete" the highway=give_way nodes completely. 
For simple cases with oneway=yes roads the highway=give_way node on the way is 
the easiest way to map them. Also for any "four-way give way" situation, 
tagging the intersection node is clear and unambigious.

* I'm not sure if putting the different traffic types into the relation type 
key is the right place. It might be better to put that into an applies_to key? 

That way you can list multiple, either as applies_to=caravan;hgv;bus or 
applies_to:bus=yes applies_to:hgv=yes

The separate key version has the advantage that it would also allow conditions:

applies_to:hgv=no
applies_to:hgv:conditional=yes@(Mo-Fr)

* instead of day_on, day-off, hour_on, and hour_off, it might be better to use 
an operating_hours key with the same format as opening_hours for shops

* overwritten_by might be better as a member instead (or in addition) of a key. 
Especially for dual carriage way intersections (mapped as # ) the 
traffic_signal nodes are usually at the stop line on the approach instead of at 
the intersecting nodes (if you tag the 4 intersecting nodes, then a route 
through the intersection would pass 2 or 3 highway=traffig_signal nodes, while 
if it is tagged only on the approaches [which are all oneways] the route 
correctly only goes through a single one). 

* the value curb value for the road_markings key should probably be kerb to 
match the barrier=kerb tag and to match UK English usage.

* in addition to the road_sign members, it would be good to also allow 
road_marking members (which would be a node on a from way, or a way with an 
intersecting node with the from way, tagged with road_marking=x, or 
barrier=kerb)

* the road_sign and road_marking members and keys should have the same name

Cheers,
Thorsten


> -Original Message-
> From: Ruben Kelevra 
> Sent: Friday, 11 May 2018 07:52
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] complete tagging of all 'right of way'-cases
> FOLLOWUP
> 
> Hey guys,
> 
> If the first one was TL;DR ... I start with working on this
> proposal to implement a give_way as a relation. This might be one
> of many to this topic and I'll follow up every different one when I
> start working on them.
> 
> 
> I thought some hours about this old proposal[1] and decided to
> update[2] it.
> 
> It now includes the ability to tag the
> * used sign (directly at the intersection)
> * road markings, like a curb or a dotted or solid line
> * main operational function of this intersection, like a traffic
> light.
> 
> The last one is necessary because we got intersection with stop and
> yield signs here, which are located at the traffic lights. So if
> the traffic lights are off (in the night or just non-operational)
> the signs located at the traffic lights are applied.
> 
> When the traffic lights are shut of every night, we can add that
> information to the node at the via tag, to disable the traffic
> light tag in those time periods for the routers. Then the give_way-
> or stop-relations come into action.
> 
> It now also includes lists of cases where it should be used and
> cases where it shouldn't. Explicitly changing the recommendation to
> NOT use it on roundabout & removing the example for it).
> 
> It's also recommending the simple solutions for a priority-to-the-
> right (not yet written) and the all-way_stop.
> 
> If the mapper wants to map more details, like the curbs, signs,
> hour_on/off or the class of vehicles where this applies, we have to
> go the relation way and create up to 4 relations to one
> intersection - I just don't see a simpler way with the same
> flexibility.
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way
> [2] https://bit.ly/2IrMh3g (just a shorted link to a diff)
> 
> As always: Feel free to fix logic and language issues in the
> proposal - I'm not a native speaker, there might be many.
> 
> I hope for more feedback on this from you, guys.
> 
> 
> Best regards
> 
> Ruben
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging