This presentation was given by Pavan Naik in Open Source India (OSI) 2014 even held in Nimans Convention Centre, Bangalore. It talks about GIS features in MySQL 5.7.
Presentation covers following topics :
1. Introduction to GIS
2. Common Terms and Concepts
3. What's new in MySQL 5.7
4. A Real World Example
5. What's next for MySQL GIS
This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template.
One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy
To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com
For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information.
http://my.oracle.com/site/fin/gfo/GlobalProcesses/cnt452504.pdf
For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.
GIS: A computer-based system that stores geographically referenced data layers (features) and links it with non-graphic data tables (attributes) allowing for a wide range of information processing, including manipulation, analysis, and modeling. A GIS also allows for map display and production.
We’re going to focus on simple location services in our examples.
X or northing which will typically be a longitude value, Y or easting which will typically be a latitude value, Z or height (optionally a true geodetic value), and M or measure (which can be used for Time, for example).
University Consortium for Geographic Information Science
USGS or United States Geological Survey
Started out as the Generic Geometry Library by OSGeo. Now it’s of course part of Boost.
R-trees are the most common index type used for spatial data. It’s a wide search tree, with some similarities with B-trees. It’s similar in that of course it’s a search tree, and it has root nodes, branch nodes, and leaf nodes.
The main differences are:
1. R-trees use pages for each level in the tree, and the page can contain X number of nodes. So the search is not binary at any level. Each level in the tree can have up to some maximum number of nodes. The maximum being set by the specific implementation.
2. You search by bounding box. If the search box overlaps with the MBR stored in a node, then you continue to search down that path, moving to the next child node.
You can set the SRID of geometries in MySQL to any 32 bit unsigned integer, and we will refuse to mix geometries of different SRIDs in the same operation. In calculations, everything will be treated as SRID 0, which in MySQL is a Cartesian system without units (what you get if you don't specify an SRID).
Common alternatives are a fixed address like this, or a GPS location from your mobile device.
I’m using the spherical law of cosines formula because it’s simpler, and thus faster, than Haversine; while also giving us virtually the same accuracy (Haversine is generally more accurate though, particularly for short distances). That’s generally why Haversine is the most common method that you’ll see used.
It’s possible that this need goes away later in 5.7 too. We’re looking into possibly adding an ST_Distance_Sphere() function that returns the great-circle earth distance calculation, in meters, between two geometries (which are points containing X,Y or LON/LAT coordinate pairs).
ST_Distance_Sphere — Returns minimum distance in meters between two lon/lat geometries. Uses a spherical earth and radius of 6,370,986 meters.
We’ll simply use the average distance between longitude and latitude degrees in our coming example. We don’t need the envelope to be too accurate as we’re simply using it to pass down to the spatial index, and we’re later calculating the actual distance using our new SLC function.
The need for this may go away later in 5.7 too. We’re considering adding an ST_MakeEnvelope() function that takes a Geometry parameter (again a POINT containing a LON/LAT coordinate pair) and an integer to create an envelope that would contain all points within the specified number of meters from the Geometry.
ST_MakeEnvelope(point, distance) --- Make a rectangle around a point(x,y) so that the distance between the point and the rectangle's boundaries is 'distance' units (km) away. This is done on an abstract cartesian plane and simply creates an envelope that contains all points within a radius of approximately <distance> km around the <point>.
In our example query we’re simplifying the bounding box calculation and using <km>/111, 111 being the average distance in km between longitude and latitude degrees. It’s not very accurate for longitude, in particular the further you get away from the equator, but it doesn’t have to be very accurate for our bounding box as we’re calculating the actual distance with our SLC function. The bounding box is just to pass down to the spatial index so that we can weed out all of the irrelevant points.