Geometry Boost List: [ggl] Projections: Patch to get access to parameters

Subject: [ggl] Projections: Patch to get access to parameters
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-06-17 04:58:12

Hi Chris,

>
> I have a patch that adds a "params()" function to the projection 
> class, to return the projection parameters.
>
> Rationale:
> - I need access to the parameters for the pj_transform
> - I need access to the "is_latlong" member of the parameters.
> - It makes it easier to port proj4-specific code to ggl.
>
> The patch only touches the "base..." files, so I don't think it 
> clashes with the automatic generator.
>
> Problem:
> - As I don't have the "parameters" template parameter in 
> projection.hpp, it is hardcoded.
Sounds perfect. I'm glad there is interest in the projections. Note that 
(besides that the whole library is still in 'preview' phase) this 
projection stuff is implemented and tested by unit-tests, but not yet 
used in practice, as far as I know. So thanks for your efforts!

Note also that it will change. The ellipses and earth models, for 
example, will be Concepts which can be extended or provided by library 
users, and harmonized by the spherical distance functions in the 
algorithms/strategies. Furthermore there were some remarks about the 
"proj4-like" parameters. You profit from it but we also need to give an 
alternative to non-proj4 users. We want to support WKT-projection 
configurations as well.

>
> BTW, I don't quite get the reasoning behind templatizing the 
> "parameters" struct... It's quite static and expected by all proj4 
> related functions. It only obfuscates/complicates the code, IMHO.
Sure, this was done because the reasons above, the parameters structure 
is not completely worked out. It can change.

>
> Do you think I should commit this as it is?
That is no problem.

>
> Furthermore, I also have a pj_transform ("+towgs84" support only) but 
> only in "hack" state. Would you want me to try to "GGL-ize" it 
> further, time permitting?
Nice word, "GGL-ize". Yes, the transform is very welcome! You might look 
at the generic "transform" function and try if it can be implemented as 
a strategy.

Thanks for all. Can you, by the way, already see if the clipping of 
polygons (without holes) is completely solved now?

Regards, Barend