I agree. I also suspect that this is going to be a problem as we move to using waze address data for search results. It would never occur to me (well if it wouldn't if I didn't spend so much time on these forums) to search for "185 Glen Mills Rd, Concord Twp" if I wanted to visit a juvenile delinquent. Granted, I'd be more likely to search for Glen Mills School. But the same holds true for 280 Glen Mills Rd (I just happen to associate the Glen Mills with the school). Everyone that I know would associate these addresses with the Post Office of Glen Mills.

The flip side of the coin is that as far as I can tell waze addresses aren't used at all if they don't have city name. So we have guidance developed for map and report display purposes. However, it will be interesting to see how the searching is effected by our city guidance.

voludu2 wrote:By tomorrow, I expect Glen Mills to disappear from the cities layer.

Be aware that this frequently does not happen. The area may be reduced to a point, but Glen Mills may well remain in the database and display on the map and as a report location in certain conditions (although in places like PA where everything has a city name I don't know if this happens or not). To make sure that the city is gone from the database you need to use this form with the special pin code. Submission without the PIN code sit on a speadsheet waiting approval from your RC or other US Champ with access to the sheet. So its best to reach out to your RC or another US Champ about any cities that need to be deleted to have them either enter the information with the PIN code or approve your submission.

I don't think we can be as strict as only allowing municipal or CDP names. I would think, in a navigational context, city names should answer the question of "Where am I?" There are many places where publicly published information may not be sufficient enough to answer that question, especially in more rural areas. As a result, we may have to rely on local expertise, like asking around (it is a social app, right?). Consequently, trying to conform to a nationwide or even statewide standard may easily lead to subpar accuracy in city names both on the map and in search results.

City name can also depend on context of question as well. There are places in NJ, particularly the more rural parts, that can go by as many as four different names depending on the context of asking the question, where? If you're talking about where taxes are paid, it's likely the township (municipal). If you're talking about mail, or in many cases, an address, it's likely the postal city (often derived from zip codes). If you're talking about something geographically official, an area might go by a CDP name. However, if you're talking about simple colloquial references, many suburban subdivisions are known by the development name, particularly if such names are still posted on signs.

CDP names sound pretty straight forward to show on the map itself. However, for search results, it's not as clear nor as simple. If I'm searching by address, or my search result includes an address, it would be kind of weird to display anything other than the postal city name to go along with it, no?

Frankly, until we can uncouple city names on the map from ones shown in search results, on a per street-section (perhaps per-segment) basis, there really is no good answer to the city name dilemma.

If waze wants to do all the searching itself, it is going to have to come to terms with the fact that the actual location (in PA, township), the locally-accepted place-name, and the zip/mailing address are all different things.

So a person could be in Chesterbrook, a locally-accepted place name but not a municipality, actually located in Tredyffrin Township in Chester County, with a zip code from Wayne, which is a locally-accepted place name within Radnor Township in Delaware County.

Google Maps, for example, does not store city information on road segments.

Waze may have to abandon this as well, in favor of separately-editable state, county, municipality, place-name, and zip code polygon layers.

Otherwise, it continues to be a nightmare.

I agree. But doing this with segment city names is subpar.

The Glen Mills segments I renamed were not even in the map location of Glen Mills. They were just 7 segments somewhere in the Glen Mills zip code territory.

That's a problem with the current data model.

City boundaries need to be a separate, directly-editable, map layer. Possibly locked at a high level.
postal codes, with numbers and locale names (if waze is going to be very serious about adress-based searching) need to be on a separate, imported from GIS (readily available in the US and most countries that use postal codes)
"points on the map" like named crossroads, and even area locales need to have their own map level, too.

So that Glen mills is just a point within the Concord Township (the actual municipality)
And also, it is a zip code region based around the Glen Mills post office.

Exton is a census-designated area within West Whiteland Township. It is also a zip code.

West Goshen is a township. But many residents of West Goshen have a West Chester addres because they are served by the West Chester post office located in the West Chester Borough.

And so on.

Trying to put that on the road segments is overloading them. It's a nightmare to maintain.

PhantomSoul wrote:
Frankly, until we can uncouple city names on the map from ones shown in search results, on a per street-section (perhaps per-segment) basis, there really is no good answer to the city name dilemma.

Totally agree.