-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing amenity=parking_space rendering #3974
Comments
Thanks for examples of what we might show. I was thinking specially about disabled people icon, but that needs some clarification of tagging first. Also some other special cases like P+R or K+R would be very useful extension of this feature. Refs are another thing worth rendering here. In general these are places which don't interfere with other features, which makes it easier to design symbols. The cases of standalone parking spaces indicate that probably parking tag is missing first, so an incomplete tagging is revealed, which is expected and positive outcome. |
My preferred way to solve this would be to stop rendering It would also make more sense to show this feature if we distinguish between different kinds of parking spaces, especially disabled parking spaces, otherwise showing these features does not provide much information for a general map user. It might also be possible to improve the rendering by changing it to z19+ only and using a color that is not so similar to the |
Is that an abbreviation for "Park and ride" (for places where you park to take a transit vehicle, like a train or bus)? What is K+R? EDIT: Oh, its "Kiss and Ride" - these are places where you can temporarily stop your vehicle to drop off a passenger who is going to ride the train or bus. In the USA these are not considered parking spaces, but perhaps they are in Openstreetmap. |
An issue about rendering icons is that most parking spaces are about 3 meters wide, and rarely are they more than 4 meters wide. At the equator 3 meters is only 10 pixels at z19, so only very small icons could fit at z19 and they would look quite crowded at mid-lattitudes. It would be more reasonable to show small symbols for special parking spaces at z20 and higher, where the spaces would be at least 20 pixels apart. (It might also be possible to render the outline or fill color of special parking spaces differently even at z19, but I don't have any ideas about how to do that.) |
Yes. K+R is similar concept - "kiss and ride".
I agree that it's micromapping and from my experience z18+ is exactly for this kind of objects. Using only typical cartography, z17 is the last zoom level needed. Anything above is useful only for showing more details (even as small as trash cans and bollards) or the way to zoom some things that were obscured by something other. And since micromapping is about scale, the basic context is a scale itself.
This is another comment about limiting rendering based on perceived usefulness, not on making map more diverse and rich. On z18+ it's taking away the most basic feedback for mappers, since this style is not only a nice preview for general users. Extending with details is always welcome, but not necessary to show easily visible on the ground objects.
z19+ does sound to me like too far - these features are relatively big. |
z19 sounds OK for icons. At the same time special cases of parking spaces are not that crowded from my observation. There is no cure for crowded items anyway (other than adding zoom levels) and we just skip rendering all the other things based on the layers priorities and Mapnik algorithms. |
We don't show all shop icons at z16 because most of them would be blocked by other icons in confusing and inconsistent ways. I believe we should hold to this rule: a clear majority of icons should be visible on the first zoom level when they are shown. If half are blocked by an adjacent icon which is rendered with the same or higher priority, then this means they are being shown too soon. So if we rendered 12 pixel x 12 pixel disabled parking icons for parking_space=disabled at z19, this might just work in Warsaw (54 degrees N) where a parking space is ~18 pixels wide, but it would not work in the tropics where a z19 parking space is only 10 pixels wide: half of adjacent icons would be blocked by collisions with neighboring parking space icons. You are right that adding z20 would change this math. |
It depends on assumption that there are a lot of crowded special cases, which I believe is not true. There are also possible inditations like additional color lines inside etc. But I think this is too early to make such detailed analysis, since first thing is to make tagging more specific than just indicating how many special spaces are on the parking (only for Also according to https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space :
so any example of parking space without the parking context is really an incomplete tagging, as I supposed. |
It looks as it should at both levels - the outline is clear and not too strong, no other objects are competing visually, shapes and distribution of them are very common and the parking gives the familiar context. In fact, this is the most typical kind of object I expect to find on big parking, apart from the inner roads. In high latitudes there are different visual problems, but really tough and populated all over the place, like a lot of crowded small buildings which render as tiny outlines noise (which is more or less a fair depiction of reality), together with tertiary roads glued to the buildings even at z18 (which is an artifact of a road system inconsistency - see #3540 (comment)). From what I have just looked, parking spaces are used only as a wrong replacement for parkings, so the solution is to correct tagging there - which current rendering helps to identify. |
I agree with the description of the problem. This is a good example of the kind of problems that result from giving priority on feature additions over map readability. There is no usable room in this style in terms of thin, faint and dark lines between the stronger rendering of barriers and the weaker rendering of landuse outlines at high zoom levels like for landuse=residential. In fact we still have cases where the outline rendering is too dark to be properly distinguished from barriers - like with quarries (example: https://www.openstreetmap.org/way/28555341). There is definitely no room in between there to add another readable class of line rendering. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Just been wondering about this topic. We render normal car parking areas, motorbike & cycle parking, but not accessible / disabled parking? e.g. https://www.openstreetmap.org/edit#map=19/-28.16782/153.53832 (you may need to move slighter closer in to see motorbike parking top-right corner) has all four types of parking mapped, but https://www.openstreetmap.org/#map=19/-28.16789/153.53822 shows that only 3 are rendered. In this day & age, not rendering accessible spaces seems a bit strange? Just a normal wheelchair icon should be sufficient to indicate them. |
Expected behavior
amenity=parking
or rarelyamenity=motorcycle_parking
,amenity=bicycle_parking
). It's main use is for tagging parking spaces with special characteristics, such as accessibility for wheelchair users or drivers with disabled parking permits or electric vehicle charging or for carpools/vanpools onlyaccess=
tags, electric charging, and so on.amenity=parking
, which shows the full extent of a parking lotamenity=parking_space
features are only marked visually by paint or plastic lines on the pavement, and there is no barrier to movement.Actual behavior
amenity=parking_space
is rendered with only an outline, which is in a 50% mix of theamenity=parking
outline color and fill color.Links and screenshots illustrating the problem
z18 https://www.openstreetmap.org/#map=18/50.60402/3.40649
z19 - perhaps ok at this high of lattitude, but note that at the equator this zoom level would look like z18 above.
Example of an 'amenity=parking_space' next to an
amenity=parking_lot
, not inside - this mapping was allowed by the original proposal and is still quite common.z19 https://www.openstreetmap.org/#map=19/43.61853/3.89878
3 parking spaces on z19 - it's not really clear that these are parking spaces rather than say a planter surrounded by a kerb or fence. Especially imagine if the central parking space was not there and there were just 2 rectanges alone: this would be hard to interpret.
Small parking lot or space mapped alone in a residential area. I would not have know what this is.
z19 https://www.openstreetmap.org/#map=19/53.08310/8.85147
The text was updated successfully, but these errors were encountered: