[Page Update] Parking Lot Areas Naming Guidelines

Map Editors Community United States US Wiki Discussion
1

It has been suggested by a few Champs with general consensus by several other Champs to update our naming guidelines for PLA’s.

Current Guidance:
“Starbucks Parking (customers only)”
“Macy’s Lot (customers only) - Big Hill Shopping Center”
Lot D (attendees only) - Cheery Stadium"
“Alpha Lot (permit only) - StudyHard University” Parking allowed by permit only ( even if permits are available to multiple groups (eg for Students, and Faculty)
“Bravo Lot (restricted access) - StudyHard University” Parking allowed for Students, and Faculty ONLY

Suggested Guidance:
“Parking - Starbucks (customers only)”
“Parking - Macy’s - Big Hill Shopping Center”

Restrictions removed in example above compared to current guidance just to eliminate any confusion that may exist. Restrictions would still be appropriate if local guidance restricts a lot specifically to customers of that establishment.

The changes reflected are those that are for dedicated business lots where an official name doesn’t exist. The change does not affect cases where the name of a particular business is used to describe the location of a lot in relation to a larger entity.

These changes will also provide for a better search experience in the app. Please provide any feedback about these suggested changes. If we do not feel a consensus is reached after a few days, we will add a poll to this thread.

2

How would the Lot D and Alpha Lot change

Overall looks cleaner and simpler

3

I agree with “Parking - Starbucks (customers only)”. This brings one-lot-one-business naming closer in line with other types of lots, and will go very far to avoid polluting search results.

I do not agree with “Parking - Macy’s - Big Hill Shopping Center”. In the case of “Macy’s Lot - Big Hill Shopping Center”, “Macy’s” is referring to the location of the lot relative to the shopping center, which is what the lot serves.

–

In short, the name of every parking lot should fit a particular framework (ignoring the placement of restrictions for the moment):

[Parking descriptor] - [Business served]

The framework is not recursive. In other words, there is only one business served in any lot name, and the rest of the name is the descriptor. The descriptor can be:

  • completely generic (“Parking - Starbucks”) for single-business-single-lot;
  • purpose descriptive (“Customer Parking - Office Depot” and “Employee Parking - Office Depot”; “Visitor Parking - LSU Eunice”; “Employee Parking - MSY” [airport]) where there is only one lot of the type;
  • location descriptive (“Southeast Lot - Big Hill Shopping Center”, “Macy’s Lot - Big Hill Shopping Center”, “Grand Blvd Lot - Big Hill Shopping Center”, “Target Garage - Big Hill Shopping Center”, “Dillard’s South Lot - Big Hill Shopping Center”, “North Lot - Offices at Buildingtown Plaza”, etc.) where more than one lot serve the same purpose for the same place; or
  • named (“Garage 2A - Mercedes-Benz Superdome”, “Credit Card Lot - MSY”) where the lot is given an official name.

But there is one common thread: the first element is a description of the lot by purpose, location, or just generically; and the second element is the associated business.

No sub-elements, no recursion, no Inception. We don’t have to go deeper.

The current wiki guidance fits within this framework with the exception of “Starbucks Parking”, which should instead be written, “Parking - Starbucks”.

–
edited to add

The specific case of shopping center parking, particularly the “location descriptive” group above, is where the “recursion” problem can arise, the temptation to name a lot “Parking - Macy’s - Big Hill Shopping Center”. But this naming scheme leads to a disparate result, as many if not most malls will not sensibly be able to name every lot or garage after an anchor store. You’ll see “Macy’s Lot - Big Hill Shopping Center” next to “Southeast Lot - Big Hill Shopping Center” and “Grand Blvd Lot - Big Hill Shopping Center”. Introducing another hyphen, reversing the words, and replacing “lot” with “parking” will serve to be more confusing.

Further, to broach the subject of where to place ([restrictions]), “Macy’s Parking (customers only) - Big Hill Shopping Center” (and “Parking - Macy’s (customers only) - Big Hill Shopping Center”) give the false impression that the parking lot is limited to Macy’s customers only, when in reality you can park there and go anywhere in the mall. Though there is concern with space, restrictions might belong at the end of the string in some cases. Or do we say that Americans understand how customer parking works and we just leave such generic restrictions as “customers only” (the norm for the USA) off? Public parking is the exception, not the rule.

4

+1 I agree completely here.
I’ll add that it was understanding from the initial page that this was the intent, and I’ll be happy to see it formalized. Sketch did a great job explaining the intent here.

I’m not concerned about agree to place restrictions in the name due to length. I’m fine with them at the end of the name, and the description.

5

They would not change at all with this proposal

6

I rarely use the parking feature in the app - I just don’t go many places where parking is difficult to find. Therefore I’m relatively ignorant of the true functionality of the feature and how it can be tweaked.

I do, however, agree that using naming that starts with “Parking” and then “location” and “place” as the syntax makes plenty of sense from a search-ability and readability standpoint.

Perhaps we could describe the syntax as:
“Parking - [business]” for cases like small stores (“Parking - Hipster Coffee Bar”) and
“Parking - [sublocation] - [large area]” for cases like malls and airports (“Parking - Lot A - Big University” or “Parking - Long Term - Busy Airport” and “Parking - Big Chain Store - Crowded Shopping Mall”)

7

I definitely agree with Sketch’s post. We want to keep things consistent and refrain from using more than one hyphen. Plus, writing “Parking” first would make indexing the search results a lot easier. Writing Parking at the end would make it seem a duplicate of the business. So in short, keep it simple and provide useful search results to Wazers who are parking geeks. :wink:

8

Agree with what Sketch has said, but I did want to elaborate on this point. With many recent ad campaigns over, and the flurry to update the place points for many businesses, I want to be sure we’re also clear on defining guidance on one-lot-one-business (OLOB) PLA naming. Currently the wiki page only lists OLOB within the example of Starbucks.

I’d like to see more explicit guidelines around if a parking lot serves a single business the naming guidance would be Parking - [Business Name]. While it can be implied based on naming PLAs within shopping centers and malls, I think it would be beneficial to have this defined for OLOB.

9

Completely agree with what Sketch said.

10

One quick suggestion: Can move to use colons instead of spaced hyphens (" - "). More often than not, the line break at the hyphen, and most places look like:

Colon would look like this:

which is much more elegant.

More important note:

We’ve done a lot of work for de-cluttering search results, but where are all my friends that complain of map clutter? Did we forget about it? I think we also need a solution (or ask Waze) to not show parking lot names on a map. This looks ridiculous: http://imgur.com/a/ApEd6

Where we can we find a middle ground? It’s silly that we won’t show areas for entire buildings, but yet we’re encouraging editors to map the parking lot around the buildings?

11

Names and polygons only show* at certain zoom levels/when you are within ~1 km of your destination, same time the [P] popups show up, IIRC.

  • With the exception of lots over a certain size, which show polygon and name all the time. I don’t personally think the size is big enough at all, as it creates situations where some but not all parking lots at, say, a shopping center are displayed all the time. It’s a bad look, and that’s the one thing I think desperately needs changing.

Note the example in your screenshot would look a lot better if we mapped building outlines at malls and not entire grounds as a single area… but I digress.

12

Here’s some thoughts I’ve had after mapping many lots, and viewing them in the app. I feel we’re over-engineering on the WME side. This is a proposed variant of Sketch’s.

  • Since Parking is a discrete function within the app
  • and therefore PLA’s should not be indexed for nor included in general search results, nor considered for automatic Google Maps linking
  • and “Parking” is already implied by the find-parking function, and by the blue “P” before each entry
    …putting "Parking - " (or some variant) as a prefix to almost every entry seems redundant and a waste of valuable horizontal screen space in the app. It seems like a hack to avoid changing something on the Waze back-end and/or app. This is especially important for shopping mall lots which can end up with fairly long names. Android beta (at least) has dynamic font scaling based on name length, and names quickly end up so small that they can’t comfortably be read on a dashboard-mounted phone.

I also believe that the word “parking” itself is therefore redundant everywhere in the name, regardless of position. Where needed, “Lot” and “Garage” are more concise. There is also plenty of implied restriction information that we can leave out of the two most common lot types, which are single-business lots, and shopping mall lots. The former is implied to be dedicated parking, the latter general parking.

Just like some of the other mapping decisions, we have to put some responsibility on the driver to watch local signs or otherwise be slightly intelligent; If they choose “CVS” as their parking choice for a nearby “Walgreen’s”, that risk is on them. Putting “CVS Only”, or “Customer Parking - CVS”, or “Parking - CVS” doesn’t really provide any additional information for the Wazer to use vs just “CVS”.

As a consumer of the app, I want my highest-impact information first on the line, which are often restrictions I wouldn’t otherwise infer, or extreme localizations like named lots/garage:

  • “Starbucks” (this shows as a “P” icon and Starbucks in the results. I can easily infer that parking is likely restricted to Starbucks. I’m very keen on not having “Parking - …” in front, because OLOB is going to be extremely common. It’s easy to have your full page of destination parking results be OLOB, so it slows down the visual scan for your preferred result having redundant prefixes.)
  • “Employee Lot - Starbucks” (I can quickly ignore any result that says “Employee” if I’m not navigating to my job…)
  • “Empty Pockets Plaza” (strip malls where parking choice is pretty much always based on navigating to the storefront and finding the closest spot, therefore one PLA for the strip mall)
  • “Visitor Lot - LSU Eunice” (I’m in a “visitor” mindset during my parking search, so this is a quick hit. I’m already navigating to LSU Eunice so my results are localized already. “Visitors - LSU Eunice” would also work, but for some reason “Visitor Lot” feels more natural)
  • “Macy’s Lot - Big Hill Shopping Center” (I know parking isn’t Macy’s-only; it’s a mall. Again “Macy’s - Big Hill Shopping Center” would probably be enough, but “Macy’s Lot - …” feels natural, and parking Garages are more common for malls, so seeing “Macy’s Lot” and “JCPenney Garage” gives me useful weather-based distinctions)
  • “Garage 2A - Mercedes-Benz Superdome” (My list is populated with results around the Superdome; I want to see the most-specific information first on the line)
  • “Cell Phone Waiting Lot - AUS” (again, in the navigation-destination mindset, I want my parking “intent” to get a quick visual match)
13

I could not agree more, consider Gas Stations. They are special places within the app and do not have a prefix/suffix of “Gas Station”; the same thinking can apply to PLAs especially OLOBs. As a general rule of thumb, it is best to provide the most specific information for the lot first before the associated buisness name (if there is more than one lot) and keep the name short. Plus, I would rather add the words “Lot” and “Garage” to provide a picture to the driver of what the parking lot looks like (considering weather conditions).

I would agree witth that. If there is a single parking lot for the place, there is no need to type in “Customer Parking - CVS” because it is already implied and is not public parking. However, if there is more than one lot for an associated place then we will have to add the restrictions. Perfect examples are colleges/universitiies and hospitals. So in general, if it can be easily inferred, do not type it in the name. We would also want to provide examples for each of distant types of mapping PLAs so editors referring to the wiki can match what they observe on the map. My thoughts, GDP.

14

Sorry, but what app are you using where there is a [P] icon in front of parking lots?

Maybe I’ve just been around here too long, but it is wishful thinking that staff will get everything done right the first time or even the fifth time. We need to map for the app that exists today, not the app that we wish would exist next month, because history shows it still may not exist even next year.

It is all well and good to say that PLAs shouldn’t be indexed, included in general search results, or linked to Google, but none of these things are currently true. Further, is that really the right approach? What about Google venues for parking lots? Surely they should link to themselves. And what if your employee or special event parking permit only gets you into Lot 2B - Mercedes Benz Superdome and not the others? What if you have a monthly contract to park at P247? What if your residential parking permit only allows you to park in Duck Pond Drive Lot - Virginia Tech?

No, at least some lots/garages should be searchable. Maybe in the future when we can link PLAs with Places, we can say “ok, this lot is only for Starbucks, so I’ll link it to Starbucks, and uncheck ‘Public’, and leave it nameless”, and that lot can be excluded from search (by virtue of being nameless). So maybe the point becomes moot, because we can remove the name of any lot that doesn’t actually have or need a name, and leave the ones that should be searchable.

And, anyway, it’s a lot easier to remove data than it is to add it. You can script something like removing "Parking - " from the beginning of any Place name in the Parking Lot category. You cannot script adding it when in 3 months you discover that staff still hasn’t followed through on any of this stuff.

15

+1 to sketch. The parking icon referenced by herrchin appears only to be available in the client by searching the “parking” category or when accessing the nearest lot to a place point/area. As sketch pointed out above, the autocomplete results don’t show a parking icon, and I would prefer us to be explicit and redundant until all parking lots are no longer indexed in search.

Since we’re on the topic being explicit, and no one responded regarding the one-lot-one-business rule I previously posted, I’ve proposed some draft language below:

If a parking lot serves a single business (i.e., not part of a mall or shopping center), it is recommended to name the parking lot area with the business name it serves. For example, Parking - Red Lobster.

16

My reference to the “P” icon is when you type an address or place name, and then choose from available parking options near that place. Isn’t that how almost everyone will use the feature / is the intent of the feature?

PLA’s being included in general search results seems to be a side-effect, not necessarily a planned feature by Waze? They could just as easily exclude them as they included them? Intentionally searching for a specific lot/garage name seems to be an edge case; do we know whether Waze intended for that to be functional or not? With all the PLA changes, I could see that disappearing randomly :wink: Or perhaps it’s been explicitly said to some that PLAs should be treated 100% like any other place, and that’s just not general knowledge. I do see how it does not suggest parking alternatives when you search/navigate to a PLA directly though…

I didn’t propose all Google linking being nixed for PLAs, just the automatic linking that has been complained about / that we’re architecting around with special naming guidelines. Easy enough to exclude the PLA type from the auto-matching engine.

Here’s some screenshots where all the “Parking” prefixes seemed redundant. My brain was saying to itself “Yeah, I get it, it’s Parking already!” :smiley:

17

The intent of adding Parking prefixed to name is not for those searching for the parking near their destination, it is to aid those performing a regular search for a regular destination so they do not see parking results (which are included in regular search results as well) and end up choosing a PLA instead of the actual destination place.

If I want to find a nearby starbucks and type that in the search field, invariably some of the incuded results will be associated PLAs, I want to immediately be able to scan the list, and recognize those PLAs, so I can skip over them and choose a destination that is actually a startbucks.

Don;t get us wrong, we have absolutely gone through the steps asking the developers to make changes on the back end which when implemented will eliminate the need for such fixes. These things are on the roadmap, but each update, change requires development time and resources. There are only so many developers, and so much time in aday, and resources are finite. This means that not every project, or update, or bug fix is top priority, some things always have to get 2nd place etc. Experience tells us that those features will come “Soon”, so in the meantime we must deal with the current feature set as our reality and work around it.

18

To summarize I think our problems are:

  • How to distinguish one lot from another?
  • How to distinguish one lot from its parent (sub-)place?
  • How to minimize the amount text to identify a lot?

Wouldn’t then “[P]” prefix, plus the shortest amount of text to describe the lot be sufficient?

[P] Starbucks
[P] Macy’s (standalone or within a mall)
[P] Zone B – you would be an exception to start your destination search by a specific lot area.
[P] Visitor Lot C (for university and hospitals)
[P] Staff Lot X
[P] Bravern Garage (independant garages)

19

Does HQ understand the magnitude of this one? We’re adding special text to parking lot names specifically to mitigate damage to normal place search. I’d classify this as a priority 1 fix, as it is a risk to end-user satisfaction (and thus ad revenue).

If I’m simply preaching to the choir, and “this is a top priority” has been relayed and acknowledged, then there’s nothing more to be done. Or perhaps it’s not and I’m just not aware of what really constitutes a top priority for Waze :wink:

Nagamasa, your “[P]” prefix workaround seems brilliant! Has anyone tested it against our set of problems? I’ll drop a few in myself soon.

20

Search searches all places, so no, it is not just as easy. A mechanism would have to be developed to exclude certain place types/categories from search.