Tag Info

Hot answers tagged

7

If all you are looking for are proximity point searches (nearest neighbour queries), then you don't want to use the old ST_DWithin or ST_Distance + ORDER BYs for that. Not anymore. Now that PostGIS 2.0 shipped, you should be using the knngist index support (a native PostgreSQL feature). It will be orders of magnitude faster. An excerpt from this blog ...


6

Spatial queries are definitely the thing to use. With PostGIS I would first try something simplistic like this and tweak the range as needed: SELECT * FROM table AS a WHERE ST_DWithin (mylocation, a.LatLong, 10000) -- 10km ORDER BY ST_Distance (mylocation, a.LatLong) LIMIT 20 This would compare points (actually their bounding boxes) using the spatial ...


5

With PostGIS 2.0 on PostgreSQL 9.1, you can use the KNN indexed nearest neighbour operator, e.g.: SELECT *, geom <-> ST_MakePoint(-90, 40) AS distance FROM table ORDER BY geom <-> ST_MakePoint(-90, 40) LIMIT 20 OFFSET 0; The above should query within a few milliseconds. For the next multiples of 20, modify to OFFSET 20, OFFSET 40, etc ...


4

Something must be wrong with your mysql installation or the .ini settings. Just tested a geospatial index on my old mac (10.6.8 / MySQL 5.2). That configuration is similar to yours and I tested the big geodata dump (9 million records). I did this query: SET @radius = 30; SET @center = GeomFromText('POINT(51.51359 7.465425)'); SET @r = @radius/69.1; SET ...


4

MySQL, like PostGIS, stores it’s spatial index data in an R-tree structure so it can find stuff fast. An R-tree, like a B-tree, is organized in such a manner that it is optimized for retrieving only a small fraction of the total data in the table. It is actually faster to ignore the index for queries that need to read a large section of ...


2

Having looked at your code where is row[] being created, I guess we are not seeing the full picture? I've seen this "GPL0" error before. It's indicating that the first parameter is invalid. If you look at the syntax section of the help for this tool it states the input features are of Data Type FeatureLayer. As we are not seeing the full code we have no ...


1

This is the travelling salesman problem, although I'm not sure that you care about returning to the same place as you began. The TSP is NP-Hard: for even a small number of destinations to be visited, there is an incredibly large number of possibilities for an algorithm to consider before it can tell you what the optimal path is. I haven't tried with every ...


1

Have you thought about breaking it up into two 1D columns instead of a single 2D column? The optimizer could be choking on all the similar data and having two columns with greater variety might help. What you might also check is the order in which items are checked. I had a problem in Oracle Spatial where I was search on Last Name and an IN_REGION filter. ...



Only top voted, non community-wiki answers of a minimum length are eligible