spatial-main — For general conversations concerning the library.

Re: [Spatial] [spatial:tickets] #6 C++20 std::allocator::rebind is deprecated

[Darío M. <mar...@gm...>]

Ok, I have a quick hack but I'll see if I can clean and complete it. It
will take some time as it's not a critical issue for me right now.
Regards.

On Wed, Mar 10, 2021 at 8:34 AM Sylvain Bougerel <syl...@gm...>
wrote:

> Hi Dario,
>
> Thanks for the notification, I have not updated the library for a while
> now, and I definitely should but do not have much time. Would you like to
> do it?
>
> Regards,
> Sylvain
>
> On Sat, Mar 6, 2021 at 11:07 PM Dario Mariani via Spatial-main <
> spa...@li...> wrote:
>
>> ------------------------------
>>
>> * [tickets:#6] <https://sourceforge.net/p/spatial/tickets/6/> C++20
>> std::allocator::rebind is deprecated*
>>
>> *Status:* open
>> *Milestone:* 2.1.9
>> *Created:* Sat Mar 06, 2021 03:07 PM UTC by Dario Mariani
>> *Last Updated:* Sat Mar 06, 2021 03:07 PM UTC
>> *Owner:* nobody
>>
>> In std::allocator, the member rebind, construct and destroy were
>> deprecated in C++20 and other allocators are doing the same (e.g. Intel
>> OneTBB). A possible solution is:
>>
>> -      typedef typename Alloc::template rebind-      <Kdtree_link<Key, Value> >::other               Link_allocator;-      typedef typename Alloc::template rebind-      <value_type>::other                             Value_allocator;+      using Link_allocator  = std::allocator_traits<Alloc>::template rebind_alloc<Kdtree_link<Key, Value>>;+      using Value_allocator = std::allocator_traits<Alloc>::template rebind_alloc<value_type>;
>>
>> and
>>
>> -        get_value_allocator().construct(mutate_pointer(&safe.link->value),-                                        value);+        Value_allocator v_alloc = get_value_allocator();+        std::allocator_traits<Value_allocator>::construct(v_alloc, mutate_pointer(&safe.link->value), value);
>>
>> ------------------------------
>>
>> Sent from sourceforge.net because spa...@li... is
>> subscribed to https://sourceforge.net/p/spatial/tickets/
>>
>> To unsubscribe from further messages, a project admin can change settings
>> at https://sourceforge.net/p/spatial/admin/tickets/options. Or, if this
>> is a mailing list, you can unsubscribe from the mailing list.
>> _______________________________________________
>> Spatial-main mailing list
>> Spa...@li...
>> https://lists.sourceforge.net/lists/listinfo/spatial-main
>>
>

Re: [Spatial] [spatial:tickets] #6 C++20 std::allocator::rebind is deprecated

[Sylvain B. <syl...@gm...>]

Hi Dario,

Thanks for the notification, I have not updated the library for a while
now, and I definitely should but do not have much time. Would you like to
do it?

Regards,
Sylvain

On Sat, Mar 6, 2021 at 11:07 PM Dario Mariani via Spatial-main <
spa...@li...> wrote:

> ------------------------------
>
> * [tickets:#6] <https://sourceforge.net/p/spatial/tickets/6/> C++20
> std::allocator::rebind is deprecated*
>
> *Status:* open
> *Milestone:* 2.1.9
> *Created:* Sat Mar 06, 2021 03:07 PM UTC by Dario Mariani
> *Last Updated:* Sat Mar 06, 2021 03:07 PM UTC
> *Owner:* nobody
>
> In std::allocator, the member rebind, construct and destroy were
> deprecated in C++20 and other allocators are doing the same (e.g. Intel
> OneTBB). A possible solution is:
>
> -      typedef typename Alloc::template rebind-      <Kdtree_link<Key, Value> >::other               Link_allocator;-      typedef typename Alloc::template rebind-      <value_type>::other                             Value_allocator;+      using Link_allocator  = std::allocator_traits<Alloc>::template rebind_alloc<Kdtree_link<Key, Value>>;+      using Value_allocator = std::allocator_traits<Alloc>::template rebind_alloc<value_type>;
>
> and
>
> -        get_value_allocator().construct(mutate_pointer(&safe.link->value),-                                        value);+        Value_allocator v_alloc = get_value_allocator();+        std::allocator_traits<Value_allocator>::construct(v_alloc, mutate_pointer(&safe.link->value), value);
>
> ------------------------------
>
> Sent from sourceforge.net because spa...@li... is
> subscribed to https://sourceforge.net/p/spatial/tickets/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/spatial/admin/tickets/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>

[Spatial] [spatial:tickets] #6 C++20 std::allocator::rebind is deprecated

[Dario M. <dm...@us...>]

---

** [tickets:#6] C++20 std::allocator::rebind is deprecated**

**Status:** open
**Milestone:** 2.1.9
**Created:** Sat Mar 06, 2021 03:07 PM UTC by Dario Mariani
**Last Updated:** Sat Mar 06, 2021 03:07 PM UTC
**Owner:** nobody


In std::allocator, the member rebind, construct and destroy were deprecated in C++20 and other allocators are doing the same (e.g. Intel OneTBB). A possible solution is:
~~~
-      typedef typename Alloc::template rebind
-      <Kdtree_link<Key, Value> >::other               Link_allocator;
-      typedef typename Alloc::template rebind
-      <value_type>::other                             Value_allocator;
+      using Link_allocator  = std::allocator_traits<Alloc>::template rebind_alloc<Kdtree_link<Key, Value>>;
+      using Value_allocator = std::allocator_traits<Alloc>::template rebind_alloc<value_type>;
~~~
and
~~~
-        get_value_allocator().construct(mutate_pointer(&safe.link->value),
-                                        value);
+        Value_allocator v_alloc = get_value_allocator();
+        std::allocator_traits<Value_allocator>::construct(v_alloc, mutate_pointer(&safe.link->value), value);
~~~


---

Sent from sourceforge.net because spa...@li... is subscribed to https://sourceforge.net/p/spatial/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/spatial/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Spatial] Learning C++ for spatial

[Sylvain B. <syl...@gm...>]

Hi Shane,

My apologies for the long wait in the response. There are a few basic
examples to use the library in the documentation itself, which I'm sure
you've found already: http://spatial.sourceforge.net/

If you give me a bit more details, I can help you to use the library along
the way.

Cheers,
Sylvain

On Wed, Dec 4, 2019 at 12:51 AM Shane Carey <car...@gm...> wrote:

> Hi,
>
> I am currently learning C++ and would like to use it for manipulating
> spatial data. Are there any good tutorials on how to use C++ to manipulate
> spatial data such as polygon shapefiles?
>
> Thanks in advance
> Le gach dea ghui,
> *Shane Carey*
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>

[Spatial] Learning C++ for spatial

[Shane C. <car...@gm...>]

Hi,

I am currently learning C++ and would like to use it for manipulating
spatial data. Are there any good tutorials on how to use C++ to manipulate
spatial data such as polygon shapefiles?

Thanks in advance
Le gach dea ghui,
*Shane Carey*

Re: [Spatial] Combined orthogonal range and kNN queries

[Sylvain B. <syl...@gm...>]

Hi Felix,

Sorry I saw your question way too late.

You will not gain much by combining both, I am afraid. There are several
reasons for this:
- kNN queries in k-D tree reduce the range space very rapidly, even in very
dense sets.
- kNN are the most processing intensive, and much of the computation will
be dominated by them anyway

There maybe cases where that might seem useful, but usually, running the
orthogonal range search first and then all distance calculations on the
result set is just as fast.

Such situation arise when you are trying to find the closest neighbor when
most points are on a sphere and the target is next to its center.

In this case of situation, an orthogonal range search is much faster and
more appropriate if you know in which sector of the sphere you must look.
But again, you might as well just run all the distance calculations in a
loop, since the kNN search will not give any benefits.

I hope it was useful,
Sylvain

On Wed, Aug 15, 2018 at 8:52 PM Felix Laufer <la...@in...>
wrote:

> Hi there,
>
> is it possible to (efficiently) combine orthogonal range and kNN queries?
> F.i. I'd like to retrieve only those k nearest neighbors within a
> specific n-dimensional box.
> Could you point me to some code examples?
>
> Thanks,
> Felix
>
> --
> M.Sc. Felix Laufer
>
> Office:   Building 48, Room 458
> Email:    la...@cs...
>
> Department of Computer Science
> AG wearHEALTH (http://www.wearhealth.org)
> TU Kaiserslautern
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>

[Spatial] Combined orthogonal range and kNN queries

[Felix L. <la...@in...>]

Hi there,

is it possible to (efficiently) combine orthogonal range and kNN queries?
F.i. I'd like to retrieve only those k nearest neighbors within a 
specific n-dimensional box.
Could you point me to some code examples?

Thanks,
Felix

-- 
M.Sc. Felix Laufer

Office:   Building 48, Room 458
Email:    la...@cs...

Department of Computer Science
AG wearHEALTH (http://www.wearhealth.org)
TU Kaiserslautern

Re: [Spatial] In-order traversal of the k-d tree

[Jakub K. <j....@gm...>]

Hi,

indeed, point_multiset<>::iterator is exactly what I've been looking for! Thank
you for the great examples and quick response.

Jakub

On 26.02.17 at 13:17 (UTC+0000), Sylvain Bougerel wrote:
> Hello Jakub,
> 
> I'm not sure I understand exactly but it seems you want to map
> N-dimensional data onto 1 dimension.
> 
> In spatial, there are 3 iterators that will do in-order traversal and
> provide some sort of mapping as a result. I will break them down below, I
> hope it helps.
> 
> 1) point_multiset<>:iterator, box_multiset<>::iterator, etc..
> The basic container's iterator will traverse the tree in-order, from
> left-most to right-most, with complete disregard for the invariant. So
> basically, considering a balanced 1D kdtree (thus looking like a normal
> tree):
> 
>                 4
>           /             \
>      2                     6
>   /     \                /      \
> 1      3              5       7
> 
> => iterating yields: 1, 2, 3, 4, 5, 6, 7
> 
> 2) mapping_iterator<>
> This iterator walks through all nodes as if they had been stored in a
> standard tree over a single dimension (of your choice). Using another tree
> as an example, but this time with 2 dimensions items (dimension ordering
> alternates with each depth):
> 
>                     (4, 1)                            ---- order against
> dimension 0
>              /                   \
>        (2, 4)                 (6, 5)               ----- order against
> dimension 1
>       /       \                 /        \
> (1, 2)   (3, 7)      (5, 3)      (7, 6)
> 
> => mapping iterator against dimension 0 yields: (1, 2), (2, 4), (3, 7), (4,
> 1), (5, 2), (6, 5), (7, 6)
> => mapping iterator against dimension 1 yields: (4, 1), (1, 2), (5, 3), (2,
> 4), (6, 5), (7, 6), (3, 7)
> 
> 3) ordered_iterator<>
> This iterator provides total ordering, in all dimension, such that if the
> same values are inserted into different trees, no matter in which order and
> how they are balanced, the iterator always yields results in the same
> order. With the following tree:
> 
>                     (2, 1)                            ---- order against
> dimension 0
>              /                   \
>        (1, 4)                 (2, 5)               ----- order against
> dimension 1
>       /       \                 /        \
> (1, 2)   (3, 7)      (2, 3)      (3, 6)
> 
> => ordered iterator yields: (1, 2), (1, 4), (2, 1), (2, 3), (2, 5), (3, 6),
> (3, 7)
> 
> 4) Final words,
> if you are looking for an ordering method that preserves locality, I think
> you really are just looking at the first iterator. The other tree are not
> meant to preserve locality, while the container's iterator will preserve
> the order in which the tree has placed each values.
> 
> I hope I was able to help you.
> 
> Regards,
> Sylvain

Re: [Spatial] In-order traversal of the k-d tree

[Sylvain B. <syl...@gm...>]

Hello Jakub,

I'm not sure I understand exactly but it seems you want to map
N-dimensional data onto 1 dimension.

In spatial, there are 3 iterators that will do in-order traversal and
provide some sort of mapping as a result. I will break them down below, I
hope it helps.

1) point_multiset<>:iterator, box_multiset<>::iterator, etc..
The basic container's iterator will traverse the tree in-order, from
left-most to right-most, with complete disregard for the invariant. So
basically, considering a balanced 1D kdtree (thus looking like a normal
tree):

                4
          /             \
     2                     6
  /     \                /      \
1      3              5       7

=> iterating yields: 1, 2, 3, 4, 5, 6, 7

2) mapping_iterator<>
This iterator walks through all nodes as if they had been stored in a
standard tree over a single dimension (of your choice). Using another tree
as an example, but this time with 2 dimensions items (dimension ordering
alternates with each depth):

                    (4, 1)                            ---- order against
dimension 0
             /                   \
       (2, 4)                 (6, 5)               ----- order against
dimension 1
      /       \                 /        \
(1, 2)   (3, 7)      (5, 3)      (7, 6)

=> mapping iterator against dimension 0 yields: (1, 2), (2, 4), (3, 7), (4,
1), (5, 2), (6, 5), (7, 6)
=> mapping iterator against dimension 1 yields: (4, 1), (1, 2), (5, 3), (2,
4), (6, 5), (7, 6), (3, 7)

3) ordered_iterator<>
This iterator provides total ordering, in all dimension, such that if the
same values are inserted into different trees, no matter in which order and
how they are balanced, the iterator always yields results in the same
order. With the following tree:

                    (2, 1)                            ---- order against
dimension 0
             /                   \
       (1, 4)                 (2, 5)               ----- order against
dimension 1
      /       \                 /        \
(1, 2)   (3, 7)      (2, 3)      (3, 6)

