I agree with it, except for (as discussed in Discord) the last sentence. That would read better as "Overlap has no effect on labels" since size and zoom cause some labels not to be displayed, at least when zoomed out some.

When I updated the places page with MEP guidance, I added information about this as well (it had been in my draft before this topic was started) and about colors of certain area place categories. Here's how the section reads now:

Overlapping{{Anchor|Area Places overlap}} wrote: Sometimes a large area place has smaller area places within it. Examples include different medical buildings within a hospital campus or separate malls within a large shopping complex. Smaller area polygons are shown on top of larger polygons. However, if the the colors of the places are the same, Waze will show only the names of the smaller area places but not their boundaries within the larger area. It may be a better approach to use point places for the components of a larger area place unless it is essential that the subset place names be visible. Future versions of the Waze client may render overlapping area places more usefully.

The stuff about using point places where same colors overlap has been in there for years. Are we saying that should go away? I would be fine with it; I find the labels useful on overlapped area places. For example, it's nice to see terminal numbers at an airport.

DwarfLord wrote:

Kartografer wrote:The stuff about using point places where same colors overlap has been in there for years. Are we saying that should go away? I would be fine with it; I find the labels useful on overlapped area places. For example, it's nice to see terminal numbers at an airport.

The reason that was in there was because many editors at the time felt that the Waze app display did a lousy job of displaying Area-Place-within-Area-Place locations. As well all know, what happens is that text "floats" unmoored in the general vicinity of the embedded Area Place. The driver is given no precision as to where exactly the labeled Place is. Under some circumstances the effect was thought to be jarring.

It is moored, but it is not fixed. The mooring is the invisible polygon, and the text will display over some part of the area polygon, but it may not be the same part in every view. That's how all area places work. Labels on overlapped places are not incorrect information, just incomplete. Removing this information is not working around some problem, and no one is relying on wishful thinking. If a place is worth displaying as an area, its label is more useful to see than not to see.

DwarfLord wrote: However, at the time of the original guidance, there were other examples -- generally in areas with clusters of several embedded Area Places -- that led the community to craft that language. In such cases it was judged that reducing driver puzzlement and/or frustration caused by these floating names could outweigh whatever benefit they conveyed. Driver puzzlement resulting from Waze's native display behavior is a problem, and adjusting our editing practice to reduce it is working around that problem.

Editor perspectives about Area Places, and our judgements about what drivers think of them, seem to differ radically from one editor to the next. Perhaps we can soften the language without eliminating it?

So where does this currently this cause driver puzzlement and frustration? Could it have been from parking lots, before most parking lot places displayed differently from other area places?

Maybe the labels used to float around more freely than they do now. They seem to show in the center of the place unless the polygon is partially off the screen, in which case they move to be easier to see. Parking lots, except for giant ones, display at a different color at day and at the same color at night, but their names are not shown, so it doesn't matter. I work close to the Ohio State University, and the smaller area places inside it look fine to me. You can see where various stadia and other facilities are. It is not confusing in the slightest; it would be really weird not to see the labels for at least some of these places.

I can get down with the "use discretion" thing here, but I do not see names rendering far away from their true location just because of an overlap, nor do I see more important names being hidden by less important names. At least part of the label is over the area place always, though the position of the label varies with zoom levels. I do see how the text size of names is always the same, independent of the size of the place, but this is no different for places that are side-by-side. The only real negative side effect is that the name of a smaller place may be mistaken as labeling the larger area place around it, like Celeste Center (a specific building in the middle of the Ohio Expo Center) being understood as the name of the entire Ohio Expo Center. You can imagine I'm just panning around my location in Waze The "part being mistaken for the whole" effect is reason enough for us to recommend discretion with overlapping area places. Do you have examples of omission or displacement?

Kartografer wrote:The stuff about using point places where same colors overlap has been in there for years. Are we saying that should go away? I would be fine with it; I find the labels useful on overlapped area places. For example, it's nice to see terminal numbers at an airport.

