Good stuff then. I wanted to be sure we're all on the same page, particularly regarding (1) the need for local (state, region) authority to generally rule the day on the city name question, and (2) the general requirement that decisions be based on factual information (i.e., city/town/village/township limits and CDP boundaries) in the normal course of operation.

Other unincorporated communities (without CDP or USPS name) do exist but are typically rather hard to nail down with borders or boundaries, but local exceptions can be used in cases where an unincorporated community can be reasonably defined. Just came across an example of this today (Crown Point, LA) which had already been mapped.

I agree with Kartographer's draft changes.

DwarfLord wrote:

sketch wrote:Other unincorporated communities (without CDP or USPS name) do exist but are typically rather hard to nail down with borders or boundaries, but local exceptions can be used in cases where an unincorporated community can be reasonably defined.

Could we go so far, at a national level, as to say that a USPS name is a necessary (but not sufficient) condition for mapping a city using segments' primary name field?

Some CDPs do not have USPS names. For example, the University of California at Davis has its own CDP separate from the town of Davis. However, all the mailing addresses within the University use Davis as the city. Unlike the fairly unique example of Stanford, California, the University does not think it is located in the "City of UC Davis", the dedicated CDP notwithstanding.

Allowing city names uncorroborated by USPS seems perilously close to mapping neighborhoods, which it's been my understanding we don't do at the present time.

We can do this at a state level of course, but if there might be national agreement on that, better still.

No, I don't agree with this. I've been working a lot of city names in Louisiana the past few weeks and been learning a lot about them. There are CDPs with names I'm quite familiar with but which aren't used as the primary USPS name anywhere.

In fact, very near to me and adjacent to my own CDP (Metairie, which is also the USPS name), there exist a trio of places—two CDPs and an incorporated city—which all share the 70123 zip code, the preferred USPS city name of which is, inexplicably, New Orleans. They are not in the same parish as New Orleans, nor are they immediately adjacent to New Orleans or Orleans Parish (which are coterminous), separated therefrom by the CDP named Jefferson, ZIP code 70121.

These 3 names are known to everyone in the area, and one of them, Harahan (pop. 9,277), is a city with its own mayor and police department and everything. The other two are River Ridge (pop. 13,494) and Elmwood (pop. 4,635; but mostly commercial & industrial). No one in their right mind would ever dare call any of these "New Orleans".

That alone is reason enough that such a rule can't work in practice. Those aren't the only examples, though.

At any rate, CDPs are designed by the Census Bureau to represent communities of people as they are known and as they exist on the ground. USPS decisions on mail routes are not primarily concerned with such analysis, and are largely decided for efficiency of mail delivery.

Further, I would argue that the information we have access to on CDP boundaries is more reliable and trustworthy than information we have on exactly the extent of USPS city names and zip codes. There is a CDP named Paincourtville, a community with a population of 911. If you believe the "USPS routes" found by USGB, there is no ZIP code or USPS city name for Paincourtville; it is bisected by the ZIP codes for Belle Rose (itself a CDP; pop. 1,902) and Napoleonville (a village, pop. 660). If you believe the ZIP code map layer also found by USGB, there is a Paincourtville ZIP code, but only about half of the Paincourtville CDP and community is in it, and the other half is in the ZIP code for Napoleonville. Who to trust?

I don't know, but I know that the city limits imported by Cities Overlay are pretty darn good, and the CDP boundaries are too. I can be confident that Paincourtville is Paincourtville, that user reports will include the city Paincourtville, that people who live in Paincourtville can give their address as Paincourtville, that Paincourtville will be accurately represented on the map, etc.

One thing I did worry about is the way that search works for CDPs that are thought of more as neighborhood names than as city names. But my worries were allayed when I tested it myself. Timberlane (pop. 10,243) is a CDP that is often thought of as a neighborhood of Gretna (pop. 17,736; parish seat of Jefferson Parish), as it is "Gretna" per the USPS. "Timberlane" is a name I've heard many times before, so I decided to see what would happen if I changed the primary name of all the streets in Timberlane to Timberlane, and ensured the alt name Gretna was present. Well, searching for an address in Timberlane with Gretna as the city name, you'd never know Timberlane was there at all. You get "400 Bellemeade Dr, Gretna" as your search result as if that's the only name. Meanwhile, you get the useful "Timberlane" labels on the map and in road reports.

