[Page update] Places/Parking lot

Map Editors Community United States US Wiki Discussion
1

This wiki implies there is still urgency to create PLAs. Combined with the numerous problem alerts present on maps in my local area of missing PLAs, I began working on creating these. Over time, I’ve found most of them deleted without any explanation. After discussion on Discord, I now have a better understanding of why this is not as urgent.

This wiki should be updated to deownplay the need for PLAs for small parking lots. It’s frustrating as a L1 editor to have work removed when official sources tell me they are needed.Further frustrating to not have an explanation until I bought it up in the #mentoring channel.

https://wazeopedia.waze.com/wiki/USA/Places/Parking_lot

2

The notice at the top of the page was placed to alert everyone at the time the parking lot changes happened, and most likely should all be integrated at the appropriate points in the article.

Can you say more about the specific guidance you have received, and how it is different from the guidance on this page? Thanks.

3

As a general rule, the national guidance is probably still good.

I do question whether

in the top banner should still be included. The client is not being updated and most/all regions have probably gone with the attitude that feel free to add them but they aren’t that urgent since the feature is on the back burner.

But overall, as has been discussed in Discord, we don’t tell anyone not to map them, we just say there are much better things to spend time on. But that is technically a regional guidance.

4

In addition, It would help if “Missing Parking Lot Place” MPs were no longer pushed to WME. And even better if existing ones were deleted, pending further updates in PLAs.

5

That would be nice. It does give rank 1 editors in “mature” areas of the map something to do for the time being.

In the meantime - who can suggest where each of the little bits in that box at the top of the page should find its correct place in the body of the article?

6

Propose to allow using Parking - Address when that is the name used by a parking lot operator. Especially if the parking lot’s entrance is not near the address of the lot/front door. This will help someone who searches for the address, they can be routed to the front door to drop someone off or if desired will see the “Parking - Address” and be routed to the location to park on a side street, the street behind the main address or an alley/parking lot road between buildings when the parking lot’s/garage’s entrance is not visible from the address pin.

Please not that this guidance is not for general parking at a store like Starbucks or where several stores share a parking lot at a strip mall. The address would not be used. This is only for when the address is used as the proper name of a parking lot/garage by the operator of the lot/garage (or a parking lot finder app).

My proposal is here.

A change display from the current wording is available here.

7

The “Parking - [name]” format is only appropriate for parking lots associated with other places. To the extent that this applies to, say, a skyscraper named 930 Poydras which has an associated parking garage, “Parking Garage - 930 Poydras” would be appropriate.

This proposal is not appropriate, however, for public lots that simply use the address as the name. It would upend the current guidance for public parking lot places, which is to use the official name of the parking lot alone (e.g., “Grove Street Garage”), the official name along with the operator (e.g., “P249 - Premium Parking”), or to leave name blank if there is no name (and allow the address to show).

8

For parking lots that are identified by an address by the operators and that have an entrance on another street. Open to suggestions on how to address this problem. How do you suggest that we provide proper guidance to the entrance particularly when the entrance is not visible from the HN or RPP anchor point?

Understand that this is a major change from the current guidance, which is why it is proposed so that there can be discussion. I don’t understand why a proposed change is not appropriate if the change can improve the routing for users. Proposing the change does not mean that it has to be made; changes like this to the wazeopedia are only made if there is consensus.

This is only for garages that have the address as their official name from the sources that people use; whether it is the operator’s website or a parking lot finder app/website.

9

I might be missing something but this proposal is meant to be along the lines of what Sketch previously mentioned for hotels, to match what they list on their website. This is just to match what is listed by the parking lot operator’s website or a parking lot finder app/website so that Waze users can easily identify the lot for their location, especially if it is not visible from the location of the building’s address.

10

I may be using the app differently. I am usually searching for a venue and routing there and relying on suggestions in the app for parking. If the lots include the name of the venue, they will generally display in instant results. So I’m not consulting parking-lot sources or websites that may have the address listed as the name.

Eventually, won’t the PLAs be linked to relevant Places that they serve? Meaning that when you search for a specific venue, appropriate parking lots will be suggested? (This is realizing the enhancement of the parking lot/Place linking won’t be available until “soon,” of course…)

Using the address may have some utility in the near term, if I understand you correctly, but I’m not sure I understand the longterm advantage, given the plans for the feature. And I’m imagining that it might be confusing if the lot is used for venues associated with another street address.

11

I think the future of what is in store for the Parking Lot Area project is quite uncertain…

In terms of parking lots that have names, we have one in Boston that clearly identifies itself as its address.

IWe also have the former John Hancock Tower, now called by its address (Globe Story on name change).

To ignore or not use a companies name because it is also the address, you loose out on the components of a place including: hours, details, proper entrance. Sure the address would also populate in the search results, and maybe one day Waze will give us the tools to link them together. I dont think that is enough of a reason to change the name of a business from what the company calls itself. I do agree that PLA should not be named by their address solely for the point of having a name, however in the circumstances that subs5 presented, where there is a business name that happens to be an address we should use it.

12

