Geometry Boost List: [ggl] space partitioning

Subject: [ggl] space partitioning
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-01-22 07:29:14

Adam Wulkiewicz wrote:
> One more thing. Querry in following form could be difficult to implement
> (or impossible for various containers) because there are no area or
> elements number bounds defined in the nearest_filter range generator.
>
> BOOST_FOREACH(my_point_type const& p, my_spatial_index |
> boost::geometry::adaptors::nearest_filter(my_point_type(5, 5)) |
> boost::geometry::adaptors::filter(my_polygon))
> {
> // do something with sorted points
> }
>
> Instead, it should look like this:
>
> BOOST_FOREACH(my_point_type const& p, my_spatial_index |
> boost::geometry::adaptors::nearest_filter(my_point_type(5, 5),
> max_distance) | boost::geometry::adaptors::filter(my_polygon))
> {
> // do something with sorted points
> }
>
> Btw, most basic spacial query might look like this:
>
> BOOST_FOREACH(my_point_type const& p, my_points_vector |
> boost::geometry::adaptors::filter(my_aabb))
> {
> // do something with sorted points
> }

Another option is to have lazily evaluated queries. Something like views 
in Boost.Fusion. The result is very flexible interface. This is what I'm 
thinking of:

operator& generates lazy evaluated range/view object
operator| generates range

using boost::geometry::adaptors;

BOOST_FOREACH(my_point_type const& p, my_spatial_index
   | nearest_filter(my_point_type(5, 5))
     & distance_filter(max_distance)
     & number_filter(max_number)
     & volume_filter(my_polygon)
   | boost::filtered(some_pred))
{
   // do something with points
}

Or if the container don't implement this kind of specialized and 
probably optimized query (closest points in some volume) we must return 
all points in some distance and then iterate over them, check which are 
in the volume and count them. Of cause, points are sorted in both cases.

BOOST_FOREACH(my_point_type const& p, my_spatial_index
   | nearest_filter(my_point_type(5, 5))
     & distance_filter(max_distance)
   | volume_filter(my_polygon)
   | counted(max_number)
   | boost::filtered(some_other_pred))
{
   // do something with points
}

Some view filters should be connectable only with some number of view 
filters. Some shouldn't be used alone. E.g. distance_filter.

But I'm affraid that we'll end up with various containers supporting 
various ranges and views and the user who wants to write code working 
with all containers will use the minimal interface. On the other hand 
the user might use some optimized queries.

Regards,
Adam Wulkiewicz