Re: [Tagging] Cycle boxes for two-stage left turns

[Jarek Piórkowski]

On Wed, 8 Jan 2020 at 08:03, marc marc  wrote:
> Le 08.01.20 à 05:10, Marc Gemis a écrit :
> > On Tue, Jan 7, 2020 at 10:30 PM marc marc  wrote:
> >> keep it simple !
> >> advanced stop box only use a cycleway=asl without relation
> >> https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl
> >> a single node is not enought ?
> >
> > The problem I see with this approach is that the node has to be placed
> > on the other street than the one the cyclist is using.
>
> I don't think so.
> we must do the same as for a traffic sign stop :
> add the node to the affected way with cycleway=tsb or any other value
> with the same meaning.

Thanks for the suggestion!

Looks like this should work for symbolic meaning (with some refinement
like cycleway:forward=tsb probably, and perhaps a fully spelled-out
value since the acronym is not really established). However it seems a
bit problematic geometrically: unlike with a stop sign where we can
place the node on where the OSM way crosses the stop line (or a very
short extension thereof), here the node needs to be a couple of meters
away from the actual box, and not really in a geometrically meaningful
position. As far as I can tell the tag cannot be on the intersection
node itself as I can't see a way to reliably indicate which of the
crossing ways has a turn box. See example at
https://bin.piorkowski.ca/2020/osm_cycleway_tsb_on_node.png (note is
only explanatory here)

Routers would then have to look for a cycleway=tsb node shortly before
a possible left turn. Would this be preferable from an algorithm's
point of view to looking for a relation?

Thanks!
--Jarek

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

Re: [Tagging] Cycle boxes for two-stage left turns

[Jarek Piórkowski]

On Wed, 8 Jan 2020 at 10:00, Paul Johnson  wrote:
> On Mon, Dec 16, 2019 at 7:06 PM Jarek Piórkowski 
wrote:
>> I'm looking for a way to tag designated areas where cyclists wait to
>> safely make a far turn (in right-hand-drive regions, a left turn).
>> I'll call them "left turn boxes" for short though pointers to a better
>> name would be welcome!
>> Since it's basically a short, mode-restricted turn lane, why not tag it
as such?  turn:lanes=whatever|left, access:lanes=whatever|no,
bicycle:lanes=whatever|designated?

This seems like it should work. I was a little wary at first, since wiki
for Key:lanes states "Count excludes cycle lanes. For tagging cycle lanes
see cycleway=*. "

However the example in
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
seems fitting, and the following seems to be liked well enough by JOSM
validator: https://bin.piorkowski.ca/2020/osm_bicycle_lanes_on_way.png

access:lanes:forward=||no
bicycle:lanes:forward=||designated
cycleway:lanes:forward=none|none|lane
cycleway=lane
turn:lanes:forward=left|none|left

Trying to go further and indicate also the through-going (painted) bicycle
lane (as done in the wiki example linked above) I arrive at:
https://bin.piorkowski.ca/2020/osm_bicycle_lanes_on_way_with_cycle_lane.png

access:lanes:forward=||no|no
bicycle:lanes:forward=||designated|designated
cycleway:lanes:forward=none|none|lane|lane
cycleway=lane (redundant?)
lanes:bicycle:forward=2
turn:lanes:forward=left|none|none|left

That seems to describe the logic of the way fully. However that is quite a
lot of tags and seems easy to get it wrong. JOSM will warn in case of
mismatch, but it's not exactly straightforward... hm...

Thanks!
--Jarek
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jarek Piórkowski]

On Wed, 8 Jan 2020 at 16:33, Mateusz Konieczny  wrote:
> Although unusual, oneway on pedestrian highways (path, footway, track) is
> possible in some places.
>
> Cases of oneway pedestrian traffic includes some hiking trails, border 
> crossing,
> exit-only passages and more.
>
> How to tag this?

