They already do this for RPPs that were converted from other types and had a name given to them. The name is still part of the venue data, it’s just not searchable.
I did some testing to personally compare 3 styles. The [P] variant works as expected: doesn’t show up in search results easily without explicitly typing “[p]”. "Parking - " as a prefix also keeps the results clean it seems. “Parking” as a suffix easily causes conflict.
Here’s a nearby parking result showing the 3 styles as an end-user would experience. I’m growing very fond of the [P] prefix…
There was recent SM chat about emoji unexpectedly working in place names, and even Jane speaking them. So I threw in a bonus 4th style 
Given the current options for Parking Lot (PLA) types in WME, a new wrinkle is presents itself.
Based on the definitions above and how the app currently handles suggested Parking Lots, a Restricted or Private lot will not be suggested when searching for a venue. The Restricted/Private Lots do show up though using a direct name search.
There may not be a benefit to using the business name for the PLA if they won’t be visible as a suggested option. We ultimately need to know more about if/how these Restricted/Private PLAs will be visible in the app in the future.
Of the current presented naming options, I’m more inclined towards the “[Parking descriptor] - [Business served]” approach. I favor it more than using “[P] - Business served” or the version using the emoji since they look too redundant next to the blue circle icon already present in the UI.
Thoughts for Consideration
- If these Restricted/Private PLAs remain hidden are we better served to keep all PLAs listed as Public and apply an agreed upon naming convention?
- If we keep the lot type as Restricted/Private for a PLA, would using just the Parking Descriptor suffice for naming? Lots named “Customer Parking” or “Staff Parking” would be less likely to trigger the Google auto-linking that happens very aggressively when we utilize the business served in the name.
I’ve been told by staff, and seen from my cursory checks recently, that the names and other data has been stripped when a place is converted to RPP. Something worth checking, which would also explain the search exclusion (the name has been deleted).
I really look forward to a final decision on naming parking lots. I cringe everytime I have to work on one because I am never sure what name to use. The most painful lots are those that do not have a visible sign showing who owns the lot/ who can park in the lot. I come across these in small strip malls that dont have a “mall” name. It also happens in medium sized towns with downtown parking lots without signage. I spend an hour one day trying to find info on a lot just so I could give it an appropriate name. Here is an example https://www.waze.com/editor/?env=usa&lon=-102.07803&lat=31.99603&zoom=7&venues=169017664.1690307712.4001593
I think you made the best possible decision for this parking lot. Hopefully additional guidance will emerge soon.
Ted
I would agree with Sketch in that, while we want to emphasize (read: put first) that it is parking, we also don’t want to be too literal about it, lest it ends up reading like a package statement on some Java code or something… (sorry, a little programmers’ joke there)
Anyway, I’m totally in favor of a simple {Description} - {Larger place} where Description is either a posted name or most commonly-noticeable landmark to identify a lot at a larger place with multiple adjacent lots. Such landmarks could include anchor stores at malls, adjacent street names, etc. - whatever people would know that lot by. The larger place would be the name of the larger place if the lot is part of multiple parking lots all meant to serve the same larger place.
For example, Macy’s West Lot - Livingston Mall, or Short Term Lot B - EWR, or just Dunkin’ Donuts Lot (that’s right, I had to be different).
On a side note, I like the hyphen surrounded by a space on either side, as it provides a nice visual break, but on the efficiency side, a colon followed by a space does take up one less character for what it’s worth. I’d be ok either way.
This discussion has been going on for over a month, let’s make a decision and then we can move forward with more improvements as they are suggested. I have posted a poll since I didn’t see 100% consensus above. I did see a majority agree, and would like to make the change official so it can be used.
Everyone please vote in the poll, and reply there.
The poll results are in with an overwhelming Yes (97%). I will go ahead and update the wiki accordingly.
Thank you PesachZ,
Hopefully this will make it less confusing for editors when working on parking lot areas.
Other sections of the wiki page need updated to match the naming section, like the restricted parking section.
Thanks PesachZ,
Two questions about the Restricted Parking section: The first example is “Parking - Starbucks (customers only)” - should that be “Parking (customers only) - Starbucks” or are we listing the restriction first in these single-venue lots?
Also “123 Somewhere St Lot (residents only)” is given as an example of a nameless lot with a restriction. I assume this only has the address in the name field because that gives us something to attach the parenthetical (residents only) to? If this were a public lot with no restriction, we would still leave the name blank entirely, correct?
The Restrictions sections should already be in compliance with the updated guidance. The only change needed was for starbucks which I made already when posting.
The change wasn’t specific about restriction positioning, in the case of a single business it might be better to have the restriction at the end, or perhaps for uniformity we should move it to follow the descriptor?
123 Somewhere St, could be the legal name of the lot as well if it is an LLC or the like. It is not listed specifically as an unnamed lot. Though I could see the benefit of adding the address as a name to list restrictions if it was unnamed. But to answer your question, yes an unnamed lot should be left unnamed, and not use the address as the name.
Personally, I lean toward consistency there, especially if the restriction is what we are trying to highlight. Also, I’m seeing restricted parking lots in search results (both autocomplete and with the search button) which I thought wasn’t supposed to be the case. I’ve also seen single-venue parking lots get automatically linked to the google place for the business after saving, which is another issue altogether. I’ve not yet experimented with which name formats cause the linking to happen.
If we’re finally choosing a naming scheme, it should be consistent in it’s usage. Especially in the case of examples on a wiki explaining how to name a PLA.
I personally would lean to consistency, but we should build some more consensus from the group before changing those examples, since that is beyond the scope of what this poll was for.
All PLAs, regardless of restricted status will be able to come up in a name search if you enter a similar name. That’s why it is so important to have the parking descriptor first so they are confused for actual business places. The only place where restricted lots do not show up currently is in the recommended parking lots lists after searching a venue and then looking for recommended parking, or searching for nearby parking.
Are there really any business that offer their lots for non-customer use? I’d imagine the majority of the lots we map are restricted to patrons in some way.
Perhaps if it’s tied to a business, one should expect it to be customers/partons/visitors only, rather than editors naming it everywhere. For residents/staff only, yes I think we can keep the restrictions.
In short, if it is obvious that it is for Custumers only then we should not include it in the title. But if there are signs and such, then I would include it in the name. For anything else like Permits, Staff, Visitors only (these would almost always have signs) then we would definitely include it in the name. In short, if it’s a singular business and there are no signs, then adding restriction is not needed. In all other restricted parking, it should be added.
What I really think we should be doing is using the Restricted and Private types properly so that the system can gather its data in time for the release of the features that allow them to be used, but I fear momentum is not on my side
I would much rather use the PLA types rather than over complicate the naming by adding in restricted designations.
The key issue is that Restricted and Private Lots won’t appear as suggested parking. If we are consistent in using the types will the loss of seeing those lots be a problem?
I’ve been on the fence about this as I have zoo and college campus with specific lots that would either be Reserved or Private in nature, but it looks better to search for the venues as a destination and see the parking options available via suggested offerings.
It may not be as big of an issue with single business or strip mall lots. You’re typically parking in area adjacent the entrance, but depending on how lots are established nearby we could have odd suggestions. Do I want to see a suggested parking garage if I’m searching for a fast food place or would it be better to keep the fast food lot set as public so it’s more likely to be displayed as my closest parking option?
Definitely needs to be discussed further.
Sent from my iPhone using Tapatalk