I have been working for a while now to add support for rock climbing to open street map (See Climb The World app on github), and also helped a lot with the climbing wiki page. (Sorry I am only allowed to put 2 links in one post right now).
My question is: Is there a “best practice” approach when trying to group physical elements into logical groups, and then have groups for this logical groups as well?
The problem I am trying to solve:
- The physical object is called a climbing route. (usually mapped as a point of start location)
- Routes can be grouped in crags. A crag usually maps to one face of the wall.
- And then crags can be grouped in climbing areas.
The solutions I have so far:
Very simplistic way to map climbing related spots. Mainly using point to represent routes starting locations (climbing routes are usually vertical so a line doesn’t really help), and also using points to map crags and areas. This sort-of work when just drawing the elements on the map, but it doesn’t when trying to do some more advance searching.
My second approach was to use relations. Basically all routes mapped to OSM will be part of the “Crag” relation. For example this Crag. And then all the crags will be part of an area relation. The corresponding area for the previous crag. This seems to be a good solution, the only problems I am having is visualizing the area of areas.
The third option I can think of is to draw the actual areas on top of OSM (I don’t know how searching will work on this yet byt maybe it should be fine). The problem I can see with this is overcrowding that will happen since usually climbing spots are in forests and parks. and what I can see usually there are areas already mapped in OSM to represent the forests and the parks.
I think you use a relation to combine them into a group, like this:
In the climbing community the routes on a rock face are also grouped in what is called a crag like this:
So should the “area” relation be a relation of relations? like this one:
Or should each route be part of 2 relations: the “crag” and the “area”.
I just noticed, in your example the crags are mapped as a node. That is a bit of a bad example since a crag is not a geographical thing, it is just an abstraction.
Relations add a layer of complexity that is best avoided unless it is truly necessary. For climbing crags I’d recommend mapping them as nodes or areas much like towns, villages, and hamlets are mapped with the place key. I wouldn’t over complicate things by adding every route to a relation for the crag. That would be like adding every building in a town to a relation representing the town (a maintenance nightmare).
For larger climbing areas that are collections of crags, I could see a site relation with each crag as a member making sense. However, if the crags are close together a node in the middle might do the job just find and would be simpler.
Thanks for the input.
First of, having climbing areas and crags as nodes, to me, it is a bit useless. Since one won’t be able to run queries that will give all the routes in a crag/climbing area.
A big advantage of mapping crags as relations, is that relations are ordered, allowing climbing routes to be mapped from left to right as they are set on the wall face. This makes them easier to identify on the wall.
As far as I know: towns, villages, and hamlets also have a relation attached to them for the administrative bounder. Example fore Rome. This makes it possible to find all the buildings in Rome.
So maybe a bounding relation or just area for climbing area, and a relation for crags.
It might be helpful to see how things are mapped in climbing areas in various places. For example, here is an overpass query showing climbing features outside Sheffield.
See also here which is an attempt to show some of the things that wouldn’t otherwise appear on a map as “sport climbing features”. The selection code for that in the map style is here.
I think most of this places were mapped before the climbing tag and wiki were refined, so it is a bit of a free for all out there.