Skip to content
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

Open
23cpo opened this issue Aug 23, 2014 · 27 comments
Open

Render operator= for car parks #905

23cpo opened this issue Aug 23, 2014 · 27 comments

Comments

@23cpo
Copy link

23cpo commented Aug 23, 2014

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.

@HolgerJeromin
Copy link
Contributor

Very useful at many supermarkets. Good idea.

@matkoniecz
Copy link
Contributor

see #698

@pnorman
Copy link
Collaborator

pnorman commented Aug 24, 2014

Many parking spaces (amenity=parking)

Parking spaces or parking lots?

@23cpo
Copy link
Author

23cpo commented Aug 24, 2014

@pnorman I mean car parks/parking lot (amenity=parking) not single parking spaces (amenity=parking_space). Unfortunately I've mixed up the terms.

@23cpo 23cpo changed the title render operator= for parking spaces render operator= for car parks Aug 24, 2014
@floscher
Copy link
Contributor

floscher commented Sep 1, 2014

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).

@matthijsmelissen matthijsmelissen changed the title render operator= for car parks Render operator= for car parks Sep 24, 2014
@matthijsmelissen matthijsmelissen added this to the New features milestone Sep 26, 2014
@HolgerJeromin
Copy link
Contributor

I see often amenity = parking with access = customers and the name of the corresponding shop in the name tag.
Imo this is wrong, as the parking is not named Aldi or Walmart for example.
Dropping name in favor to operator does not work with independent parking.

Is rendering operator instead of name only for access = customers too complicated for the mappers?

@Tomasz-W
Copy link

Is there anybody still interested in this? No comments for more than 2 years, maybe close the issue?

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 8, 2019

Having looked at the use of operator= tags with amenity=vending_machine + vending=parking_tickets, it does not seem that the name of the operator= is very helpful for a general map users.

Many parking lots in urban areas have a operator tag with the name of the corporation which runs dozens of private parking lots in one city, others are all operated by the local government, which would lead to rendering many of the same name labels on multiple parking lots in one area.

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.

@Adamant36
Copy link
Contributor

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
Copy link
Contributor

What about this amenity=parking rendering?

Render operator when we have access=customers (for the places which are connected to shops)
Render name for the places with a name, for the places which have a real name)
Render ref for the places which should only a ref.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 9, 2019

@HolgerJeromin, in your town how many amenity=parking features would be improved by this rendering?

In the places I have checked, adding the operator key would not be helpful: it would duplicate the name of the nearby supermarket, mall, shop or office in many cases, and in many others it the operator is not helpful for orientation since it is merely the name of the town transportation department which is obvious and not needed, or the name of a corporation or individual owner of the parking lot but not something visible on a sign.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 9, 2019

Render ref for the places which should only have a ref

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):
https://taginfo.openstreetmap.org/tags/amenity=parking#combinations

Per these overpass-turbo.eu searches (1 2), there less than 2.8k amenity=parking features with a ref but without a name, which is less than 0.1% of features (compared to 270k with a name and 96k with operator).

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 9, 2019

people have cards or memberships with certain parking lot operators

I'm not aware of this situation for car parking lots, do you have an example?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Nov 9, 2019

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,

@HolgerJeromin
Copy link
Contributor

In the places I have checked, adding the operator key would not be helpful: it would duplicate the name of the nearby supermarket, mall, shop or office in many cases,

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 name instead of operator is considered wrong tagging.

@jeisenbe
Copy link
Collaborator

jeisenbe commented Nov 11, 2019

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 operator=:

z18-aldi-edeka-parking

(There is also a shop called Edeka on the east side, with a parking lot of the same name/operator and access=customers)

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?

@Adamant36
Copy link
Contributor

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.

@jeisenbe
Copy link
Collaborator

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

But is it necessary for map users to know this?

[OT (off-topic):

The public parking lot is paid. So you can't go by access. Since both are access=costumers

A paid, public parking lot which can be used by everyone, for a fee, should be access=yes + fee=yes]

@kocio-pl
Copy link
Collaborator

But is it necessary for map users to know this?

On the other hand - why hide the proper feedback? Why stop encouraging people from adding more precise data?

@jeisenbe
Copy link
Collaborator

We currently render name=* tags for amenity=parking.

If we added the operator=* tag this could worsen feedback for the name=* tag, especially if name and operator were rendered in the same style or a similar style.

@Adamant36
Copy link
Contributor

If we added the operator=* tag this could worsen feedback for the name=* tag, especially if name and operator were rendered in the same style or a similar style.

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.

2019-11-11 (1)

But is it necessary for map users to know this?

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."

2019-11-11 (2)

@Adamant36
Copy link
Contributor

Adamant36 commented Nov 12, 2019

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.

2019-11-11 (3)

(It was actually a lot worse in that area, but I've spent a lot of time cleaning it up)

@jeisenbe
Copy link
Collaborator

If we were to stop rendering the name=* of amenity=parking, I would not be in favor of rendering operator=* instead, for the reasons mentioned above.

Note that 270k or 8.26% of amenity=parking have a name tag, compared to 96k or 2.94% with an operator tag.

@Adamant36
Copy link
Contributor

Note that 270k or 8.26% of amenity=parking have a name tag

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?

@HolgerJeromin
Copy link
Contributor

HolgerJeromin commented Nov 15, 2019

I am strong against dropping name for all parking spaces:
https://www.openstreetmap.org/way/39539586#map=19/51.22639/6.78605
Thats why I suggested operator only for access=customers

@Adamant36
Copy link
Contributor

@HolgerJeromin, wouldn't the name tag continue to render in your example because it still contains the building tag?

@aceman444
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests