Advanced relationships
Advanced relationships is a proposed database extension that allows us to model many things that we currently can't model easily. Please correct mistakes and add examples here, but discuss the proposal on the talk page. Please note that while this page talks of "segments" (because we're all used to them), all the examples work equally well in a situation where segments are removed (and ways consist of an ordered list of nodes).
Introduction
The more I use OpenStreetMap, the more I think it needs an Advanced Relationships feature like MusicBrainz has (see http://wiki.musicbrainz.org/AdvancedRelationships). The idea is that you can link any two items in the database with a tag that describes the connection.
Possible Implementations
See Advanced relationships/Implementation for ideas how to implement this.
Relationships
Example uses:
Restricted, Prohibited and Priority Manoeuvres
(no right turn at a crossroads)
- Restricted Manoeuvres (where there is a physical impedement to making the turn)
- Prohibited Manoeuvres (where there is a legal impedement to making the turn)
- Priority Manoeuvres' (to describe the lack of a give way at the junction from this direction).
"is in" tag
Moved to Relations/Proposed/Is_In
Grade Separated Crossing
A Grade Separated Crossing may be one of:
- A Bridge
- A Tunnel
- A Viaduct
In GDF the general term 'Brunnel' is used for any of the above
This relationship associates two lengths of infrastructure (rail/road/footway etc) with a 'Brunnel' taking the form "Element 'X' passes over 'Y' using 'Z'" (where X and Y are highway types and Z is a bridge/tunnel/viaduct)
It should be possible to associate multiple relationships with a single Brunnel, to describe a railway and road crossing something using the same facility.
It should be possible to describe the physical extent of the Brunnel (for example a very long viaduct, or a wide bridge carrying a railway, road and canal)
Special instructions for direction lists
At a complex junction, if you are at segment A and your route includes segment B (not necessarily the next segment in the journey, just a segment that happens later), then you could have a relationship from A to B with key="route_instruction" value="stay in the middle lane, then follow the sign that says London", which could be printed or read out with a speech synthesizer.
Node is address of way
If a node is near number 31 on the north side of a street, you would have k="address_north" v="31" on the node and way. Other addresses could then be interpolated.
Way "is border"
e.g. of country, county or city node. Every county border way is part of two counties (one on each side) - it would be possible to build rough county maps by combining partial borders that we know about with delaunay diagram guessed borders and/or a kind of join the dots approach. The nice thing here is that if a county border is a river, you don't need to put it in the database twice.
The is border idea could be extended to do all kinds of micromapping - you could have ways that are is_border of a road way that define where the pavement/sidewalk starts. The road way would be topologically correct for routing, and would be used for all the maps we currently have, but at really large scales, the actual sides of the road could be shown.
Way is opposite side of dual carriageway to (another) way
So that renderers know to only render a name on one of them; so that renderers can combine dual carriageways into a single rendered line; so that maplint can check they have the same attributes or copy attributes between them.
Way is part of logical road
A logical road being what one would normally think of as a road, which is basically be a collection of contiguous ways; A navigation system gives directions from one logical road to the next.
- This scheme only does 1:1 relationships, not collections. You would only be able to link each way in the road to the next way in the road, forming a 'chain' not a 'collection'. I'm not sure if this is a good idea (perhaps it is exactly what we need, perhaps it is a terrble plan from a data model point of view). Rjmunro 16:39, 14 June 2007 (BST)
- One-to-many relationships are important. Could a scheme be devised that would accommodate both one-to-one and one-to-many relationships? (rather than going through the pain twice...)
Node is centre point of feature
E.g. a large building such as a shopping mall may be rendered as an Area in high zoom, but be rendered as a point at low zoom. Also works for towns, counties etc.
- That's the same as is_border, just expressed the other way around Rjmunro 16:34, 14 June 2007 (BST)
- Actually this is subtly different (have changed the word "area" to "feature" in the section heading, because it is not necessarily an area that we want the centre point of). For example it is desirable to render motorway junctions as their centre points at low zoom; this could not be done with is_border.
Node is entry point of feature
E.g. a tube (metro) station has multiple entrances, that may be in different places to the actual centre point of the feature. Allows navigation to the entrance of a feature rather than guessing where the entrance is.
Areas with holes
If we, e.g. in the course of abolishing segments, cannot support non-contiguous ways any more, we need another way to model areas with holes (i.e. "donuts"). Currently you would have two rings of segments and they'd both be part of the same way. In the future we might have two ways (one for each ring) and a relationship between them saying "A is hole in area B".