On 2-9-2013 0:04, Adam Wulkiewicz wrote:

Initially I thought about providing ray queries. Those queries return some number of objects hit by a ray.




Because we don't have a Ray concept I decided to use Segment and by extension Linestring. I thought about a real intersection because this algorithm will probably be the fastest one but more general variations could also be useful. I'd like to allow users using any algorithm they want in a strategy of the nearest() predicate. More algorithms means more possibilities.

Btw, Is this what you've thought?

Yes, based on your proposal, I think that intersecting and objects close by are both interesting. But if you want the first 5, you might get ambiguities (closer to starting point, or closer to the line...)

Yes, the knowledge about the position of a measure-point in some cases is useful, e.g. in the Linestring example above where the position of a closest point must be calculated and then it's distance from the beginning of the Linestring.

I thought about something related to this and nearest predicate. If we have two points inside a Polygon or Two Polygons intersecting one Point, which one is the closest?



If I remember correctly, currently I'm using distance = 0 if the Point is inside (intersecting) the Box but one could also say that the closest one is the one nearest to the centroid or further of the border or even something else.

I see, so this is another sort of ambiguity indeed. I don't know what users expect if they ask for the 5 nearest points and there are 10 inside. But using the centroid is an interesting solution. However, if two points are located on the same distance (w.r.t. centroid), you can still get an arbitrary choice... I don't think that is really problematic, though I'm quite sure some users want to have a consistent choice in these cases.