4

According to their documentation the spatial objects can be of the following 

POINT(0 0)

LINESTRING(0 0,1 1,1 2)

POLYGON((0 0,4 0,4 4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1))

MULTIPOINT(0 0,1 2)

MULTILINESTRING((0 0,1 1,1 2),(2 3,3 2,5 4))

MULTIPOLYGON(((0 0,4 0,4 4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 -2,-2 -2,-2 -1,-1 -1)))

GEOMETRYCOLLECTION(POINT(2 3),LINESTRING(2 3,3 4))

However , there is no circle type, where I can just store a point and its radius. And have the same feature where I can get a bounding box for that circle when do I query if the point exist within it.

Sharky
  • 6,154
  • 3
  • 39
  • 72
user1493786
  • 325
  • 1
  • 3
  • 13
  • Why not convert the circle to a polygon, with more or less nodes, according to the prcision you require ? – Lorenz Meyer Jan 27 '15 at 19:28
  • won't that be just an approximate, like I am trying to implement a simple geofence lookup server that tells if a point is within this geofence which can be either a polygon or circle. While I thought circle would have been easier, but it turns out PostGIS is used on polygon types. What function converts the circle to polygon? – user1493786 Jan 27 '15 at 19:32
  • You can do st_buffer(mypoint,radius) to get a circular geometry around that point. – mlinth Jan 27 '15 at 19:43
  • @mlinth Given my point I want to check against all the circular geofences (point and radius), this wont work if I use for querying as I have to know the radius before hand. However if I am storing my circular geofences using st_buffer then in my column what type of spatial object would it be ? – user1493786 Jan 27 '15 at 19:52
  • The type is geometry. But I thought some of your fences were circular and your problem was that you didn't know how to store them? – mlinth Jan 27 '15 at 20:05
  • When you say it is of type geometry is it as in geometrycollection, because I want to use this function http://postgis.net/docs/manual-1.5/ST_Contains.html and if its of type geometry colllection but if this converts it to type geometry collection. I cannot use it . – user1493786 Jan 27 '15 at 20:21
  • Ok so I looked at ST_buffer again. It returns all the points that is less or equal to the distance surrounding the point and is of type geometry. So its returning a collection of POINTS ?. Then if I made a spatially indexed column to accept spatial objects of type multipolygon would this still be allowed or it will have to be in GeoCollection. :P – user1493786 Jan 27 '15 at 20:30
  • 2
    Hang on - I think you have a fundamental misunderstanding. Your quote from the documentation refers to WKT representations; WKT is not the same as PostGIS's geometry type. You need a geometry column and to work with geometries - I don't think you need to worry about collections or multipolygons or anything like that. Best thing would be to find a getting started tutorial with PostGIS via Google. – mlinth Jan 27 '15 at 20:34
  • So I think I have a better understanding after reading a bit more. In this http://postgis.net/docs/using_postgis_dbmanagement.html#geometry_columns . My confusion is still valid, as I asked if the column is set to accept a type will it 'GEOMETRYCOLLECTION' or 'GEOMETRY'. Look at the column 'Type' specs. – user1493786 Jan 27 '15 at 21:25
  • 1
    Geometry collections have nothing to do with circles, but are made up of any combination of (Multi) Point, Linestring or Polygon. They are generally to be avoided -- some functions behave badly with them and they are not supported well by GIS. The geometry type, on the other hand, means any one of the above, but not all together in one record, as with the collection. – John Powell Jan 27 '15 at 22:17

2 Answers2

6

There is no Postgis type for representing a circle with 100% accuracy, ie, with a centre point and a radius, as there is with SQL Server's circular arcs. As pointed out in the comments, you can approximate a circle with the 2nd form of ST_Buffer, ie, ST_Buffer(point, distance, num_seg_quarter_circle). As you increase the 3rd parameter, you get closer to an actual circle, at the cost of greater calculation times and storage space. The return type of buffering a point will be a Polygon, as can be seen from running, something like:

SELECT ST_GeometryType(ST_Buffer(ST_MakePoint(0,0),100));

My personal view is that while allowing for an arc type may improve the precision of calculations involving circles, it also complicates things, as you are no longer dealing with geometric objects composed entirely of points, linestrings and polygons (the latter two, being also composed of points).

You can always run tests increasing the 3rd parameter of ST_Buffer, until you get a result that is acceptable, but given other inaccuracies inherent in spatial, such as the earth being approximated by a geoid, I would think that issues caused by approximating a geofence like this would be rare. If you run,

SELECT ST_Area(ST_Buffer(ST_MakePoint(0, 0), 1, num_segments));

for different values of num_seg_quarter_circle and compare to PI, you can get an idea how close you are to a true circle.

John Powell
  • 12,253
  • 6
  • 59
  • 67
  • Thank you John, your response really helped. I took the time to reread the whole documentation again and now a lot of it makes sense. YAY ! – user1493786 Jan 28 '15 at 00:59
  • You are welcome. It's a very reasonable question. Hopefully you will agree that there is some sense in not having a spatial circle type, though. – John Powell Jan 28 '15 at 11:59
  • I still don't fully understand why do they need to convert a circle back into polygon. Its like having a less accurate version. All they have to do is store a radius and a point, and maybe if it was spatially indexed just have a bounding box on it. To just compute if a point is within a circle is mathematically straightforward, just comparing if the distance between a point and the centre point of the circle is less than the radius of the circle. – user1493786 Jan 28 '15 at 16:28
0

If all you need to determine if a something is within a distance of another, use ST_DWithin. You can even make it faster by using a spatial index.

If this is your use-case, this discussion of polygon v. circle is irrelevant. Buffering will always have a small amount of error, since it is complicated (e.g. number of segments and other parameters). ST_Buffer is only an approximation of a true, exact buffer. Buffering is also computationally much more expensive. See a good discussion on gis.SE, and a useful tip for newbies.

Community
  • 1
  • 1
Mike T
  • 41,085
  • 18
  • 152
  • 203
  • Since circles can;t be stored in geometry format, how do they create a bounding on box on it when it is spatially indexed ? – user1493786 Jan 29 '15 at 18:51
  • The geometries have a spatial index, which can be used with distance operators like ST_DWithin, which is essentially the same approach as using circles (circles are nothing more than a distance from a point). ST_DWithin is by far the most efficient and exact method. – Mike T Jan 29 '15 at 20:12
  • What I mean is when you store circle in a geometry column, which is not possible. Then you can't even spatially index it . If the point alone was stored as geometry type we cannot leverage spatially indexing cause there is no bounding box for a point. – user1493786 Jan 29 '15 at 20:17
  • Actually it is possible to directly store a circle: use a `CURVEPOLYGON` geometry, but I wouldn't suggest using it since it is seldom supported internally and with other software. Spatial indexes can work on all geometry types. – Mike T Jan 29 '15 at 20:23