Street parking scheme, not comprehensive enough, needs :[position]:

General talk Tagging general discussion
1

Parking tagging on a road way.
Needs :[position]:

I posted this also on the talk page

====
There is no explanation/replacement in the Streetparking for the deprecated parking:lane, we used parking:lane:both=no_parking, in the key there must be, the carriageway, lane, this should be possible: parking:lane:both:restriction=no_parking, now with extra :restriction, 1 string to do the job.

How to tag this in the new method? When there is a other parking possibility.

By EU law the sign Nederlands_verkeersbord_E1.svg gives a prohibition only on the lane, carriageway, no_parking, beside the lane there could be al kinds of rules in force for parking on parking:shoulder= parking:streetside=. this lane must be expressed in the key and in the right order. So I think parking:lane could not be deprecated.

Additional example:
At the same way there could be:
a onesided E1 Nederlands_verkeersbord_E1.svg lane prohibition
over the whole way:
parking:right=lane + parking:right:restriction=no_parking
and also on parts of the way
parking:right=streetside + parking:right:orientation=parallel

we can only use once, parking:right=[position].

Also parking:right:orientation=parallel refers to the carriageway, lane, this is not right.
That is the problem, so there must be :[position]: in the key.
In the old, parking:lane and parking:streetside where active, with new scheme, there should be parking:side:position:=, parking:side:position:orientation=, if you only want to keep parking:side.

====

So I am forced to still use the old scheme parking:lane:left=no_parking to express a onesided sign on that side of the carriageway, where there is streetside parking.

image a left sided example

afbeelding
afbeelding1015Ă—477 71.2 KB

2

Allowing street-side parking automatically forbids on-lane parking and vice versa, because you would be blocking the cars. If you have an exotic case where this was possible, I’d advise for going with separately mapped amenity=parking areas to get maximum precision, but I have yet to see this being allowed.

By the way: I raised a similar problem some time ago: what does parking:<side>=separate imply? No parking or no stopping for all other regions? I don’t think we can solve 100% of the use cases yet, but it’s already pretty darn close.

3

The picture tells that right parking on street is OK i.e. [parking:right=lane] (assuming the way was drawn bottom to top)(parking:right=lane | Tags | OpenStreetMap Taginfo) per the new schema, and left I’d recommend mapping the parking area, add the parking=street_side tag (for routability) and orientation=perpendicular. Maybe parking:left:restriction=no_parking per the sign.

4

parking:left=street_side + parking:left:orientation=perpendicular should suffice, because it implies that parking on the street is forbidden. But of course you can always map it separately.

5

And this is not possible in the new scheme. Because off, parking:left=lane;streetside is not possible.

We must tag as directly as posible, the traffic sign E1 Nederlands_verkeersbord_E1.svg for beter understanding. Not with if, if, if. We do not have to tag it on that part. To much to think about, keep it straight the whole carriageway get that tag, because the Nederlands_verkeersbord_E1.svg said so.

As for the image
The whole road should get parking:left=lane parking parking:left:restriction=no_parking, new scheme.
Now we have two tag lines, this could be possible with one k/v, for beter understanding en control. If :[position]: was taking as a keypart in the scheme, it would all be much easier.

It is easier to control 2 lines, then 4.

6

Actually Osmose, yes Osmose, is wholly content with just the restriction line for left. Why say there is and then say there isn’t?

7

I’m sorry, I’m having problems understanding youre answer.

Where in your picture can you park on the lane and on the street side? parking:left=street_side already implies that parking on the lane is forbidden, the sign wouldn’t be necessary.

But if you want to, you can tag the whole road parking:left=no + parking:left:restriction=no_parking and add separate amenity=parking + parking=street_side areas.

I think you’re misunderstanding the tagging schema. parking:left=lane means that you are allowed to park on the lane. Adding parking:left:restriction=no_parking is only for when you have parking:left=no and want to be more specific.

1 Like
8

To be precise, parking:left=lane only means that there is a physical parking lane on the left side. There are many reasons why parking might be restricted or prohibited within that physical lane, which subkeys can deal with. This article explains the distinction between physical characteristics and regulations. When there are multiple parallel forms of parking infrastructure, each with different regulations, the most straightforward approach would be to map one or more of them as separate areas.

2 Likes
9

Given I’d map the street_side parkings separately as amenities I’d be on revisit inclined toward parking:left=separate + parking:left:restriction=no_parking, even parking:left=separate as single entry would tell there’s no parking on the left lane itself but the added restriction makes it unequivocal.

10

I do not understand, what you mean?

11

afbeelding
afbeelding992Ă—454 65.9 KB

In front of streetside, left, what rule is their, that you can not park there?

Double parking is not allowed by law. (Drivers must not double park their vehicles.)
When there is no one parking on the streetside left. And then?
It is maybe not usual or unfriendly, but forbidden?
Here it is because of E1.

I just want to give the whole left side of the carriageway :restriction=no_parking.

These are two different methods of taggen, amenity is topographic and on the way is parking access routing.
Two methods functioning side by side.
Do not give this as a solution. It isn’t.

12