If you search for a business and have the app suggest parking locations this has no affect on the current state. If you search for an address of the location either from knowing the locations address or using the provider’s name of the lot or using a parking app to suggest a lot to park at, then you will see the front door of the location as the address and also have the Parking - Address show up. The entrance to many lots on a major street are often not on that street since that is a loss of prime real estate (think prime location store front rental being more than the place around the corner with the same address). The pin for the parking lot would be to the actual location of the entrance not the store front.

13

I guess I may be confused at what the intention is for or something (very possible) but

#1. I don’t see a need to add the address as an alt, wouldn’t that be handled by an address search in the app. We don’t do this for business, we just add an RPP (if needed) to cover the person searching for the address.

#2. You can name the stop points for when phase 2 or 3 of MEPs is active.

#3. If the official name of the lot is actually 2354 Massachusetts Ave then it should be named that but being that is just the address of the building, it is would be covered under the either the building place (if it is a valid PP) or by RPP/HN (if needed) to cover address searching.

14

If there is no compelling reason to put the address in the primary name, then I agree that there is no compelling reason to put it in the alternate name

15

I agree there is no need for alt names to be an address and cases that come up should be dealt with at a local level with your respective SM

16

OK, I’m a bit clearer on the concept: The Wazer who enters the address of the parking lot will get both the HN and the address-named PLA in the instant results.

I’m still thinking about how many people are likely to do that, though, and whether that formatting would be an advantage very often. Most people, if they enter a street address, search for the address of the end destination. Using the address as the primary name of a parking lot seems duplicative.

My own habits with the app are different, I guess – but continuing to play a bit with searches and results.

17

You have the heart of the issue. Is searching for an address duplicative process for a PLA?

Usually I would agree, we are trying to look at a small subset scenario where the business name is the address. I think another layer to this debate we haven’t discussed is if a business name is an address how would that work with an external provider result? That could be polluting our result field as it is, and with the 100 Clarendon Parking Garage scenario I listed, the PLA is directly over a freeway. Using other place data could result in undesirable search results. Granted this is resolved by place linking regardless of the PLA name.

18

We already have a lot of cases where the wazer searches for an address on one street, and is directed around the corner to a side street to get into the parking lot.

Would this situation be best handled by replacing the HN for the address with an RPP?

19

Maybe, scenarios where the parking garage name is the address should be handled on a case by case scenario with local leadership guidance and not explicitly forbidden. There are many nuances and clearly differences of opinions. How many entrances, where the entrances are, public vs restricted/private etc.

20

I’m not saying the proposal should be rejected wholesale, but I don’t think it’s proper in most cases.

Users searching for an address expect to find one result for that address, and they expect it to take it where they expect it to take them.

For a public parking lot not associated with a building and which is the only thing for that address, address search should work the same, providing only one result for 123 Jefferson Ave, which will take them where they want to go.

If a regular HN is inadequate for this purpose, RPP and/or PLR can and should be used, like any other address. This will continue to ensure the best experience for all users, who select the lone address result for that address, as is proper.

The appropriately unnamed parking lot place which is there allows for the primary intended usage of the parking lot feature: the selection of that lot from a list of parking lots nearby to you or your destination.

If the lot is named simply with the address, (1) that list will show the address twice, a la
“930 Jefferson St
930 Jefferson St, New Orleans”
which is redundant and can take up unnecessary space in the list; and (2) search results for the address will now be polluted and confusing, with 2 results for 930 Jefferson St: an address result and the parking lot. Users who aren’t regular and knowing editors (i.e., essentially all users) will not know or understand the difference and will not know or understand which is the better result.

So, you end up with essentially all users not necessarily going to the right place, or not knowing what the right place is. The Google address result is always going to be there, and we can’t do anything to stop it. Our best practice, therefore, should be to provide one and only address result to users, and to ensure that it navigates as best as it can, whether with HN, RPP, or RPP + PLR.

Naming the lot “Parking - 930 Jefferson St” instead doesn’t really help with the user selection issue. This could either make it more or less confusing, but it doesn’t fix the problem, you’re still providing 2 results for 1 location in 1 search, and the nearby parking list is still redundant (except the problem of taking up extra space is even worse).

Now, all that being said,

There is a limited case that perhaps should already allow for the format “Parking - [address]”, and that’s where a building is known by/named for its address. There are a few skyscrapers in downtown New Orleans named things like “930 Poydras” for example.

There is also a case to be made, perhaps, for a lot with an operator name (say, “Premium Parking”) which has a lot named after an address (say, “882 Jefferson Ave”) to be named in the normal way that a lot with an operator is named, e.g., “882 Jefferson Ave - Premium Parking”. But there is also an argument that this still creates redundancy, in that you’d get the same amount of information from a result that says,
“Premium Parking
882 Jefferson Ave, Citytown”
as you would from a result that says,
“882 Jefferson Ave - Premium Parking
882 Jefferson Ave, Citytown”
but without taking up as much space in the interface, as the latter is likely to wrap onto multiple lines of text.

But I would not want to go much further than that. The normal format for standalone public lots is just “[name]” where there is a name, and no name where there isn’t. Anything more pollutes address search. Further, because it has been our standard for quite a long time, “Parking - [name]” implies that the lot is a parking lot associated with a separate location called [name], and is therefore not appropriate for standalone lots.