-
Notifications
You must be signed in to change notification settings - Fork 820
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
Render operator= for car parks #905
Comments
Very useful at many supermarkets. Good idea. |
see #698 |
Parking spaces or parking lots? |
@pnorman I mean car parks/parking lot (amenity=parking) not single parking spaces (amenity=parking_space). Unfortunately I've mixed up the terms. |
Another case where the rendering of operator=* would make sense would be leisure=pitch. Many of those have the name of the sports club set as their name. Rendering the operator of pitches would probably encourage the usage of operator=* in those cases. This issue is similar to #800 (suggests rendering of name/brand/operator=* for amenity=car_sharing) and #840 (suggests rendering of name/brand/operator=* for post offices). |
I see often amenity = parking with access = customers and the name of the corresponding shop in the name tag. Is rendering operator instead of name only for access = customers too complicated for the mappers? |
Is there anybody still interested in this? No comments for more than 2 years, maybe close the issue? |
Having looked at the use of Many parking lots in urban areas have a If the parking lot has a common name, that can be helpful for routing and orientation, but the name of the operator is not very useful for routing or finding your location. I suggest closing this issue. |
Is operator used in cases where people have cards or memberships with certain parking lot operators? It might be useful in cases like that so the person can plan to go to a different parking lot where they have a card with operator. Although id guess its to much of a niche to warrent rendering. |
@HolgerJeromin, in your town how many In the places I have checked, adding the |
I imagine many of these are internal reference numbers, not the common name of the lot. According to Taginfo only 0.2% of parking lots have a ref (6418 features): Per these overpass-turbo.eu searches (1 2), there less than 2.8k |
I'm not aware of this situation for car parking lots, do you have an example? |
That's another example where it looks like a systematic tuning, where number of uses is not really important (for example only 5% of highway tags have refs). Parking lots are not interfering with other features, so it's not a visual problem, and refs are easy to understand. I also suppose that some (maybe even a lot) names on parking lots are just refs indeed, but tagged for rendering, |
That is exactly my Point. It is useful to show if I am allowed to use a parking space. But this parking is NOT called Aldi (the supermarket is), so using the |
This is the example mentioned above about a supermarket name "Aldi", where the adjacent parking has been given the same name (incorrectly), but this is an example of what we might see if rendering (There is also a shop called Edeka on the east side, with a parking lot of the same name/operator and I don't think this rendering is helpful; it is clear that the parking lot is associated with the Aldi supermarket because it wraps around the store building. I think that the location of the parking lot compared to surrounding features is almost always sufficient to show where a private or customers-only parking feature belongs. @HolgerJeromin can you show some examples of where the lack of the operator tag is a problem? |
I have a few examples that I'm unfortunately able to provide right now. Its a public parking lot next to a private one where the place that the private parking lot is for is across the street. There's way to tell its for that place though unless you use the operator tag. The public parking lot is paid. So you can't go by access. Since both are access=costumers. There's also large parking lots in shopping centers where it looks its one big giant lot, but is actually smaller connected ones that are maintained by the different businesses. For example they do their own repaving and inforce parking restrictions in their lot. Even it appears to be a single bigger one. Operator might be useful in those cases. |
But is it necessary for map users to know this? [OT (off-topic):
A paid, public parking lot which can be used by everyone, for a fee, should be |
On the other hand - why hide the proper feedback? Why stop encouraging people from adding more precise data? |
We currently render If we added the |
I say stop rendering the name tag for parking and start using the operator tag instead. There's a bunch of miss-uses of the name tag for parking (around 37,090 according Taginfo. At least for operator it's a real thing/title. There's almost zero, or zero, places where the name tag on parking wouldn't be descriptive.
I think I mentioned it here before, but one time I was standing in the parking lot of a retail center in-front of a specific store. They were the only store in the shopping center that had their own security guard, who said I was loitering and asked me to leave. So, I walked across the parking lot to a fast food restaurant's parking lot where I was perfectly fine. I don't know if it's "necessary" for map to users to know that kind of information, but it's helpful, and what really is "necessary" to render anyway? Here's that place I was talking about. The largest parking lot, tagged as access=costumers, is for the Jefferson center. You wouldn't know it though by the location though. It could either be for the YMCA (which would have been my guess), or the two buildings to the left. The larger of the two parking lots to the right of it if I remember correctly are public, but ran by some none city parking lot operator company that charge to park there. Whereas, the smaller parking lot just below it if only for costumers of the buildings across the alley. IMHO it would be way useful to rendering operator in these types of situations. Otherwise, you'll risk having people tag the parking lot for Jefferson Center as "Jefferson Center." |
One more example, this is an OverTurbo Query for name=park. 99% of the results are parking lots in parks tagged with name=park when the operator tag should have been used instead, but the name tag renders and operator doesn't. So that's what people use. Unfortunately my computer could only search a small areas, but there's a lot more places like that. (It was actually a lot worse in that area, but I've spent a lot of time cleaning it up) |
If we were to stop rendering the Note that 270k or 8.26% of |
The question is how many of those uses are actually legit. My guess is not many because there isn't really that many actual, real world named parking lots out there. Whereas, its almost always the case that the operator tag is correct. So, I'm not sure what the is. Except not incuraging abuse of the name tag anymore. Which you shouls be all for. Otherwise, how exactly would rendering operator worsen feedback for the name=* tag? I don't I don't see it ghappening in other places where operator is rendered (at the cost of name rendering). So why would this be any different? |
I am strong against dropping |
@HolgerJeromin, wouldn't the name tag continue to render in your example because it still contains the building tag? |
I also agree that most name tags on parkings are descriptive in the form "Parking of ". That is what gets rendered. If we switched to rendering operator only, which would only contain "", would that be correct? Notice the value change. |
Many car parks (amenity=parking) have no own name but they have an operator tag. I think it would be useful to render those operators if there's no name tag.
The text was updated successfully, but these errors were encountered: