Edge cases and possible improvements

This page will contain edge cases and limitations of our API to determine the possible improvements of the system.

ID8: As a DG, I would like to see weather data on a given road segment.

We get weatherdata for a whole municipality and not local areas such as Byåsen or Midtbyen.
- There are only to weather stations in Trondheim measuring rainfall. -Problem can be solved by using a linestring to determine a geographical area and map weather accordingly.
- Using historical data may be the best way to go and remove weather from the API part and handle it front-end.
Weather may be inaccurate. Only handle weather from a 24 hour period. Weather accuracy improves with faster updates.
No way to track if the precipitation is snow, rain or similar. Only track mm and the degrees.

ID23: As a user of the system I want the production data to be correctly mapped to a road segment.

Multiple road segments within offset will be mapped to the closest.
~~Multiple roads with same coordinates (bridge over road) can cause problems.~~
- If production data and a road segment crosses at 90 degree angle +- 30 degrees or so it should be ignored. There might be unknown edge cases.
We do not track which side of the road that are being maintained, both sides are one segment.
Production data is mapped on an individual basis, not as part of a sequence of data points. This leads to some inaccuracy and can result in some points in a sequence being incorrectly mapped to an adjacent road.
~~With equal distance to two or more road segments, one of them is selected arbitrarily.~~
- The most parallel road segment will be selected.
There is no handling of transitions from one segment to a different one.
- For now it maps the one of them that is a better candidate, or none.
Production data that we have used in our mapping are from normal roads, while the road network are for CP-roads. This can potential cause unexpected problems with mapping data for the correct road network that we do not have access to.
If production data and a segment does not overlap, the check for parallelity is probably not as accurate.

ID24: As a user I want the system to check if new production data belongs to a road with already existing production data.

Old data are removed and new data added. If only a part of the segment are maintained the production data for the whole segment will still be deleted and updated.
If production data older than the current data is inputted, it will be ignored.
If the production data is from the same time period as the current data on a segment, it will be added. This means one could insert the same data over and over and the system would accept it.

ID25: As a DG I want the system to gather, update and segment the road network and store it in the database.

Updating road network must be done manually. We do not detect new roads and add them automatically.
~~You cannot add only one road. Refreshing the road network is needed.~~
The fra_meter and til_meter fields on split segments are a bit imprecise. This is due to rounding up when calculating length. A segmented road may be 513 meters in length according to us when the real value is 511. Use vegref to double check if it is important.

ID27: As a DG I want to be able to retreive the attributes of a given road segment.

ID28: As a DP I want the API to support production data as input.

API supports datainput in JSON format.
- The structure and required fields are described in the API documentation page

Production data
- Setting a constraint on the material_type_code, dry_spreader_active and wet_spreader_active so that if either of the spreaders are True the material_type_code cannot be Null. Also if none of the spreaders are active the material code has to be Null.
- Mapping to segments:
  - The sequence of data is not treated as a sequence. The entries are mapped independently, but could take the best segments of their previous and next entries into count when mapping.

Provide feedback