Geometry Boost List: [ggl] proj4 transformer design approach

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

Thanks.

> 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...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110429/f5bd458b/attachment-0001.html