2

For a spatial search I need a 900km buffer around a given point(lon 18 degrees, lat 63 degrees) and search all geometries in a table that intersect with the envelope around the buffer( actually a quadrat or rectangle depends where you look at it). The geometry records in the table have SRID 4326. My problem is the envelope object I get does not seem to be correct. I use the following:

select st_astext(
         st_transform(
           st_envelope(
             st_buffer(
               st_transform(
                 ST_GeomFromText('POINT(18 63)', 4326),
                 3857),
              900000)), 
           4326));

First I convert the center point to srid 3857 which is meter based, create a buffer with 900000m radius(a circle in 3857 srid), than make an envelope around the buffer( a quadrat in 3857), and convert it back to 4326 where I will get a rectangle. The result is the Polygon below:

POLYGON((9.9151 59.0917,
         9.9151 66.4469,
        26.0848 66.4469,
        26.0848 59.0917,
         9.9151 59.0917))

I have removed some of the decimals returned. As seen the polygon has a width of about 17 longitude degrees which seems ok, but the heigth is only about 6,6 latitude degrees that is much too short. What am I doing wrong? Is the accuracy for such large buffers so poor? When the center point has the coordinates POINT(18 33) with a lower latitude value the results seem to be Ok. I use PostgreSQL 9.6 and PostGIS 2.2 on Windows.

2
  • 2
    Welcome to GIS SE. As a new user, please take the Tour. There is no "accuracy" issue here, just the inherent complications of buffering on a spheroid. You seem to be going the long way around the block by not casting to a geography, but the result so far north would be the same.
    – Vince
    Jun 9, 2018 at 12:22
  • With smaller buffer sizes the problem is not so evident. Anyhow using another meter based system like 2163 for the buffer generation we got exceptions on the st_transform function when using negative latitudes, so we tried with 3857. Thank you for your comment.
    – rimetnac
    Jun 9, 2018 at 15:04

1 Answer 1

0

In your area at 63°N the degrees in West-East directions are much shorter than at the equator. See for example Calculating longitude length in miles?. The length of latitude is 111461.61 meters while the length of longitude is only 50672.80 meters. Therefore the metric buffer of 900 km must appear flattened when it is shown in the "plate carrée projection" https://en.wikipedia.org/wiki/Equirectangular_projection.

With this SQL you can create the metric buffer from geography and express it as geometry:

SELECT ST_AsText(
ST_Envelope(
ST_Buffer(
ST_GeogFromText('POINT(18 63)'),900000)::geometry));

And this is the result as an image showing the centre point, the 900 km buffer and the envelope of the buffer.

The envelope as WKT is

POLYGON ((
        0.0427499612517697 54.92603943866185, 
        0.0427499612517697 71.05803605306652, 
        35.880482526992445 71.05803605306652, 
        35.880482526992445 54.92603943866185, 
        0.0427499612517697 54.92603943866185
    ))

It is 35.8377325657406753 degrees wide and 16.13199661440467 degrees high. With the lengths of longitude and latitude given above the size of the envelope in kilometers is 1815.998 (W) 1798.098 (H). Not exacty 1800 but not much different either.

enter image description here

If you place a round sticker to a football and look at it from different angles you will notice that it is not odd at all that at the sticker seems to be wider than high when looked at flat angle.

5
  • I am aware that longitude degrees are shorter wenn going north or south. The heigth of the rectangle is 7.4 degrees which is shorter than 900 km. I used the transform from 4326 to 3857 in order to call ST_Buffer and pass the distance in meters rahter than degrees. With Geography I can not do this. Another issue was the following: I expected that the ST_Transform will convert a rectangle(in meters) from 3857 SRID to a "trapezoidal" polygon in SRID 4326 ( degrees), but I got a rectangle with the same width at the upper and lower edges
    – rimetnac
    Jun 11, 2018 at 11:01
  • See the SQL above, it is exactly using 900000 meters as a buffer with geography. EPSG:3857 distorts the scale towards the poles and it is one of the most unsuitable coordinate systems for distance and area calculations. Don't use it.
    – user30184
    Jun 11, 2018 at 12:53
  • So the ST_buffer used on a geography object uses meters as unit and not degrees. We have used previously srid 2163 for converting degrees based geometry to meter based, but the 2163 delivered wrong results in the southern emisphere that's why we have chosen 3857. Thank you for your support.
    – rimetnac
    Jun 11, 2018 at 13:08
  • Right, it is documented in postgis.org/docs/ST_Buffer.html synopsis: geography ST_Buffer(geography g1, float radius_of_buffer_in_meters);.
    – user30184
    Jun 11, 2018 at 13:10
  • Once again thank you very much. Your answer solved the problem!
    – rimetnac
    Jun 12, 2018 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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