Re: Customizable model field (such as SRID for geometries) and migrations

[Chetan Ganji]

I dont understand your requirements :P

But this will certainly help.
https://docs.djangoproject.com/en/3.2/ref/contrib/gis/tutorial/#geodjango-tutorial
https://docs.djangoproject.com/en/3.2/ref/contrib/gis/model-api/

IN the below link, it says about setting the SRID field :P
https://docs.djangoproject.com/en/3.2/ref/contrib/gis/tutorial/#geographic-data

Note that the models module is imported from django.contrib.gis.db.
The default spatial reference system for geometry fields is WGS84 (meaning
the SRID  is 4326) – in other words,
the field coordinates are in longitude, latitude pairs in units of degrees.
To use a different coordinate system, set the SRID of the geometry field
with the srid argument. Use an integer representing the coordinate system’s
EPSG code.


I hope this helps you !!!



Regards,
Chetan Ganji
+91-900-483-4183
ganji.che...@gmail.com
http://ryucoder.in


On Wed, Jun 2, 2021 at 12:26 PM Olivier Dalang 
wrote:

> Dear List,
>
> I'm working on a Django app whose models have geometry fields and that
> will be deployed in several geographic locations.
>
> Using a globally available reference system (WGS84) and reprojecting on
> the fly will not work due to performance and accuracy implications for
> geometric queries. Thus I'd like to make the SRID customizable.
>
> The issue comes with migrations which hard-code the SRID in the
> CreateModel statements. I could import an SRID from a variable in
> settings.py, but don't like that idea, as changing it after creating would
> mess things up (srid mismatch, creating new migrations...). It's actually
> not really a django setting, but more related to the data.
>
> One idea would be to store the default SRID in the DB itself (in a
> dedicated settings model) and retrieve the SRID dynamically from that
> before running the migrations and loading the models. There could even be
> some logic to reproject/adapt all geometries fields if the value changes.
> Sounds nice, but also complicated (models are not available .
>
> I'm probably not the first one with this type of requirement (could also
> happen for other use cases such as language, currencies, etc.). Is there a
> package I could use or some design pattern I could follow ?
>
> Thanks !!
>
> Olivier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAExk7p1s%2B4XozdQOxjZKMbXmG7xq6hhMSiVTsrSyj26VBG%3DFJw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAMKMUjsrmPnCTC81Wc7bs6dQ%3D-bWsDDXAGQ8%3Dzi45n%3D_eD1hhQ%40mail.gmail.com.

Customizable model field (such as SRID for geometries) and migrations

[Olivier Dalang]

Dear List,

I'm working on a Django app whose models have geometry fields and that will
be deployed in several geographic locations.

Using a globally available reference system (WGS84) and reprojecting on the
fly will not work due to performance and accuracy implications for
geometric queries. Thus I'd like to make the SRID customizable.

The issue comes with migrations which hard-code the SRID in the CreateModel
statements. I could import an SRID from a variable in settings.py,
but don't like that idea, as changing it after creating would mess things
up (srid mismatch, creating new migrations...). It's actually not really a
django setting, but more related to the data.

One idea would be to store the default SRID in the DB itself (in a
dedicated settings model) and retrieve the SRID dynamically from that
before running the migrations and loading the models. There could even be
some logic to reproject/adapt all geometries fields if the value changes.
Sounds nice, but also complicated (models are not available .

I'm probably not the first one with this type of requirement (could also
happen for other use cases such as language, currencies, etc.). Is there a
package I could use or some design pattern I could follow ?

Thanks !!

Olivier

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAExk7p1s%2B4XozdQOxjZKMbXmG7xq6hhMSiVTsrSyj26VBG%3DFJw%40mail.gmail.com.