Page 2 of 5

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 4:08 am
by johnsninja58
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.

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 5:39 am
by subs5
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.

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 10:05 am
by jm6087
I guess I may be confused at what the intention is for or something (very possible) but

Proposal wrote:
    1. If there is a listing with proper name/Address, ex. National Theater Garage/2354 Massachusetts Ave, list the proper name as the PLA's primary name and use then Parking - Address as the alternate.

    2. If an alternate address is given for the actual entrance, then add that as an alternate name. Example for National Theater there is an indication that the entrance is 129 8th St, then add Parking - 129 8th St and make sure there that House Number is added to WME.

    3. Note some parking lots/garages even have signage that says "Welcome to 2354 Massachusetts Ave" as you drive into the lot/garage, especially if the entrance is on another street.

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

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 11:22 am
by voludu2
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

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 12:15 pm
by johnsninja58
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

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 12:57 pm
by Machete808
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.

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 1:16 pm
by johnsninja58
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.

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 1:31 pm
by voludu2
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?

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 1:51 pm
by johnsninja58
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.

Re: [Page update] Places/Parking lot

PostPosted: Thu Jun 06, 2019 5:12 pm
by sketch
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.