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 would like to be able to create projects where the administration boundaries are provided by the project owner.
The functionality should support popular geospatial file formats such as:
geojson
geopackage
geoparquet
shapefile
Upon uploading the dataset, the user should indicate columns that correspond to:
Boundary level
Boundary name
Boundary unique code
Conceivably we could support multiple layers (e.g. admin0, admin1) to represent different administration levels, or we could require a single layer which contains different admin levels codified by their 'Boundary level' column to indicate which level they represent.
Additionally, it would be good to store a reference for the layer such that the boundaries can be cited if needed.
Internally we should load the user uploaded boundaries into the postgresql backend and serve them back to the project as as_mvt vector tiles so they they are essentially the same delivery mechanism as pulling boundaries from GeoRepo.
Where Ucodes and other GeoRepo specific API calls, this GeoSight-side implementation should completely replace the need for GeoRepo, emulating the appropriate API calls if needed or providing an alternate logic path for ucode lookups etc.
The text was updated successfully, but these errors were encountered:
We would like to be able to create projects where the administration boundaries are provided by the project owner.
The functionality should support popular geospatial file formats such as:
Upon uploading the dataset, the user should indicate columns that correspond to:
Conceivably we could support multiple layers (e.g. admin0, admin1) to represent different administration levels, or we could require a single layer which contains different admin levels codified by their 'Boundary level' column to indicate which level they represent.
Additionally, it would be good to store a reference for the layer such that the boundaries can be cited if needed.
Internally we should load the user uploaded boundaries into the postgresql backend and serve them back to the project as as_mvt vector tiles so they they are essentially the same delivery mechanism as pulling boundaries from GeoRepo.
Where Ucodes and other GeoRepo specific API calls, this GeoSight-side implementation should completely replace the need for GeoRepo, emulating the appropriate API calls if needed or providing an alternate logic path for ucode lookups etc.
The text was updated successfully, but these errors were encountered: