Subject: [ggl] proj4 transformer design approach
From: Denis Kurilov (denis)
Date: 2011-04-27 18:38:40
I have recently found an information about upcoming release of GGL in Boost
1.47, it is
great that now such a generic library will be available for public without
an overhead that could
be found, for example, in GEOS.
However, I wonder about the approach that is used for design of geographic
transformations extension. PROJ4 is widely used shared library, it is really
not good to
"link it statically" (e.g. to use your code translation approach).
I can imagine that the reasons are Boost policy for external libraries. But
look, your translated
PROJ4 code is header-based, it really hurts the compilation times. Another
thing is that your
translated proj4 does not handle grid transformations, it are vital for many
The question is - how do you think, will the following approach be more
natural for users:
- Leave proj4 as external shared library, do not translate anything;
- Implement a projection transformation extension base as a part of a
- Implement a proj4-based transformer (that is a thin wrapper around
put it into a library "examples" folder.
The same is applied to IO and indexing extensions. Users would be happy to
use the SVG
Library on their preference, as well as spatial index implementations.
There is at least one library in Boost that have employed the same design
decision at early stage,
and now, after years of releases and bugfixes it is a nightmare to change
anything in core.
I mean boost::serialization and its ability to serialize into XML or binary.
>From my experience,
there are a lot of people who wants to link boost::serialization with, say,
libxml2, or with
Google Protocol Buffers, but the complexity of internal library design
prevents them from
Hope your library will employ a more flexible approach. The PROJ4 IMHO is a
first priority in
compare to IO and spatial indexing.
-------------- next part --------------
An HTML attachment was scrubbed...
Geometry list run by mateusz at loskot.net