Would just like to note that oneway=yes is established on
highway=steps (usually with conveying=yes, i.e., an escalator) to the
point where a major data consumer openstreetmap-carto supports it,
e.g. https://www.openstreetmap.org/way/367618960

Arguably escalators are a special case since unlike most footways
there is a mechanical component to them. However I would still be
interested in seeing any tagging for footways maintain at least some
consistency with it.

If this is hugely problematic for data consumers I would not be
opposed to tagging like highway=footway + foot:backward=no, with
oneway=yes allowed as optional for human readability.

--Jarek

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

Re: [Tagging] surface=block_paved, or surface=paved + paving=block

[Fernando Trebien]

From the key:surface article:

- surface=paved: "This value gives only a rough description; use a
more precise value if possible."
- surface=paving_stones: "A relatively smooth surface paved with
artificial blocks (block pavers, bricks) or natural stones
(flagstones), with a flat top. The gaps between individual paving
stones are very narrow, either because the stones have a perfectly
regular shape (rectangular, or any surface-filling shape) or because
they have been carefully selected, fitted and placed in order to form
an even, closed surface."

The picture [1] fits the description for surface=paving_stones, and
I've been told that the description fits current mapping practices.
[2] So the question is whether the mapping terminology fits the common
language and whether this would be a good reason to change the tagging
scheme. Language is a problem for other values as well, such as
surface=cobblestone. Since surface=* is, in principle, an open set, it
may be interesting asking if it is worth distinguishing the three
subtypes (block pavers, bricks, and flagstones) for data consumers
(routing, rendering, etc.). I don't see when the distinction would be
really important, and in fact many of the values in current use are
not yet supported by the oldest data consumers.

There seems to be almost no usage of paving=*, [3] I'm not sure this
would be ideal.

[1] https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
[2] https://forum.openstreetmap.org/viewtopic.php?id=61042|
[3] https://taginfo.openstreetmap.org/keys/paving#value

On Wed, Jan 8, 2020 at 7:37 PM Mateusz Konieczny
 wrote:
>
> Is following picture
> https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> depicting construction of surface=paving_stones?
>
> Or is it incorrect to tag in this way and
> surface=block_paved, or surface=paved + paving=block
> should be considered as preferable?
>
> Posted to look for more feedback in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> discussion.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
Fernando Trebien

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

Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

[François Lacombe]

Hi all,

This proposal is still in RFC and may be voted in a couple of weeks as
evaluation shown no issue so far, at least on transmission power lines.
line_management tag is used carefully for testing.
Read more : https://www.openstreetmap.org/user/InfosReseaux/diary/391058

Nevertheless it's an opportunity to review the branch:type tag replacement
with line_management=*

i'm still looking for an appropriate illustration for two values examples:
* line_management=cross (two or more lines with different directions
sharing the same support without connecting)
* line_management=loop (two or more lines coming from the same direction
are connected as to mock some of them)

Feel free to propose and complete if you find corresponding situations on
ground

Thanks in advance

François

Le sam. 26 oct. 2019 à 20:59, François Lacombe 
a écrit :

> Hi all,
>
> After the review of line_attachment key this summer and Karlsruhe
> hackweekend at Geofabrik headquarters last week, let me introduce the
> second stage of tower:type key cleaning project for power lines. Great time
> has been spent on discussing and finding relevant situations.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management
>
> It's now about the arrangement of power lines around their supports: how
> the lines branch, split, transpose or terminate.
> As current tagging (without line_management) still collides with any tower
> building function, the line_management key may be a solution to strip
> unrelated values from tower:type.
>
> I've published a diary entry to give more explanations
> https://www.openstreetmap.org/user/InfosReseaux/diary/391058
>
> I'd draw your attention to the conclusion :
> "Mapping utility supports like power towers or telecom poles is a
> worldwide challenge. For instance in France, professionals including
> operators and contractors rolling out overhead telecom cables are currently
> looking for approx. 16 millions missing shared power poles that weren’t
> mapped in operational GIS. There’s no doubt updating OSM can help."
> There's no short term risk of importing massive data, at least.
>
> This proposal is a first try and may cause worries about some local
> concerns. RFC is here to solve this prior to vote anything.
> We have to focus on simple situations to begin with to adopt the right
> semantic. More complex cases will be added step by step.
> Feel free to open a topic in Talk page.
>
> All the best
>
> François
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[Volker Schmidt]

