Merging

Merging routes or areas is extremely complex. This article is written in order to make our business rules transparent. In that way, if you think something is unusual, you can work out whether or not there is a bug in the process or we are just simply missing some logic.

This is not a tutorial on how to merge nodes, but rather an explaination of what happens.

The general principle with merging is that we do not loose data and that it does not matter which way you merge (ie merging A with B is equivalent to merging B with A). The later is only a principle and there will be some details that are dependant on the direction of the merge (eg route name if they are not identical).

Even though data is not lost the merge process cannot be undone because, for example, ascents will be moved accross and we have no method of tracking where they came from if we wanted to undo the process. Because of this please take care with merging.

We allow merging for the following merge activities:

  • Route merged with route
  • Area merged with area (with or without children)

Because of the complexity involved some of the merging process is undertaken by the back-end system after the merge has taken place. Currenly this is a process which runs every hour. This means it may take an hour for you to notice all the merged details coming across.

When merging the following occurs straight away:

  • The merged node has it's status set to merged and removed as a child node from it's parent.
  • All children nodes are moved to the merged node.
  • Route history is moved.
  • Node names are copied across if they do not match. The principle name becomes an alternate name in the target node.
  • Descriptions are merged, by either copying across or concatenating with existing description.
  • Principle route grades are combined into a grade range.
  • Publication and personal route grade contributions are moved.
  • Grade summary fields recalculated.
  • Route fields (height, pitches, bolts, top rope flag, and project flag) are merged by copying across if the target route is empty.
  • Area fields (approach time from parking) are merged by copying across if the target area is empty.
  • Photos are moved.
  • Topos are moved.
  • Routes in topos are moved so that a topo does not reference a merged route. If the target route is already in the topo then the route being merged is delete.

And the following will be processed later:

  • Various statistics are recalculated.
  • Merged node is removed from general query results (such as feeds).
  • Node permits are removed.
  • Associated publications are moved.
  • Ascents are moved.
  • Node sequences are adjusted if necessary

And the following will are currently not being processed:

  • Node locations are not moved due to internal complexities (at some point we will address this).

If you try and access a merged node you will get the node it is merged with.

Merging nodes will effect the ascent and activity feeds. All ascents and activity will be merged in the feeds. This effectively changes history for a particular node. Please note that that the feeds are provided with a particular type of caching set based on the date of the last entry. This means that even though the feeds may have historically changed you might not see the change until there is a new latest entry.

Even though ascents are merged they maintain their labelled name and grade which is stored with the ascent when the ascent was first logged. This is particularily important because it means that climbers ascents statistics will not change if a route has been merged with a harder route.

If you think we have missed something or you think the system is not behaving the way we have described then please contact us.

Simple eh