I have a point (x, y) with srid 900913. I transform it to srid 2180 and then again to srid 900913. Imo I should have the same point, but it differs. Why?
SELECT ST_X (ST_Transform(ST_Transform(ST_GeomFromText('POINT(21.01233628836129 52.23044648850736)', 900913), 2180), 900913)),
ST_Y(ST_Transform(ST_Transform(ST_GeomFromText('POINT(21.01233628836129 52.23044648850736)', 900913), 2180), 900913));
The quick answer why the two transformations were different is because of a common confusion of projection systems.
The coordinate POINT(21.01233628836129 52.23044648850736) on a Spherical Mercator projection is at 0°0'1.689"N 0°0'0.680"E, which is way outside Poland, which makes it difficult or typically impossible to reproject it to anything else.
The coordinates you were looking at are most likely longitude/latitude on WGS 84 (EPSG:4326).
I think this is the exercise you were attempting (LatLon_check in particular):
SELECT ST_AsLatLonText(geom) AS LatLonText,
ST_AsLatLonText(ST_Transform(ST_Transform(geom, 2180), 4326)) as LatLon_check,
ST_AsText(ST_Transform(geom, 2180)) AS Poland_CS92,
ST_AsText(ST_Transform(geom, 900913)) AS Spherical_Mercator
FROM ST_GeomFromText('POINT(21.01233628836129 52.23044648850736)', 4326) AS geom;
-[ RECORD 1 ]------+----------------------------------------
latlontext | 52°13'49.607"N 21°0'44.411"E
latlon_check | 52°13'49.607"N 21°0'44.411"E
poland_cs92 | POINT(637389.203455155 486840.46005323)
spherical_mercator | POINT(2339082.5759974 6841900.8700405)
Related
I have a point at (-130.2, 30.5) and a box at (-130, 30, -129, 31). As geometry, the && operator reports no bounding box intersection, while as geography, it does:
WITH src(point, envelope) AS (SELECT
ST_SetSRID(ST_MakePoint(-130.2, 30.5), 4326) AS point,
ST_MakeEnvelope(-130.0, 30.0, -129.0, 31.0, 4326) AS envelope)
SELECT
point::GEOMETRY && envelope::GEOMETRY AS geom_bbox_intersects,
point::GEOGRAPHY && envelope::GEOGRAPHY AS geog_bbox_intersects,
ST_Intersects(point::GEOGRAPHY, envelope::GEOGRAPHY) AS geog_poly_intersects
FROM src;
geom_bbox_intersects | geog_bbox_intersects | geog_poly_intersects
----------------------+----------------------+----------------------
f | t | f
Here's what the scenario looks like in 2D (using QGIS in SRID 4326):
I assume for geography, PostGIS is using a rectangular bounding box on the spheroid rather than my longitude-parallel envelope. Is that the case? How might I visualize what's going on in PostGIS using a 2D tool like QGIS?
Versions
PostgreSQL: 10.17
PostGIS: 2.4
Geography use great circle arcs instead of straight lines. To visualize them, you can segmentize a geography into small segments, then convert these segments to geometry
WITH src(geom) AS (SELECT ST_MakeEnvelope(-130.0, 30.0, -129.0, 31.0, 4326) AS geom)
SELECT
st_segmentize(geom::geography,1000)::geometry
FROM src;
That being said, a great circle along a meridian is the meridian itself, so I really fail to see why the geography bounding box are said to overlap. If it fits your workflow, using st_intersects() will return false with the two sample shapes as geography.
Given a list of coordinates, how can I find the closest pair of coordinates using only ONE SQL statement? I have been stuck on this question for a while now and haven't managed to come up with any ideas yet. Since I'm only allowed to use one sql statement I assume variables are not allowed too.
for visualization:
id lat long
1 -12 35
2 -1 100
3 -9 3
You can use a self join:
select t1.*, t2.*
from t t1 join
t t2
on t1.id < t2.id
order by power(t1.lat - t2.lat, 2) + power(t1.long - t2.long, 2)
limit 1
Longitude and latitude are measures associated with the surface of a sphere (our Earth) and the shortest distances are great circles, not straight lines. This is one reason airplanes flying from New York to Rome fly over Newfoundland. Your Euclidean measure would only be shortest if the world looked like this:
This is an equi-rectangular projection of the spherical earth onto a flat map. Note the distortion at the poles. The calculation of great circles is WAY more complex and I doubt you could calculate it in a SQL statement. I suspect, although I have not tried to find any cases, that there are points that calculate as further away but are actually closer as you travel on the earth's surface.
In my MySQL database I have three fields, x,y,z representing a position.
I would like to transform these coordinates into polar coordinates az,el,r, and based on these, select the rows where (e.g.) az are within some region.
How would I go about doing this in MySQL?
EDIT:
This in not a question of how to actually do the coordinate transformation, but rather, if MySQL is capable of transforming the data based on some method, and then selecting data once it is transformed with a criterion based on a comparison of the transformed data.
Solve the Triangle ...
Cartesian = How far along and how far up
Polar = How far away and what angle
In order to convert you need to solve the right triangle for the two known sides
you need to use Pythagoras theorem to find the long side (hypotenuse)
you need the Tangent Function to find the angle
r = √ ( x2 + y2 ) = Pythagoras
θ = tan-1 ( y / x ) = Tangent Function
assuming there's no negative values - then you would have to take the inverse of tan function, or convert them to their positive counterpart
Mysql Pythagorus
SQRT((POWER(242-'EAST',2)) + (POWER(463-'NORT',2))) < 50
assuming your coordinates look like this.... here is an example
http://www.tek-tips.com/viewthread.cfm?qid=1397712
Tangent Function here
http://dev.mysql.com/doc/refman/5.0/en/mathematical-functions.html#function_tan
IMHO this is really a spherical coordinate system maths problem, not a MySQL-specific question.
MySQL just happens to be the data container in this instance.
For any solution you need to work out the maths first, then it becomes a matter of applying the equations to the data.
I can help with MySQL, but I'd have to Google solving these equations and my fingers are tired =)
I'm trying to query any locations within a specified distance from another location. The query is not the problem, but the distance returned by geography.STDistance is.
It seems STDistance makes fairly accurate calculations on locations close to the equator, but I need this to work with locations in the nordic countries. Norway, Sweden, Finland and so on...
According to my calculations, made on locations in northern Sweden, the distance is wrong by a factor of around 2.38?!
Expected result is 1070 meters and returned distance is 2537,28850694302 meters
My query looks like this:
DECLARE #g geography = geography::STGeomFromText('POINT(65.580254 22.179428)', 4326)
SELECT name, [pos].STSrid as srdi, [pos].STDistance(#g) as d
FROM [GPSCHAT].[dbo].[USERS]
and the "other location" has coordinates (65,578541 22,202286) (stored with SRID 4326)
I'm guessing this has to do with the distance from the equator (close to the polar circle), but there has to be a way to calculate this more accurately based on the Latitude or am i wrong?
It looks like you're creating your point using 'X, Y'.
When creating a point from text, use 'Y, X' instead.
Check out this MSDN Article for some more info.
Why don't you make use of another spatial reference identifier which fits better the earth curvature around your position. SRID 4326 might not been measured as accurate as other local referential systems
this is an oldie, but i cannot seem to find a solution.
When i want to do an st_transform on a 900913 coordinate to a 4326 system, the y coordinate shifts.
example:
SELECT
AsText(
Transform(
Transform(
GeomFromText( 'POINT( 449760.25168159 6790560.4594059 )', 900913),
4326
),
900913
)
)
here the original 900913 stating point is st_stransformed to 4326 and back to 900913. the result is not the original point, y differs. (i will insert the result later, i don't have it here).
i tried altering the proj4text for 4326, adding +nadgrids=#null like i read somewhere
the proj4text for srid 4326 is currently:
"select proj4text from spatial_ref_sys where srid=4326"
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
the proj4text for srid 900913 is currently:
"select proj4text from spatial_ref_sys where srid=900913"
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=#null +no_defs
i also tried doing a projection from 900913 to another projection to 4326, but i get the exact same point as a direct transformation from 900913 to 4326.
anyone any ideas?
EJ
EPSG:900913 is ill-defined projection. You should use EPSG:3857 instead, which should be exactly the same Spherical Mercator but a standardized one.
Any reprojection is a lossy operation. Converting a coordinate back and forth is going to make noise in last binary digits, which are usually sub-millimeter error.
What version of PostGIS are you using? I've tried the query with this configuration: POSTGIS="1.5.2" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" and it works fine.
Despite that, I've red some problems involving 900913 coordinates.