dewberry / mcat-ras Goto Github PK

Some temporary fixes have been put in place to make endpoints respond faster. These temporary fixes duplicate code. A better approach should be adopted to fix this permanently.

Commit just before code duplication
https://github.com/Dewberry/mcat-ras/tree/cc15a8956b79223dc0ff6ae385ae31a1f0cd395a

Tyson_Marsh_Upper.zip

Index endpoint response for the above model:

We have extracted most BC types by now but some are still to be extracted, they are advanced types with complex data. We don't want to extract their data but we can easily extract their type and show they exist. Let's extract them.

Let's add and endpoint to provide current settings in a model to provide a list of the outputs that will be generated as parameterized in a model.

Extract IB-Stage/Flow and Gate Openings Hydrographs from HEC-RAS .u__ files

With the recent simplification of endpoints in #13 different endpoints behave differently for example, gesopatialdata only consider a model geospatial if it has .projection file while upsert/geom would take into account other kinds of projections files as well.

Thus if you don't have .projection file in a model but other kinds of projection files gesopatialdata would fail but upsert/geom would not.

Use go channels and routines to simultaneously parse files for

• geospatialdata

  mcat-ras/handlers/geospatialdata.go

  Line 68 in d650fdc

  for _, fp := range mfiles {

• forcingdata

This will be similar to geospatialdata endpoint but will return the data from steady, unsteady and potentially quasi unsteady flow files.

We need another endpoint for identifying breach locations / options.

I encountered an issue while using the MCAT-RAS library, specifically related to panic handling. When intentionally providing an incorrect string for the Coordinate Reference System (CRS), a panic occurs and it is not being gracefully handled by the library's panic handlers.
The function I was using was GetGeospatialData and when I passed "2284" into sourceCRS string it caused a panic and crashed the server was working on. Though we realized that the correct implementation was to add the following sting:

const wkt2284 = PROJCS["NAD83 / Virginia South (ftUS)",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",37.96666666666667],PARAMETER["standard_parallel_2",36.76666666666667],PARAMETER["latitude_of_origin",36.33333333333334],PARAMETER["central_meridian",-78.5],PARAMETER["false_easting",11482916.667],PARAMETER["false_northing",3280833.333],AUTHORITY["EPSG","2284"],AXIS["X",EAST],AXIS["Y",NORTH]]
`

A panic still shouldn't have occurred and should have been handled by a defer and recover in Go.

Look into Postman and Newman and official HEC-RAS example files to create a testing environment that can be integrated with GitHub CI/CD.

Steady flow files have Storage Area Elevations. A placeholder exists in the Profile struct in steady.go file for []StoAreaElevation, but no data is being extracted to it.

• Include logic to extract Storage Area Elevations.

Following model contain dummy storage area elevations data data-collectors/jpaul/OysterCreek1DStorage/OysterCreek.prj

• Refactor API
• Create a new local docker stage
• Add test data from HEC RAS examples

The current code to parse HEC RAS input files scans the same file multiple times. A new better approach is adopted in forcingdata endpoint that only scans one file.

The other code should be refactored to adopt the same approach to improve performance.

HEC-RAS has the following hierarchical structure for Rivers and Reaches:

{
    "River A": {
       "Reach 1": [
            "Node 1",
            "Node 2",
            "...."
       ],
       "Reach 2": [
            "Node 1",
            "Node 2",
            "...."
        ]       
    },
    "River B": {
        "Reach 1": [
             "Node 1",
             "Node 2",
             "...."
        ],
        "Reach 2": [
            "Node 1",
            "Node 2",
            "...."
        ]
    }
}

Currently, the API doesn't conform to this structured format and returns data like this in index, geospatialdata, forcingdata (forcingdata was done deliberately like this to match the pattern):

{
    "River A - Reach 1": [
        "Node 1",
        "Node 2",
        "...."
    ],
    "River A - Reach 2": [
        "Node 1",
        "Node 2",
        "...."
    ]
}

Fix the API response to match HEC-RAS Structure in

• Index
• GeospatialData
• ForcingData
• Database

This will be a breaking change.