ST_Buffer distance units - postgis

Hello I used the ST_Buffer to set a 5 kilometre buffer with this code:
CREATE TABLE Buf_5km_Schiff as
SELECT ST_Buffer(geom, 0.05)
FROM public."Input_Schifffahrtswege";
It works but im not sure why I need to set 0.05 for 5 kilometres. I tried 5 and 5000 at first but it did not work.
Btw. I used the EPSG 4258 Coordinate System.
Thx in advance!

EPSG:4258 is in degrees. You will have to transform to some metric projection to use the buffer setting you are expecting. You could try EPSG:3857 by wrapping your geometry column into ST_Transform(geom, 3857) and then calling ST_Buffer but note that 3857 will give you a approximation but there will be more suitable projections to improve the result.

Related

CDO regridding and calculating grid fractions

I have a global IGBP land use dataset in which the land cover exists out of forest cover (depicted with a '1') and non-forest cover (depicted with a '0'), hence, each land grid cell has either the value 1 or 0.
This dataset has a spatial resolution of approximately 1 km at the equator, however, I am going to regrid the dataset to a spatial resolution of approx 100 km at the equator. For this new grid resolution I want to calculate the fraction of forest cover (so the fraction of 1's) for each grid cell, but I am not sure how this can be done without GIS. Is there a way to do this with cdo remapping or perhaps with python?
Thank you in advance!
if you want to translate to a new grid that is an integer multiple of the original then you can do
cdo gridboxmean,n,m in.nc out.nc
where n and m are the numbers of points to average over in the lon and lat directions.
Otherwise you can interpolate using the conversative remapping which means that you don't need to worry if the new grid is not a multiple of the old
cdo remapcon,new_grid_specification in.nc out.nc
Note that in the latter case, however, the result is only first order accurate. There is also a slightly slower second order conservative remapping available using the command remapcon2. The paper describing the two implemented conservative remapping methods is Jones (1999). For further info on remapping you can also see my video guide.
Thanks to Robert for reminding also that you may need to convert to float, which would mean using the option
cdo -b f32

Postgis - How to find whether two circles based on two points overlap?

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

Spatial query - poor performance, not using index

I'm trying to find locations within some distance from given coordinates. On a table with about 32k records query takes about 2 seconds - which is way too slow, imo.
It is doing a clustered index scan, which is logical - it has to calculate distance for every location.. However, I still think this should be faster over a data set this small. I do have spatial index defined, however it's not used, and query fails if I'm forcing it.
Most of the time (~86%) is spent on Filter that calculates the distance - so I'm looking for a ways to optimize that, and I need some help here..
The query I'm using is this:
SELECT Name
FROM Venue
WHERE (Coordinates.STDistance(geography::STPointFromText('POINT(-113.512245 51.498212)', 4326)) / 1000) <= 100
One old approach is to use a BOX firxt.
From your point, make two points on opposite ends of the box. +R/+R and -R/-R from the center.
Then you can filter - a point has to be in this box AND in the circle you describe.
The box check can run on the index and kills most elements.
Simple school geometry. You draw a rectangular box around the circle you describe.
Your current approach can not use the index because the index does not contain the fields.
ALTERNATIVELY: DRAW A CIRCLE - do not use a distance calculation. Draw a circle. With points.
Or read https://stackoverflow.com/questions/11311363/my-application-is-about-asp-net-using-linq-and-remote-mssql-my-connection-is-be which is the same issue you ask.

Spatial search with ravenDB

I have a rather specific spatial search I need to do. Basically, have an object (lets call it obj1) with two locations, lets call them point A and point B.
I then have a collection of objects(lets call each one obj2) each with their own A and B locations.
I want to return the top 10 objects from the collection sorted by:
(distance from obj1 A to obj2A) + (the distance from obj1B to obj2B)
Any ideas?
Thanks,
Nick
Update:
Here's a little more detail on the documents and how I want to compare them.
The domain model:
Listing:
ListingId int
Title string
Price double
Origin Location
Destination Location
Location:
Post / Zipcode string
Latitude decimal
Longitude decimal
What i want to do is take a listing object (not in the database) and compare it with the collection of listings in the database. I want the query to return the top 12 (or x) number of listings sorted by the crow flies distance from the origins plus the crow flies distance from destinations.
I don't care about the distance from origin to destination - only about the distance of origin to origin plus destination to destination.
Basically Im trying to find listings where the starting and ending locations are close.
Please let me know if I can clarify more.
Thanks!
Here is how one would solve such a problem in
mysql 4.1 &
mysql 5.
The link from mysql 4.1 seems quite helpful, esp. the first example, it's pretty much what you are asking about.
But if this is not quite helpful, I guess you'd have to loop and do queries either on obj1 or obj2 against its counterpart table.
From algorithmic perspective, I'd find the center of the bounding box, then picked candidates with increasing radius while I find enough.
Also I just want to remind that crow fly distance over the globe is not Pythagoras distance and different formula must be used:
public static double GetDistance(double lat1, double lng1, double lat2, double lng2)
{
double deltaLat = DegreesToRadians(lat2 - lat1);
double deltaLong = DegreesToRadians(lng2 - lng1);
double a = Math.Pow(Math.Sin(deltaLat / 2), 2) +
Math.Cos(DegreesToRadians(lat1))
* Math.Cos(DegreesToRadians(lat2))
* Math.Pow(Math.Sin(deltaLong / 2), 2);
return earthMeanRadiusMiles * (2 * Math.Atan2(Math.Sqrt(a), Math.Sqrt(1 - a)));
}
Sounds like you're building a rideshare website. :)
The bottom line is that in order to sort your query result by surface distance, you'll need spatial indexing built into the database engine. I think your options here are MySQL with OpenGIS extensions (already mentioned) or PostgreSQL with PostGIS. It looks like it's possible in ravenDB too: http://ravendb.net/documentation/indexes/sptial
But if that's not an option, there's a few other ways. Let's simplify the problem and say you just want to sort your database records by their distance to location A, since you're just doing that twice and summing the result.
The simplest solution is to pull every record from the database and calculate the distance to location A one by one, then sort, in code. Trouble is, you end up doing a lot of redundant computations and pulling down the entire table for every query.
Let's once again simplify and pretend we only care about the Chebyshev (maximum) distance. This will work for narrowing our scope within the db before we get more accurate. We can do a "binary search" for nearby records. We must decide an approximate number of closest records to return; let's say 10. Then we query inside of a square area, let's say 1 degree latitude by 1 degree longitude (that's about 60x60 miles) around the location of interest. Let's say our location of interest is lat,lng=43.5,86.5. Then our db query is SELECT COUNT(*) FROM locations WHERE (lat > 43 AND lat < 44) AND (lng > 86 AND lng < 87). If you have indexes on the lat/lng fields, that should be a fast query.
Our goal is to get just above 10 total results inside the box. Here's where the "binary search" comes in. If we only got 5 results, we double the box area and search again. If we got 100 results, we cut the area in half and search again. If we get 3 results immediately after that, we increase the box area by 50% (instead of 100%) and try again, proceeding until we get close enough to our 10 result target.
Finally we take this manageable set of records and calculate their euclidean distance from the location of interest, and sort, in code.
Good luck!
I do not think that you find a solution directly out of the box.
It'll be much more efficient if you use a bounding sphere instead of a bounding box to specify your object.
http://en.wikipedia.org/wiki/Bounding_sphere
C = ( A + B)/2 and R = distance(A,B) /2
You do not precise how much data you want to compare. And if you want to see the closests or the farthest objects pair.
For both case, I think that you have to encode C coordinate as a path in an octtree if you are using 3D or quadtree if you are using 2D.
http://en.wikipedia.org/wiki/Quadtree
This is a first draft I can add more information if this not enough.
If you are not familiar with 3D start with 2D it easier to start with.
I show your latest add, it seems that your problem is very similar to clash detection algorithm.
I think that if you change the coordinate system of the "end-point" by polar coordinate relative to the "start-point". If you round the radial coordinate to your tolerance (x miles), and order them by this value.