The reason that was in there was because many editors at the time felt that the Waze app display did a lousy job of displaying Area-Place-within-Area-Place locations. As we all know, what happens is that text "floats" unmoored in the general vicinity of the embedded Area Place. The driver is given no precision as to where exactly the labeled Place is. Under some circumstances the effect was thought to be jarring.

Since the Area Place display behavior has changed only slightly (in five years), I'm not sure why this floating-text behavior should now be considered OK. I guess we could say that we should no longer worry about this because we all know it's bad, so one day Waze will improve it. Maybe they will, but with apologies to Rumsfeld, don't we go to edit with the display we have, not the display we wish we had?

I do agree that using PP instead of AP for something that would ordinarily get an AP is inconsistent editing practice and annoying. I wish Waze would fix the display instead of us having to work around it. But I'm not sure that is sufficient rationale to stop working around it.

Kartografer wrote:...the text will display over some part of the area polygon, but it may not be the same part in every view. That's how all area places work. Labels on overlapped places are not incorrect information, just incomplete. Removing this information is not working around some problem, and no one is relying on wishful thinking. If a place is worth displaying as an area, its label is more useful to see than not to see.

I think I understand your point, but the devil may be in the details. You may be thinking of specific cases, such as a huge state park with one campground, that itself covers a large area. In such cases I agree that there is little harm, and potential benefit, in displaying the text "floating" over the general area of the campground. In fact I recently created just such a situation, so I am guilty of putting an Area Place within another Area Place; the result looks a bit silly but I think it is a net win because, as you say, the floating campground label is not absurdly detached from the campground location. I do agree guidance should be more flexible in this respect.

However, at the time of the original guidance, there were other examples -- generally in areas with clusters of several embedded Area Places -- that led the community to craft that language. In such cases it was judged that reducing driver puzzlement and/or frustration caused by these floating names could outweigh whatever benefit they conveyed. Driver puzzlement resulting from Waze's native display behavior is a problem, and adjusting our editing practice to reduce it is working around that problem.

Editor perspectives about Area Places, and our judgements about what drivers think of them, seem to differ radically from one editor to the next. Perhaps we can soften the language without eliminating it?

Kartografer wrote:

DwarfLord wrote: However, at the time of the original guidance, there were other examples -- generally in areas with clusters of several embedded Area Places -- that led the community to craft that language. In such cases it was judged that reducing driver puzzlement and/or frustration caused by these floating names could outweigh whatever benefit they conveyed. Driver puzzlement resulting from Waze's native display behavior is a problem, and adjusting our editing practice to reduce it is working around that problem.

Editor perspectives about Area Places, and our judgements about what drivers think of them, seem to differ radically from one editor to the next. Perhaps we can soften the language without eliminating it?

So where does this currently this cause driver puzzlement and frustration? Could it have been from parking lots, before most parking lot places displayed differently from other area places?

My recollection is that the original problem occurred mostly at airports and at various kinds of campuses, especially medical campuses with their Area Place exemption, where editors had mapped various buildings and destinations with Area Places, sometimes with long names. All that showed up on the app was a uniform gray polygon with multiple long text labels floating around it and occasionally interfering with each other. This was long before Waze made parking a thing, so I don't think parking lots were part of the original problem.

I need to repeat this test, but just recently I had the impression that parking lots within larger conference/event center area places display with a different color in the daytime theme, but with the identical color in the nighttime theme. Where's the Pepto-Bismol?

Well, perhaps it's not the problem it used to be. I believe our Area Place eligibility guidance tightened up also since that time, which would reduce the scale of the problem. I will check out Ohio State and see if I can find other example situations.

p.s. Thanks for confirming I'm not going crazy that Parking-Lot APs within other APs do indeed disappear at night. You're right, if there's no text, then not part of this issue. Just one more idiosyncrasy.