Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

For the smart (the white car), the same rules apply as if it was 
overtaking the parked cars, it may only pass once the other side is free.


The signs on the right say "no stopping", arrow to the left means "no 
stopping starts here", arrow to the right means "...and ends here". They 
are just there temporarily, there is some construction or something like 
that.


Maybe it is difficult to see in the perspective the photo was taken, but 
actually none of the parking cars is parking there illegaly. At the 
sections where stopping is forbidden, there are no parking cars.


Tobias

On 19/11/2020 23:22, Graeme Fitzpatrick wrote:




On Fri, 20 Nov 2020 at 00:22, Tobias Zwick > wrote:



https://westnordost.de/misc/2or1lanes.jpg


It is a residential road marked clearly for 2 lanes, so it seems
obvious
to tag it with lanes=2. But on the other hand, you'll notice that there
are parking cars on the right side that effectively render the right
lane unusable.


So what happens when somebody wants to drive the other way - & by the 
direction those parked cars are facing, they must?


Also, what do the signs mean above the parked cars - Red X & white 
left-pointing arrow on a blue background? Anything relevant to parking?


Thanks

Graeme


___
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] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

Okay, but the data consumer won't know how you reached that decision (to 
count it or not). So whoever attempts a visualization of the data will 
have no idea whether to put the parking lane next to the rest of the 
street or put it "on top" (see

https://westnordost.de/misc/parallel_parking_lane.png )

This is not only an issue with visualization, also routers will want to 
know if parking cars effectively reduce the usable width of the road by 
the width of a car, or not.


This is why I initially stated that I see the need to distinguish these 
cases.


On 19/11/2020 23:17, Andrew Harvey wrote:
The way I understood the tagging guidelines was that if there was nobody 
parked there, could you drive along the lane as usual. If you can't then 
I wouldn't include it as lanes=* and only tag it as parking:lane. If you 
can drive along it when vacant, but you can still legally park there 
then I'd include it as lanes=* and also tag parking:lane.


It's common that during peak hour the lane is used by traffic, but 
off-peak it's available for parking.


On Fri, 20 Nov 2020 at 01:22, Tobias Zwick > wrote:


Hello all

First of all, in the past, we have explored many edge cases for the
lanes-tag in various discussions and I am happy that for the most part,
it seems to be quite well defined by now. However, there is one edge
case which is not uncommon at all but still unclear or awkward to tag.
Look at this:

https://westnordost.de/misc/2or1lanes.jpg


It is a residential road marked clearly for 2 lanes, so it seems
obvious
to tag it with lanes=2. But on the other hand, you'll notice that there
are parking cars on the right side that effectively render the right
lane unusable. These parking cars would (currently) be tagged I
believe as

parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

  > And the following lanes should be excluded:
  > [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the
road has marked lanes, the number of marked lanes should be tagged, on
the other hand, there are these kind of "parking lanes" which do not
have their own space marked as a parking lane but simply absorb the
space assigned to normal car traffic. In OSM tagging, these are also
"parking:lane"s as far as I know.

We need to dissolve this ambiguity by defining a way how to distinguish
between these two cases:

https://westnordost.de/misc/parallel_parking_lane.png

(1) a dedicated parallel parking lane. This lane should not count as a
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant
for the lane count.

My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking
lane tagging out and about and its documentation could also state their
point of view here. According to the wiki edit history, looks like at
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.
What do you think?

There is also at least one data consumer I know about that is using
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet
 it would be good to know how
they interpret and visualize the data.

Cheers
Tobias

___
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] lanes - is "parking allowed" a parking lane?

[Graeme Fitzpatrick]

On Fri, 20 Nov 2020 at 00:22, Tobias Zwick  wrote:

>
> https://westnordost.de/misc/2or1lanes.jpg
>
> It is a residential road marked clearly for 2 lanes, so it seems obvious
> to tag it with lanes=2. But on the other hand, you'll notice that there
> are parking cars on the right side that effectively render the right
> lane unusable.


So what happens when somebody wants to drive the other way - & by the
direction those parked cars are facing, they must?

Also, what do the signs mean above the parked cars - Red X & white
left-pointing arrow on a blue background? Anything relevant to parking?

Thanks

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

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Andrew Harvey]

