Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#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 Changed 3 years ago by Claude Paroz

The solution might be to customize the OpenLayersWidget.deserialize method, trying to inject the proper srid into the input value.

comment:2 Changed 3 years ago by Claude Paroz

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:3 Changed 3 years ago by Claude Paroz

Has patch: set

Added a possible resolution in this PR.

comment:4 Changed 3 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:5 Changed 3 years ago by Sergey Fedoseev

Cc: Sergey Fedoseev added

comment:6 Changed 3 years ago by Carlton Gibson

Triage Stage: AcceptedReady 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.)

comment:7 Changed 3 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 2a2ed0e7:

Fixed #29116 -- Fixed OpenLayersWidget deserialization ignoring the widget map's SRID.

Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.

comment:8 Changed 3 years ago by Tim Graham <timograham@…>

In 357a483:

[2.0.x] Fixed #29116 -- Fixed OpenLayersWidget deserialization ignoring the widget map's SRID.

Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.

Backport of 2a2ed0e70a93bfd1a3d41af40870fe963dc2687d from master

Note: See TracTickets for help on using tickets.
Back to Top