Boost logo

Geometry :

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


Geometry list run by mateusz at loskot.net