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 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.
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.
So I think the best way to represent climbing in OSM is like this:
level1: Routes and climbing gyms: nodes, ways and areas.
level2: Crags: Relation of nodes and ways. This will also encode the information of left to right.
level3: Climbing areas: Super-relation of crag relations.
OSM is a geographical database so this information is available by interrogating the data rather than relying on the members of a relation being ordered (not something which is guaranteed).
For a typical UK crag it’s probably enough to map the crag line as natural=cliff with the start of routes as nodes. For these a simple geospatial query would give you left-to-right ordering (climbers view). More complex are things like the Bishop & Actress routes on Stanage, but one can indicate layering.
Relations could be used to manage names of the overall climbing area when one want’s to preserve individual crag names (usually relations of type=site), but a equally climbers’ names of buttresses etc. tend to be just that, a name only known to climbers, and may be suitable for a distinct name tag (thus avoiding confusing a walker, say, who will not know the microtoponymy used by climbers.
However, it’s usually best starting by seeing what can be done without using relations, as with a very small number of exceptions they have poorly defined semantics.
My original idea was also to use the cliff tag for crags, unfortunately I don’t think it is a good fit.
Climbing routes occupy mainly a vertical space, so they usually end up being represented by a single node with the climbing=route_bottom tag for the start of the route. Cliffs on the other hand: “If the cliff is not perfectly vertical the way should be located on the top edge.”. This generates a bit of a conflict between the 2. Maybe this can be solved by having both climbing=route_bottom and climbing=route_top nodes with a way in between them?
My original idea was to map climbing routes the way streets, districts and cities are mapped.
The analogy being:
Climbing routes are like streets, they all have names and they map to physical objects.
Crags are like districts, the hard thing about crags is that they don’t have physical objects surrounding them that can be used to form a boundary relation.
And then areas are like cities. Again with the drawback of not having streets or other physical objects to be used as boundaries.
Crags are like districts, the hard thing about crags is that they don’t have physical objects surrounding them that can be used to form a boundary relation.
Have you compared with the way TheCrag.com and Mountain Project arrange routes and areas and crags, etc.?
TheCrag has a table of area types:
MP:
Areas are arranged in a hierarchy from states (and countries) down to small crags and individual boulders. States can have any number and levels of sub-areas. Complicated areas will have more sub-areas than straightforward ones. Sub-areas can contain either more sub-areas OR routes, but not both.
Uhhhh this looks like a “what not to do” example of using the tag “nature=cliff” tag. That area is a complete mess of using that tag. Remember that “nature=cliff” tag should not surround every hill, it should only map the top part of a cliff.
Yes I did. From OSM point of view, I don’t need to care about country and state, that can be figured out through a generic bbox query. The only info that I find useful in OSM is climbing area and crag name.
I had a look at one of the BMC Guides for the Peak District, and they have a map of Black Rocks at Cromford using more-or-less the type of schema I suggest. When I get the chance I’ll post it here.