You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have had a lot of trouble in the HydroVIS side loading ras2fim V2 geocurves. We discovered that the geometry column is not created with its crs embedded, only pure geometry and it can not be picked up by auto-detect. Reason: The data we saved to that column. If you look at V1, we did not have the geometry in the .csv, but in a separate gpkg so crs was defined and could be auto detected.
Each csv has a "crs" column, but that is the crs column from the original hecras source and has no value in the HV services. What HV does need is all csv geometries to be the same. There was a line of code in the the create_geocurves that reprojected it to 3857 but it was commented out.
This forces HV to not load in bulk but load each csv one at a time, read the csv adn its crs column, reproject, then save it to the DB which is very slow. For v2.0, we will do it this way but this has to be fixed for future loads.
It might be the same problem in the files going to HAND. Even though it only uses points, it might have incorrect csv's for each HUC. Review is needed.
The text was updated successfully, but these errors were encountered:
We have had a lot of trouble in the HydroVIS side loading ras2fim V2 geocurves. We discovered that the geometry column is not created with its crs embedded, only pure geometry and it can not be picked up by auto-detect. Reason: The data we saved to that column. If you look at V1, we did not have the geometry in the .csv, but in a separate gpkg so crs was defined and could be auto detected.
Each csv has a "crs" column, but that is the crs column from the original hecras source and has no value in the HV services. What HV does need is all csv geometries to be the same. There was a line of code in the the create_geocurves that reprojected it to 3857 but it was commented out.
This forces HV to not load in bulk but load each csv one at a time, read the csv adn its crs column, reproject, then save it to the DB which is very slow. For v2.0, we will do it this way but this has to be fixed for future loads.
It might be the same problem in the files going to HAND. Even though it only uses points, it might have incorrect csv's for each HUC. Review is needed.
The text was updated successfully, but these errors were encountered: