Repository navigation
Conversation
cmangeat
left a comment
There was a problem hiding this comment.
je n'ai pas regardé le front !
| return extent | ||
|
|
||
|
|
||
| def _to_wgs84(conn: Connection, bbox: dict[str, float], epsg: int) -> dict[str, float]: |
There was a problem hiding this comment.
ST_Transform on the envelope only reprojects its 4 corners. In conic projections like Lambert 93 the edges curve, so the WGS84 bbox comes out a bit too small. ST_Transform(ST_Segmentize(envelope, …), 4326) would fix it, or ST_Extent(ST_Transform(geom, 4326)) for an exact result.
| """Set the geographic bounding box of the resource to *bbox* (EPSG:4326).""" | ||
| return self | ||
|
|
||
| def _set_geographic_bbox( |
There was a problem hiding this comment.
Could you add tests in tests/services/metadata_service_internals/ like the other methods have? One for creating the extent and one for overwriting an existing bbox, for both 19115-3 and 19139. The existing samples should be enough.
| .add_online_resources_from_layer_urls_19115_3(layer_urls) | ||
| ) | ||
| if wgs84_bbox is not None: | ||
| schema.update_geographic_extent(wgs84_bbox) |
There was a problem hiding this comment.
Question: this rewrites the bbox on every dag_success, scheduled runs included, so a bbox edited by hand in GeoNetwork gets overwritten. Is that intended?
There was a problem hiding this comment.
It makes sense if rewrite on scheduled, because, as the dataset evolves and grows, so does the bbox. But it should indeed, well documented (or customizable ? @LHBruneton-C2C )
There was a problem hiding this comment.
I'm almost certain this writing the bbox in the metadata is currently dead code kept from Datafeeder V1 but not used by MEL in Datafeeder V2 (switched off by the default template and/or the xml transformation).
We faced several question about the extent, same as what @tonio mentionned.
I thought we were only updating the GeoServer extent ?
…col, and dropping left col, df was showing an error
This PR fixes 2 bugs when joining a table