Special case of route names

[asaunier]

Route names are a special case compared to other documents titles because they are closely related to the associated waypoints.

For instance http://www.camptocamp.org/routes/53781/fr/mont-blanc-arete-des-bosses

• displayed route name is "Mont Blanc : Arête des Bosses".
• the actual route name is "Arête des Bosses" though. The summit name is appended first in order to "discriminize" the route name, for instance when the route name itself is too common (eg. "Face N").

Several drawbacks with this approach:

• In v5 the displayed route name determination is really (too!) complicated: when several summits are associated to the route, the highest summit is used (based upon the summit elevation attribute). Then if the summit has several culture, the most appropriate one must be figured out depending on the interface language or user's preferences. This is done every time the route name must be displayed (even though some caching may be used in some cases).
• In the mapfile it is not possible to make that complicated computations and the route names displayed for vector features on the maps omit the summit name.
• In some cases, the highest summit is not the most relevent one (eg. a route to a hut that would go through some pass above the hut).
• In some cases omitting the summit name would make sense, eg. for raids.

With @tsauerwein we considered moving the summit name (if relevent) directly into the route title field. I have discussed it with the association and it would cause other problems. For instance when climbing sites are reorganised, if a bunch of routes are transfered from one site to another, one would have to change all the route names by hand. Ditto if a new culture is added to the summit with a different summit name (eg. Cervin/Cervino/Matterhorn). In addition contributors would most likely introduce inconsistencies in route names, for instance "Cervin : Face N", "Cervin Face N", "Cervin / Face N", "Face N du Cervin" or even "Face N" (summit name incorrectly omitted).

By the way having the summit name in the route name attribute would require to adapt the v5>v6 migration script.

Please note that in v6 using WP names (not only summit names) would make sense. For instance for hut-access routes, climbing route names including the name of a climbing site.

Suggested solution (to be precised and debated in the current issue):

• the route title attribute still contains only the actual route name (no WP name is embedded). As in v5.
• The displayed route name contains a WP name as well. As in v5. Except maybe for some route types (eg. raids).
• in the route detail page, it should be possible to specify the "main WP" among associated WPs. If only one WP, it is automatically considered as the main WP. If several WP are associated, the main WP would be the highest one by default.
• In order to avoid complicated computations when displaying the route name (including for instance in the mapfile), the routes "locale" (i18n) table [1] would contain a "prefix" attribute that would automatically be set with the "main WP" title. This attribute would be updated whenever the "main WP" is changed or renamed. We could also have a "waypoint_id" attribute in the route table if it helps figuring out the routes that must be updated when a waypoint changes.
• Since the prefix is not really related to the route data itself, it is not necessary to create a new entry in the route archives when the "main WP" is changed or renamed (ie. when the "prefix" attribute must be updated) => the "prefix" attribute would be available only in table "routes_locales" not in table "routes_locales_archives". Which means that when a new version of the route is created, the "prefix" attribute should be preserved.

Please note that the route indexing in Elastic Search is also impacted by the current issue: the route index should take into account the names of all WP associated to a given route, so that the route is returned when searching on a WP name.

[1] https://github.com/c2corg/v6_api/blob/master/c2corg_api/models/route.py#L228

TODO: indexing WP names when indexing routes

[tsauerwein]

in the route detail page, it should be possible to specify the "main WP" among associated WPs. If only one WP, it is automatically considered as the main WP. If several WP are associated, the main WP would be the highest one by default.

This logic ("if one wp -> main wp, if more wps -> highest wp") would only be used for the migration script?

Because otherwise, if you create a new route you need at least one wp and this wp would be used as the main wp by default. This would also allow not to specify a main wp in case you don't want to prefix the route name with a wp name.

[asaunier]

This logic ("if one wp -> main wp, if more wps -> highest wp") would only be used for the migration script?

At "runtime" as well. In most cases, having a WP name in the route name is needed, at least not hurting. In most cases, the highest WP is indeed the the one that should be mentioned in the route name => this would be the default "main WP". We would need then to be able to pick another WP to make it "main WP" if the highest one is not relevent.

if you create a new route you need at least one wp and this wp would be used as the main wp by default.

Yes. Is it a problem? Having at least one WP associated to a route is mandatory (it's especially needed to have a default localisation based on the WP if no geometry is provided or for figuring geoassociations out).

This would also allow not to specify a main wp in case you don't want to prefix the route name with a wp name.

We could define a way to set "main WP" = None. Or (if easier) say that only some route types (eg. raids) omit the main WP name. For raids, "main WP" is not that relevent.

[asaunier]

Discussed with @tsauerwein : actually the "highest WP is the main one" logic is only needed when migrating summits from v5 to v6. When using v6, since "main WP" will have already been set, associating a higher WP to a route won't change the "main WP". User will have to set it as "main" explicitely (or else the "main WP" concept is useless).

[tsauerwein]

To sum it up:

• We add the field main_waypoint_id to Route and RouteArchive.
  • The main waypoint can be of any waypoint type, not only summits.
  • In the migration script this field is filled with the highest linked summit.
  • When creating a new route, this field is filled with the waypoint that is needed to create a route.
  • When editing a route, the main waypoint can be changed to a different linked waypoint. It can also be set to null, in that case the route name is not prefixed with a waypoint name.
• We add the field title_prefix to RouteLocale which caches the title of the main waypoint. This field is not archived.
  • The field is updated, when:
  • locales of the main waypoint change.
  • a different main waypoint is selected.
• The title of a route that is sent to ElasticSearch contains the title prefix.

[asaunier]

Correct!

The title of a route that is sent to ElasticSearch contains the title prefix.

Yes It would be nice if route-associated waypoints could be indexed as well (if not too complicated!? maybe in an evolution?) since it would help finding a route to be able to mention any of the summits the route goes through.