Mercurial > gemma
view TODOs-historization_ng.md @ 4890:5d9c7fcda566
Fix drawing of fairway profile.
The basic functionality for calculating the graph to draw resides in geo.js
This was a port of existing code from the backend (cross.go).
For historic reasons there was a bug present in this code which was fixed in the backend.
The height was transformed via Math.abs() which results in strange behavior for
measurements above the waterlevel. Points which are 1.5m above the waterlevel were drawn
1.5m below the waterlevel.
There were two fixes:
1) The y-component of the x/y-pair of the fairwayprofile point is taken as is without Math.abs()
2) To draw the diagram, there is the definition of a domain necessarry.
A minimum value for the values above the waterlevel is constructed in case there is no point above
(10 percent of the range below the waterlevel). In case there are values above the waterlevel
which in turn means the minumum value is < 0, there is this value taken as a minimum.
D3 scales accordingly.
| author | Thomas Junk <thomas.junk@intevation.de> |
|---|---|
| date | Mon, 10 Feb 2020 15:09:59 +0100 |
| parents | 6bfe42f88638 |
| children |
line wrap: on
line source
# TODOs for HNG (Historization NextGen) ## gauges-reference-water-levels Could be seen as direct part of the gauge data and therefore kept with the foll primary key reference... ## Water level diagrams: One time range might reference different verions of one gauge: - How is that hanedled currently? - How to handle it in HNG? ## Map display: Ensure only current gauges are shown in all situations - Gauges layer - Search - more? ## Bottlenecks: Always associate the correct gauge, when: - Uploading Sounding results (how is that currently handled?) - Displaying Sounding data - Creating/showing X-Cuts - Unclear: what constraints shall we chekc for on bottleneck imports? Cut end of validit _after_ accepting the new one. ## Sounding Results: - Maybe add a constraint to check, that a ref gauge is available? Maybe not neccessary as import isn't possible anyway, as the reference gauge is needed for the import process... (So the constraint would never catch anything, as no data could be produced without ref gauge) Only upside: we would triger if there is an error in the backend generating SR with invalid ref data. - Check during upload that matching bottleneck and reference gauge data is available (and use ist correctly) - Use correct reference gauge for X-Cuts - (Maybe later) use matching BN data for display ## EVERYTHING ELSE Not being mentioned here, doesn't mean something is done... # DONE Stuff done will bemoved moved here for reference: