I was using gdal2tiles.py with spatial reference WSG84 and it was working fine. However, when I changed to spatial reference EPSG:3440. I got the the following error:
First, I run the command:
gdal_translate -of VRT -a_srs EPSG:3440 -gcp 0 0 58.068451479718924 23.65512391903488 -gcp 21816 0 58.126966134442846 23.65512391903488 -gcp 21816 14871 58.126966134442846 23.6185834507829 myinputimage.png myoutput.vrt
Than, I run the command:
python gdal2tiles.py myoutput.vrt
I got the following error:
Is there is way to fix this error or use similar spatial reference which doesn't have this error. Notice, this error happen only when using spatial reference other than WSG84.
EDIT: I guess the issue could be that spatial reference EPSG:3440 is not inculded, but the question remain, is there away to add it to gdal reference database.
The EPSG:3440 is a projected system. The correct definition for accuracy 0.5 meter would be probably:
+proj=utm +zone=40 +ellps=clrk80 +towgs84=-180.624,-225.516,173.919,-0.81,-1.898,8.336,16.71006 +units=m +no_defs
If I have a look at http://epsg.io/3440-1439 it tells:
Projected bounds:
-35283.71 1840661.51
789562.66 2942956.58
In your command above you assign ground control points which looks like geodetic (latitude longitude numbers) such as 58.068451479718924. This is very probably wrong - as the numbers you assign are not in the projected bounds range.
You must very use in the -gcp parameter of the gdal_translate numbers which are bigger - already projected and in the above range.
It is possible to transform your lat/lon from WGS84 via the online interface at:
http://epsg.io/3440-1439/map and assign in the -gcp argument the transformed numbers.
You have marked your query with tag maptiler which refers to http://www.maptiler.com/. This tool would be able to assign the coordinates visually as well without a need to create VRTs - so you can click on your image and copy&paste the above coordinates in a projected system.
MapTiler generates a viewer which display the EPSG:3440 tiles in OpenLayers or transform these to a spherical mercator tiles for overlays with Google or OSM or use in mobile apps.
BTW glad to hear you use the systems gdal2tiles, maptiler and http://epsg.io/ which we have developed...
Related
Consider the following query:
SELECT ST_Simplify(SHAPE, 1.0)
FROM nhdflowline
WHERE OGR_FID = 12701;
Running that gives me the following error:
Error Code: 3618. st_simplify(LINESTRING, ...) has not been implemented for geographic spatial reference systems.
However, if I do this, it works just fine:
SELECT ST_Simplify(ST_GeomFromText(ST_AsText(SHAPE)), 1.0)
FROM nhdflowline
WHERE OGR_FID = 12701;
This doesn't make any sense to me. I can't run ST_Simplify directly on a geometry - I have to convert it to text and then back to a geometry to run ST_Simplify?
Am I missing something? I'm running MySQL 8.0.22.
The key is in the last part of the error message: "has not been implemented for geographic spatial reference systems".
There are two kinds of reference systems (SRID): geographic, with computations on sphere, and projected, with computations on plane map.
When you do ST_AsText, and then back to geometry, you remove SRID, so the geometry which used to be associated with geographic (i.e. spherical) geometry, now has planar semantics and SRID=0. It's semantics changed for MySQL. What used to be lat:lng on sphere now are just two coordinates on plane.
Your version of MySQL implements simplify for planar (projected) geometry, but not for geographic SRID. You can use simplify on plane, but units of distance are different (usually degrees vs meters), as well as semantics (one degree along meridian is bigger in meters than one degree along parallel if you are far from equator).
MYSQL ver 5.7
Requirement:
I have a bunch of POINT geometries in MYSQL table and I have to find all the POINT geometries that are within 5km distance/radius of a GEOMETRYCOLLECTION object.
GEOMETRYCOLLECTION may contain more than one type of geometries like POINT, POLYGON etc.
Sample GEOMETRYCOLLECTION data:
SET #g1 = ST_GeomFromText('GEOMETRYCOLLECTION(POINT (-156.366489591715 66.913750389327),POLYGON ((-156.357608905242 66.906958164897, -156.360302383363 66.9066027336476, -156.361997104194 66.9067073607308, -156.363616093774 66.9066368440642, -156.365477697938 66.9065867326059, -156.368127298976 66.9065970034393, -156.370061891681 66.9066888794808, -156.37182258022 66.9068547305222, -156.373286981259 66.9070724523969, -156.374390675008 66.9072952721882, -156.376359777088 66.9077681138541, -156.377706173961 66.9080113180204, -156.379222192708 66.9081328753119, -156.380729601039 66.9081591586452, -156.382562289578 66.9081211961453, -156.387571662487 66.9099676951007, -156.389320598943 66.9125180930134, -156.389291120818 66.9145787836353, -156.384722634367 66.9167899596735, -156.37955035 66.9195246586276, -156.372520662511 66.9209119638337, -156.360432280238 66.9215118034161, -156.355776993787 66.9203754471679, -156.34906598338 66.9180659711298, -156.347941981299 66.9174007836309, -156.346853913592 66.9167568252985, -156.34605399901 66.9158971169665, -156.346982815675 66.9151925950926, -156.346794497967 66.9144321773854, -156.345642955261 66.9140107294695, -156.343831364638 66.9136152003034, -156.342996512556 66.9130307378043, -156.343113243806 66.9123137492637, -156.343498096931 66.9119029992644, -156.344661664637 66.9111819440571, -156.345080786511 66.9105884961414, -156.345524286511 66.9099605023924, -156.347168040675 66.9098486503092, -156.348952756297 66.9096090419763, -156.348689200048 66.9089614565606, -156.349495732338 66.908706844061, -156.350786711503 66.9082992794783, -156.352211271917 66.9083472388533, -156.353952768789 66.90829894302, -156.355389368787 66.9082072242701, -156.356512531285 66.9079768284371, -156.356677961493 66.9078075857291, -156.356422527119 66.907644261771, -156.355901372953 66.9072802273965, -156.357608905242 66.906958164897)))');
Sample POINT data:
SET #p1 = ST_GeomFromText('GEOMETRYCOLLECTION(POINT (-156.342840017 66.9320439348))');
I have tried ST_DISTANCE_SPHERE(#g1,#p1) spatial function (which returns the value in meters) but it seems it doesn't support geometry types other than POINT and MULTIPOINT.
Then I have used:
ST_DISTANCE(#g1,#p1)
'0.015301834064271899'
I am unable to understand the what is the UNIT of this returned value in MYSQL 5.7?
I have searched a lot on the internet and there is no proper documentation available regarding the same. In POSTGIS, this can be done but I am struggling to do this in MYSQL ver 5.7.
Any help is appreciated.
Thanks in advance!
ST_Distance returns "distance" in degrees here - i.e. the flat map view of the shortest distance between shapes. This value cannot be mapped to real distance, as real world distance of 1 degree along parallel is different from distance of 1 degree along meridian except near the equator.
Looks like MySQL cannot correctly compute distance here. You would be better served by systems with more geospatial support, like PostgreSQL + PostGIS, or Google BigQuery, etc. They give you correct answer, you just need to replace ST_GeomFromText with ST_GeogFromText to work with spherical geographies.
I have to discover if a given point is at least 500 meters (ou other distance) from a route line that exist in my database recorded using the MySQL Spatial.
I see there is no similar function in MySQL Spatial, and find a previous answer that doesn't work for me because the line is too big (more than 300km) to check with this solution point by point:
Find N Nearest LineString From A Point Using MySQL Spatial Extensions
I'm even can't create a buffer (a circle/polygon with a given radius) to the point to check if is even touch.
UPDATE - 12/7
I did it, but MySQL Spatial it is seams not trustable.
I made a createBuffer function, to create a 20 points Polygon around the given Point with a meters given distance for the radius: http://pastebin.com/xEFb8ZXi
I'm testing with the QGis the given results from this buffer, and everything is fine with the function (except the meters to decimal degress value that generate smaller then expected, but it is not the issue right now).
And made a few Intersects checks, and this is aways return true, even if the result polygon is not intersects the line.
I remade the same tests using just the center point, and the results is the same.
I discovery now that the INTERSECT doesn't check the LineString with the Point or Polygon, but the Bounding Box of the LineString, when a indicate a point OUTSIDE the Linestring BBox.
Intersects QUERY Where "rota" is the Linestring data:
SELECT Intersects(rota, createBuffer(GeomFromText('POINT(-19.7736 -43.7255)'),500))
FROM log_viagem WHERE rota IS NOT NULL;
How can I trust the MySQL Spatial now?
Or my concept about INTERSECTS is wrong?
SOLVED:
I didn't read the important note at 5.5 version of MySQL:
Note
Currently, MySQL does not implement these functions according to the specification. Those that are implemented return the same result as the corresponding MBR-based functions.
The Solution is taking with the server administrator to update to 5.6.1, there is an upgrade in the note
Note
MySQL originally implemented these functions such that they used
object bounding rectangles and returned the same result as the
corresponding MBR-based functions. As of MySQL 5.6.1, corresponding
versions are available that use precise object shapes. These versions
are named with an ST_ prefix. For example, Contains() uses object
bounding rectangles, whereas ST_Contains() uses object shapes.
As of MySQL 5.6.1, there are also ST_ aliases for existing spatial
functions that were already exact. For example, ST_IsEmpty() is an
alias for IsEmpty()
I have been using the MBRWithin function for quite a lot of times. Suddenly I notice on google map this POINT(101.11857 4.34475) is out of the geo fence which I specify but it still give a value of 1 in mysql any reason or tweaking need to be done?
SELECT MBRWithin(GeomFromText('POINT(101.11857 4.34475)'),GeomFromText('POLYGON((101.12112522125244 4.3531723687957164,101.11846446990967 4.351417913665312,101.13138198852539 4.336397898951581,101.13477230072021 4.33211863778494,101.14065170288086 4.321933898868271,101.14992141723633 4.306699328215635,101.15455627441406 4.30978050198082,101.1397933959961 4.334600612212089,101.12112522125244 4.3531723687957164,101.12112522125244 4.3531723687957164))')) As geoFenceStatus
MySQL 5.6.1 and later have exact geometry algorithms in addition to the earlier functions that only operated on MBR.
You can use ST_WITHIN rather than MBR_WITHIN. See documentation. Like this
SELECT ST_Within(GeomFromText('POINT(101.11857 4.34475)'),
GeomFromText('POLYGON((101.12112522125244 4.3531723687957164,101.11846446990967
4.351417913665312,101.13138198852539 4.336397898951581,101.13477230072021
4.33211863778494,101.14065170288086 4.321933898868271,101.14992141723633
4.306699328215635,101.15455627441406 4.30978050198082,101.1397933959961
4.334600612212089,101.12112522125244 4.3531723687957164,101.12112522125244
4.3531723687957164))')) As geoFenceStatus
MBRWithin() will return results based on the minimum bounding rectangle of it's parameters. Your polygon contains both larger and smaller values for both coordinates than the point, so it will be within the polygon's MBR.
MySQL has no built-in point in polygon algorithm, so you'll either have to roll your own or find one elsewhere. This one seems to be a good candidate.
i have a table with two fields (X,Y)
they hold the location of points in New Israel Projection (EPSG: 2039) (e.g. X=194545.05941493041, Y=668112.83849507652)
i want to reproject all points to WGS84 (EPSG: 4326). (e.g. the same coordinates above should translate to something around: 34.940578289586, 32.106153057749005
how do i do that in SQL 2008?
There may be a easier solution now, but what I had to do a few years ago was the following:
I needed to reproject between UTM33N(x, y ) and WGS84 (lat lon).
I use http://projnet.codeplex.com/ to translate each coordinate. The key you need is the two WKT (WellKnownText) that make up the projection model.
For me it was some hours of try and fail, but eventually I had a good translation.
Later when we started to use spatial indexes I created a SSIS package to reproject all data on inport.
There may be better solutions that that today:
perhaps it's supported by http://sqlspatialtools.codeplex.com/
Also I see that many are using ogr2ogr http://www.gdal.org/ogr2ogr.html