entries.location nullable + db revision

[AlexDo1]

Column location in table entries is now nullable, as spatial / raster data cannot be represented as POINT location. Datasource.spatial_scale.extent should be used instead for PLOYGON locations.

[codecov[bot]]

Codecov Report

Merging #186 (96a9c61) into master (faf2266) will decrease coverage by 0.07%. The diff coverage is 52.63%.

@@            Coverage Diff             @@
##           master     #186      +/-   ##
==========================================
- Coverage   61.54%   61.47%   -0.08%     
==========================================
  Files          70       71       +1     
  Lines        3352     3369      +17     
==========================================
+ Hits         2063     2071       +8     
- Misses       1289     1298       +9     

Flag	Coverage Δ
e2e	61.47% <52.63%> (-0.08%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
metacatalog/api/add.py	49.27% <ø> (ø)
metacatalog/db/revisions/__init__.py	100.00% <ø> (ø)
metacatalog/models/datasource.py	66.82% <40.00%> (-0.68%)	:arrow_down:
metacatalog/db/revisions/rev11.py	50.00% <50.00%> (ø)
metacatalog/__version__.py	100.00% <100.00%> (ø)
metacatalog/models/entry.py	68.94% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[mmaelicke]

I am still not sure if we should enforce POINT geometries for overview maps. Alternatively, drop the location altogether and introduce a view of POINTS, derived from spatial extent table....

[AlexDo1]

The RADKLIM metadata entry is now added to the database metacatalog-dev on the server and can serve as an example for how we want to handle locations now. I did not use NULL for entries.location but the centroid of the RADOLAN grid. With this PR, we could / should use NULL, the centroid of the grid is then calculated from the spatial extent for the location View: https://github.com/VForWaTer/metacatalog/blob/9655d0691db8f5c8b57bcd3b6b423b69217b1b7a/metacatalog/db/views/locations.sql#L9-L21

Here is a screenshot of the location View, which also shows the area of the column geom:

This map shows all point locations, with the RADKLIM location as the centroid of the grid:

And this shows the column geom with the actual shape of the extent / the RADOLAN grid:

@mmaelicke @MarcusStrobl we should discuss how we want to handle and store locations, especially POLYGON locations.

[mmaelicke]

Thanks @AlexDo1!

I guess, with this in place, we can make the location column nullable and remove the point for RADKLIM data. The view should then generate the centroid as a point for the point_location view column, right?

I guess the key here is the area column, as we can request the geometries depending on the Map zoom level. For a small zoom level (ie 2, almost world-view) the Geoserver layer should use only geom that have a minimum size, effectively shrinking the rectangle around BaWü to its centroid, but at the same time the Radklim can still be viewed. If we are closer (ie. zoom level 12), BaWür would use the POLYGON as well.

So to come back to your question: we add location as point, whenever that makes sense, we add the geom, if there is a Non-Point representation of the spatial domain of measurements (ie. catchment) and we set the geometry inside the spatial scale of the datasource as a bounding box (effectively the extent of all measurements) as required by INSPIRE/ISO 19115. The distinction between the datasource.spatial_scale.extent and the entry.geom is not 100% clear, I guess, and we can discuss this. My 2 cents on this: the geom is the area, that is represented by the measurements (so its about the data), while the spatial extent is the covered area (so its about the metadata).