=> ordered iterator yields: (1, 2), (1, 4), (2, 1), (2, 3), (2, 5), (3, 6),
(3, 7)

4) Final words,
if you are looking for an ordering method that preserves locality, I think
you really are just looking at the first iterator. The other tree are not
meant to preserve locality, while the container's iterator will preserve
the order in which the tree has placed each values.

I hope I was able to help you.

Regards,
Sylvain


On Sun, Feb 26, 2017 at 8:19 PM Jakub Klinkovský <j....@gm...> wrote:

> Hi,
>
> I'm looking for a library that would allow to do an in-order traversal of a
> balanced k-d tree. This is useful in applications where an ordering of
> points
> preserving spatial locality is necessary, see e.g. this comment on SO:
> http://stackoverflow.com/a/499230/4180822
>
> The Spatial library is by far the closest match I could find as it
> provides the
> "ordered_iterator" and "mapping_iterator" iterators, which sort the values
> along
> a specified dimension. (By the way, what is the difference between these
> two
> iterators?) It seems that the container's "iterator" and "const_iterator"
> do
> some simple traversal of the tree, but is it in-order? Or have I missed
> some
> iterator for in-order traversal?
>
> I'd appreciate any help with this or other suggestions.
>
> Thanks,
> Jakub Klinkovský
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>

