Путаница широты и долготы с использованием Geo Django и OSMGeoAdmin - PullRequest
Новая
       51

Путаница широты и долготы с использованием Geo Django и OSMGeoAdmin

0 голосов
/ 03 августа 2020

Я пытаюсь сохранить многоугольник с помощью виджета карты OSMGeoAdmin, и я объявил свой класс администратора следующим образом: 

class ProjectAdmin(OSMGeoAdmin):
    default_lon = 4600000
    default_lat = 180000
    default_zoom = 4

И это базовый класс моей геометрической модели: 

class AbstractGeometryModel(models.Model):
    class Meta:
        abstract = True

    geometry = models.MultiPolygonField()

    @property
    def boundary(self):
        boundary = self.geometry.boundary[0]
        return [[x[1], x[0]] for x in boundary]

    @property
    def bbox(self):
        box = self.geometry.extent
        return [[box[1], box[0]], [box[3], box[2]]]

    @property
    def centroid(self):
        return [self.geometry.centroid[1], self.geometry.centroid[0]]

Как упоминалось в Django документах, SRID по умолчанию должен быть 4326, и, как я лично проверял, когда вы получаете экстент геометрии, он имеет формат [lat, lon, lat, lon], и мне нужно, чтобы они были lon, lat, поэтому я написал эти методы свойств.

Проблема в том, что всякий раз, когда я развертываю свой сервис в новом производственном окружении или запускаю его с нуля в локальной среде разработки, я вижу, что lat, lon хранятся в обратном формате .

чтобы проверить эту проблему, я решил сравнить производственную базу данных с моей локальной базой данных разработки, и вот результаты: 

>>> from django.contrib.gis.geos import GEOSGeometry
>>> production_data = GEOSGeometry('0106...(Geometry copied from production db)...1532')
>>> production_data.extent
(17.2922570380823, 44.879874515170165, 18.00644604063442, 46.02245264001086)
>>> production_data.srid
4326
>>> development_data = GEOSGeometry('0106...(Geometry copied from development db)...1532')
>>> development_data.extent
(44.75627832378126, 17.887728306166515, 46.09661035484472, 18.10414680358874)
>>> development_data.srid
4326

Как видите, SRID совпадают но данные хранятся как lat, lon в производственной базе данных, а также как lon, lat в локальной базе данных!

Я пытался отладить, чтобы узнать, что происходит, но мне это не удалось. Буду признателен, если кто-нибудь поможет мне с этой проблемой. Спасибо.

ОБНОВЛЕНИЕ Я также запускаю код ниже как на сервере, так и на локальной python консоли:

local: 

Python 3.8.3rc1 (default, May 10 2020, 12:11:09) 
[GCC 7.4.0] on linux
Django 2.2.4
>>> from django.contrib.gis.geos import GEOSGeometry
>>> a = GEOSGeometry('SRID=3857;MULTIPOLYGON(((..lots of geo numbers...)))')
>>> a.transofrm(4326)
>>> a.extent
(34.109070627613065, 46.87535791416505, 36.24604033684087, 53.423209475753794)

server: 

root@fdfd7ccf489b:/code# python manage.py shell
Python 3.7.6 (default, Feb 26 2020, 15:34:58) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from django.contrib.gis.geos import GEOSGeometry                                                                                                                                                                                      

In [2]: a = GEOSGeometry('SRID=3857;MULTIPOLYGON(((..lots of geo numbers...)))')                       

In [3]: a.extent                                                                                                                                                                                                                              
Out[3]: (5218140.9737573, 4043456.9660937, 5947044.4753833, 4334529.1697632)

In [4]: a.transform(4326)                                                                                                                                                                                                                     

In [5]: a.extent                                                                                                                                                                                                                              
Out[5]: (46.875357914165036, 34.10907062761305, 53.42320947575378, 36.246040336840856)

поэтому кажется, что проблема связана с версией или конфигурацией Geo Django ...

1 Ответ

0 голосов
/ 04 августа 2020

Похоже, что root источник проблемы - разные версии GDAL, установленные в производственной (GDAL 2.4.0) и локальной (GDAL 3.0.1) среде.

https://code.djangoproject.com/ticket/31695#no1

...