It is not unusual to have one parking area with one name with dedicated
areas for different vehicle categories. I cannot use amenity=parking for
both the entire parking area and the vehicle-type-specific "sub"-areas, at
least JOSM does complain when you do that. We could ignore that and use
nested amenity=parking tags.

.


On Wed, 8 Jan 2020, 15:52 John Willis via Tagging, <
tagging@openstreetmap.org> wrote:

> If I have a sign that says all cars go here, and all HGV goes over there,
> and one is painted for 1000 car spots and one has 50 giant bus spots, those
> are designated lots.
>
> I have used parking_space when I have found A lone disabled space - but a
> group of 50 spots for busses is a bus lot.
>
> At least being able to say “this is the lot for busses” as an attribute of
> amenity=parking should be doable (with a subtag).
>
> Javbw
>
> On Jan 8, 2020, at 7:18 PM, Volker Schmidt  wrote:
>
> make use of the fact that amenity=parking_space
>  can be
> used for this.
> Make separate parking space areas for different vehicle types.
>
> ___
> 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] surface=block_paved, or surface=paved + paving=block

[Paul Allen]

On Wed, 8 Jan 2020 at 23:06, marc marc  wrote:

> why it isn't a paving_stones ? the max height ?
>

Shape and size.

https://en.wikipedia.org/wiki/Brick#Optimal_dimensions,_characteristics,_and_strength

I ask myself how and how many mappers 'll see a diff.
>

Any who have ever laid bricks, or handled bricks, or seen bricks.  Maybe.

Oh, and those who happened to watch a YouTube video about the history of
bricks, :)

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

Re: [Tagging] surface=block_paved, or surface=paved + paving=block

[marc marc]

why it isn't a paving_stones ? the max height ?
I ask myself how and how many mappers 'll see a diff.

Le 08.01.20 à 22:36, Mateusz Konieczny a écrit :
> Is following picture
> https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> depicting construction of surface=paving_stones?
> 
> Or is it incorrect to tag in this way and
> surface=block_paved, or surface=paved + paving=block
> should be considered as preferable?
> 
> Posted to look for more feedback in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> discussion.
> 
> 
> ___
> 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] surface=block_paved, or surface=paved + paving=block

[Philip Barnes]

On Thu, 2020-01-09 at 07:15 +0900, Joseph Eisenberg wrote:
> The picture shows clay bricks being laid as paving for a service
> road, in a herringbone pattern.
> 
> Perhaps this should be surface=brick/bricks? Both are used a few
> thousand times.
> 
That is definitely block paving, not bricks. Not 100% sure what the tag
is.
Phil (trigpoint)


> - Joseph Eisenberg
> 
> On Thu, Jan 9, 2020 at 6:37 AM Mateusz Konieczny <
> matkoni...@tutanota.com> wrote:
> >   
> > 
> >   
> >   
> > Is following picture
> > https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> > depicting construction of surface=paving_stones?
> > 
> > Or is it incorrect to tag in this way and 
> > surface=block_paved, or surface=paved + paving=block
> > should be considered as preferable?
> > 
> > Posted to look for more feedback in
> > https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> > discussion.
> > 
> >   
> > 
> > ___
> > 
> > Tagging mailing list
> > 
> > Tagging@openstreetmap.org
> > 
> > https://lists.openstreetmap.org/listinfo/tagging
> > 
> 
> ___Tagging mailing 
> listtagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=block_paved, or surface=paved + paving=block

[Joseph Eisenberg]

The picture shows clay bricks being laid as paving for a service road, in a
herringbone pattern.

Perhaps this should be surface=brick/bricks? Both are used a few thousand
times.