Geometry column: STGeomFromText and SRID (what is an SRID?)

I'm playing with the new geography column in SQL Server 2008 and the STGeomFromText function. Here is my code (works with AdventureWorks2008)
DECLARE #region geography;
set #region = geography::STGeomFromText('POLYGON((
-80.0 50.0, -90.0 50.0,
-90.0 25.0, -80.0 25.0,
-80.0 50.0))', 4326);
SELECT #region;
My question is about the 4326 in the code. It is supposed to be a spacial Reference ID. When I go to MSDN there isn't a lot on it. If I change the value to 56 I get an error telling me the value must be in the sys.spatial_reference_systems table.
You can look at that table by executing:
select * from sys.spatial_reference_systems
There is a well_known_text column in that table, but it doesn't tell me much. The value for 4326 is:
GEOGCS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199433]]
Can anyone explain this mystery to me? What is the SRID?
So I ended up talking with an ex-military guy yesterday who was a radar/mapping specialist.
Basically, he knew exactly what that number (4326) was, where it came from, and why it is there.
It is an industry standard for computing geography. The problem is that the earth is not a perfect sphere (it bulges in the middle), and SRID 4326 accounts for that.
As I stated, the table sys.spatial_reference_systems lists all of the code and what they are. But the short version is that you are really only going to use 4326 unless you have a very specific reason to use something different.
SRID = Spatial Reference IDentifier
coordinates must use the same SRID to be comparable. otherwise you'd end up comparing kilometeres and miles. or something similar.
There are a lot of systems to map the earth. For example you want to map some state in USA. You can set the most south-east point as 0,0 and map all other spatial coordinates according to this point. On the other hand you may want to map some spatial data that span all over the map. In any case you must choose some point as 0,0. In addition you must select some sort of measurement unit: miles/kilometers/degrees/some other magical unit that suits you better. Over the years a lot of such systems where developed. Each has its own zero point, its own coordinates, its own rules about if the earth is flat or not. SRID or SRS is the id of such system. Using this id you can map point expressed in one system to another system, although sometimes it involves some pretty complex math.
And about 4326 SRID. It also called "WGS 84"
(http://en.wikipedia.org/wiki/World_Geodetic_System) system. It's the most common system to represent point on spherical(not flat) earth. It uses degree,minute,second notation and its x and y coordinates are usually called latitude and longitude.
Most used non-spherical earth projection is called UTM. You can read about it here: http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system
Anyway, as long you are not doing any spatial conversions from one system to other, you don't really care about the system that you data uses.
I have found this website: http://spatialreference.org/ref/epsg/4326/ quite helpful in understanding the SRID you intend to use. It provides a handy map, some bounding box information and other links.
For other SRIDs simply change the digits at the end of the URL to what you are after.
The distance returned depends on the "Spatial Reference Identifier (SRID)" you define for your geography types.
In the example below, the default SRID of 4336 is used, see the second argument of STGeomFromText. This means the distance returned is in meters, you find this via querying the catalog view spatial_reference_systems i.e. select srs.unit_of_measure from sys.spatial_reference_systems as srs where srs.spatial_reference_id = 4326
As an alternative to STGeomFromText, you can use parse which assumes a SRID of 4326 and you don't have to specify one explicitly.
When calculating the distance between two points, you must use the same SRID for both geography types else you get an error. Example:
DECLARE #address1 GEOGRAPHY
DECLARE #address2 GEOGRAPHY
DECLARE #distance float
SET #address1 = GEOGRAPHY::STGeomFromText ('point(53.046908 -2.991673)',4326)
SET #address2 = GEOGRAPHY::STGeomFromText ('point(51.500152 -0.126236)',4326)
SET #distance = #address1.STDistance(#address2)
SELECT #distance --this is the distance in meters

Resources