There have been a half-dozen or so suggestions that are by-products of the same underlying cause: ROUTES AND PLACES ARE NOT DISTINCT. This is another one of those. If all votes were combined, it likely would be one of the top concerns for improvement.

Let me summarize briefly. In the current design, there is not distinction between a route and a place. Activities must be scheduled at a a single route/place wihich is then used to detectl trip conflicts.

The first thing that's wrong about that is that routes and places are inherently different. A place is where we go and a route is how we get there. Places have area, they may be as small as a trail intersection or larger than a national park. On a map, places look like an enclosed shape, including waypoints which are a special case of a very tiny enclosed shape. Routes look line lines on the map. They go from place-to-place-to-place. Places have area, but not distance, difficulty, or activity type. (what is the activity type for Mt. Ranier National Park or Snow Lakes Trailhead?) . Routes have distance, difficulty,elevation gain, etc.

I submit that routes may be specific to-activity type. in other words, a scrambling route and a climbing route are different even if they start and end at the same places. (From a design standpoint, this is arguable--one can also make the case that they are the same route, but that the route can be used for multiple activity types, tbd when the activity is scheduled. But, I don't want to get distracted by that nuance at this moment)..

Second, the popular notion of a route typically includes multiple places--starting and ending places at a minimum. They may even include more, depending on the complexity of the route description. This is important because when we schedule an activity at a route, we want to recognize that the activity goes to multiple places and, most likely, the party will be at the different places at different times.

Third, managing trip conflicts at the route/place level is over-simplistic. While we don't want two parties at the same place at the same time, we certainly may be able to allow them on the same route at the same time. The Wonderland Trail, for example, could certainly accommodate two parties, provided they stay a reasonable distance apart. That level of trip conflict control is not possible if the Wonderland Trail is represented as a single Route/Place that takes a week.

On the other hand, if the Wonderland Trail is represented as a route that travels to different places over the course of a week, we have the foundation to manage trip conflicts at the place level. That would permit several parties on the route in many circumstances.

I agree that the warning is still appropriate, since avoiding trip conflicts with certainty is well beyond the scope of what's feasible without complex and expensive GIS infrastructure.

Some of the route/place suggestions have been addressed by the recently added "common uses" for a route/place. While that may appease some users, it's kind of a hack that adds a superfluous dimension. How is "lecture" or "field trip" not an activity type?

A better long-term solution (sorry for the techno-speak)

-reduce the route/place entity to a supertype with only the attributes common to both routes and places, plus a subtype designaor.
=add separate subtype objects for route and place, each having appropriate attributes and inheriting the common ones in the supertype.

-construct routes as a sequence of places
-manage trip conflicts at the place level

-create separate routes by activity type
OR
-allow multiple activity types per route

-redefine Activity Type to include a broader range of activities like lecture, field trip, meeting, pot luck, etc. After all, the foremost purpose of Activity Type is to classify an activity. When applied to a route or place, it really qualifies the kinds of activities for which the route/place is suitable. While activity types like those suggested above aren't very appropriate for routes, they are perfectly suitable for places..