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).
--
Ticket URL: <https://code.djangoproject.com/ticket/29116>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Claude Paroz):
The solution might be to customize the `OpenLayersWidget.deserialize`
method, trying to inject the proper srid into the input value.
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:1>
Comment (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?
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:2>
* has_patch: 0 => 1
Comment:
Added a possible resolution in [https://github.com/django/django/pull/9668
this PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:3>
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:4>
* cc: Sergey Fedoseev (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:5>
* stage: Accepted => Ready for checkin
Comment:
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.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:6>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"2a2ed0e70a93bfd1a3d41af40870fe963dc2687d" 2a2ed0e7]:
{{{
#!CommitTicketReference repository=""
revision="2a2ed0e70a93bfd1a3d41af40870fe963dc2687d"
Fixed #29116 -- Fixed OpenLayersWidget deserialization ignoring the widget
map's SRID.
Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:7>
Comment (by Tim Graham <timograham@…>):
In [changeset:"357a48368a0102d88675da601bf2fa59098eef01" 357a483]:
{{{
#!CommitTicketReference repository=""
revision="357a48368a0102d88675da601bf2fa59098eef01"
[2.0.x] Fixed #29116 -- Fixed OpenLayersWidget deserialization ignoring
the widget map's SRID.
Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.
Backport of 2a2ed0e70a93bfd1a3d41af40870fe963dc2687d from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29116#comment:8>