[Page Update]Places#Area_Places_overlap

Moderator: USA Champs

Re: [Page Update]Places#Area_Places_overlap

Postby DwarfLord » Mon Jun 17, 2019 4:57 pm

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.
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2500
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1088 times
Been thanked: 1475 times

Re: [Page Update]Places#Area_Places_overlap

Postby DwarfLord » Mon Jun 17, 2019 6:05 pm

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?
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2500
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1088 times
Been thanked: 1475 times

Re: [Page Update]Places#Area_Places_overlap

Postby DwarfLord » Mon Jun 17, 2019 6:57 pm

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?
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2500
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1088 times
Been thanked: 1475 times

Re: [Page Update]Places#Area_Places_overlap

Postby DwarfLord » Mon Jun 17, 2019 7:33 pm

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.
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2500
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1088 times
Been thanked: 1475 times

Re: [Page Update]Places#Area_Places_overlap

Postby DwarfLord » Sat Jun 22, 2019 4:15 pm

Kartografer wrote:the smaller area places inside it [Ohio State University] 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've looked at this and while the intentions are certainly good, I don't think the way this appears to the end user is as useful as we would wish. But I don't think it's dreadful either. I do appreciate that stadiums are popular destinations and valuable orientation cues. I can see value in displaying their names, even if those names do "float" gray-on-gray over the campus Area Place.

The real problem here is really Waze's display limitations. So, here is a suggestion that focuses on those limitations.

In the "Overlapping" section of the USA Wazeopedia Places article:

Proposed text wrote:Overlapping

Sometimes a large Area Place has smaller eligible Area Places within it. Examples include urgent care facilities within a hospital campus or stadiums within a university. If an Area Place is mapped as a subset of another, then provided the categories render with different colors, the smaller area polygon will display within the larger polygon.

In the common case where the Places share the identical display color, however, Waze will show the name of the smaller Area Place but not its boundaries within the larger Area Place. Waze will show both names with the identical typeface and font size; drivers won't have any cues as to relative significance without reading the names. Further, to avoid overlapping text, Waze may omit a name altogether depending from moment to moment on name length, Area-Place size, and screen center, zoom, and orientation.

Because of this display behavior, the end result of overlapping Area Places may involve unintended artifacts. The name of a more important Area Place may be omitted to favor one less important, the display may crowd with many names all appearing equally important, or the names may render far enough from their true location to be less useful for orientation. To minimize such artifacts, exercise discretion when mapping Area Places as subsets of others. Guidance for some Place categories recommends using Point Places for subset locations, even if normally eligible for an Area Place. For other categories, particularly when the subset and encompassing Area Places are of the same category, it is not necessarily wrong to use a Point Place instead of a subset Area Place to optimize the end user's display experience; consult local leadership on the best approach.


I will head for the bunker now :mrgreen:
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2500
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1088 times
Been thanked: 1475 times

Re: [Page Update]Places#Area_Places_overlap

Postby Kartografer » Wed Jun 05, 2019 6:58 pm

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.
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 547 times
Been thanked: 773 times

Re: [Page Update]Places#Area_Places_overlap

Postby Kartografer » Sat Jun 15, 2019 11:38 am

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.
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 547 times
Been thanked: 773 times

Re: [Page Update]Places#Area_Places_overlap

Postby Kartografer » Mon Jun 17, 2019 5:20 pm

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.
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 547 times
Been thanked: 773 times

Re: [Page Update]Places#Area_Places_overlap

Postby Kartografer » Mon Jun 17, 2019 6:36 pm

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?
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 547 times
Been thanked: 773 times

Re: [Page Update]Places#Area_Places_overlap

Postby Kartografer » Mon Jun 17, 2019 7:08 pm

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.
[ img ]
Galaxy S9 running Pie on Mint
SM Ohio, AM New Mexico, South Dakota
Wazeopedia projects
Then you will know the truth, and the truth will set you free.
-John 8:32
Kartografer
Wiki Master
Wiki Master
 
Posts: 1181
Joined: Wed Dec 23, 2015 2:32 pm
Location: Westerville, Ohio, USA
Has thanked: 547 times
Been thanked: 773 times

Next

Return to US Wiki Discussion

Who is online

Users browsing this forum: Chronos74, jangliss, Mapman44, n4dog, RussPA