[Spatial] In-order traversal of the k-d tree

[Jakub K. <j....@gm...>]

Hi,

I'm looking for a library that would allow to do an in-order traversal of a
balanced k-d tree. This is useful in applications where an ordering of points
preserving spatial locality is necessary, see e.g. this comment on SO:
http://stackoverflow.com/a/499230/4180822

The Spatial library is by far the closest match I could find as it provides the
"ordered_iterator" and "mapping_iterator" iterators, which sort the values along
a specified dimension. (By the way, what is the difference between these two
iterators?) It seems that the container's "iterator" and "const_iterator" do
some simple traversal of the tree, but is it in-order? Or have I missed some
iterator for in-order traversal?

I'd appreciate any help with this or other suggestions.

Thanks,
Jakub Klinkovský

Re: [Spatial] Declaring a metric problem

[Sylvain B. <syl...@gm...>]

Hi Taylor,

It looks like the piece of code you sent is incomplete, could you send me
the source itself (or simply the files involved so that I have a look at
it)? In particular, in the last line, I need to know how you instantiate
"metric".

Btw, looking at the definition of your metric, I saw:

double distance_to_plane(dimension_type rank, dimension_type dim,

                              const coord& origin, const coord& key) {

                                             return 0.0;

                              }


distance_to_plane() should not return 0.0 or you will not find the true
nearest neighbor. It should return the computed distance to the hyperplane
perpendicular to the axis represented by dim and the point origin, and the
point key.


In case of a manifold, like the one defined by the coordinate system Lat,
Long for example, if I have 2 sets of coordinates:


(lat = 0, long = 60) and (lat = 0, long = 61), if I search
distance_to_plane() along the second axis (long), then it should return 1
because I am looking at longitudes at the equator.


