Currently in my django I use the following function to take a point, buffer it by 2000 meters, and produce a circle polygon:

updatequery = str("update table_events set event_geo = ST_Multi( ST_Transform( ST_Buffer(ST_Transform(ST_GeomFromText('POINT({0})',4326), 3395), 2000), 4326)) where table_events.source_id = '{1}';").format(geomstring, idstring)

This works great but I'd like to do this more pythonically through GEOS as opposed to passing a raw stringed SQL call to my Postgresql/PostGIS backend. I have tried the following code:

from django.contrib.gis import geos
from django.contrib.gis.geos import MultiPolygon
from datetime import datetime
lat = 34
lon = 38
center = geos.Point(lon, lat)
center.srid = 4326
poly = center.buffer(2000)
entry = events(event_date=datetime.now(), event_geo=MultiPolygon(poly),value=99)

When I go into QGIS to look over the output I have a circle that is the size of the world. What am I doing wrong?

Waaaaay too big of a Circle


The offender may well be this line:

poly = center.buffer(2000)

Are you certain those units are in meters?

I've had issues with rasters being created at 0.5 arc degrees as apposed to 0.5m.



poly = center.buffer(0.018)

if the result is around 2000m my final answer would be that arc degrees is the unit of measure.

  • Using center.transform(3395) should change this to meters based system so when I do the buffer at 2000 it should be 2000 meters. Attempting the 0.018 creates a diameter of 3323.5 meters so that's closer to the answer but not quite what I was looking for. – Echelon_One Apr 11 '17 at 13:20
  • I had a look at the EPSG codes you are using and the second one (after the buffer is done) uses arc degrees... I wonder if perhaps the transformation you are applying, which seems to be only on the buffer, isn't incorrectly reprojecting said buffer. – Ingwe Apr 11 '17 at 13:46
  • So I came back to this today. I found that if I changed the projection to 3857 instead of 3395 it was able to buffer correctly in meters and then transform back to WGS 84 with minimal excess distortion and not having to integrate some excessive conversion methodologies. It adds about 200m on but that's close enough for my project. – Echelon_One Aug 30 '17 at 12:47

I found the best result was merely to change center.transform(3395) to center.transform(3857)

It is important to note this is not a precise conversion and will cause some slight distortion when transforming back and forth between projections. In my samples it added about 200m onto the buffer but for my problem set was completely acceptable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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