Whew, I'm getting a little long-winded here. Point is, it won't work here. I don't think the existence of a USPS name is a necessity. I think these are communities that exist with names that are known, otherwise they wouldn't be CDPs. My not having heard of a CDP name 45 minutes away doesn't mean that the people who live and drive in that area aren't familiar with the name of that community. I have seen enough examples of CDPs for places I do know about that I consider the CDP to be a good indicator of location and surely worthy of being on the map. And given that they're invisible in address searches that don't use them, all the more reason.

DwarfLord wrote:To be clear, my thinking was not that a city name must be a primary USPS name to be eligible, but that it simply be corroborated by USPS. USPS is able to recognize/support different city names for the same zip code; that's good enough for me.

So, using the USPS tool for looking up zip code given city and state, I tried some of the names you listed. Results:

[...]

(For "Timberlane" USPS spit back "Timberlake" -- different town?)
TIMBERLAKE LA 71485

(Three results for Gretna)
GRETNA LA 70053
GRETNA LA 70054
This ZIP Code™ used for a specific PO BOX
GRETNA LA 70056

With the exception of Timberlane, the USPS recognized and was willing to handle all the names you mentioned. So all of them except Timberlane would pass my proposed necessary-but-not-sufficient test for a valid city name. From what you said it sounds like Timberlane is kind of on the hairy edge of being a neighborhood?

Timberlane is entirely within 70056, which the City Finder by ZIP Code says is "Gretna" but you can also use "Terrytown". Timberlane is not mentioned. Terrytown is its own CDP, part of which is also in 70056, and it's more of a household name than "Timberlane" (but which is still well known particularly to people who live on the Westbank). It's also more than twice the size of Timberlane.

I can understand your position given the examples I've seen so far, but nevertheless I do believe such names are helpful and useful for things like road reports and map display (in that, e.g., "Heavy traffic, Belle Chasse Hwy, Timberlane" gives you more specific information than "Heavy traffic, Belle Chasse Hwy, Gretna" does, or would if we required the USPS corroboration). Given that address searching shows you the city name you searched for regardless, I don't see a downside.

DwarfLord wrote:p.s. I'm definitely not proposing using anything from the USPS to determine boundaries! My proposal regarding USPS was just as a verification step for city names.

Good, just want to be sure we're on the same page again. As I understand it you're saying "you can use the CDP name, with the CDP's boundaries, as long as somewhere (I mean, somewhere in or near the CDP, whether or not there are any associated routes or boundaries), the USPS says it's an acceptable city name. Again, I understand, I just don't agree based on the examples I've come across so far.

DwarfLord wrote:Sketch — I just looked at this location (you mean 400 Bellemeade Blvd, not 400 Bellemeade Dr, right?). There do not appear to be House Numbers for that street on the Waze map. Using the app to search for 400 Bellemeade does return Gretna, but isn't that because it's getting the the pin from Google, which returns Gretna? Would the Waze app search switch to Timberlane if the HN were enabled?

Sorry, it was Westmeade Dr I'd put all the HNs on so far. I knew "Bellemeade" was the name of the subdivision and also a street in Timberlane, but that's about all I got right

As I understand it, all or virtually all address searching in Waze is done by matching from Google one way or the other.

When you search "404 Westmeade Dr, Timberlane" in Google Maps, it brings you to the right spot but displays "404 Westmeade Dr, Gretna". At this point, "404 Westmeade Dr, Gretna" is passed along to Waze, which finds its HN match, 404 Westmeade Dr, Gretna, through the alt name.

My belief, therefore, is that the resolution of "Timberlane" to "Gretna" for addressing purposes is happening Google-side, before the search for the HN is done.

At any rate, Google is handing Waze "404 Westmeade Dr, Gretna", and Waze is showing us "404 Westmeade Dr, Gretna" from the alt name.

In most situations, the user would be searching for the address with the USPS city name anyway, which should be in the alt name in many cases. The fact that Waze returns the search result with that alt name instead of with whatever the primary city name might be is particularly encouraging to me. In this case, we can try to trick it, but Google won't let us.

I believe that gives us latitude to use city names that would be helpful in map display and on alerts but aren't always helpful for addressing—because they won't be used for addressing where they aren't wanted.

As I understand it, there is roughly 0 chance of Waze ever moving to a totally native search, because it's something that Google is pretty good at and something that is really hard to develop.

I never quite understood the reasoning for that. I've still got the "LSU" city name in Baton Rouge that I've never gotten around to doing anything about. Maybe it was to allow for the display of area places on campus (because Waze still can't figure out places within places unless they're different colors, I guess).

Of course, all that being said...







I do think you'll find some conflict with the Military Bases guidance unless you allow specifically for it.