for (lat = 90, long = 60) and (lat = 90, long = 61), if I search
distance_to_plane() along the second axis (long), then it should return 0
this time. The reason is that since you are at the north pole (lat=90), all
longitudes are meeting at the same location.


Best regards,

Sylvain

On Sat, Feb 11, 2017 at 3:05 PM Taylor, Wesley <tay...@se...>
wrote:

> Hello,
>
>
>
> We are trying to find  the 5 closest spots from a given longitude and
> latitude. And we are getting a undefined reference.
>
> This is our struct that we defined for our metric
>
>
>
> typedef spatial::point_multiset<2, coord,
>
>                               spatial::accessor_less<coord_acc, coord>>
> tree;
>
>
>
> typedef double distance_type; //[1]
>
>                               double
>
>                               distance_to_key(dimension_type rank,
>
>                               const coord& origin, const coord& key)
> const; //[2], [4]
>
>
>
>                               double
>
>                               distance_to_plane(dimension_type rank,
> dimension_type dim,
>
>                               const coord& origin, const coord& key)
> const; //[3],[4]
>
>
>
>                               double distance_to_plane(dimension_type
> rank, dimension_type dim,
>
>                               const coord& origin, const coord& key) {
>
>                                              return 0.0;
>
>                               }
>
>
>
>                               double distance_to_key(dimension_type rank,
>
>                               const coord& origin, const coord& key) {
>
>                                              distance_type distance;
>
>                                              distance =
> getDistance(origin.lat, origin.lon, key.lat, key.lon, 'M');
>
>                                              return distance;
>
>
>
>                               }
>
>                };
>
>
>
>                This is how we call the neighbor iterator
>
> neighbor_iterator<tree, guacMet> iter = neighbor_begin(container, metric,
> target);
>
>
>
> I do not know hwy we are getting a undefined reference to
> guacMet.distance_to_plane and guacMet_distance_to_key
>
>
>
> Any help would be greatly appreciated.
>
>
>
> Thank you
>
> Wes
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>

[Spatial] Declaring a metric problem

[Taylor, W. <tay...@se...>]

Hello,

We are trying to find  the 5 closest spots from a given longitude and latitude. And we are getting a undefined reference.
This is our struct that we defined for our metric

typedef spatial::point_multiset<2, coord,
                              spatial::accessor_less<coord_acc, coord>> tree;

typedef double distance_type; //[1]
                              double
                              distance_to_key(dimension_type rank,
                              const coord& origin, const coord& key) const; //[2], [4]

                              double
                              distance_to_plane(dimension_type rank, dimension_type dim,
                              const coord& origin, const coord& key) const; //[3],[4]

                              double distance_to_plane(dimension_type rank, dimension_type dim,
                              const coord& origin, const coord& key) {
                                             return 0.0;
                              }

                              double distance_to_key(dimension_type rank,
                              const coord& origin, const coord& key) {
                                             distance_type distance;
                                             distance = getDistance(origin.lat, origin.lon, key.lat, key.lon, 'M');
                                             return distance;

                              }
               };

               This is how we call the neighbor iterator
neighbor_iterator<tree, guacMet> iter = neighbor_begin(container, metric, target);

I do not know hwy we are getting a undefined reference to guacMet.distance_to_plane and guacMet_distance_to_key

Any help would be greatly appreciated.

Thank you
Wes

Re: [Spatial] [spatial:tickets] #4 Default constructor in spatial::accessor_less causes compile error

[Sylvain B. <syl...@gm...>]

Thanks Michal,

I will look into it as soon as I get time (probably next weekend). Are you
able to modify the source to make it work for yourself at the moment? Which
compiler did you use?

Regards,
Sylvain
On 3 May 2015 05:32, "Michał Garapich" <gar...@us...> wrote:

