In a MySQL database, how do I find circular areas that fall entirely or partially within a certain distance from another point? There are plenty of examples to find points within a certain radius, but not circular areas that intersect that certain radius.
I have a list of contractors that service certain areas (point and radius). Customers need to be able to find these contractors based on a distance from them.
I think you are looking for ST_Buffer, which will buffer a geometry by a certain distance. In your case this will turn your point into a circle, and you can then use ST_Intersects to find intersecting circles representing contractor areas.
Something like:
Select id from contractor c where intersects(c.geom, st_buffer(point, radius));
where obviously you need to provide values for point and a radius.
Related
I have a set of of polygons. Sometimes they are completely disconnected (like separate patches). Other times, two sides of two polygons may touch each other (when the polygons are adjacent like on a chess board). The polygons never cross each other. In other words, their intersection is always empty.
I need to check if a point is contained in any one of those polygons. Is there a way I can build a single geometry using these polygons and check if the point is in it?
Currently I'm building a long WHERE close with OR conditions and do something like the below:
st_contains(st_GeomFromText('POLYGON(("+polygon+"))'), st_GeomFromText(CONCAT('POINT()')))
Thanks.
I'm in a process of developing an application and I would appreciate some help regarding an idea how to store data in mysql table.
I have two points - point A and point B which are start and end point.
I've already wrote some php function that will create rectangles similar to:
http://googlegeodevelopers.blogspot.com/2010/05/search-along-route-made-easy-with.html
However depending on the route and radius it generates different amount of rectangles. What is the best way to save those rectangles into the database, so later I can query the DB and check if another two points (start/end) are in any of those rectangles.
Can you give me an example?
The easiest way to do it is to store your rectangles as polygons, per
http://dev.mysql.com/doc/refman/4.1/en/polygon-property-functions.html
You can then use MBRIntersects to figure out if they intersect (or use MBRWithin or MBRContains, if you'd prefer), per
http://dev.mysql.com/doc/refman/5.1/en/functions-for-testing-spatial-relations-between-geometric-objects.html#function_mbrintersects
For funky-shaped polygons, this isn't adequate, but the MBR (minimum bounding box) of a rectangular bounding box will be exactly the same as the rectangle itself.
My Company currently runs a listing service of family activities. In our CMS we have two types of entities Branches (The shops we list) and Events (Special Offers, Occasions etc).
Typically when listing an event we would say which Branches it is for and create a relationship, we would search the near by shops for events. Grab them and sort them by distance.
Now our clients want to be able to list a one off event that hasn't got a branch associated with it (For example they host a Festival at a near by garden center rather than one of their shops), I can easily make it I can sort these by distance as well.
But what I was wondering is how could combine the both, so one of our apps could go to our API, "Dude, where are 10 events near to whee I am right now ? " and the api would pull up a list of the 10 closest events.
It should be able to handle Events that are using the location of Branches as well as having its own unique location.
Or do you think I should just store location as its own entity or have hidden branches, places we can set up as being where the event is happening but don't actually show up as being a branch in the app :)
If you have lat / long positions for your events and your branches you can apply the Haversine Formula to compute approximate distances, then order by ascending distance.
MySQL can do this, if you're willing to use a hairy query. This note from the Google Maps team gives the query. You don't have to use Google Maps to do this; you just need lat/long information for each place involved.
https://developers.google.com/maps/articles/phpsqlsearch_v3
Edit It's true that this is very slow if you compute the distance between many pairs of places. The trick to making this kind of operation fast is using a bounding box (spherectangular) distance limit, and putting indexes on your latitude and longitude.
Look at this: Geolocation distance SQL from a cities table
MYSQL has support for "spacial databases" as the spacial extension This will allow you to use "spacial" datatypes in your columns, as well as build index on them, and perform various "spacial analysis" such as polygon intersection.
Not sure this is what you need, but that may worth investigations.
I've found various questions with solutions similar to this problem but nothing quite on the money so far. Very grateful for any help.
I have a mysql (v.5.6.10) database with a single table called POSTS that stores millions upon millions of rows of lat/long points of interest on a map. Each point is classified as one of several different types. Each row is structured as id, type, coords:
id an unsigned bigint + primary key. This is auto incremented for each new row that is inserted.
type an unsigned tinyint used to encode the type of the point of interest.
coords a mysql geospatial POINT datatype representing the lat/long of the point of interest.
There is a SPATIAL index on 'coords'.
I need to find an efficient way to query the table and return up to X of the most recently-inserted points within a radius ("R") of a specific lat/long position ("Position"). The database is very dynamic so please assume that the data is radically different each time the table is queried.
If X is infinite, the problem is trivial. I just need to execute a query something like:
SELECT id, type, AsText(coords) FROM POSTS WHERE MBRContains(GeomFromText(BoundingBox, Position))
Where 'BoundingBox' is a mysql POLYGON datatype that perfectly encloses a circle of radius R from Position. Using a bounding box is, of course, not a perfect solution but this is not important for the particular problem that I'm trying to solve. I can order the results using "ORDER BY ID DESC" to retrieve and process the most-recently-inserted points first.
If X is less than infinite then I just need to modify the above to:
SELECT id, type, AsText(coords) FROM POSTS WHERE MBRContains(GeomFromText(BoundingBox, Position)) ORDER BY id DESC LIMIT X
The problem that I am trying to solve is how do I obtain a good representative set of results from a given region on the map when the points in that region are heavily clustered (for example, within cities on the map search region). For example:
In the example above, I am standing at X and searching for the 5 most-recently-inserted points of type black within the black-framed bounding box. If these points were all inserted in the cluster in the bottom right hand corner (let's assume that cluster is London) then my set of results will not include the black point that is near the top right of the search region. This is a problem for my application as I do not want users to be given the impression that there are no points of interest outside any areas where points are clustered.
I have considered a few potential solutions but I can't find one that works efficiently when the number of rows is huge (10s of millions). Approaches that I have tried so far include:
Dividing the search region into S number of squares (i.e., turning it into a grid) and searching for up to x/S points within each square - i.e., executing a separate mysql query for each square in the grid. This works OK for a small number of rows but becomes inefficient when the number of rows is massive as you need to divide the region into a large number of squares for the approach to work effectively. With only a small number of squares, you cannot guarantee that each square won't contain a densely populated cluster. A large number of squares means a large number of mysql searches which causes things to chug.
Adding a column to each row in the table that stores the distance to the nearest neighbour for each point. The nearest neighbour distance for a given point is calculated when the point is inserted into the table. With this structure, I can then order the search results by the nearest neighbour distance column so that any points that are in clusters are returned last. This solution only works when I'm searching for ALL points within the search region. For example, consider the situation in the diagram shown above. If I want to find the 5 most-recently-inserted points of type green, the nearest neighbour distance that is recorded for each point will not be correct. Recalculating these distances for each and every query is going to be far too expensive, even using efficient algorithms like KD trees.
In fact, I can't see any approach that requires pre-processing of data in table rows (or, put another way, 'touching' every point in the relevant search region dataset) to be viable when the number of rows gets large. I have considered algorithms like k-means / DBSCAN, etc. and I can't find anything that will work with sufficient efficiency given the use case explained above.
Any pearls? My intuition tells me this CAN be solved but I'm stumped so far.
Post-processing in that case seems more effective. Fetch last X points of a given type. Find if there is some clustering, for example: too many points too close together, relative to the distance of your point of view. Drop oldest of them (or these which are very close - may be your data is referencing a same POI). How much - up to you. Fetch next X points and see if there are some of them which are not in the cluster, or you can calculate a value for each of them based on remoteness and recentness and discard points according to that value.
Does anyone know of a way to fetch all polygons in a MySQL db within a given distance from a point? The actual distance is not that important since it's calculated for each found polygon later, but it would be a huge optimization to just do that calculation for the polygons that are "close".
I've looked at the MBR and contains functions but the problem is that some of the polygons are not contained within a bounding box drawn around the point since they are very big, but some of their vertices are still close.
Any suggestions?
A slow version (without spatial indexes):
SELECT *
FROM mytable
WHERE MBRIntersects(mypolygon, LineString(Point(#X - #distance, #Y - #distance), Point(#X + #distance, #Y + #distance))
To make use of the spatial indexes, you need to denormalize your table so that each polygon vertex is stored in its own record.
Then create the SPATIAL INDEX on the field which contains the coordinates of the vertices and just issue this query:
SELECT DISTINCT polygon_id
FROM vertices
WHERE MBRContains(vertex, LineString(Point(#X - #distance, #Y - #distance), Point(#X + #distance, #Y + #distance))
The things will be much more easy if you store UTM coordinates in your database rather than latitude and longitude.
I don't think there's a single answer to this. It's generally a question of how to organize your data so that it makes use of the spacial locality inherent to your problem.
The first idea that pops into my head would be to use a grid, assign each point to a square, and check select the square the point is in, and those around it. If we're talking infinite grids, then use a hash-value of the square, this would give you more points than needed (where you have collisions), but will still reduce the amount by a bunch. Of course this isn't immediately applicable to polygons, it's just a brainstorm. A possible approach that might yield too many collisions would be to OR all hashed values together and select all entries where the hashes ANDed with that value is non-zero (not sure if this is possible in MySQL), you might want to use a large amount of bits though.
The problem with this approach is, assuming we're talking spherical coordinates (lat, long generally does) are the singularities, as the grid 'squares' grow narrower as you approach the poles. The easy approach to this is... don't put any points close to the poles... :)
Create a bounding box for all of the polygons and (optionally storing these results in the database will make this a lot faster for complex polygons). You can then compare the bounding box for each polygon with the one round the point at the desired size. Select all the polygons which have intersecting bounding boxes.