The related table extension basically defines a mapping between the primary keys of two tables in terms of base (the left side of the mapping) and related (the right side of the mapping).
Right now, the left side can be tiles, attributes or features.
The right side can be tables of attributes containing media (or "simple attributes" if something like #29 or #30 is applied). That constraint is implied by defined values of relation_name. Now there is no reason why you can't do any other value, but it won't be particularly interoperable.
However it means that there are things that can't appear on the right side. In particular, I think there is a case for linking spatial X to spatial Y. For example, the FAA publishes airports as point locations (and a bunch of attributes, and runways as polygons (and a bunch of different attributes). See http://ais-faa.opendata.arcgis.com/datasets?keyword=airports . There is enough data to link them, and there is probably a sensible UI that allows you to click on an airport, select a runway, be shown the runway as features on the map, get related obstructions if its VFR, or get the instrument approach plate (in PDF, using a media related table); then click on a table of comms frequencies for the airport (as simple features). We can do most of that, just not the linkage from airport feature to runway feature (i.e. feature on the right side of the mapping).
I'm not currently seeing the need for tiles on the right side of the mapping, but that would probably be analogous to whatever we come up with here.
The related table extension basically defines a mapping between the primary keys of two tables in terms of
base(the left side of the mapping) andrelated(the right side of the mapping).Right now, the left side can be tiles, attributes or features.
The right side can be tables of attributes containing media (or "simple attributes" if something like #29 or #30 is applied). That constraint is implied by defined values of
relation_name. Now there is no reason why you can't do any other value, but it won't be particularly interoperable.However it means that there are things that can't appear on the right side. In particular, I think there is a case for linking spatial X to spatial Y. For example, the FAA publishes airports as point locations (and a bunch of attributes, and runways as polygons (and a bunch of different attributes). See http://ais-faa.opendata.arcgis.com/datasets?keyword=airports . There is enough data to link them, and there is probably a sensible UI that allows you to click on an airport, select a runway, be shown the runway as features on the map, get related obstructions if its VFR, or get the instrument approach plate (in PDF, using a media related table); then click on a table of comms frequencies for the airport (as simple features). We can do most of that, just not the linkage from airport feature to runway feature (i.e. feature on the right side of the mapping).
I'm not currently seeing the need for tiles on the right side of the mapping, but that would probably be analogous to whatever we come up with here.