Using SetGeom() for a PostGIS feature does not set geometry spatial reference system (Python bindings)

[hairymapper]

When doing:

    out_srs = ogr.osr.SpatialReference()
    out_srs.ImportFromEPSG(27700)

    geom.AssignSpatialReference(out_srs)
    
    feature.SetGeom(geom)
    layer.CreateFeature(feature) # where layer is a PostGIS table.

The resulting EKWT string passed to PostGIS contains an SRID value of -1 and not the SRS applied from out_srs.

You can see my related question on GIS StackExchange at: ​http://gis.stackexchange.com/questions/19614/how-to-assign-ogr-geometry-a-spatial-reference-when-writing-to-a-new-layer-using

[Even Rouault]

Spatial reference attached at the feature geometry level are indeed ignored. What is taken into account if the SRS used at layer creation or registered in the geometry_columns table. There must be something odd in your setup if the PG driver isn't able to set the SRID registered in geometry_columns. Does ogrinfo on that layer returns a SRS ?

[hairymapper]

Replying to rouault:

Spatial reference attached at the feature geometry level are indeed ignored. What is taken into account if the SRS used at layer creation or registered in the geometry_columns table. There must be something odd in your setup if the PG driver isn't able to set the SRID registered in geometry_columns. Does ogrinfo on that layer returns a SRS ?

Thanks for your comment. You were correct, the layer was not returning a SRS (geometry_columns table wasn't being updated in earlier create table functions). Once this was fixed I could update the table using the above code.

However, I feel this raises an important point: SetGeom should parse the SRS from the geometry (especially as it's using EWKT so the functionality is there) otherwise this renders PostGIS' enforce_srid_geom check useless and we have no way of verifying if user input is in the correct coordinate system. For example, I've just managed to insert geometry via feature.SetGeom(geom) which is in a different coordinate system to that as defined in the table/layer and in the enforce_srid_geom check.

[Even Rouault]

It is quite a common practice that people use SetGeometry() and CreateFeature() with a geometry without explicit SRS assigned, so enforcing too strongly would break many code (including GDAL autotest suite).

But what is reasonable would be to check, that *if* a SRS is assigned to the geometry, it must match the layer SRS. If it doesn't, emit a warning/error. If the geometry has no assigned SRS, then we will silently use the layer SRS, as currently.

[hairymapper]

Replying to rouault:

It is quite a common practice that people use SetGeometry() and CreateFeature() with a geometry without explicit SRS assigned, so enforcing too strongly would break many code (including GDAL autotest suite).

But what is reasonable would be to check, that *if* a SRS is assigned to the geometry, it must match the layer SRS. If it doesn't, emit a warning/error. If the geometry has no assigned SRS, then we will silently use the layer SRS, as currently.

I agree passing a geometry without an SRS assigned should be valid, especially given that Wkt/Wkb don't contain SRS definition, but as you said if a SRS has been defined this should really be checked and a warning thrown if found to be different than that of the target layer.

I will write something to this effect in our software, but it would be great to see in the OGR library. Should I close this ticket and open a new feature request?

Thanks for your insight with this - it has been very helpful.

[Even Rouault]

No need to create a new ticket. That one should be fine

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.