# Geometry :

Subject: Re: [geometry] Identifying What all works well with Boost Geometry
From: Tanjot Uppal (tanjot.uppal_at_[hidden])
Date: 2013-06-19 05:10:42

Hi,

>> Dear Boosters,
>>
>> I am looking for some details of features/functionality implemented in Boost
>> Geometry with different geometry types. It would help me identifying what
>> functions work fine with what all combinations and order of geometry types
>> and what is yet to be implemented in 0-Dimension, 1-Dimension and
>> 2-Dimension.
> If I may, I'd suggest to work it out the other way around:
> create matrix or matrices of features and their combinations
> you need (i.e. geometry type vs algorithm, geometry type vs dimension,
> geometry type of dimension N vs algorithm, etc.), post it somewhere
> (i.e. github wiki)
> and then let's try to fill the cells.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
As per the suggestion I have created the attached matrix and also posted
it on GITHUB
(https://github.com/TanjotUppal/Boost-Geometry-Functional-Matrix/wiki).
Would need your help in filling the corresponding cells.
The cells can be filled in with the functions (along with the algorithm
name wherever applicable) that work for the corresponding pair of
geometry types in order considered from left to right horizontally.
*Example:* Suppose if intersects() work for the geometry type pair
"Segment" & "Ring" as well as "Ring" & "Segment", then we should fill in
intersects(Segment,Ring) at {Column=6, Row=4} and
Intersects(Ring,Segment) at {Column=4, Row=6} in the matrix.

>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 18 Jun 2013 13:35:53 +0100
> From: Bruno Lalande <bruno.lalande_at_[hidden]>
> To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
> Subject: Re: [geometry] Identifying What all works well with Boost
> Geometry
> Message-ID:
> <CAB-MWKyGSJF--Nu9isz=kSKCHXYf_SZ0gf80BfA0o4zFjHfA5Q_at_[hidden]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> All our algorithms inherit from boost::geometry::not_implemented in the
> primary definition of their dispatch class, which ensures that not
> implemented calls are easy to detect at compile-time. In addition, we have
> a tool that uses that to produce a report of what's supported for each
> algorithm:
>

>
> Just compile it and run support_status with no argument (passing "qbk" will
> make it output the results directly into the documentation rather than
> output the result in raw text mode). As you can see it only checks 2D
> though, but I don't expect 3D to be difficult to add. You can always play
>
> Regards
> Bruno
> -------------- next part --------------
> HTML attachment scrubbed and removed
I have pulled in the tool and will give it a try, however I dont think
so it would give me what exact is required. Hence I would be obliged if