Boost logo

Geometry :

Subject: [ggl] proj4 transformer design approach
From: Barend Gehrels (barend)
Date: 2011-04-29 08:43:53

Hi Denis,

> 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 projections
> 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 local projections.

First note that the projections are still an "extension", and that the
extensions will not yet be part of the release. The reason for this is
that the interface might change, or that the pieces are not completely
developed yet. So things might change here.

Second, the conversion to C++ is good for performance. Our header-based
translated code runs about 10% faster than the original PROJ4, IIRC.
That is not too much but it might be a difference for some applications.

Third, and more important, Boost.Geometry is independant on number type.
So we calculate with floats, doubles or other (e.g. high precision)
arithmetic number types, such as ttmath. We can therefore supply high
precision arithmetic in projections, which can be potentially quite
important for some applications. It is then probably the only projection
library offering that.
Note that this is not yet supported because the conversion does not
replace any found "double" intermediary type by other (templated) types,
but I did it once manually so I know that it basically will work.

Fourth, if I'm going to work again on the conversion, it might also be
possible to output other languages, e.g. C#, and it would be great to
have a native (managed) .NET projection library as complete as proj4 is.
Didn't start on it but I think it should be feasable. So the C++
translation can be seen as "native C++", the original is "native C".

Fifth, (this is not important to have it as it is, but a side effect),
during writing the unit tests for our translated projections, by
projecting forwards and inverse, I found and reported four errors in
PROJ4 (in the inverse projections), which are all solved now.

Sixth, the plan is to project not only points but also lines and
polygons where a straight line will be converted into a curved
linestring (or vice versa). This is also possible by using it as an
external shared library, but we might have more control.

Seventh, using a EPSG coordinate system, we might be able to calculate
the distance between two points in different projections, where the
inverse right projection is (statically, compile time) selected for
them, and applied on the fly (and distance calculated over the earth).
This is probably also possible by using it as an external shared lib,
but not compile time.

Compilation times are indeed higher because of header and template
approach. I don't know if you have tried it, it is not that long, I
found it quite reasonable.

> 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
> library;
> -Implement a proj4-based transformer (that is a thin wrapper around
> PROJ4) and
> put it into a library "examples" folder.

Yes, this is possible. It is perfectly possible to support both: the
translated code (we have them, and have the translator) and the
externally linked code which might keep other users happy.

Actually I think I ever started with that proj4-based transformer in the
examples folder, and then thought it is better to translate it (for some
of the reasons I listed above).

> 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.

The SVG code is not using an external library, I all wrote this
manually. It is not large, by the way, just transforms and writes text
in SVG-format. It has been proven very useful both in tests, samples,
and in real-life applications.

The spatial indexes are currently being implemented by Adam, as you know
from this list. But yes, it should be possible to use external indexing
libraries as well.

> 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
> doing it.
> Hope your library will employ a more flexible approach. The PROJ4 IMHO
> is a first priority in
> compare to IO and spatial indexing.

Nice you are that interested in them. And it will get attention. But,
measured to traffic on this list and the Boost list, most people are
asking for the spatial indexes.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at