| 171 | | <br> |
| 172 | | </div> |
| 173 | | }}} |
| | 171 | <hr/> |
| | 172 | <p> |
| | 173 | I think the solution to this multipoint problem is the key to the algorithm we want to implement. There would be only one point, there would be no problem. The problem is: How do I know which distance to compute (to which point) for each pixel while I iterate on them. What if the number of point is greater than the number of pixel? Should we iterate on the point in this case instead of iterating on the pixels?<br> |
| | 174 | <br> |
| | 175 | The point here is what to scan first and how many times? Do they rescan the whole raster for every points? That's ok if you have a low number of points but what if you have millions?<br> |
| | 176 | <br> |
| | 177 | I think with the knn index already built you could scan pixels only once assigning the distance to the closest point. and that would be fast even if there are millions. Is this correct?<br> |
| | 178 | <br> |
| | 179 | >> From: Pierre<br> |
| | 180 | >> I want also a kind of approach to the problem of billions of points. Does<br> |
| | 181 | >>the knn indexing help us in quickly identifying what is the nearest point to the<br> |
| | 182 | >>pixel without rescanning all the point for every pixels.<br> |
| | 183 | > From: Qing<br> |
| | 184 | > Yes, KNN index will definitely help us to identify the nearest point to the pixel.<br> |
| | 185 | > With the capability of PostGIS 2.0 to return sorted results from a GiST index, we<br> |
| | 186 | > can have the results ordered by the geometry distance between pixel centroid<br> |
| | 187 | > and identify the shortest one without having to rescan all the points. However,<br> |
| | 188 | > the "order by distance between bounding box centroid" works now for<br> |
| | 189 | > geometries. When it comes to point data, the bounding boxes are equivalent to<br> |
| | 190 | > the points themselves. So the same would apply to the center of pixel in our<br> |
| | 191 | > calculation. We now have a GiST index over the raster column. However, I am<br> |
| | 192 | > not sure about how we build spatial index embedded in the pixels or the raster<br> |
| | 193 | > geometry.<br> |
| | 194 | <br> |
| | 195 | Not sure I understand well. Could converting pixel centroids into points and computing the knn index on the mix of points and centroids converted to points be an avenue?<br> |
| | 196 | <br> |
| | 197 | I think, considering all the constraints, that we might have to end up with different approaches depending on different constraints. A simple one if some constraints are involved, a more complex one if more constraints are involved.<br> |
| | 198 | <br> |
| | 199 | So in your analyses you have to put into relationship: constraints, features (like the possibility to define a limited distance or the possibility to work with line and polygons), possibilities (limits of the data structure imposed by the DB like the fact that all the geometries are on a different row), scalability, flexibility (we want a generic solution to implement other kind of distances) and performance.<br> |
| | 200 | </p> |
| | 201 | <br> |
| | 202 | </div> |
| | 203 | }}} |
