Modify or get rid of P Symbol in Car Parking Areas #3013
Comments
AFAIK P icon is quite universal for parkings. Can you propose anything better?
see above
Can you create a new issue, with an example of affected area (if it is not reported already)? If necessary appearance of icon may be tweaked.
How legend is displayed at http://openstreetmap.org/ is decided at https://github.com/openstreetmap/openstreetmap-website - you may want to create issue there if it is not tracked or made a PR (see openstreetmap/openstreetmap-website#1017 for example of PR fixing legend)
Can you give example of correctly tagged area affected by this problem? Usually it is caused by not using multipolygon where necessary. |
|
P in a building could be #2457 |
|
@Adamant36 Can you point to a location where the P is "too obvious". Something like this is always going to be a value judgement (what the person looking at the map thinks is important), so it helps to be looking at the same area. FWIW in a different map style I did make the P symbol slightly smaller; maybe that would help? |
|
Parking areas already got less obtrusive when yellow was replaced with grey. |
|
@Adamant36 Ping? Can you reply to questions? |
|
@matkoniecz I proposed a few things in my original message. I personally think getting rid of the P, or making it blend in better somehow, and not prioritizing parking spaces symbolically is the way to go. That's just my opinion though. I am no expert on the subject. So, what are your thoughts on how to make it less obvious in places where it is an issue? I think SomeoneElseOSM's suggestion of making it smaller is a good one. Maybe making the blue more of a pastel color to fit the color scheme better would work to. The Bright blue seemed to work better when the parking spaces where bright yellow. Now that is everything is toned down more though, it makes since to tone the P down also. I know the P symbol for parking is a universally recognized. I wasn't talking about its use in general though. The question was specific to Carto and why Carto tends to give parking spaces symbolic priority over other areas so to speak, when Carto seems to be general map that is not geared singularly to navigation where something like that would useful. Although it seems that other maps like Bing, Google maps, Here Maps, Waze, etc etc do not put P's in parking areas and is their main purpose. So it might be universally recognized, but it is clearly not universally used. Which was the point. I only ask because I was thinking about contributing code to the project. Plus I already do a lot of editing. So I am trying to learn more about the design process here and when it comes to maps in general. Here's links to a few examples. It seems to mainly be an issue in older down town areas with a lot smaller behind building parking and at the third zoom level. https://www.openstreetmap.org/#map=17/40.58347/-122.39153 Downtown Redding https://www.openstreetmap.org/#map=17/40.80228/-124.16443 Downtown Eureka, which seems particularly chaotic. In a lot of places the P is larger then the actually parking area or the P will be displayed in the middle of the road, but the parking lot will not be displayed because it is to small to show up at that zoom level. Making the P smaller would probably help there, but then it would still display wrongly in the road. Maybe there could a flag added to make it so that the P symbol doesn't show up on the map for parking areas that are to small for their geographically area to display. I don't know. I think HolgerJeromin's reference to the issue #2457 is correct. Its been about a month since I've seen it happen and it appears to have been fixed since then. Thanks HolgerJeromin for the reference. @SomeoneElseOSM It's pretty cool you made your own map style. It looks like quit the task. I know things like this are always going to be a value judgement. That could be said all "improvements" though. If known one else has an issue with it, I am fine with it staying the same. I it bothers me sometimes though. So I thought id role the dice and pose it as a change request. Since I'm trying to get more involved here. If everyone thinks its not a problem though, feel free to close this. I really don't mind. I do think your sugestion of making the P symbol slightly smaller though is a good one. It looks less intrusive on your map. @polarbearing I agree that parking lots are less intrusive since the color changed. I disliked the old color a lot. It doesn't mean there isn't more room for improvement though. As stated in my original post, the issue comes up when there is a lot of smaller parking lots in the same area, not due to "bad mapping." Although there is a lot of that though, especially with parking lots. I do know the difference. I will say this is only the third issue Ive posted on Github. So, obviously I'm not great at it yet. Thanks for the thumbs down though and the comment ;) @matkoniecz Sorry for the delay. I've been mapping things pretty hardcore the last couple of weeks. So I was going to take a few days off and let my eyes - hands rest and respond when I came back. I guess that didn't happen though. |
|
Thanks for the Redding and Eureka examples. This is why we ask for examples, since everybody has different situations in mind when talking about such a subject. While in Redding and Eureka the parking might be mapped spatially correct, I assume that lots of these areas are private or customer car parks, which should have an appropriate access tag. That would already lead to the halftone P-icon, and help a lot in those examples. |
|
@Adamant36 - Are you sure that there are no missing access tags on parkings in Redding and Eureka? |
Did you see #2429? It's exactly about "P"s (and one-way arrows) being rendered before some other, more important objects, like amenity labels. I'd like to fix it and I guess it means making parking special layer which has lower priority than other amenities. Would you like to join this effort? Did you try to set installation environment (probably Docker-based)? BTW: osm-carto is generally how we call this style in comments, not Carto. |
|
@polarbearing Your welcome. I actually wasn't even aware that the access tag makes the P icon halftone. It seems like putting access restrictions on parking lots is the exception and not the rule. I'm glad to know that though. It would help a lot. @matkoniecz I'm sure a lot of them are. I wasn't even aware that the halftone thing was even a thing until you and polarbearing mentioned it. Maybe that should be clearer somewhere. @kocio-pl Thanks for the reference. I'll have to read through it. I could see where creating a special layer for parking wouldn't be very high up on the priority list. It seems like parking isn't really mapped all that much yet anyway, at least not in Northern California. I installed Docker on Ubuntu and have been tweaking around with it a little. Its quit the thing to setup. Unfortunately I only have experience programming in Java and Basic at this point. So I need to do some reading up on Lua and CSS before I start doing any osm-carto coding. Once I do though, I'll probably start by knocking down some of the easier issues to learn the ins and outs of the Github process. The parking layer thing sounds like an interesting project to work on after that though. Sorry for calling the project the wrong name. I'll do my best to call it osm-carto from now on. |
putting access restrictions on parking lots where access is restricted is standard. adding access=yes for unrestricted parking is less common, but it becomes more popular See https://taginfo.openstreetmap.org/tags/amenity=parking#combinations - 19% of parkings have access=* (and most of parking without access tag have unrestricted access). |
If you encounter problems and documentation is not helpful or you see how instructions may be improved - please open an issue (I recently made some changes that are supposed to help but somebody new trying to follow instructions is a best tester). |
|
@Adamant36 I think LUA is not needed most of the time (I've never touched it and I'm quite active here), so you should not worry. However it's good to remember that CartoCSS is a different thing than CSS (they share only basic concepts of styling, as far as I know). I thought it was clear, but there were people not aware of this, so I just want to make it clear. Anyway, looking at examples in the code helps to learn CartoCSS a lot, so you also don't need to dig too deep into it. It's great that you already used Docker, I guess our documentation is quite short and I hope clear enough, please report any issues with it: https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md Trying to fix some easy tasks is a good thing for a start - just ask anything, we're ready to help you: |
I think that it can be closed then as OSM data issue and reopened if adding correct access tags will not fix it, right? |
|
Just to add another data point, here is somewhere also in the US with lots of individual parking areas mapped, with access tags. |
While the halftone P works well here, I find mapping such private infrastructure stretching the definition of an 'amenity'. |
Those maps have a different approach, they're dynamic, and you have to ask them what you want so they can show it for you. If you compare your OSM links, yes, the P are not even there, but neither the two churches, post office, several restaurants and banks or even the big hospital (in the case of Redding). I don't think you can really compare them because of this. |
This one seems fine for me, what at least in my opinion proves that real problem is tagging restricted access parkings without access tag.
Note that this topic is completely offtopic here (changing standards of tagging is complex but it certainly should not start here). |
Well, tagging and rendering is a mutual relationship. As much as we should not tag wrongly for the renderer, we should not render for the tagger, i.e. not compensate problematic tagging with rendering workarounds. |
|
In this case it is completely offtopic as tagging private parkings with amenity=parking is well established - https://taginfo.openstreetmap.org/tags/amenity=parking#combinations access=private is used over 200k times with amenity=parking. Anybody wishing to change established tagging or describe it as something that should be changed should not start here. |
|
Those 200k probably include e.g. a company providing a private car park with e.g. 50 spaces as amenity to their employees. The cited examples however were spots for 1-2 cars in front of an individual home. For those, maybe parking_space would be appropriate. |
|
note that amenity=parking_space is for "a single parking space on a parking lot" - https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space |
|
Still mapping |
|
I'm not really sure what to say about the rest of the discussion at this point, but as kind of an interesting side to it and a case study of what I was originally imagining, I found a few places around Northern Sacramento where parking spaces are mapped as areas and don't have the P. I don't know if the tagging is correct or if it is necessarily the way to go with business parking, but it sure looks cool. Plus, not having the distracting P symbol is definitely a bonus. I'm interested to know what other people think about it as a design decision. I do agree with @polarbearing that the definition of amenity=parking_space is kind of getting stretched to its limits by making all the parking private and that compensating problematic tagging with rendering workarounds is not such a good thing either. Who knows what the answer is though. https://www.openstreetmap.org/#map=18/34.15952/-117.41038 There's also this crazy freak show of an area with a similar thing going on. Its pretty surreal in some places. They both at least give an idea of what parking might be like if there was a lot of it and finding it was dependent purely on a geographic visual cue. If its better or not then the current system, I don't really know. I can see a time in the future though where a lot of driveways are mapped, which might be a situation the P symbol becomes problematic. Even shaded. For the sake of uniformity, it make more sense to just merge the two styles visually since they are essentially the same thing. |
I created https://www.openstreetmap.org/note/1269722 https://www.openstreetmap.org/note/1269733 as I believe that this tagging is case of https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer |
|
@Adamant36 and @matkoniecz These two examples have nothing to do with amenity=parking. The mapper added area=yes to a set of driveway serice tags. |
|
@matkoniecz Thanks for adding the notes. I wasn't really sure what to do about myself. I was going to post on the forum asking if someone could help me clean it up, but I didn't want to undue someone else's work without knowing if it was correct or not. As a side to that, in your opinion would it be incorrect to create a large parking lot area at say like a mall and then create the building as an inner relation to the parking lot or something? because I am still not really sure how to map large parking lots with semi segregated parking areas that have large traffic islands between them. Since the its technically all the same parking lot and there is the one element rule, but yet they are divided and there is currently no way to map the area of traffic islands. for example the Mt. Shasta Mall or the FoodMax parking lot here @drkludge They have something do with it as far as showing a graphical example of what parking could look like visually without the P symbol being there. I was showing it because it had the area=yes tag, and I was the one that created the request in the first place. So it was relevant to me and my attempt to show what I originally meant. Since it seemed like known understood it. Anyway, OSM is a visual map that people take visual cues from is it not? It seems like it would be relevant on that alone. I guess not though. Man, tough crowed here. I was thinking about trying to revise my original request to be clearly and starting a new one, I don't really see a point though if 90% of the comments aren't even constructive and most of the people just discount my request off hand. So, I'll probably just go back to mapping instead. I appreciate the constructive feedback from the few people that gave it though. It was pretty helpful. |
Please, ask tagging questions on tagging mailing list or some similar forum. |
|
@matoniecz I know about the mailing list. I asked you though. If you dont want to answer the question, just dont answer it. |
I you want to discuss tagging with just me you can send me a PM using https://www.openstreetmap.org/message/new/Mateusz%20Konieczny |
|
@matkoniecz OK thank you. I appreciate that. |
I suggest to either get rid of the P symbol in car parking areas or either modify it to a less obvious color and font that blends in better, because at this point it seems to stand out much, especially in places on the map with lots of small parking areas. Also, parking does not seem to be in map key. Although I could be missing it. Personally, I think the most coherent route would just to get rid of the P all together, since other areas don't have special letters associated with them, and to add it to the map key or make it black instead of blue. Doing that would also fix places where the parking lots wind around things, which sometimes causes the P to appear in the middle of a grassy area or a building. Or, if the P remains, for the sake of constancy, make it similar in size, color, font, etc to other text on the map so it blends in better. As a side to that, if there was a good original rational for why the P is there in the first, I'm really interested to know what is.
The text was updated successfully, but these errors were encountered: