Geometry Boost List: [ggl] space partitioning

Subject: [ggl] space partitioning
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-01-22 08:05:17

Adam Wulkiewicz wrote:
> 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.

I'd like to clarify one thing. This lazy evaluation wouldn't be exactly 
like in Boost.Fusion views because in there it's performed for each 
element. Our query would be built by using operator& and then performed 
one time e.g. by using operator|.

Regards,
Adam Wulkiewicz