default_lon and default_lat have no effect for OSMGeoAdmin

[stuartk]

When using the default_lon and default_lat options with OSMGeoAdmin, no changes are made to the presented map. The options work when using GeoModelAdmin.

Using the examples given on the Open Street Map wiki for using OpenLayers, I have created a small patch to the openlayers.js file. I have tested it, and it doesn't effect the use of GeoModelAdmin.

[stuartk]

Open Layers javascript file patch

[stuartk]

When using the default_lon and default_lat options with OSMGeoAdmin, no changes are made to the presented map. The options work when using GeoModelAdmin.

Using the examples given on the Open Street Map wiki for using OpenLayers, I have created a small patch to the openlayers.js file. I have tested it, and it doesn't effect the use of GeoModelAdmin.

[jbronn]

The default_lon and default_lat are not working for you because OSMGeoAdmin uses a different projection system than GeoModelAdmin. Specifically, OSMGeoAdmin uses the so-called "Google" projection (SRID=900913) and GeoModelAdmin uses WGS84 (SRID=4326). As such, just transform your default_lon and default_lat values to 900913:

>>> from django.contrib.gis.geos import Point
>>> pnt = Point(lon, lat, srid=4326)
>>> pnt.transform(900913)
>>> default_lon, default_lat = pnt.coords

[Krzysztof Jurewicz]

The comment above actually describes why this bug exists and how to make a workaround, not why it is not a bug. If I’m not mistaken, coordinates in the Web Mercator projection cannot be named “latitude” and “longitude”. Two ways to fix this (not excluding each other):

Ⓐ Assuming that default_lon and default_lat are always given using WGS84 projection and converting them automatically. (Though it would not break any documented behavior, such a change should be probably mentioned in release notes in the section which lists backwards incompatible changes).
Ⓑ Adding a field named default_center which would allow specifying an arbitrary django.contrib.gis.geos.Point object as map center. If no SRID is given, it can possibly be assumed that SRID is the same as the map_srid attribute of the model admin class. As this mechanism is more generic, it would be probably wise to deprecate default_lon and default_lat.

[Tim Graham]

I'm not too knowledgeable about GIS, so I can't comment on the appropriate solution.

[Claude Paroz]

Option B is interesting. Patch welcome!

[Richard Laager]

#11634 has a very similar fix, but that one takes into account display_srid. That might be a reasonable way to settle the SRID of default_lat and default_lon. So I'm boldly marking this one as the duplicate, even though it came first.