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.

This lot is not identified by the address. "901 New York Avenue NW" is the name of the high rise building behind it. The lot serves the building, it is not standalone.

https://en.wikipedia.org/wiki/901_New_York_Avenue

That fits into my proposed clarification of the current framework and does not support your proposition.

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.

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

I appreciate the opportunity to speak my piece. The responses, and those hitting the "thanks" links to them, are making clear that my proposal will fail. That's fine, this is how things work here, I'm cool with that, grateful to be able to say anything at all.

Some observations, upon withdrawing my proposal...

The distinction between tactical and strategic is brilliant. Chess vs. Checkers. I like it. But I'm not convinced it fits when dealing with Waze. Past experience with other aspects tells us it's almost certainly dead because there are too many other pressing needs. And even if it does miraculously come back to life, it will be reborn into a modified form wrought by lessons learned, and it's doubtful that the saved PLAs will be absorbed into the new plan without a fair number of major changes and editing to make them fit the new mission. Major changes with a workload awfully similar to starting anew. At that point, what difference does it make....fixing the bad data vs. making new ones? Not much. In the meantime, while we wait (just in case), we have this clutter and misdirection, when we could have clean simplicity. But barring a cadre of Champs suddenly agreeing with me, I know the debate is over.

Also, the issue of PLAs named for relocated or defunct businesses is going to get worse over time. Do we have any ideas how we are going to stay ahead of that, or just live with it?

Thanks for the discussion.

I know we say never delete, but that should be considered here. The map purists among us already practice deletion when they find unnecessarily complicated mapping work. Deletion is an acceptable and viable solution to avoid obfuscation and data pollution.

In general, Places are already an editing maintenance black hole, there's no way to keep up. But now thanks to past guidance, we have huge numbers of PLAs named for specific businesses. With Google place linking, we have a means to detect when a business linked to a PP closes (thank you WMEPH), our attention is helpfully called to the problem so it can be fixed. But we presently have no way of automatically detecting when a PLA is named after a business that has closed.

People search for a business by name, see the PLA in the Waze results and may or may not even notice that it is a parking lot, and when they get there.... it's gone and all they find is this not very helpful PLA still named after the place, though. Great. That's accidental bait-and-switch, and I think we all know how we would feel about any search service that does that to us, intentional or not. We'd dump it immediately.

Our collection of business-named PLAs is only a couple years old now, but as they age in place, this is going to start becoming a bigger problem as more places close and move or are otherwise renamed. Do we really want to devote a sizable portion of our limited editor man-hour resources and develop methods of tracking all of these business-named PLAs for closures, to keep them current? To support an abandonware feature that even at present provides dubious actual value, and from all outward appearances is never going to be developed further?

We have to be smart about how we invest our editing/monitoring resources. The Parking Project is presently not a wise place to invest, and over time left alone is going to become increasingly damaging to the average Wazer's experience through the accidental bait-and-switch events that are already happening.

I'm going to plug my suggestion from before, that looks like parking guidance before the Parking Project: Only map PLAs for (1) general-purpose parking areas open to anyone for any reason, (2) park-and-ride facilities, and (3) specifically named lots for larger campus installations that could be individually sought. In all three of these cases, their names are extremely unlikely to change often if ever, and maintenance demands will be quite low. The rest of them, IMO, are unhelpful clutter baggage and future-maintenance black holes, and should be removed.

Sorry for exceeding my soapbox time limit.

DwarfLord wrote: That being said, for the community to deliberately and explicitly depart from Waze's official guidance is...well, rebellion. Is rebellion the correct response to abandonment? Maybe. But that's sure above my pay grade.

Well, I sure wasn't intending to propose a mutiny. But yes, you captured the tone of the frustrations well.

Perhaps if we can gain a notable consensus amongst editors and testers with influence that this warrants attention and resolution, we can then establish a coalition in fundamental agreement before taking the issue to HQ?

So, is there anyone opposed to changing the rules back - as long as we get an acknowledgment from HQ that the project is dormant or dead?

Kartografer wrote:

SeveriorumPatrem wrote:Third criteria... Park and Ride lots. Named and set to restricted. They should be a destination, not a suggestion when you're doing something unrelated.

Why? If they're public, and you're going somewhere nearby that doesn't have parking, why shouldn't you get them as a suggestion?

The falls under criteria #1 - available for anyone to park in for any reason. As opposed to restricted to mass transit and carpooling users.

Third criteria... Park and Ride lots. Named and set to restricted. They should be a destination, not a suggestion when you're doing something unrelated.