djangopostgresqldjango-rest-frameworkpostgissrid

How is postgis treating coordinates sent with different SRID


I am running a django application and I am using the PostGis extension for my db. I am trying to understand better what happens under the hood when I send coordinates, especially because I am working with different coordinate systems which translate to different SRIDs. My question is threefold:

  1. Is django/postgis handling the transformation when creating a Point or Polygon in the DB.
  2. Can I query it back using a different SRID
  3. Is it advisable to use the default SRID=4326

Let's say I have a model like this (note I am setting the standard SRID=4326):

class MyModel(models.Model):

    name = models.CharField(
        max_length=120,
    )
    point = models.PointField(
        srid=4326,
    )
    polygon = models.PolygonField(
        srid=4326,
    )
  1. Now I am sending different coordinates and polygons with different SRIDS.

I am reading here in the django docs that:

Moreover, if the GEOSGeometry is in a different coordinate system (has a different SRID value) than that of the field, then it will be implicitly transformed into the SRID of the model’s field, using the spatial database’s transform procedure

So if I understand this correctly, this mean that when I am sending an API request like this:

data = {
   "name": "name"
   "point": "SRID=2345;POLYGON ((12.223242267 280.123144553))"
   "polygon": "SRID=5432;POLYGON ((133.2345662 214.1429138285, 123.324244572 173.755820912250072))"

}

response = requests.request("post", url=url, data=data)

Both - the polygon and the point - will correctly be transformed into SRID=4326??

EDIT:

When I send a point with SRID=25832;POINT (11.061859 49.460983) I get 'SRID=4326;POINT (11.061859 49.460983)' from the DB. When I send a polygon with 'SRID=25832;POLYGON ((123.2796155732267 284.1831980485285, ' '127.9249715130572 273.7782091450072, 142.2351651215613 ' '280.3825718937042, 137.558146278483 290.279508688337, ' '123.2796155732267 284.1831980485285))' I get a polygon 'SRID=4326;POLYGON ((4.512360573651161 0.002563158966576373, ' '4.512402191765552 0.002469312460126783, 4.512530396754145 ' '0.002528880231016955, 4.512488494972807 0.00261814442892858, ' '4.512360573651161 0.002563158966576373))' from the DB

  1. Can I query it back using a different SRID

Unfortunately I haven't found a way to query the same points back to their original SRID. Is this even possible?

  1. And lastly I am working mostly with coordinates in Europe but I also might have to include sporadically coordinates from all over the world too. Is SRID=4326 a good standard to use?

Thanks a lot for all the help in advance. Really appreciated.


Solution

  • Transforming SRS of geometries is much more than just changing their SRID. So, if for some reason after a transformation the coordinates return with exactly the same values, there was most probably no transformation at all.

    This example uses ST_Transform to transform a geometry from 25832 to 4326. See the results yourself:

    WITH j (geom) AS (
     VALUES('SRID=25832;POINT (11.061 49.463)'::geometry))
    SELECT ST_AsEWKT(geom),ST_AsEWKT(ST_Transform(geom,4326)) FROM j;
    
     
    
           st_asewkt            |                      st_asewkt                       
    ---------------------------------+------------------------------------------------------
     SRID=25832;POINT(11.061 49.463) | SRID=4326;POINT(4.511355210946569 0.000446125446657)
    (1 Zeile)
    

    Make sure that django is really storing the values you mentioned. Send a 25832 geometry and directly check the SRS in the database. If you're only checking using django, it might be that it is transforming the coordinates back again in the requests, which might explain you not seeing any difference.

    To your question:

    Is SRID=4326 a good standard to use?

    WGS84 is the most used SRS worldwide, so I'd tend to say yes, but it all depends on your use case. If you're uncertain of which SRS to use, it might indicate that your use case does not impose any constraint to it. So, stick to WGS84 but keep in mind that you don't mix different SRS in your application. Btw: if you try to store geometries in multiple SRS in the same table, PostgreSQL will raise an exception ;)

    Further reading: ST_AsEWKT, WGS84