I don't really have a dog in the fight either way but I do think we need to decide as I have more than my fair share of discussions about this particular subject in the editor chat. Do we even have a definitive list on which place areas do and do not suppress traffic reports?

A question for Alan regarding his comment about "recommend parking places for a place". Are you talking about being able to set a destination Point like an area or a house address. If that is the case than I am failing to see what mapping parking lot areas separately has to do with this particular issue.

If it was along the lines of Student Parking B doesn't that become served even better as a point?

I think the questions for some of those are different than others. (For instance, where would we map parks other than at the fence line? A park is an area of land, not a building.)

I believe what would make Waze look a lot better while answering a lot of these questions — and I've said this before — is the ability to have a lighter-shaded "grounds"-type Place and a darker-shaded "building" place. Name the grounds "Lakeside Shopping Center" and leave the building blank; name the grounds "Tulane University" and the buildings "Reily Student Center" and "Diboll Complex" and "Weinmann Hall"; name the grounds "DTW – Detroit Metropolitan Wayne County Airport" and the buildings "North Terminal" and "McNamara Terminal"; and so forth.

Not that this can't be accomplished navigationally with stop points and point places, but it'd make identification of an airport vs. a mall vs. a college campus a lot easier.

Some parks are historic in nature with buildings that may be destinations. For example, Fort Worden State Park rents out former officers' homes for special events. So even with parks the conflict between footprint and fence line can arise.

To me the conversation is going in the direction of both fence line AND footprint, as sketch recommends. This is great as far as I am concerned, except of course that (1) the current version of WME makes it a bit awkward to handle Area Places within Area Places, and (2) the current version of the app doesn't display them as layered. Are these capabilities slated for improvement? Maybe nobody who knows is at liberty to say...

How about this proposal: AT MINIMUM, map certain types of destinations to the fence line with a single expanse that incorporates all structures, parking, and open space, as per long-standing convention. Then, should an editor wish to ADD specific structure outlines within the area, go for it, provided the structures satisfy some principles for an Area vs. a Point.

It's true that this means building outlines within a campus won't render nicely in the current versions of Live Map or the app. On the other hand, what if hordes of good editors, who read the wikis and the forums and try to do the right thing, get rid of those fence-line Places -- and then in a few months sketch's recommendation is supported and all those fence-line Places have to be put back? Angry natives...

If the feeling is that we shouldn't do anything that doesn't render well in the current version of the app regardless of what capabilities may be coming, then I would say we hold off sacrificing the fence line for the footprint and rely on Point Places to represent buildings. For now, anyway, until Waze's road map for overlapping Areas is revealed.

Based on this conversation, I'd like to add this to the == Area == section of the Places wiki. I've edited this since I first posted it, significant edits in boldface.

=== Extent ===

Some locations appropriate for an Area Place may involve one or more structures as well as open space, roads, and parking. In such cases, particularly if these components form a unified complex or campus with an overall identity, the boundaries of the Area Place should encompass the entire property (i.e., "mapped to the fence line"). This will ensure that clients render and label the Area Place with the correct significance when viewed with reduced zoom.

Other appropriate Area Places whose property lines are substantially identical with a structure may be drawn, if desired, to approximate the structure's outline or footprint.

=== Overlap ===

At present, the Waze client renders overlapping Area Places without distinct boundaries. As a result, users cannot visually distinguish Area Places located within other Area Places except for the text labels. This limits the utility of drawing Area Places subset within a larger Area Place, for example, creating building outlines within a large hospital campus.

Future versions of the Waze client may render overlapping Area Places more usefully. In anticipation of this, subset Area Places, such as building outlines, may be created within larger Area Places now. However, the recommended general approach for the present is to use Point Places for the components of a larger Area Place unless it is essential that the Place name be visible in the current version of the Waze client. If overlapping Area Places do render more usefully in the future, eligible Point Places may be converted to Area Places at that time.

Here's my take: Overall, I agree with what nzahn1 said. However, there is a potential caveat to using the fence-line approach to many places. Having dealt with numerous URs that resulted from Waze routing drivers to roadway nearest (especially freeways) to the pin or area, I can see there being potential routing problems if editors use the fence-line approach. If an area place is surrounded on all 4 sides by roads, there is likelihood that Waze will route drivers to any one of the 4 roads (whichever one is the shortest drive for them), even if only one of those sides provides access.

I can still see reasons for going to the fence line though. In fact, I dealt with a UR yesterday in which Waze wanted a driver to take a circular route around a specific set of segments on a road that had no problems with it at all. Since I wasn't able to find any problems with any of the segments in the area and LiveMap routed me properly on some test routes, I concluded that Waze might have received erroneous speed data from a Wazer who might have been sitting in the nearby In-N-Out Burger drive-thru with their Waze client still running. As nzahn1 suggested earlier, this could be a good case for having an Area Place that is drawn around the entire property.

In the interest of preventing potential routing issues related to "nearest roadway", I think the use of PLRs should be strongly encouraged so as to force Waze to route drivers to the point/area using the proper roads/driveways required to enter the location.

ScottZane wrote:Having dealt with numerous URs that resulted from Waze routing drivers to roadway nearest (especially freeways) to the pin or area, I can see there being potential routing problems if editors use the fence-line approach. If an area place is surrounded on all 4 sides by roads, there is likelihood that Waze will route drivers to any one of the 4 roads (whichever one is the shortest drive for them), even if only one of those sides provides access.

(...)

In the interest of preventing potential routing issues related to "nearest roadway", I think the use of PLRs should be strongly encouraged so as to force Waze to route drivers to the point/area using the proper roads/driveways required to enter the location.

Curious, does this still happen even if the Stop Point for the Area Place has been located correctly?

A big problem going forward is probably going to be the default Stop Points on zillions of large Area Places being somewhere in the middle of a property rather than at the natural destination point. For example, a stop point in the middle of a massive park instead of on the visitor center, or on the golf course's 9th hole instead of on the club house.

If I understand how it's supposed to work, correct Stop-Point placement plus coordinated use of streets where necessary to get you there would address most routing issues.

The main objection to "fence line" mapping for which there isn't (currently) any good solution is that, when one is near or in the Area Place, it renders visually as a big undifferentiated colored expanse with text that floats around. The technical term for this effect appears to be "blob" .

Well I sure don't like the blob effect either, but as the Waze rendering engine is going through massive changes to support Places, I really don't want to see us start a campaign to undo the long-standing fence-line practice before we have a concrete idea of where the Waze renderer is taking us.

(Edit: What if Waze HQ is using our maps to gauge how to program the new renderer for best results, while at the same time we are adjusting the maps so they look good with the old renderer? Now that's a scary thought.)

With the most common complaint about Area Places being map clutter, what would be really nice to see is the ability to set filters in the client (or WME too), both generic (all places) and by category. I don't think it would be difficult for the Waze staff to implement such a feature. This would also allow people who want to see such things to see them, and those who don't want to see some or all of them to do so as they desire.

I think 'sketch' hit on a key point that is mentioned in the current Wiki. And without some resolution (or at least additional information) on said point it's hard to make a call on this issue. The idea of areas within areas is very real and is often critical for navigation. Tallahassee Memorial has a moderate campus (at least compared to those in big cities) but there are certainly key destination points: the ER, the Urgent Care center, Administration, and at least two medical office facilities. The entire campus should be clearly identifiable but it is important to identify the included facilities.

*IF* we're going to be able to map areas in areas in the near future (perhaps with the color coding mentioned by sketch) that will be an ideal solution. But until then, I would vote for fence line areas with point locations internal to the larger facility.