I still don’t think I understand what you mean, and I know it’s just a language problem. After all, we’re both not native speakers. Also, I don’t know about your local legislation, so maybe I’m just ignoring something that’s obvious to you, but not to me, or vice versa.

  1. You want to know how tag that you are forbidden to park on-lane on the left side, but are allowed to park street-side?
  2. You want to know how to tag that you are forbidden to park on the lane of the left side, but not forbidden to stop.
  3. You want to know how to tag that you can park on-lane on the right if no one is parking street-side on the left.

Are you allowed to park next to a lowered curb in your legislation? Over here, it’s not. If it was allowed, then yes, the current parking schema wouldn’t allow you to tag that. That’s why I said parking:left=street_side implies that all other forms of parking on the left side are forbidden. The current schema doesn’t allow more than 1 location where to park on each side. If you really need this, then I think, this is going to end up very complicated. Are you really sure that you could park in front of a street-side parking without that parking forbidden sign?

13

In our legislation there is no mention of a curb in relation to parking
What is mentioned, but does not apply in this situation.

at a crosswalk or within five metres of it;
in front of a driveway or an exit;
at an intersection at a distance of less than five metres from it;
on an occasion intended for the immediate loading and unloading of goods;

The last one there must be a sign. Nederlands_verkeersbord_E7.svg

Complicated?
They choose to use parking:[side] new scheme
The old scheme was not that bad parking;[position]:[side] example: parking:lane:left and parking:street_side:left.
With one tagline, we tagged, the position and the side.
The new scheme use two taglines for that, that is more complicated, even worse, you must search for a second tagline, to make the conclusion, the restriction is for what part of the road, and ruling out second parking condition.
The old scheme had it in it.
So we need :[position]: in it, to do the job
parking:[side]:[position]

They only switched from :[position]:[side]: to :side for what reason?
Someone thought is was better to set :[side]:upfront

New scheme on second :[…]: you have three choices, both, left, right. But needed a second tagline.
Old scheme, we have more choices, lane, street_side, on_kerb, half_on_kerb, shoulder, on the second.
Surely this can’t be the reason fot the change.

Also there is the area:highway=verge, where you can park, or it is prohibited.
with Nederlands_verkeersbord_E1.svg, the sign is only for the carriageway (lane), then you can park on the verge. You need to express the two positions.

There two options:
deprecate the new scheme and take over :orientation :restriction to the old scheme.
or
In the new scheme use :position: after :side: and deprecate parking:[side]=lane etc.

So do not use this extra tagline.

I would write: only means that there is a physical lane on the left side that could be used for parking.

14

Also by legislation:

outside built-up areas on the carriageway of a priority road;

with this sign priority_road in rural area, it is prohibited to park on the lane of a carriageway.
60px-Nederlands_verkeersbord_B1.svg

There lots of parking bays, besides these lanes, so, whe have two positions to express.

afbeelding
afbeelding951Ă—491 50.6 KB

I was making a preset for priority_road rural, with the tagline for parking.
Ended up with this conflict.

15

if
in front, on the green part, when there are no cars (red cross) on the parking street_side.
afbeelding

16

“implies” can lead to an unworkable situation, where road signs and rules are worked out 1 by 1 in a preset setting. Which is more understandable.

Because no short-term solution can be expected.
[:position] in the key.

Therefore:

My conclusion is that I will continue to use parking:lane for parking prohibition on the lane.
And will process it into the preset.

17

As others have already said: There is no need for a “position” in the key. If a specific rule applies on the lane that differs from parking rules beside the lane, then map the situation beside the lane separately (e.g. amenity=parking=street_side + subtags) and put the rule for the lane in the parking:<side> tag (e.g. parking:both=no_parking). As others also already mentioned: Usually there is no need for this, because parking:both=separate also means that there is no parking on the lane. If you want to explicitely record exact parking traffic signs, just use parking:<side>:traffic_sign.

P.S. Also in the old scheme there was no distinction between parking:lane:* and parking:street_side:*! Everything was mapped as parking:lane:* - this key was a historically grown exception that was not about the definition of a namespace and :lane therefore didn’t have the meaning of a position specification.

1 Like
18

Before I started this topic, I knew, what some wrote. As a solution.
It is talking something straight, that is crooked.
Making it more difficult.

This are two different methodology, one, a way is for routing and one on closed way ( amenity) is for topographic visualisation (polygon).

This two exit next to each other. And must work so.

There lots of people, who want to tag the lane and streetside on the highway way and some gave advice to me, tag it on the highway. It must be possible.

Working on a preset for E1 Nederlands_verkeersbord_E1.svg
afbeelding

Setting a tag should not confuse the already set tag of.
The parking:left=lane should not retag parking:left=street_side with a One Click.
The chosen suffix combination is more likely to cause errors.
If :[position:[side] is used both streetside and lane have there own strings.
And the second tagline is not needed, parking:left=lane or parking:left=street_side This is a advantage.
Tag a sign as directly as possible, one string can do the job.
parking:lane:left:restriction=no_parking

I am repeating myself a bit. There is the need. Dispite what others write, as a solution.