The way I understood the tagging guidelines was that if there was nobody
parked there, could you drive along the lane as usual. If you can't then I
wouldn't include it as lanes=* and only tag it as parking:lane. If you can
drive along it when vacant, but you can still legally park there then I'd
include it as lanes=* and also tag parking:lane.

It's common that during peak hour the lane is used by traffic, but off-peak
it's available for parking.

On Fri, 20 Nov 2020 at 01:22, Tobias Zwick  wrote:

> Hello all
>
> First of all, in the past, we have explored many edge cases for the
> lanes-tag in various discussions and I am happy that for the most part,
> it seems to be quite well defined by now. However, there is one edge
> case which is not uncommon at all but still unclear or awkward to tag.
> Look at this:
>
> https://westnordost.de/misc/2or1lanes.jpg
>
> It is a residential road marked clearly for 2 lanes, so it seems obvious
> to tag it with lanes=2. But on the other hand, you'll notice that there
> are parking cars on the right side that effectively render the right
> lane unusable. These parking cars would (currently) be tagged I believe as
>
> parking:lane:right=parallel
> parking:lane:right:parallel=on_street
>
> And the wiki states
>
>  > And the following lanes should be excluded:
>  > [...] Parking lanes [...]
>
> So here is an ambiguity in the documentation. On the one hand, if the
> road has marked lanes, the number of marked lanes should be tagged, on
> the other hand, there are these kind of "parking lanes" which do not
> have their own space marked as a parking lane but simply absorb the
> space assigned to normal car traffic. In OSM tagging, these are also
> "parking:lane"s as far as I know.
>
> We need to dissolve this ambiguity by defining a way how to distinguish
> between these two cases:
>
> https://westnordost.de/misc/parallel_parking_lane.png
> (1) a dedicated parallel parking lane. This lane should not count as a
> lane in the lanes-tag.
> (2) (parallel) parking is allowed (and used). This should be irrelevant
> for the lane count.
>
> My suggestion would be
> (1) parking:lane:*:parallel = lane
> (2) parking:lane:*:parallel = on_street
>
> Maybe especially those who recently involved themselves with parking
> lane tagging out and about and its documentation could also state their
> point of view here. According to the wiki edit history, looks like at
> least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.
> What do you think?
>
> There is also at least one data consumer I know about that is using
> parking lane information and displays it visually,
> https://github.com/dabreegster/abstreet it would be good to know how
> they interpret and visualize the data.
>
> Cheers
> Tobias
>
> ___
> 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] Feature Proposal - Voting - Pumping proposal

[François Lacombe]

Hi all

Tonight I'm pleased to announce the start of voting for the tagging
proposal about pumps
https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal

A lot of comments lead us to an interesting tagging for pumps devices,
water wells and wind pumps. Thank you to anyone involved in this review.
Some values are proposed to be deprecated as to classify pumps according to
their technologies and capabilities.

Several contributors tested the proposed tags in real conditions and no
problem seems to remain.

Feel free to give your opinion until December 3

All the best

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

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Minh Nguyen]

Vào lúc 06:17 2020-11-19, Tobias Zwick đã viết:

Hello all

First of all, in the past, we have explored many edge cases for the 
lanes-tag in various discussions and I am happy that for the most part, 
it seems to be quite well defined by now. However, there is one edge 
case which is not uncommon at all but still unclear or awkward to tag. 
Look at this:


https://westnordost.de/misc/2or1lanes.jpg

It is a residential road marked clearly for 2 lanes, so it seems obvious 
to tag it with lanes=2. But on the other hand, you'll notice that there 
are parking cars on the right side that effectively render the right 
lane unusable. These parking cars would (currently) be tagged I believe as


parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

 > And the following lanes should be excluded:
 > [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the 
road has marked lanes, the number of marked lanes should be tagged, on 
the other hand, there are these kind of "parking lanes" which do not 
have their own space marked as a parking lane but simply absorb the 
space assigned to normal car traffic. In OSM tagging, these are also 
"parking:lane"s as far as I know.


We need to dissolve this ambiguity by defining a way how to distinguish 
between these two cases:


https://westnordost.de/misc/parallel_parking_lane.png
(1) a dedicated parallel parking lane. This lane should not count as a 
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant 
for the lane count.


My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking 
lane tagging out and about and its documentation could also state their 
point of view here. According to the wiki edit history, looks like at 
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.

What do you think?

There is also at least one data consumer I know about that is using 
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet it would be good to know how 
they interpret and visualize the data.


I'm not intimately familiar with the highway engineering standards and 
driving rules in Vienna Convention countries, but I wonder if case (2) 
is (literally) an edge case where we can tag it as a parking lane but 
not count it separately in lanes=*. After all, the roadway doesn't have 
any purpose-built infrastructure for parking, even if that's what people 
are doing.


For high-resolution renderers, maybe we need some variation on 
lane_markings=* to indicate that the parking lane specifically is 
unmarked. Or maybe a way to explicitly indicate that two lanes overlap. 
There are other cases of overlapping lanes, like turning movements that 
overlap with bike lanes [1] and often require turning vehicles to sneak 
around vehicles going straight. [2]


[1] 
https://nacto.org/publication/urban-bikeway-design-guide/intersection-treatments/combined-bike-laneturn-lane/
[2] 
https://www.latimes.com/archives/la-xpm-2003-may-27-me-wheel27-story.html "You 
can drive side by side for a mile in the same lane, as long as it’s 
large enough."


--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Alex]

I'm not sure if your first case
(https://westnordost.de/misc/2or1lanes.jpg) should be mapped as parallel
parking at all or if it's illegal parking and should actually be
no_parking or no_stopping (maybe depends on the local legislation or
permanence of the situation)? I recently discussed a similar case with
another mapper: Here it was about de facto parallel parking in a
living_street outside of designated parking areas, which is illegal at
least according to the traffic regulations in force here (which is even
indicated by a sign at this street!). See this picture:
https://www.mapillary.com/map/im/0kZ-LZX4-J36J5xov_UBvw

In this situation I argued for "map what is on the ground" and for
mapping the situation as de facto parallel parking (the cars have been
parked there for years, as can be seen on aerial photographs). My
counterpart was against this. In the meantime, the situation has been
resolved by the fact that the public order office has distributed
parking tickets several times and the street is no longer permanently,
but only sporadically, parked :)

But I am not sure whether there is a basic consensus on how to deal with
contradictions between de facto and de jure situations like this in OSM?
In my opinion, this should be clarified at first.

I am currently also working on parking lane analyses (see
https://wiki.openstreetmap.org/wiki/User:Supaplex030/Parkplatzanalyse_Neuk%C3%B6lln,
sry for german language at present) and therefor differentiate between
(1) on_street, (2) half_on_street and (3)
on_kerb/shoulder/lay_by/street_side parking (for street side parking see
the current proposal under vote:
https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side).

I think a distinction between "on_street" and "lane", as you suggested,
is unnecessary or too error-prone. Already when differentiating between
on_street (= lane) and street_side parking I noticed that these cases
are sometimes difficult to distinguish, especially when there are kerb
extensions. Wouldn't it be better to simply distinguish between marked
and unmarked parallel parking lanes and work with width:* values
(https://wiki.openstreetmap.org/wiki/Key:width#Width_of_streets) instead
of lane information?

Cheers,
Alex / Supaplex030


Am 19.11.20 um 15:17 schrieb Tobias Zwick:
> Hello all
>
> First of all, in the past, we have explored many edge cases for the
> lanes-tag in various discussions and I am happy that for the most
> part, it seems to be quite well defined by now. However, there is one
> edge case which is not uncommon at all but still unclear or awkward to
> tag. Look at this:
>
> https://westnordost.de/misc/2or1lanes.jpg
>
> It is a residential road marked clearly for 2 lanes, so it seems
> obvious to tag it with lanes=2. But on the other hand, you'll notice
> that there are parking cars on the right side that effectively render
> the right lane unusable. These parking cars would (currently) be
> tagged I believe as
>
> parking:lane:right=parallel
> parking:lane:right:parallel=on_street
>
> And the wiki states
>
> > And the following lanes should be excluded:
> > [...] Parking lanes [...]
>
> So here is an ambiguity in the documentation. On the one hand, if the
> road has marked lanes, the number of marked lanes should be tagged, on
> the other hand, there are these kind of "parking lanes" which do not
> have their own space marked as a parking lane but simply absorb the
> space assigned to normal car traffic. In OSM tagging, these are also
> "parking:lane"s as far as I know.
>
> We need to dissolve this ambiguity by defining a way how to
> distinguish between these two cases:
>
> https://westnordost.de/misc/parallel_parking_lane.png
> (1) a dedicated parallel parking lane. This lane should not count as a
> lane in the lanes-tag.
> (2) (parallel) parking is allowed (and used). This should be
> irrelevant for the lane count.
>
> My suggestion would be
> (1) parking:lane:*:parallel = lane
> (2) parking:lane:*:parallel = on_street
>
> Maybe especially those who recently involved themselves with parking
> lane tagging out and about and its documentation could also state
> their point of view here. According to the wiki edit history, looks
> like at least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.
> What do you think?
>
> There is also at least one data consumer I know about that is using
> parking lane information and displays it visually,
> https://github.com/dabreegster/abstreet it would be good to know how
> they interpret and visualize the data.
>
> Cheers
> Tobias
>
> ___
> 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] coastline v. water

[Eric H. Christensen via Tagging]

‐‐‐ Original Message ‐‐‐

On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano 
 wrote:

> This was fascinating reading.  I do agree that we ought to have a definition 
> for what gets tagged natural=coastline, and I think it's fine if that 
> definition has some subjectivity.
>
> I would offer something as simple as:
>
> "The coastline should follow the mean high tide line.  In some cases this 
> rule would result in the coastline extending an unreasonable distance along 
> the banks of tidal rivers.  In those cases, mappers should identify a 
> reasonable choke point at which to terminate the inland extent of coastline 
> tagging."

I would just classify it as "where the ocean meets the land".  Any other water 
that isn't ocean should be mapped as water and tagged appropriately.  That 
makes the map more accurate and detailed.

R,
Eric

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

Re: [Tagging] coastline v. water

[Eric H. Christensen via Tagging]

‐‐‐ Original Message ‐‐‐

On Wednesday, November 18th, 2020 at 5:04 PM, Christoph Hormann 
 wrote:

> > Eric H. Christensen via Tagging tagging@openstreetmap.org hat am 18.11.2020 
> > 21:19 geschrieben:
>
> > [...]
>
> First: the matter has been discussed at length previously so i would advise 
> anyone who wants to form an opinion on the matter to read up on past 
> discussion where essentially everything relevant has been said already. Most 
> relevant links:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-July/054405.html
>
> and resulting discussion:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-August/thread.html#54434
>
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

Whew, after reading all of those messages, my take-away is that it's mostly 
what the locals see the water as.

> Third:
>
> While this is ultimately not relevant because the delineation of tags in OSM 
> should be based on verifiable criteria obviously i have never seen any map 
> that displays ocean water and inland waterbodies in differentiated form that 
> shows the Chesapeake Bay as inland water.
>
> Classical examples with differentiated rendering are TPC/ONC (caution: links 
> go to large images):

Pilot maps don't usually have lines deliniating sections of water.  Marine 
charts do, however.

R,
Eric

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

[Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

Hello all

First of all, in the past, we have explored many edge cases for the 
lanes-tag in various discussions and I am happy that for the most part, 
it seems to be quite well defined by now. However, there is one edge 
case which is not uncommon at all but still unclear or awkward to tag. 
Look at this:


https://westnordost.de/misc/2or1lanes.jpg

It is a residential road marked clearly for 2 lanes, so it seems obvious 
to tag it with lanes=2. But on the other hand, you'll notice that there 
are parking cars on the right side that effectively render the right 
lane unusable. These parking cars would (currently) be tagged I believe as


parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

> And the following lanes should be excluded:
> [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the 
road has marked lanes, the number of marked lanes should be tagged, on 
the other hand, there are these kind of "parking lanes" which do not 
have their own space marked as a parking lane but simply absorb the 
space assigned to normal car traffic. In OSM tagging, these are also 
"parking:lane"s as far as I know.


We need to dissolve this ambiguity by defining a way how to distinguish 
between these two cases:


https://westnordost.de/misc/parallel_parking_lane.png
(1) a dedicated parallel parking lane. This lane should not count as a 
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant 
for the lane count.


My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking 
lane tagging out and about and its documentation could also state their 
point of view here. According to the wiki edit history, looks like at 
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.

What do you think?

There is also at least one data consumer I know about that is using 
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet it would be good to know how 
they interpret and visualize the data.


Cheers
Tobias

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

Re: [Tagging] power lines/cables power

[François Lacombe]

Hi André

It's great to have such a discussion here as to move forward on power
routing.
Answers below

Le mer. 18 nov. 2020 à 02:38, André Pirard  a
écrit :

>
> Haille François,
>
> Merci pour ta réponse.
> So, I was told that 7,5 GW rating by an ALEGrO engineer but I didn't see
> it on OSM. He didn't mention 1 GW.
>

7.5 GW is really huge for a single system.
This : https://www.amprion.net/Grid-expansion/Our-Projects/ALEGrO/ states
1000 MW only.


> So I looked all over the wiki.
> Passing an accepted proposal that should say that it is overridden by
> another one, typical wiki, I saw no mention of power rating except for
> generators. And that cable has dead ends.
>
Rating was proposed for power transformers
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal
https://wiki.openstreetmap.org/wiki/Tag:power%3Dtransformer#Tagging
Generators got an output value with generator:output:electricity

Which proposal is overridden please?

And in the proposal you show, I see no mention of power rating either, esp.
> in the relation.
>
That's right, the proposal introduces a new relation formalism to put
properties on power systems (ALEGrO is a power system, composed of a line
and other components)
We will be able to add ratings, like frequency or operating voltage on that
system.


> A typical OSM browser needs to be an expert already to know how to look at
> tags and do so.
> Let alone guessing that what he does not find could be in a relation.
>
We're not responsible for world complexity and we need reliable models to
describe what actually exists.
Editors, tools, render, documentation are here to help to do so.
i.e. that's counterproductive to make things more intuitive than they
actually are for sake of edition ease.

Furthermore, I don't see at all how a relation could indicate the
> operational *power ratings of branches*.
>
It can't indeed.
It's the same as voltage: some branches could be designed up to 400 kV but
the whole system will be operating at 220 kV
So power lines branches will get voltage=40 and the system relation
will get voltage=22
Is this difference clearer?
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Power_routing_proposal#Splitting_logical_from_physical_infrastructure

Puting system rating on physical route is the same as marking public
transport buses capacity on osm highway ways
We actually have public transport relations for that


> All in all, I continue to believe that a cable or line should indicate
> their power ratings.
>
Yes, but that's not what we discuss about here since ALEGrO is a power
system
Public documentation will give the system rating, not the cable design in
detail (I think but change my mind)

power:maximum=7.5 GW
> power:used=1 GW
>

That's a nice try thank you
Those values should be on two separate osm features according to what we
intend to do regarding power systems
I have doubts on the sense of "used": used values change every second.
Don't we deal with operated value instead?


> Quite self-describing and friendly.
> Please discuss this matter and warn me of any change.
>

Power routing proposal is still in RFC and its author is waiting for API
0.7 to start voting.
It's a pity since this topic deserve a clear and reliable tagging to
provide a better understanding to everyone
Our discussion (and many before and certainly many in the future) help to
refine wording and improve docs and explanations

All the best

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