#12555 WFS export by current viewport doesn't work as expected - #12557
Conversation
There was a problem hiding this comment.
@Binabh
Lood good overall but I noticed few cases where the import doesn't work as expected, could please check. Thanks!
WFS (Shapefile)
- Without crop to viewport, upon importing the shaptefile, a warning
The file {{name}} cannot be imported because it does not fit the map boundariesis shown and import fails - With Crop to viewport, the imported feature shown on map is incorrect. Use the map in the issue
|
@dsuren1 thank you for your review. I will look into the case you reported and push a fix in a while. |
|
@dsuren1 the issue related to import failing was related to projection mismatch rather than crop features. When data was exported using native CRS rather than wgs84 then this error was happening. I have pushed the fix. Please review it and let me know if any further improvements are required. |
|
@dsuren1 waiting for your new review here. thanks. |
There was a problem hiding this comment.
@Binabh
I see why you went in this direction to address the issue. Inspecting the generated .shp shows that the exported Native SRS shapefile stores latitude as X and longitude as Y (for example, in the Florida dataset, xmin ≈ 25, xmax ≈ 35, ymin ≈ -87, ymax ≈ -80). The same shapefile is also rendered incorrectly in multiple independent shapefile viewers, which suggests the issue originates from the exported shapefile itself rather than our import implementation.
Based on this, I think we should revert the frontend axis-swapping changes, as they appear to compensate for the exported shapefile instead of addressing the root cause. Also I noticed if works correctly with certain other layers (ex: test:Linea_costa)
I think it would be better to create a separate ticket to investigate this, as it appears to originate from the export side. FYI @tdipisa
We shall merge this PR, as the viewport is sent currently for the WFS export. (Please merge with latest master to avoid lint action failure)
Add to the new issue:
- Investigate whether the native SRS SHAPE-ZIP export is writing coordinates according to CRS axis order instead of the shapefile specification (X = longitude, Y = latitude).
- Investigate whether the issue is specific to WFS 1.1.0 SHAPE-ZIP export and its handling of EPSG axis-order semantics.
- Verify whether the current GeoServer/GeoTools axis-order configuration (e.g.
forceXY) influences the generated SHAPE-ZIP output.
|
@dsuren1 Thank you for your review. Also regarding using same viewportFilter value in try and catch block,(this comment) I realized it is not feasible to use same value as viewportFilter value can be mutated in first WFS request. For that I have used function call in both try and catch block and removed viewportFilter variable entirely as it is useful just once. Let me know anything further can be improved. Also, CI checks are now passing. |
|
@ElenaGallo Kindly test it in DEV when available. Thanks! |
|
Backport failed for |
@offtherailz quite a strange error here... Is that referring the local repo of who created the original PR or what? |
|
Backport failed for |
|
Successfully created backport PR for |
… (#12811) * fix: add viewport filter support to WFS export in startFeatureExportDownload * Add support for reading .prj files and update shpToGeoJSON to handle projections * Fix viewportFilter assignment in startFeatureExportDownload * Fix axis extraction logic in getPrjAxisDirections function * Revert axis swapping and removing readShapePrjFiles * remove unused import and whitespace * fix: update viewportFilter assignment in startFeatureExportDownload function (cherry picked from commit 3082f80) Co-authored-by: Binabh <binabhdevkota@gmail.com>
5 participants
Description
Even if
Crop dataset to current viewportturned on for WFS layer the cropping of download features was not happening properly because the proper OGC filter was not being passed. So, the feature was not working properly.Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
Issue
What is the current behavior?
#12555
What is the new behavior?
Now OCG filter of intersect is applied to if
Crop dataset to current viewportis turned on. This sends valid OCG filter to crop the data. If option is not checked the behavior is same as before.Breaking change
Does this PR introduce a breaking change? (check one with "x", remove the other)