the key problem is that horizon points are tuples (x,y) but an observation is a singleton (except for depth max/min info that can be added).
Suggested solutions are below (# 3 is my favorite).
suggested solution 1
create new locations for horizon measurements that are lines instead of points, the azimuth of the line then corresponds to the azimuth of the horizon
advantages: not many
disadvantages: separates observations into many different locations, when they represent the same location. Convention is somewhat ad-hoc; would require good documentation. Creates many locations that are only used for one purpose, stores information about the observation (i.e. the azimuth) in the location description
suggested solution 2
implement an ad-hoc convention:
e.g.
- by convention, the 'text_value' is azimuth and 'numeric_value' is horizon
- by convention, the 'height_max_metres' is horizon and 'numeric_value' is azimuth
- store as a text value e.g. "000-00" (azimuth-horizon)
advantages: data can be stored easily, all observation data is kept in the observations table
disadvantages: does not fit into conceptual schema. Would need to be documented and followed.
suggested solution 3:
discretize azimuthal directions into different sensors
e.g. {"device_id":"horizon_at_000", ..., }, {"device_id":"horizon_at_005", ..., }, …, {"device_id":"horizon_at_355", ..., }
All horizon sensors could be grouped as a single device (e.g. horizon camera/quickhorizon) (instead of human observation)
advantages: fits well into conceptual schema
disadvantages: restricts the data that can be entered. Creates a lot of sensors that are basically the same, stores information about the observation (i.e. the azimuth) in the sensor description
the key problem is that horizon points are tuples (x,y) but an observation is a singleton (except for depth max/min info that can be added).
Suggested solutions are below (# 3 is my favorite).
suggested solution 1
create new locations for horizon measurements that are lines instead of points, the azimuth of the line then corresponds to the azimuth of the horizon
advantages: not many
disadvantages: separates observations into many different locations, when they represent the same location. Convention is somewhat ad-hoc; would require good documentation. Creates many locations that are only used for one purpose, stores information about the observation (i.e. the azimuth) in the location description
suggested solution 2
implement an ad-hoc convention:
e.g.
advantages: data can be stored easily, all observation data is kept in the observations table
disadvantages: does not fit into conceptual schema. Would need to be documented and followed.
suggested solution 3:
discretize azimuthal directions into different sensors
e.g.
{"device_id":"horizon_at_000", ..., }, {"device_id":"horizon_at_005", ..., }, …, {"device_id":"horizon_at_355", ..., }All horizon sensors could be grouped as a single device (e.g. horizon camera/quickhorizon) (instead of human observation)
advantages: fits well into conceptual schema
disadvantages: restricts the data that can be entered. Creates a lot of sensors that are basically the same, stores information about the observation (i.e. the azimuth) in the sensor description