#29116 closed Bug (fixed)
Geometry editing issue when widget map_srid different from original value srid
Reported by: | Claude Paroz | Owned by: | nobody |
---|---|---|---|
Component: | GIS | Version: | 2.0 |
Severity: | Release blocker | Keywords: | |
Cc: | Sergey Fedoseev | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Regression in [6ecccad711b52f9273b1acb07a57d3f806e93928].
When a form posts data with GeoJSON formatted input and a map SRID different from the srid of the original value, the deserialization gives a wrong geometry (or crash with OGRFailure
when trying to transform the geometry in the field clean()
method).
Change History (8)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Quoting the latest GeoJSON spec (https://tools.ietf.org/html/rfc7946):
4. Coordinate Reference System The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level. Note: the use of alternative coordinate reference systems was specified in [GJ2008], but it has been removed from this version of the specification because the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues. In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters. However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.
So should we blame MapWidget
for not converting the value to WGS84 before serializing the value?
comment:4 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:5 by , 7 years ago
Cc: | added |
---|
comment:6 by , 7 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
The new patch covers the regression.
(There's some duplication of logic between the field's to_python
and the widget's deserialize
but short of a restructuring that's probably out of scope here it's not clear how that can be avoided.)
The solution might be to customize the
OpenLayersWidget.deserialize
method, trying to inject the proper srid into the input value.