> ------------------------------
>
> * [tickets:#4] <http://sourceforge.net/p/spatial/tickets/4> Default
> constructor in spatial::accessor_less causes compile error*
>
> *Status:* open
> *Milestone:* 2.1.6
> *Created:* Sat May 02, 2015 09:32 PM UTC by Michał Garapich
> *Last Updated:* Sat May 02, 2015 09:32 PM UTC
> *Owner:* nobody
>
> function.hpp:136 -> this constructor leads to compile error, as the call
> to it in spatial_equal.hpp:39 is abiguous. The example about
> point3d_accessor from Quick Starting Guide provides a minimal code snippet
> that leads to the compilation error.
> ------------------------------
>
> Sent from sourceforge.net because spa...@li... is
> subscribed to https://sourceforge.net/p/spatial/tickets/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/spatial/admin/tickets/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>
>

[Spatial] Nearest point in a specific region

[Henrique T. <ht...@te...>]

Hi Silvain,

I am currently working on a project where I need to search for for a
nearest point given a location in a 3d space. Your lib has come in handy
very well (congrats!)

Now I am trying to evolve into a more specific goal, that would be finding
the nearest point in a predefined 3d region. This predefined region would
not necessary be regular nor orthogonal, in fact, it would be similar to a
pyramid.

Given my knowledge of the kd-tree structure, I have an idea of how I could
verify at each step through the tree levels if the generated hyper-plane
excludes or includes such volume (that would be MY problem), however I am
currently experiencing some trouble in how to insert such traverse
intelligence in the existing code.

Would you have any suggestion of how to best define a custom
tree-traversing operation in your kd-tree structure?

Thanks in advance!
Henrique

Re: [Spatial] [spatial:tickets] #2 References to tr1 don't work with C++11

[Sylvain B. <syl...@gm...>]

Thanks, I will look into it!


On Sat, Apr 26, 2014 at 3:49 AM, Ed Baskerville <eba...@us...>wrote:

> ------------------------------
>
> * [tickets:#2] <http://sourceforge.net/p/spatial/tickets/2/> References to
> tr1 don't work with C++11*
>
> *Status:* open
> *Milestone:* 2.1.4
> *Created:* Fri Apr 25, 2014 07:49 PM UTC by Ed Baskerville
> *Last Updated:* Fri Apr 25, 2014 07:49 PM UTC
> *Owner:* Sylvain Bougerel
>
> There are references to various names in the std::tr1 namespace; these do
> not work with C++11. Identified using: Apple LLVM version 5.1
> (clang-503.0.40) (based on LLVM 3.4svn)
>
> Simply replacing all instances of std::tr1:: to std:: makes everything
> work. Thus,
>
> #if __cplusplus <= 201103L
>
> should make it possible to use C++11 as well as TR1 compilers.
> ------------------------------
>
> Sent from sourceforge.net because spa...@li... is
> subscribed to https://sourceforge.net/p/spatial/tickets/
>
> To unsubscribe from further messages, a project admin can change settings
> at https://sourceforge.net/p/spatial/admin/tickets/options. Or, if this
> is a mailing list, you can unsubscribe from the mailing list.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Spatial-main mailing list
> Spa...@li...
> https://lists.sourceforge.net/lists/listinfo/spatial-main
>
>

[Spatial] box_multiset

[Petr K. <pet...@gm...>]

Hi,
I am trying to use Spatial library to store very large set of boxes and
than search through them using point query.

I would like to know, how do I use the box_multiset class. From the
documentation it not clear how am i supposed to
store the box and ho do I use the search for it.


Thank You,

Petr Kotas

[Spatial] Annoncement: Delivery of Spatial 2.0.0

[Sylvain B. <syl...@gm...>]

Dear all,

The new version of the library, that fixes the deep rooted issue with
read/write access on nodes has finally been delivered, after 2 years of
work.

You may think work has been slow, but in fact it has progressed as quite a
constant pace. Yesterday I merged 120 commits from the development branch
to the master branch at once, and completely updated the documentation and
the available packages on Sourceforge.

Of course, it contains much more than the fix, and it is finally the
embodiement of the library as I had envisionned it when I started working
on it in 2009. It provides fractional amortized time removal,
auto-rebalancing on insertion and removal, faster neighbor iterators, more
versatile, and a brand new "ordered" iterator joins the list of iterators.

The documentation is still lacking a bit behind the implementation, but I'm
releasing commits on a daily basis to update it. I'll update the website
weekly.

I strongly advise you to go and check it out:
http://spatial.sourceforge.net/

Warmest regards,
Sylvain

[Spatial] Another test

[Sylvain B. <syl...@gm...>]

Some contents

[Spatial-main] This is a test

[BOUGEREL S. <syl...@as...>]

This is a test on the list...

Sylvain Bougerel