Proposal talk:Parking=street side

parking=lane

One possible avenue of feedback we might receive is that parking=lane already does what we propose; some mappers do seem to use it for all of our examples. If that is the prevailing opinion we could consider simply adopting that tag with our proposal. I don't consider this too likely though, because it seems to be used a lot for these kind of 'on-carriageway' parking lanes (OSM). JeroenHoek (talk) 19:08, 4 October 2020 (UTC)

Yes, I have also thought about whether parking=lane could be defined with this proposal. It would be helpful to distinguish these two types from each other (but I would always emphasize that "lane" should not be captured as a separate area, but with the parking:lane=* scheme -- but at least when using the area:highway=* scheme it might be interesting to define such areas explicitly as separate objects).

But not only from a semantic point of view it would be wrong in my opinion to tag the bays we call "street_side" with "lane". Also from a constructional point of view, they are two completely different types: "street_side" are explicitly built/physically separated parking areas, "lane" are merely carriageway areas that are used for parking, with or without markings based on local legal regulations or signs. (This could be a definition approach).--Supaplex030 (talk) 19:59, 4 October 2020 (UTC)

Agreed. JeroenHoek (talk) 06:47, 5 October 2020 (UTC)

Additional photographs

These two are examples of parking:lane=* (and probably parking=lane as well). Might be useful as examples of what not to map.

• 
• 

In the second example there are absolutely no markings on the street, yet everybody parks exclusively on one specific side, and probably have done so for decades. Of course you can't park on the other side without blocking the road, but it's curious how this arrangement just doesn't change, ever. JeroenHoek (talk) 19:25, 4 October 2020 (UTC)

de-/over-emphasized rendering

I have experimented with over- and de-emphasized renderings - do you think it is helpful?--Supaplex030 (talk) 21:28, 4 October 2020 (UTC)

• 

  over-emphasized rendering (carto default)

• 

  de-emphasized (like private parking - might be confusing)

• 

  no rendering of parking symbol

• 

  small parking symbol

• 

  small light parking symbol

Interesting, I experimented with the smaller P as well a while back, and found it a good direction to experiment with. I think you can even go a little smaller; worth trying out perhaps? You are right that the semi-transparent P is confusing. That looks to much like access=private. No P is an option, but not with the current background colour for this amenity. It would have to be a more explicit blue for them to stay recognizable I think. JeroenHoek (talk) 06:46, 5 October 2020 (UTC)

Intermediate level

I doubt using amenity=parking (commony meaning parking lots) for this. There are often enclosed "street-side parking" (sometimes in the middle of the road) with defined entrances that are basically a mini carpark on the street, as opposite a group of spots along the street. Since you mentioned amenity=parking_space which was supposed to be capacity=1, would an medium level of parking feature grouping a bunch of parking spots (regardless of being in a parking lot or kerbside) be more direct, and less affecting to amenity=parking? ---- Kovposch (talk) 07:41, 5 October 2020 (UTC)

If you look at the use of amenity=parking, I think it's clear that this tagging is today much broader than perhaps intended in the early days of OSM (when the intention at first was maybe to map only "larger" parking spaces). It is common and accepted (and in my opinion also useful) to use it also on "smaller" parking facilities, e.g. carports or "garage_boxes". Then, "street_side" parking should of course also be included. To differentiate these different types of parking spaces, we have parking=* -- and from this perspective, it is even more important to distinguish "street_side" or "lane" parking from "surface". (It would also be difficult to draw a line or define until when this "middle" level should be used.) Or what do you think about this?--Supaplex030 (talk) 08:33, 5 October 2020 (UTC)

Maybe this is a mapping style topic. Take your example above, should we consider parking spots separated by a tree (if I'm understanding it correctly) as separate? As extreme as separating 852385380 852385380 with capacity=1 out. Even if it's as "small" as a amenity=motorcycle_parking or amenity=bicycle_parking, they would probably still be grouped togehter (need to research). With parking=carports and parking=garage_boxes, at least they can be grouped together in one amenity=parking easily. Currently their respective building=* can further enclose amenity=parking_space underneath as an implicit middle level. There's no such counterpart for kerbside parking, as in something like a lay-by feature? (cf highway=emergency_bay, highway=passing_place, bus_bay=* for other functions) This issue is avoided in a conventional "parking lot". ---- Kovposch (talk) 13:12, 5 October 2020 (UTC)

Okay, maybe I get your point. I always use parking:lane:*=separate on the highway, which could be a kind of grouping - depending on the purpose for which you need this grouping at all. I have also seen relations, like here from Jeroen: 11230744 11230744. What do you think such a grouping would be useful for? I think I will also use something like parking:street_side:of:name=* in such cases in the future to connect/associate the parking areas with the name of "their" street (the problems are a bit similar to those with separately mapped sidewalks or cycleways, see is_sidepath=*).

Part of the problem seems to me to be that such areas are already mapped separately, but are tagged parking=surface. A tagging like the one proposed here could bring more clarity in the future and make it clear to data consumers what kind of parking space is there. The discussion whether such areas should be mapped separately at all does not seem to me to be very helpful, because the level of detail has reached a level in some areas where it would be strange not to map them separately. For special parking evaluations and applications it can be valuable as well. The question is how to map them... Do you have a different approach?--Supaplex030 (talk) 15:53, 5 October 2020 (UTC)

Grouping them is something I'm on the fence about still. From a data-consumer's standpoint it makes sense to logically group street-side parking areas in one (stretch of) street as a single parking-amenity. If a navigational aid shows nearby parking opportunities, it will limit the list quite a bit. It currently also has the added benefit of not blasting the standardlayer on openstreetmap.org full of blue P's (although that should not be a goal in itself). It is also easier to tag extended shared attributes such as maxstay and fee.

A possible downside is that it is more complex to map (even though it is quite trivial in JOSM). JeroenHoek (talk) 10:08, 10 October 2020 (UTC)

Do you have any other ideas besides a relation? Isn't a relation and the use of parking:lane:<side>=separate (as well as possibly parking:street_side:of:name=*) all that is needed for an interpretable grouping? Should we explicitly mention relations for "chains" of street_side-parking bays in the proposal?--Supaplex030 (talk) 21:42, 10 October 2020 (UTC)

Relation to other parking-values

I've added a section on the relation to other parking=* values. It might be useful when discussing the tag-value on the mailing-list. JeroenHoek (talk) 10:01, 10 October 2020 (UTC)

Nice! It's on my list and I'll do it soon, but at the moment I am lost in an other OSM-project :o --Supaplex030 (talk) 12:26, 10 October 2020 (UTC)

One other tag-value that might come close is parking=bays (as the plural of 'bay' for a single parking space), but it has only a handful of uses. JeroenHoek (talk) 07:54, 11 October 2020 (UTC)

Any added value?

All what you say is included in the existing parking:lane=* schema, I see no added value. Am I missing something? I know some mappers are not using parking:lane=* but probably because they don't know this cleaner, more logic, solution to the mis-usage of amenity=parking. OSM is supposed to be a mapping system, not a drawing system. parking:lane=* means it's less important than a "real" parking. The only added value et the proposal to display the parking spaces on the map, fine we don't need a tag proposal for that, only a PR on some rendering engines at high level. Or a ticket, and your mock-up are a great starting point for that. KISS --Nospam2005 (talk) 12:53, 24 October 2020 (UTC)

This proposal is for both explicitly (example) and implicitly mapped parking areas along a street. That is, as a value for parking=*, and as a value for the relevant parking:lane=* keys. Which of the two you use is up to the mapper. Using parking:lane=* is fine of course, but when more accurate satellite and government geodata is available, mapping the parking areas themselves is also possible. Neither is wrong; the latter tends towards micro-mapping, but not more than, say, drawing fields of grass or bits of shrubbery. For consistency and general suitability we target both mapping schemes with this proposal.

To be able to render these mapped areas differently the proposed tag can be used, which is a stated goal of the proposal. JeroenHoek (talk) 13:16, 24 October 2020 (UTC)

So you're proposing to reinvent the wheel. https://wiki.openstreetmap.org/wiki/Key:area:highway --Nospam2005 (talk) 13:39, 24 October 2020 (UTC)

Not at all, parking=amenity can coincide with areas mapped under the area:highway scheme of course, but it has its own semantics (signifying the ability to park and all the meta-tags, like capacity, that go with it). Thanks for pointing out the potential for confusion though; we'll add a note about it to the proposal. JeroenHoek (talk) 16:20, 24 October 2020 (UTC)

I got your point, however capacity can, for instance, be calculated from the length of the road. For parallel park spaces without individual marking capacity is probably better guessed by a computer than by mappers. If the mapper wants to add the capacity, (s)he will appreciate a tool with the ability to draw easily the park spaces, helped by a precise aerial imagery. So I doubt capacity will be often used in this case. --Nospam2005 (talk) 22:06, 1 November 2020 (UTC)

In the English language there seems to be no clear unambiguous term for this type of parking, so we decided upon street_side.

Use the term lane, and your problem is solved by parking:lane=*. That's it. --Nospam2005 (talk) 13:39, 24 October 2020 (UTC)

Thanks, that's certainly a pragmatic point of view. We've found some drawbacks for the term lane though (as mentioned in the proposal), but I'll take note of your suggestion. JeroenHoek (talk) 16:20, 24 October 2020 (UTC)

I do agree, I would not have used the term lane in this sense either, but I'm not a British native speaker, in French file has a narrower sense (lanes where cars can drive).

But I don't mind the exact term, it exists (parking:side_street=* would have been fine too IMHO). iD, JOSM and other editors can hide the term in a more understandable way. Yes really pragmatic: make the usage of this schema easier is probably the best way to get a unified and clean way to get the information into the database. I believe we all agree of the good ideas behind the proposal. My point is that the existing schema is good enough, let's try to improve editing and rendering. Navigation engine to find a parking space will also benefit from a better description. --Nospam2005 (talk) 17:12, 24 October 2020 (UTC)

parking=street side as node or relation?

Does it make any sense? As node: on which side of the street? As relation: I've no clue what it could be good for. --Nospam2005 (talk) 13:12, 24 October 2020 (UTC)

Mapping as a node is probably not useful, but the parent tag amenity=parking permits it. It would be up to the mapper, the same as with parking=surface. We are not proposing a new parking mapping scheme: this is a value for the existing amenity=parking and parking:lane=* schemes. JeroenHoek (talk) 13:19, 24 October 2020 (UTC)

So it shows the little usability of this tag, thanks for the clarification. --Nospam2005 (talk) 13:38, 24 October 2020 (UTC)

For node, certainly. The intended use of parking=street_side is for mapped areas, and for parking:lane=* on the highway though. JeroenHoek (talk) 13:42, 24 October 2020 (UTC)

how it relates to amenity=parking_space?

how it relates to amenity=parking_space? It also can be used to tag groups of parking spaces. Is it supposed to create new alternative tagging scheme for such feature, replace it for this use or what? Mateusz Konieczny (talk) 21:28, 1 November 2020 (UTC)

This proposal changes nothing about how amenity=parking and amenity=parking_space interact. Mappers can map separate parking spaces if they wish; I often do so myself when the information is available. JeroenHoek (talk) 07:29, 2 November 2020 (UTC)

Also, in general amenity=parking_space is predominantly meant for single parking spaces. Mapping multiple parking spaces is possible and supported via capacity=*, but this is meant for things like an area within a amenity=parking, not as a replacement of it. One example that comes to mind is a delineated area for motorcycles that is too small to map separately with the imagery available. This proposal only adds sub-tag values for parking=* and parking:lane=*, and leaves the existing semantics of parking amenity and parking spaces unchanged. JeroenHoek (talk) 07:39, 2 November 2020 (UTC)

unclear area:highway=parking_space relation

"On page area:highway=*, it must be pointed out that parking=street_side is used on parking areas of this kind and that area:highway=parking_space is not used in this case."

Why area:highway=parking_space would not be applicable? Mateusz Konieczny (talk) 21:29, 1 November 2020 (UTC)

Hmm, good question. I think it might be OK to use in addition to amenity=parking (and parking=street_side) if that is the dominant tag for mapping parking areas within area:highway=* — as long as it doesn't carry the meaning of 'a single parking space', but I don't think it does. What do you think Supaplex030? JeroenHoek (talk) 07:43, 2 November 2020 (UTC)

You are right: I changed this. First of all I wanted to express that amenity=parking + parking=street_side should be used in this case — which does not exclude additional tagging with area:highway=parking_space. (However, this tag is rarely/not documented, so I wanted to make sure that it is not understood in the same way as amenity=parking_space. But you are probably right: In the context of area:highway=* it has a different meaning and can be used here).--Supaplex030 (talk) 09:38, 2 November 2020 (UTC)

painted/parking spots on carriage way as a polygon mapped

People map them as polygon. This is for me also streetside parking. I mis this example as a polygon tagging. Sometimes there are on these spots planter or concrete blocks. This is not worked out. This must be included. Traffic_signs refer to these spots. This is different then a carriageway with no painted spots, this is the image in the proposal parking=lane. Traffic_signs refer to these spots in opposite usage(prohibited). Therefore i would say, vote no. But in general, it is okay --AllroadsNL (talk) 13:17, 15 November 2020 (UTC)

We've intentionally left parking on the carriageway out of this proposal in favour of the lane value already used in both parking:lane=* and parking=lane. These existing values seem to have been intended for this purpose. We've made an attempt to clarify existing values such as surface, lane, and lay-by, but I feel further discussion of their semantics falls beyond the scope of this proposal. JeroenHoek (talk) 13:21, 15 November 2020 (UTC)

Node, way and area?

You wrote in the proposal that parking=street_side "applies to node, way, area". Why way? How can this be mapped as a way? Key:parking states that "parking=*" applies to nodes, areas and relations. Other types of parking: multi-storey and underground can be mapped as a node or area. Why street_side is different? maro21 01:40, 23 November 2020 (UTC)

parking=street_side does not apply to way, but when parking amenities are mapped as an attribute of the street via parking:lane=*, then the street_side value can be used there on the way in the form of parking:lane:<side>:<type>=street_side. It looks confusing in the proposal header, but is explained further on. After the proposal lands the documentation will be added to the relevant pages, so the confusing 'applies to' should vanish. JeroenHoek (talk) 08:04, 23 November 2020 (UTC)

Shared Relation for multiple parking areas along one street side

An issue that could be worked out in the implementation of this proposal is the shared relation, which should be used to group sequential parking spaces along a street/on one side of a street. In the proposal we recommend a relation of type=site with site=parking. If I remember correctly, in the past Jeroen simply used multipolygons for this. What do you think: What is the better option? Should we stay with the site relation or recommend a multipolygon instead? From my point of view the variants have the following impacts:

Multipolygon:

• easy to create and edit
• the parking spaces will form a "unified" object (Does this reflect reality correctly? Is it "one shared parking area" or "many individual parking bays"?). However, different properties such as capacity=* can still be specified on the individual areas
• therefore only one parking space symbol appears or only one entry in nearby lists of parking spaces in navigation applications (can avoid "spam" without special algorithm adjustments, but rendering looks a bit strange sometimes as the symbol only appears on the first object)
• it could happen that some applications cannot handle multipolygons?

Site relation:

• more complicated to create and maintain
• each parking space remains an "independent object" and must be declared as a parking space individually(?)
• each area keeps its own symbol with standard rendering methods/its own entry in lists without special algorithms
• because every parking space remains an "independent object", the parking spaces are readable even for simple applications that can't handle relations

I'm not sure which variant I prefer... --Supaplex030 (talk) 19:41, 29 November 2020 (UTC)

What problem do multipolygon / site relations actually aim to solve? As far as I understand now, it is only meant to group several, seperately mapped parking spaces together, mainly for rendering reasons? (This does not seem right and I am wondering if I am completly missing the point?) Adding to the question already raised in the second list item under multipolygon: How do the individual bays/spaces relate to each other? I'd argue that they don't (or just in an insignificant way that could be derived from geometry/proximity/similarity as well) – it's just a collection of similar spaces along a certain (shared) trajectory. (I am not even sure what a data consumer is supposed to do with this additional information?) In contrast, if a relation would include the adjacent/accessing highway(s) – specified as a different role, of course –, it might actually provide some meaningful context to data consumers (and solve the "helicopter problem" – if it even is one to be taken seriously – mentioned in the voting discussion). However, adding (multipolygon or site) relations introduces another level of complexity, making editing more complicated, not only, but especially for less experienced users: Solving(?) one problem whilst creating another, maybe even more burdensome, calls for careful reconsideration. --!bm (talk) 23:09, 29 November 2020 (UTC)