I am looking for an algorithm that can do efficient search in a grid.
I have a large array which includes all the centroid points (x,y,z)
Now for a given location (xp,yp,zp) I want to find the closest centroid to that p location.
Currently I am doing a brute force search which basically for each point p I go through all points, calculate the distance to location p and by this find out which centroid that is.
I know that octree search and kd-tree might help but not too sure how to tackle it or which one would be better.
I would you a spatial index, such as the kd-tree or quadtree/octree (which you suggested) or maybe an R-Tree based solution.
Put all your centroids into the index. Usually you can associated any point in the index with some additional data, so if you need that, you could provide a back-treference into the grids, for example grid coordinates).
Finding the nearest point in the index should be very fast. The returned data then allows you to go back into the grid.
In a way, a quadtree/octree is in itself nothing but a discretizing grid that get finer if the point density increases. The difference to a grid is that it is hierarchical and that empty areas are not stored at all.
Related
Given two 2-dimensional bounding boxes. Each bounding box have a different pose and velocity.
Assume the velocity of both objects stay constant, I am interested in the time point when they collide, if such a time point exists.
Shrink one of the boxes to a point and that the same time inflate the other accordingly. The shape that you obtain is the so-called Minkowski sum of the two boxes. It will be an octagon.
Then consider the difference of the speeds, which gives you a relative displacement vector. Now the problem reduces to finding the intersection between the half-line from the point and the octagon, which is relatively easy.
How to find city based on current location lat, lng without reverse Geo coding ? I tried to save Indian cities data in the form of Geo json but it is of type Multi Polygon. i didn't find any way to convert it to single polygon which is easy to find. if i try to find lat lng inside every polygon it will take lot of time. i want to do it efficiently and faster way.
If you do not want to use an API, you will need to maintain a list of cities and their coordinates yourself.
For example, here is a good starting point for such a list:
https://www.latlong.net/category/cities-102-15.html
With the list, take current lat/lng and calculate the distance. Euclidian distance would work well enough for most practical applications. Sort the results starting by smallest and take the first one. This is your nearest city.
wondering if anyone has any insight as to how to ascertain the order of differently sized rectangles from left to right and from top to bottom when they are not already aligned to any grid, and they are differently sized and/or rotated. Some might also be missing.
As anyone can see from the illustration, the objects should be numbered as shown. But how, mathematically or programmatically, can I determine this? What is the logic? I don't even know what words to use to describe the problem.
This looks like a rather complex problem; maybe some algorithm already exists, IDK.
Approach 1: grid positioning.
One approach could start with trying to position the rectangles on a grid whose mesh size will have to be calculated; maybe a best fit to the size of the rectangles (H & W, or surface, maybe?)
Once a reasonable grid has been determined, it must be appropriately placed over the rectangles; maybe in such a way that minimizes row overlap and column overlap of the rectangles?
The last step would consist of traversing the grid row by row, and assigning a label to each rectangle; maybe based on the max common surface shared by a grid cell and a rectangle?
There will be many edge cases to identify and resolve.
Approach 2: sweep line.
Alternatively, a sweep line numbering of the rectangles from N, S, E, and W, and an appropriate weighting/averaging of the numbering of the rectangles from each direction, might give good results?
It may require several passes, after identifying what could be rows and columns, in order to find a "best fit".
This second approach is likely easier to implement.
For instance, I want the grid cells (squares) inside or partially inside polygon #14 to be associated with #14. Is there an algorithm that will compute if a square is inside a polygon efficiently?
I have the coordinates of the edges that make up the polygon.
If I get it right, this is an implementation of Fortune's algorithm in JavaScript, that takes a set of 2-d points (called sites) and returns a structure containing data for a Voronoi diagram computed for this points. It returns polygons in a list called cells. It seems to use Euclidean distance as measurement. If it's true we know that polygons are always convex (see Formal definition section in Voronoi wiki page).
Now, these are options to solve this problem (hard to simple):
1. Polygon Clipping:
Form a polygon for the square.
Find its intersection with all cells.
Calculate area of this intersections.
Find the largest intersection.
2- Point in Polygon:
You also can simply find the cell that center of the square lies inside it. Ray casting is a robust PIP algorithm. Although there's a simpler approach for convex polygons (see Convex Polygons section here).
3. Distance Between Points:
I if you know the site associated to each cell then you just need to calculate distance between center of square to all sites. Regardless of what distance measurement you use to compute the Voronoi, the center point of square lie inside the cell that distance of it's associated site is minimum, since this is actually the idea for partitioning the plane in a Voronoi diagram.
Exceptions:
First approach is computationally expensive but most accurate. Second and third options work fine in most cases, however, there are exceptions that they fail to decide correctly:
Second and third are pretty much alike, but the down side of PIP is cases where point lies on edges of the polygon that cost you more overhead to detect.
Does anyone have any handy algorithms that could be used to reduce the number of geo-points ?
I am using a list of 2,000,000 postcodes which come with their own geo-point. I am using them to collect data from an API to be used offline. The program is written in C++.
I have to go through each postcode, calculate a bounding box based on the postcodes location, and then send it to the API which gives me some data near to that postcode.
However 2,000,000 is a lot to process and some of the postcodes are next to each other or close enough to each other that they would share some of the same data.
So far I've came up with two ways I could reduce them but I am not sure if they would work:
1 - Program uses data structure to record which postcode overlaps which and then run a routine a few time to removes the ones that have overlaps one by one until we are left without ones without overlapping postcodes.
Start at the top left geo point of the UK and slowly increment it the rough size of a postcode area until we have covered the entire UK.
Is there a easy way to reduce these number of postcodes so that I have few of them overlapping as possible ? whilst still making sure I get data covering as much of the UK as possible ? I was thinking there may be an algorithm handy for this, that people use else where.
You can use a quadtree especially a quadkey. A quadkey plot the points along a curve. It's similar to sort the points into a grid. Then you can traverse the grid to search deeper in the tree. You can also search around a center point. You can also use a database with a spatial index. It depends how much the data overlap but with a quadtree you can choose the size of the grid.