I would like to buffer the warning polygon by two miles can anyone help me with
this so if ema personal are with in to miles of the warning the are listed, I've been trying to use ST Buffer (to expand the polygon coverage for the search) but cant seem to get it right? Is it in Meters (3218.69)? I'm using the latest opengeo suite.
SELECT DISTINCT ON (ema.name)
ST_X(ema.geom),ST_Y(ema.geom),ema."name", torpoly.expire
FROM ema INNER JOIN torpoly ON ST_Within(ema.geom, ST_BUFFER(torpoly.geom)
ORDER BY ema."name"
Your options are either:
Use an appropriate projected coordinate system for the region that uses linear units in metres or feet (UTM, State plane, etc.). All distance calculations on geometry types use a Cartesian coordinate system, which is quick and simple.
Use the geography type, which does distance calculations on objects with EPSG:4326 (lat/lon) with distance units in metres. If you don't want to change the data types, you can use a geom::geography cast, and maybe make an index on that cast.
And never do ST_Within(.., ST_Buffer()) for this type of analysis. It is slower and imperfect. Instead, use ST_DWithin, which finds all geometry/geography objects within a distance threshold of each other, which is just like a buffer. This function may use a spatial GiST index, if present.
Related
I have a list of Bus routes from GTFS. I also have a list of Bike Tracks as Polylines.
I'm looking to match the bus routes against the bike tracks. They dont match perfectly, so I just need the list of bike tracks sections that runs along a bus route section. I'm hoping to get as end result, for each bus route a list of bike tracks segments.
My initial thoughs to solve this problem is to split the bike track into multiple segments and start comparing points from bike track to points in my bus route.
Seems a bit naive this approach and I fear it won't have the best performance.
Is there a better way? To find the polyline that fits another polyline?
Thanks
One possible approach would be to perform a Spatial Join using the ST_DWithin function of PostGIS on the join condition.
You would pass your "tolerance" (how large can the closest distance between both polylines for you to still to consider them as "overlaps") as the distance in the third parameter. Note that this tolerance must be in the same SRID (coordinate system) of the input geometries (which must also be equal).
That is, if your coordinates are specified in degrees, and you want to have a tolerance of, say, 100 meters, you'd need to convert 100 meters to degrees too. Note that the physical size of a degree changes depending on your latitude (increasing as you move further away from the Equator), but this probably matters little to your scenario since you control the tolerance threshold (unless you're dealing with extreme latitudes for some reason).
I can calculate the distance between two points using:
SELECT ST_Distance(
ST_GeomFromText('SRID=4326;POINT(54.5972850 -5.930119)')
, ST_GeomFromText('SRID=4326;POINT(54.516827 -5.958130)'),
false);
However, my goal is to create a rough circular zone (this can be square, hexagon, octagon .etc) around each point and then check if the zones overlap.
I am looking at ST_Overlaps as a possible solution but I am not sure how to convert these points into polygons to be compared. My ideal result would be something like:
SELECT ST_Overlaps(
ST_CreateCircularPolygon(geom1, 1000, 6)
ST_CreateCircularPolygon(geom2, 10000, 4)
);
Where:
ST_CreateCircularPolygon(geomerty, metreRadius, numberOfRadialPoints (e.g. 6 creates a hexagonal polygon))
Any guidance would be much appreciated!
You can use the quad_seg parameter of st_buffer to specify the number of segments per quarter of a circle. That is, the total number of segments in the output will be a factor of 4.
To produce a square:
select st_asText(st_buffer(st_geomFromText('Point(10 10)'), 1, 'quad_segs=1'));
st_astext
------------------------------------------------------
POLYGON((11 10,10 9,9 10,9.99999999999999 11,11 10))
(1 row)
Octagon:
select st_asText(st_buffer(st_geomFromText('Point(10 10)'), 1, 'quad_segs=2'));
st_astext
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
POLYGON((11 10,10.7071067811865 9.29289321881345,10 9,9.29289321881345 9.29289321881345,9 10,9.29289321881345 10.7071067811865,9.99999999999999 11,10.7071067811865 10.7071067811866,11 10))
(1 row)
Since you want to work in meters but have unprojected coordinates, you can cast your geometry to geography, apply a buffer in meters and cast back to geometry. Let's note that st_buffer in geography will internally cast to a geometry in UTM, do the buffer, then cast back to geography (a lot of casting, but it's handy!)
That being said, a square is not a circle and it sounds very very wrong to assume otherwise. The orientation of the square is not obvious: should a corner be at the north? or should a segment be facing norht? or should the square be rotated? by how much?
You will save yourself a lot of trouble by using a real circle. In this case, don't use st_buffer at all, nor st_distance but rather st_dwithin which can leverage spatial indexes
I am looking to use Redis' GEORADIUS command.
However, this command only searches within the range of a two-dimensional circle around a given longitude and latitude. I need to also search with an altitude, thus finding results within the range of a three-dimensional sphere.
How would I achieve this in Redis?
I believe what you're actually trying to do is search within a 3D cylinder (or some kind of a cone if you take into account the Earth's spherical nature).
An altitude search isn't natively included with Redis' geospatial indices, but you could store that property in its own Sorted Set as score. Then, you can perform a range search (ZRANGEBYSCORE) on the altitude and intersect (ZINTER) the results with those from the radius query (hint: use a temporary key to STORE results).
For your reference, this is the approach I took with the xyzsets in geo.lua.
What is the Difference between Geodist(sfield,x,y) and dist(2,x,y,a,b) in Apache Solr for Geo-Spacial Searches ??
dist(2,x,y,0,0) :- calculates the Euclidean distance between (0,0) and (x,y) for each document. Return the Distance between two Vectors (points) in an n-dimensional space.
I was earlier using geodist() distance function for Geo-Spatial searches on my website but its response time was large. so have done a POC(proof of concept) for different distance functions and found that dist(2,x,y,0,0) distance function is relatively taking half of the time. But I want to know the reason behind this and the algorithms which both functions are using to calculate the distance.
I have to make a difference matrix for the same to convey it further.
The main difference is that geodist() is intended to work with spatial field types.
Most spatial implementation are based on Lucene's Points API, which is a BKD Index. This field type is strictly limited to coordinates in lat/lon decimal degrees. Behind the scenes, latitude and longitude are indexed as separate numbers. Four main field types are available for spatial search :
LatLonPointSpatialField
LatLonType (now deprecated) and its non-geodetic twin PointType
SpatialRecursivePrefixTreeFieldType (RPT for short), including RptWithGeometrySpatialField, a derivative
BBoxField (for areas, 4 instances of another field type referred to by numberType)
In geodist (sfield, x, y), sfield is a spatial field type that represents two points (lat,lon), so the direct equivalent using dist() would be to implement dist (2, sfieldX, sfieldY, x, y) with sfieldX and sfieldY being respectively the (lat,lon) coordinates of sfield.
Using dist (power, a, b, ...) you can't query a spatial field type. In order to perform the same spatial search, you would have to specify every point's dimension separately. It would require 2 indexed fields (or values per field at least) for 2 dimensions, 3 for 3d, and so on. That makes a huge difference because you would have to index every coordinates of each point separately.
Besides, you can also use geodist() as is with the BBoxField field type that indexes a single rectangle per document field and supports searching via a bounding box. To do the same with dist() you would have to compute the center point of the box to input each one of its coordinates as a function argument, so it would be too much hassle to yield the same result if you want to use an area as parameter.
Lastly, LatLonPointSpatialField for example does distance calculations based on Haversine formula (Great Circle), BBoxField does it a little faster because the rectangular shape is faster to compute. It's true that dist() may be even faster but remember that requires more field to be indexed, a lot of preprocess at query time to be able to yield the same calculated distance, and, as mentioned by Mats, it wouldn't take the earth' curvature into account.
An euclidean distance doesn't account for the curvature of the earth. If you're only sorting by the distance, the behavior can be OK - but only if your hits are within a small geographical area (the value of a unit compared to meters greatly change when you're getting closer to the poles).
There's an extensive and good answer that explains the difference between a Euclidean distance and a proper geographical distance (usually calculated using haversine) available at the GIS Stack Exchange.
Although at small scales any smooth surface looks like a plane, the accuracy of the Pythagorean formula depends on the coordinates used. When those coordinates are latitude and longitude on a sphere (or ellipsoid), we can expect that
Distances along lines of longitude will be reasonably accurate.
Distances along the Equator will be reasonably accurate.
All other distances will be erroneous, in rough proportion to the differences in latitude and longitude.
Does Postgres' Spatial plugin, or any Spatial package for that manner, factor in the altitude when calculating the distance between 2 points?
I know the Spatial packages factor in the approximate curvature of the earth but if one location is at the top of a mountain and the other location is close to the sea - it seems like the calculated difference between those two points would greatly vary if the difference in altitude was not factored into account.
Also keep in mind that if I have 2 points are at the same ocean altitude but a mountain exists between the 2 points - the distance package should account for this.
Those factors are not being counted at all. Why? The software only knows about the two features (the two points you are getting the distance, the sphere/spheroid and a datum/projection factor).
For that to happen you need to probably use a developed linestring, in which you will connect your point with n vertices, each of them being Z aware.
Imagine this (loose WKT): LINESTRING((0,1,2),(0,2,3),(0,3,4),(0,10,15),(0,11,-1)).
Asking the software to calculate the distance between each vertex and summing it up, will consider the variations of terrain. But without something like that, it is impossible to map for irregularities in terrain.
All GIS softwares cannot tell, by themselves, what are those irregularities in terrain, and therefore, not take them in account.
You can create such linestrings (automatically) with softwares like ArcGIS (and others), using a line (between two points), and a surface file, such as the ones provided freely by NASA (SRTM project). These files come in a raster format, and each pixel has a X Y and Z value, in meters. Traversing the line you want, coupled with that terrain profile, you can achieve the calculation you want to achieve. If you need to have super extra precise calculations, you need a precise surface, and precise Z values in each vertex of this profile line.
That cleared up?
If the distance formula you're using does not take the altitude of the two points as parameters (in addition to the Latitudes and Longitudes of the two points), then it does not factor in altitude to the distance calculation. In any event, altitude difference does not have a very significant effect on calculated distance.
As usual with GPS, the difference in distance calculations that altitude would make is probably smaller than the error in most commercial GPS devices anyway, so in most applications altitude can be safely dispensed with (altitude measurements themselves are pretty inaccurate with commercial GPS devices, although survey data on altitudes is quite accurate).
PostgreSQL does not factor in altitude when calculating distances. It is all done in a planar surface.
Most of database spatial packages will not take this into account, altought, if your point is 3d, i.e., has a Z coordinate that might happend.
I don´t have PostgreSQL in this machine, but try this.
SELECT ST_DISTANCE(ST_POINT(0,0,10),ST_POINT(0,0,0));
It´s fairly easy to know if it is taking into account your Z value, since the return should be > 0; If that turns out to be true, just create Z aware features, and you will be successfull.
What SQL SERVER 2008, for example, takes into account when calculating distances, is the position of a Geography feature in a sphere. Geometry features in SQL SERVER will always use planar calculations.
EDIT: checked this in PostGIS manual
For Z aware points you must use the ST_MakePoint function. It takes up to 4 arguments (X Y Z and M). St_POINT only takes two (X Y)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance.html
ST_DISTANCE = 2D calculations
ST_DISTANCE_SPHERE documentation (takes in account a fixed sphere for calculations - aka not planar)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance_Sphere.html
ST_DISTANCE_SPHEROID documentation (takes into account a choosen spheroid for your calculations)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance_Spheroid.html
ST_POINT documentation
http://postgis.refractions.net/documentation/manual-1.4/ST_Point.html