Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I'm inserting map data from a GML file with srid EPSG:27700 into a PostGIS database table with srid EPSG:4326. I'm using the ST_Transform function as in this snippet:

 ST_Transform(ST_GeomFromGML('<gml:Point srsName="EPSG:27700">
    <gml:coordinates>527347.0,181346.0</gml:coordinates></gml:Point>'), 4326);

After the data was inserted in the database I tried to find if its geometry intersects with an existing table's geometry using the ST_Intersects function. The function returned FALSE in all cases, but I knew that the two geometry layers should intersect.

So, I loaded the layers in QuantumGIS to see what's happening. The PostGIS layers indeed don't intersect, but when I loaded the GML data directly from the GML file using the original srid (EPSG:27700) the map data correctly appeared on top of the pre-existing layer with srid 4326, with which I knew it should intersect. The problem is that the ST_Intersects function (as well as all the others of the same kind) works only for geometries with the same srid, so I need to solve the transformation issue.

Apparently there's either a problem with the ST_Transform function, or I'm missing something that I should know. I use PostGIS 1.5.3. Any help will be greatly appreciated.

share|improve this question
I tried to duplicate your steps and got the expected results. I started with a polygon layer in 4326, and created a new point layer, also in 4326. Then I INSERTed a point into the layer using ST_Transform(ST_GeomFromGML()), using coordinates from a different CRS, but which should fall inside the poly. It worked correctly. So your method seems correct. –  Micha Jul 23 '12 at 16:18
Are you sure the ST_GeomFromGML function has created the geometry as expected? - does the geometry have EPSG:27700 as its srid. –  CHenderson Jul 23 '12 at 22:31
@Micha Sounds strange, I keep on getting it wrong. Thanks for trying it out! –  Orestis Tsinalis Jul 25 '12 at 15:28
@CHenderson I double-checked it and the srid is definitely correct. –  Orestis Tsinalis Jul 25 '12 at 15:28
What I did in the end was to convert the other layer into EPSG:27700 (it's a shape file that I import in PostGIS using the shp2pgsql tool), and to import the GML without transforming the geometry to a different spatial reference system. It then worked as expected, but I would really like to understand what went wrong in the first case. –  Orestis Tsinalis Jul 25 '12 at 15:28

1 Answer 1

I've been having the same problem for a few days now. I found a solution, however, I didn't use PostGIS. Instead, I used QGIS (2.0.1 - Dufour) to do so.

My problem was the same as yours. I imported a shapefile of road network that I have previously displayed in QGIS, where it would display correctly. The original SRID was 3347 (EPSG:3347 - NAD83 / Statistics Canada Lambert). I was trying to change it to 32188.

I used ST_Transform() and UpdateGeometrySRID(), in multiple orders, reverting back to the original SRID at times, but to no avail. The output of ST_SRID was displaying the correct value of 32188. But, when I tried to display it in QGIS, the layer wouldn't appear. Moreso, displaying the geometry using ST_AsText() would show the original coordinates (SRID=3347), not those expected from a SRID=32188.

The solution

I simply opened the shapefile in QGIS. Right-click > Save as... >

  1. Format: ESRI Shapefile
  2. Save as: Choose a new name
  3. CRS > Browse > Selected the correct CRS (32188)
  4. Add saved file to map: Check
  5. Ok

After that, I used the PostGIS Shapefile Import/Export Manager to import that shapefile. Now, everything works fine. The coordinates and the SRID are both correct.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.