Im trying to build a function to create an Ellipse without passing by classic programming language.
I have these parameters stored in a custom GeoJSON.
smallSide and bigSide has to be expressed in meters. Resulting geometry has to be created with EPSG 4326:
My parameters are:
"geography" : {"type":"Ellipse",
"smallSide":100,
"bigSide" : 110,
"rotation" : 0,
"coordinates":[8.54736328125,46.37156925087649]}
Searching on web I found this solution that is very close to resolve my problem:
ST_AsEWKT(ST_Translate( ST_Rotate( ST_Scale( ST_Buffer(ST_Point(8.54736328125,46.37156925087649)::geography, 3000)::geometry, 0.3,0.5)::geometry, 0), 8.54736328125,46.37156925087649))
This function creates an Ellipse near Norway. Try with: http://geojson.io/#map=11/69.5354/11.1216
The original center is in Switzerland.
This function has 2 big problem:
1. The Ellipse is not centered in the coords;
2. I don't know how to convert xFactor/yFactor of Scale to match meters parameters;
PS. This is the WKT of above function:
SRID=4326;POLYGON((11.123273576134 69.5574277440815,11.1230606869505 69.5547928070317,11.1224064250309 69.55225640052,11.1213360407351 69.5499159578464,11.1198907409861 69.547861360983,11.1181260946945 69.5461714955871,11.1161098932273 69.5449112303195,11.1139195487472 69.544128934906,11.1116391298573 69.5438546306632,11.1093561468668 69.5440988431489,11.1071582077927 69.5448522000687,11.1051296707337 69.5460857895281,11.1033484183676 69.5477522651534,11.1018828760511 69.5497876565102,11.100789386429 69.5521138166206,11.1001100408036 69.554641414163,11.099871051113 69.5572733570283,11.1000817266595 69.5599085170987,11.1007340973332 69.5624456140896,11.1018032006992 69.5647871095818,11.1032480248444 69.5668429613212,11.105013073265 69.5685340926073,11.107030493374 69.5697954420587,11.1092226874817 69.5705784748924,11.1115053053956 69.5708530575261,11.1137905020249 69.5706086220194,11.1159903323456 69.5698545746198,11.1180201503338 69.568619932341,11.1198018783021 69.5669522018393,11.1212670184877 69.5649155445927,11.1223592894673 69.5625883002992,11.1230367854657 69.5600599653373,11.123273576134 69.5574277440815))
Welcome to Stack Overflow! I'm not sure I quite understood the parameters bigSide and smallSide, but if you're only trying to create a buffer around a point using meters as parameter, you can use something like this:
SELECT
ST_AsText(
ST_Rotate(
ST_Buffer(
ST_GeomFromText('SRID=4326;POINT(8.54736328125 46.37156925087649)')::GEOGRAPHY,3000, 'quad_segs=16')::GEOMETRY,0));
Which will draw a buffer around the given point (south of Switzerland):
Note: Calculations using GEOMETRY and GEOGRAPHY are made differently, and so are their results. GEOGRAPHY calculates the coordinates over an spherical surface (which can be much slower than GEOMETRY) and uses meters as unit of measurement, while GEOGRAPHY uses a planar projection and uses the SRS unit. (Text from this answer)
The first problem is that you use the original coordinates of the center to translate the geometry. (I mean deltax and deltay in st_translate())
As far as i understand delta should be the difference beetween coordinates you need and actually have.
So the solution is to calculate preliminary (shifted) polygon:
prePoly := ST_Rotate( ST_Scale( ST_Buffer(ST_Point(8.54736328125,46.37156925087649)::geography,
3000)::geometry, 0.3,0.5)::geometry, 0);
and then translate it calculating deltas:
st_translate(prePoly, 8.54736328125 - st_x(ST_Centroid(prePoly)),46.37156925087649 - st_y(ST_Centroid(prePoly)))
I'm not sure that i got the second problem right, but if you originally have big and small sides in meters, you can take one (for example, big one) as a radius of buffer and than calculate
xFactor = smallSide/bigSide, and yFactor = 1
In this case your ellipse will be ellongated along the Y axis.
Related
I try to figure out how to come from a single given coordinate (lat/lon) to the nearest bounds which enclose this coordinate on a map e.g. streets or sea.
Here two examples to give you a better understanding of what I mean:
What i tried already or thought about:
Setting up a Nominatim server and search for the given coordinate via the reverse-function to get the bbox and/or the geojson polygon of this coordinate. -> this only works when the given coordinate is within a POI or for example directly on a street.
Writing an algorithm to walk in all 4 or 8 directions (n/e/s/w) and 'stop' when the map layer/surface changes (change = stop for this direction and mark a bounding-point)
Building up an image-recognition system using TensorFlow to detect the different colors and 'draw' the polygon. Worked with TensorFlow a couple of times but this seems to be the most tricky solution to implement (but at my current understanding the most precise one)
Does someone of you have any other ideas to get a solution for this problem? Would appreciate any kind of approaches
Cheers!
If I got your question right, you might wanna first select all polygons in which the given point is inside of using ST_Contains, and then compute the distance to this point using ST_Distance. If you ORDER BY distance and LIMIT to 1 result you'll get the nearest polygon, e.g.
Data Sample
CREATE TABLE t (gid int, geom geometry);
INSERT INTO t VALUES
(1,'POLYGON((-4.47 54.26,-4.44 54.28,-4.41 54.24,-4.46 54.23,-4.47 54.26))'),
(2,'POLYGON((-4.48 54.25,-4.40 54.25,-4.41 54.23,-4.48 54.23,-4.48 54.25))'),
(3,'POLYGON((-4.53 54.23,-4.44 54.29,-4.38 54.22,-4.53 54.23))');
Query
SELECT gid,ST_AsText(geom) FROM t
WHERE ST_Contains(geom,ST_MakePoint(-4.45, 54.25))
ORDER BY ST_Distance(geom,ST_MakePoint(-4.45, 54.25))
LIMIT 1;
gid | st_astext
-----+------------------------------------------------------------------------
1 | POLYGON((-4.47 54.26,-4.44 54.28,-4.41 54.24,-4.46 54.23,-4.47 54.26))
(1 Zeile)
Google Maps has the function isLocationOnEdge(point, polyline, tolerance) that takes a tolerance value in degrees and uses it to determine whether a point falls near a polyline.
Is there anything similar in Leaflet(or some plug-in) that does the same thing?
A handful library for such operation is Turf.
For your case, a simple approach would be to:
Create a polygon out of your polyline using turf.buffer with appropriate "tolerance" (Turf takes a distance at Earth surface, or degrees).
Check whether your point is within that polygon or not using turf.inside.
Unfortunately, turf.buffer is only an approximation, it does not takes geodesy into account… therefore for big tolerance you will have a deformed shape.
An exact method could be to:
Use instead turf.pointOnLine to find the nearest point of the polyline.
turf.distance to measure the distance between those 2 points, and compare with your tolerance (or even just Leaflet latLng.distanceTo, but you would have to convert GeoJSON points back to Leaflet LatLngs).
I have a table in a SQL Server 2012 database with 3.000.000 records. Those records represent a point on a map. Al those records have x, y coordinates and geography point as fields (x, y, geo).
I need to calculate all points within a distance of 10.000 meter from a certain point.
Query no. 1 I use :
DECLARE #point geography
DECLARE #rad float
SET #point = geography::STGeomFromText('POINT(51.2207099068778 4.39961050577564)', 4326);
SET #rad = 10000
SELECT count(1)
FROM t_mailbox WITH (INDEX(SIndx_t_mailbox_geo_MHHM_512))
WHERE
#point.STDistance(geo) <= #rad
Result : It takes 4 seconds to find 273.346 points. Drawing those points on a map results in an oval shape on the map.
For sure this is wrong because not all points are included in the result.
Query no. 2 I use :
declare #radius int = 10000
DECLARE #x float = 51.2207099068778
DECLARE #y float = 4.39961050577564
SELECT count(1)
FROM t_mailbox
WHERE
ACOS(COS(RADIANS(90-#x))*COS(RADIANS(90-x)) +SIN(RADIANS(90-#x)) *SIN(RADIANS(90-x))*COS(RADIANS(#y-y)))*6371000 <= #radius
Result : It takes 2 seconds to find 564.547 points. Drawing those points on a map results in a perfect shaped circle.
Questions :
Why is using SPATIAL INDEX and STDistance slower then the more complicated query with SIN, COS and ACOS?
Why is results in a wrong oval shaped set of points?
What am I doing wrong?
Geography data is drawn on the surface of a sphere. This means it looks different than geometry (flat) data.
Imagine taking a globe, and drawing a point on it. Then take a compass and draw a circle around that point. Now peel the skin off the globe. Notice it does not lie flat, to make it flat you have to stretch it. Now the way most people do that, is the stretch the top and bottom (north/south poles) and stretch it until it is the same length as the equator. This makes the circle you drew an oval which is bigger horizontally than vertically.
Now the formula you used is for points within a radius on flat plane. This means that you assume the distance between two lines of longitude is the same no matter what latitude you are (5 feet away from the north pole, the distance between 90 degrees and 91 degrees longitude is much smaller than at the equator).
On a mercator projection map, this formula will make a map that is a perfect circle, however on a globe, it is not. Hopefully this makes sense.
As for you speed issue: A: Apples to oranges, you are doing different calculations. and B: Without knowing how you have your index set up, it is very difficult to analyze, but geography indexing is pretty bad regardless, it works much better on very large geographies like countries.
Whilst hcaelxxam answers the "why" perfectly, you may find better performance by moving away from STDistance(). Whilst not always the case, I have generally found it better to use STIntersects() or STWithin() for distances - how you do this is pretty easy!
Try changing your query to the following. I'd be interested in the results:
DECLARE #point geography;
DECLARE #rad float = 10000;
SET #point = geography::STGeomFromText('POINT(51.2207099068778 4.39961050577564)', 4326).STBuffer(#rad); -- We're creating the "oval" here
SELECT count(1)
FROM t_mailbox WITH (INDEX(SIndx_t_mailbox_geo_MHHM_512))
WHERE
#point.STIntersects(geo) = 1
You may also like to try with and without the index hint. Sometimes, forcing it can generate an inefficient query plan.
I have a question about the use of postgreSQL/postGIS.
I would like to display markers on a map (stored in a database) which are some distance away from the user (coordinates given to the request).
The type of the field of the markers is POINT (I store lat/long).
The user position is detetermined by the Google Map API.
Here is the actual request :
SELECT * FROM geo_points WHERE ST_distance(ST_SetSRID(geo_points.coords::geometry,4326),ST_GeomFromEWKT('SRID=4326;POINT(45.0653944 4.859764599999996)')) > 65
I know (after some research on internet) that the function ST_distance gives me the distance in degree between markers and the user position and that I test the distance in km.
I think I have to use the function ST_tranform to transform the points in metric coordinates.
So my questions are :
- what is the SRID for France
- how can I make this dynamically for the entire world according to the user position ?
I also kow that the function ST_within exists and that could do this. But I anticipate the fact that later, I could need the distance.
Any help would be greatly appreciated
ps: there are maybe solutions in other post, but all the answers I have found during my researches were not really meeting my needs.
Firstly, pay attention to the axis order of coordinates used by PostGIS, it should be long/lat. Currently you are searching in Somalia. Swapping to the coordinates, you would be searching in France.
You can use a geodesic calculation with the geography type, or use geodesic functions like ST_Distance_Spheroid. With the geography type, you may want to use ST_DWithin for higher performance.
Here are geo_points 65 m away or less from the point of interest in France (not Somalia):
SELECT * FROM geo_points
WHERE ST_Distance_Spheroid(
ST_Transform(geo_points.coords::geometry, 4326),
ST_SetSRID(ST_MakePoint(4.859764599999996, 45.0653944), 4326),
'SPHEROID["WGS 84",6378137,298.257223563]') < 65.0;
However, it will be very slow, since it needs to find the distance to every geo_points, so only do this if you don't care about performance and have less than a few thousand points.
If you change and transform geo_points.coords to store lon/lat (WGS84) as a geography type:
SELECT * FROM geo_points
WHERE ST_DWithin(
geo_points::geography,
ST_SetSRID(ST_MakePoint(4.859764599999996, 45.0653944), 4326)::geography,
65.0);
I'm currently working on a mapping app for iPhone. I've created some custom maps of various sizes, but I've run into an issue:
I would like to implement the ability for users' locations to be checked automatically, but since Im not using a MapView this is much more dificult. (see below)
given the different coordinate systems, I would like to receive a geolocation (green dot) and translate it into a pixel location on a custom map.
Ive got the geolocations for the 4 corners, but the rect is askew. Ive calculated the angle of rotation, but Im just generally confused.
note: the size of the maps arent big enough for the spherical nature of the earth to come into calculation.
Any help is appreciated!
To convert a geolocation to point you need to first understand the mapping. assuming you are using Mercator.
x = R*long
y = R*(1+sin(lat))/cos(lat)
where lat and long are in radians.R is radius of earth. the scale of the image would be from 0 to R*PI
so to get it within view.frame.size you may have to divide by a scale factor.
for difference between points.
x2-x1 = R* (long2-long1)
y2-y1 = R* ( (1+sin(lat2))/cos(lat2) - (1+sin(lat1))/cos(lat1) )