- Joseph Eisenberg

On Thu, Jan 9, 2020 at 6:37 AM Mateusz Konieczny 
wrote:

> Is following picture
> https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> depicting construction of surface=paving_stones?
>
> Or is it incorrect to tag in this way and
> surface=block_paved, or surface=paved + paving=block
> should be considered as preferable?
>
> Posted to look for more feedback in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> discussion.
>
> ___
> 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] How to tag oneway restriction applying to pedestrians?

[Martin Koppenhoefer]

Am Mi., 8. Jan. 2020 um 22:35 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> But sometimes it is used on paths and footways to indicate that such way is
> oneway for pedestrians (especially in cases where only pedestrians are
> allowed)
> to use it.
>


I'd put it like this: "with the intention to indicate that such way is
oneway for pedestrians", because oneway can not apply to pedestrians, they
are excluded by the general definition, and if we changed it, we would
break a lot more than those few exceptions of actual oneway for pedestrians.




> There is oneway:foot=yes but it is considered as problematic because
> "According to how conditional restriction syntax works, adding a mode of
> transport such as :foot only ever limits who the tag applies to, it
> doesn't
> normally add someone it applies to."
> ( https://wiki.openstreetmap.org/wiki/Talk:Key:oneway#Pedestrian_oneways
> and
> https://wiki.openstreetmap.org/wiki/Talk:Key:oneway:foot )
>
> Personally I consider oneway:bicycle=yes or oneway:foot=yes
> as not problematic in any way, I want to check whatever I am alone in this.
>


it would be introducing another exception, for no good reason, there is
already foot:backward=no with the same intended meaning and without the
problem, as unlike oneway:foot it is consistent with the well introduced
concept of nested tagging.

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

[Tagging] surface=block_paved, or surface=paved + paving=block

[Mateusz Konieczny]

Is following picture
https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
depicting construction of surface=paving_stones?

Or is it incorrect to tag in this way and 
surface=block_paved, or surface=paved + paving=block
should be considered as preferable?

Posted to look for more feedback in
https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
discussion.

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

[Tagging] How to tag oneway restriction applying to pedestrians?

[Mateusz Konieczny]

Although unusual, oneway on pedestrian highways (path, footway, track) is
possible in some places.

Cases of oneway pedestrian traffic includes some hiking trails, border crossing,
exit-only passages and more.

How to tag this?

oneway=yes is currently described on OSM Wiki as applying only to vehicles
- see https://wiki.openstreetmap.org/wiki/Key:oneway
Also, it is sometimes used on ways such as 
highway=footway + bicycle=yes + oneway=yes to indicate that
such way is oneway for cyclists.

But sometimes it is used on paths and footways to indicate that such way is
oneway for pedestrians (especially in cases where only pedestrians are allowed)
to use it.

There is oneway:foot=yes but it is considered as problematic because
"According to how conditional restriction syntax works, adding a mode of 
transport such as :foot only ever limits who the tag applies to, it doesn't 
normally add someone it applies to."
( https://wiki.openstreetmap.org/wiki/Talk:Key:oneway#Pedestrian_oneways 
and
https://wiki.openstreetmap.org/wiki/Talk:Key:oneway:foot )

Personally I consider oneway:bicycle=yes or oneway:foot=yes
as not problematic in any way, I want to check whatever I am alone in this.

foot:backward=no was proposed as superior solution to oneway:foot=yes
but personally I really dislike this.

This is posted as there is some ongoing discussion on Wiki and I am interested 
in
experience/opinions of more people.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] recreational vs functional routes

[Paul Johnson]

On Tue, Jan 7, 2020 at 1:23 PM joost schouppe 
wrote:

> Especially for car routes, I haven't seen any way to tag touristic routes
> for driving cars, like the Turist Veger in Norway or the Route des Cols in
> France. It is also of specific interest for cycling. For example, in
> Belgium we have a very dense "node network" for cycling for fun, but those
> routes aren't exactly interesting for commuting. On the other hand, we have
> "cycle highways" which can be boring and focus on actually getting
> somewhere.
>

Sounds like a job for route relations.  Also a good reason why moving route
refs off ways and make them exclusively relation-based is a good idea we
really need to strongly consider.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Cycle boxes for two-stage left turns

[Paul Johnson]

On Mon, Dec 16, 2019 at 7:06 PM Jarek Piórkowski 
wrote:

> Hello,
>
> I'm looking for a way to tag designated areas where cyclists wait to
> safely make a far turn (in right-hand-drive regions, a left turn).
> I'll call them "left turn boxes" for short though pointers to a better
> name would be welcome!
>

Since it's basically a short, mode-restricted turn lane, why not tag it as
such?  turn:lanes=whatever|left, access:lanes=whatever|no,
bicycle:lanes=whatever|designated?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

If I have a sign that says all cars go here, and all HGV goes over there, and 
one is painted for 1000 car spots and one has 50 giant bus spots, those are 
designated lots. 

I have used parking_space when I have found A lone disabled space - but a group 
of 50 spots for busses is a bus lot. 

At least being able to say “this is the lot for busses” as an attribute of 
amenity=parking should be doable (with a subtag). 

Javbw

> On Jan 8, 2020, at 7:18 PM, Volker Schmidt  wrote:
> 
> make use of the fact that amenity=parking_space can be used for this.
> Make separate parking space areas for different vehicle types.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

> On Jan 7, 2020, at 3:37 AM, Martin Koppenhoefer  
> wrote:
> 
> For a municipal tourist bus parking, who is "customers" referring to? 
> Customers of what?

Tollway service area  lots inside the toll area are “customers” of nexco, the 
operators. There are “permissive” lots outside the toll area at service areas 
as well for anyone to access the services (locals going to the shops there, for 
example), but the lots inside the toll are considered access=customers. 

The “road station” network on the regular trunk roads are “permissive” as 
anyone can drive up and use it whenever. 

Sorry if O am using [vehecle]=designated incorrectly, but it seems to fit for 
busses. 

But all the lots are just parking lots, and the ones designed for busses or 
other HGV should be tagged, and instead of making a whole new amenity, I think 
a subtag is a  better solution. 

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

Re: [Tagging] Cycle boxes for two-stage left turns

[marc marc]

Le 08.01.20 à 05:10, Marc Gemis a écrit :
> On Tue, Jan 7, 2020 at 10:30 PM marc marc  wrote:
>>
>> Le 06.01.20 à 04:19, Jarek Piórkowski a écrit :
>>> Comments most welcome!
>>
>> keep it simple !
>> advanced stop box only use a cycleway=asl without relation
>> https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl
>> a single node is not enought ?
> 
> The problem I see with this approach is that the node has to be placed
> on the other street than the one the cyclist is using.

I don't think so.
we must do the same as for a traffic sign stop :
add the node to the affected way with cycleway=tsb or any other value
with the same meaning.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[Andy Townsend]

On 08/01/2020 10:14, Volker Schmidt wrote:
What about going back to the wiki and make use of the fact that 
amenity=parking_space 
 can 
be used for this.
Make separate parking space areas for different vehicle types. Add 
parking entrances 
 
(at present restricted fto underground and multi-level car parks, but 
I acan see no reason ot to us ita lso for surface parking). Tie it 
together with a relation 
. 




... and if anyone wants to look at the usage of that around the world, 
try here:


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

(move the map to where you're interested in and hit "run").

Best Regards,

Andy


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

Re: [Tagging] amenity=tourist_bus_parking

[Volker Schmidt]

What about going back to the wiki and make use of the fact that
amenity=parking_space
 can be
used for this.
Make separate parking space areas for different vehicle types. Add parking
entrances
 (at
present restricted fto underground and multi-level car parks, but I acan
see no reason ot to us ita lso for surface parking). Tie it together with a
relation
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging