A few parking space questions

As far as I understand the wiki a amenity=parking_space should not be mapped without being part of a amenity=parking.

If there is a single parking space mapped should it then be changed to a amenity=parking with capacity=1?

And what about a amenity=charging_station (mapped as an area) containing parking spaces, is this a valid substitute for a parking area?

Yes, that’s exactly what I would do. Change it to a single amenity=parking area with capacity=1.

The amenity=charging_station I would put next to the amenity=parking as a node on the position of the charger with infos about fee=*, capacity=*,…

At the amenity=parking you might as well add restriction=charging_only but that depends on local regulations/signs.

2 Likes

Also, I’m also not sure on how to map parking for disabled people that are single spaces along a street that already has parking info tagged for the way (e.g. ‘parking:both=*’).

I often see them added as ‘amenity=parking_space + capacity=1 + parking_space=disabled’. Should the tagging be ‘amenity=parking + capacity=1 + capacity:disabled=1’ ? or is this not needed when the street itself already has parking tagging?

I hope that made sense. It’s basically the same issue that was raised in: Mapping of Parking Spots for Disabled Persons in Public Space

That depends a bit on how the parking data is processed.
Usually you would not split up the highway line for a single parking-space as this might, depending where you are, fragment the highway network by quite a lot.

Here you can find two maps which process and display parking data from OSM:
Straßenraumkarte Neukölln, Layer Parkraum (by Supaplex030) and TILDA Parkraum Berlin (by tordans and Supaplex030).
Both maps process data by reading the parking data along the way, apply it to a generated virtual kerb line left and right of the way and then cut out obstacles where it is not possible to park (e.g. driveways, crossings, physical objects tagged with obstacle:parking=yes and many more).

Separately mapped street_side parking or individual disabled parking spots can overwrite the data which is mapped along the way when it is positioned along the virtual kerb lines.

So if I encounter a disabled parking spot on a street which has parking mapped along the way I would map it separately. Where I map, there are two different kinds of disabled parking spots.

One which can be used by everyone who has a disabled-parking-id. Which would be:
amenity=parking
parking=lane/street_side/on_kerb/half_on_kerb/shoulder (choose one)
orientation=parallel/perpendicular/diagonal (choose one)
access=no
disabled=designated
capacity=1 (I have seen capacity:disabled=1 as well but I just add capacity=1 usually. Not sure if there is an agreement in the community on that.)
if you want you could add these tags as well:
surface=*
street:name=”Name of the street”
markings=yes/no (choose one)

Another type where you are only allowed to park if you have a specific disabled-parking-id with an individual number, which I map like this:
amenity=parking
access=no
capacity=1
disabled=private
markings=yes/no
orientation=parallel/perpendicular/diagonal
parking=lane/street_side/on_kerb/half_on_kerb/shoulder
surface=*
traffic_sign=DE:314,1044-11

Sometimes these come with a sign which says they are only disabled parking spaces in specific times. Then you would need to change the access=no to access=yes + access:conditional=no @ (Mo-Fr 08:00-18:00) and the disabled=* to disabled:conditional=designated/private @ (Mo-Fr 08:00-18:00).

Disclaimer: I am working since June for FixMyCity as user fmc_3 and mapped lot’s of parking in Berlin. TILDA-Parkraum gets developed by FixMyCity. I’m not an expert on how the processing works exactly.

In this example ( OpenStreetMap ) , you would then change it to a amenity=parking without touching the street tagging?:

Also, when using the preset options in the iD Editor the tagging would then be something like:

amenity=parking
wheelchair=yes
capacity:disabled=2
capacity=2

I.e. no disabled=designated

Does that look ok?

Yes, amenity=parking without touching the street tagging for the example you showed.

On Mapillary I see two marked areas with a wheelchair symbol. What are the danish traffic regulations for that sign? Do you need a disabled-parking-id placed behind your windshield / a disabled sign on your car or does the sign mean that you have to be a wheelchair user to park there? Are others, able-bodied people, allowed to park there too?

wheelchair=yes does mean according to the wiki:

This tag may be used to mark places or ways that are suitable to be used with a wheelchair and a person with a disability who uses another mobility device (like a walker).

I think it’s not wrong to tag it with wheelchair=yes, if there would be a lowered kerb next to it, to help wheelchair / mobility device users to reach the parked car, but it does not specify the access in osm for your example.

Not sure if there is a way to get visual feedback for street parking in ID. Street parking in urban areas can be very complex, so I recommend to find a way to display it.
I recommend to use JOSM for editing street parking. You can add tagging presets and there is a map-paint-style you can add to visualize street parking and separately mapped parking.


(not real situation. I changed some things just to have a bigger diversity for this screenshot)
Orientation of parking is clearly visible by the direction of the lines.

Green is fee=no
Blue is fee=yes (You have to get a parking ticket)
Pink is zone=* + (fee=yes) (only residents with a parking id can park there or you have to get a parking ticket.)
The small white arrows mean parking=separate.
At the top of the screenshot the red framed separate parking is access=no + car_sharing=designated.
At the left side the white framed separate parking is tagged with loading_only @ (Mo-Sa 06:00-12:00; Mo-Fr 19:00-22:00).


(not real situation. I changed some things just to have a bigger diversity for this screenshot)
The gray rectangles mean parking=no or they display no_parking (orange) and no_stopping (red) restrictions. The orange dotted line means there is a conditional no_parking restriction.

Screenshot_2026-03-21_13-48-30My JOSM Toolbar. I added one-klick-presets (street_parking_hot_buttons by Supaplex030) and some of my own for the tags I use quite a lot.

1 Like

Able-bodied people are never allowed to park there. They are only available to people presenting a disabled-parking-id in the windshield but I don’t know the specific criteria for getting that ID.

I will try JOSM and see if it is better for parking editing. I’ve used it from time to time but always return to iD which I like better for the type of fairly basic mapping that I mostly do. Also, in this case I’ve prepared a mapcomplete project with all the parking spaces in my area that are not part of a parking area. I’m not sure how well JOSM work with mapcomplete.

In addition to @Mlvln answers: The OSM Wiki for Street Parking includes a section on mapping separate areas (Some quotes: “Street parking areas can also be mapped as separate areas with amenity=parking, in particular […] if different parking restrictions apply to individual parking areas than in the rest of the street (e.g. for single or a group of disabled parking spaces, parking spaces for charging electric vehicles, etc.)”. “…the attributes of separately mapped areas “overwrite” the attributes on the street centerline at their location.”

JOSM is very well suited for mapping street parking, especially if you add the Street Parking style. There are also tips on this in the Wiki.

2 Likes

Last question (I hope :slightly_smiling_face: ):

In this case how would you map the amenity=parking to encompass all these spaces? By adding one big area (also including the road) or tracing the outline of the parking spaces (making a very long and narrow parking)?

https://www.openstreetmap.org/#map=18/56.157643/8.891045

Thanks!

amenity=parking can include access roads.

The purpose of the entire area there is basically parking (even if just short-term parking). So, it’s valid to me to map it