Geometry Boost List: [ggl] proj4 transformer design approach

Subject: [ggl] proj4 transformer design approach
From: Denis Kurilov (denis)
Date: 2011-05-02 19:51:16

Hi Barend,

 

Thank you for the comprehensive reply, now I better understand the reasons
behind PROJ4 code translation.

 

The compilation times are fine, it was only a minor note. I just wanted to
say that there should be a choose

between inlining and usage of external shared library, as a lot of
applications would prefer second. Imagine a 

situation when third-party component uses projection transformation from
shared PROJ4, and your

component uses a version from Boost.Geometry. Maintaining them together
inside one application is a very 

very bad idea.

 

You have also mentioned the transformation of lines and polygons, this is
probably the most complex thing

about transformation API, as you would need to indicate the accuracy needed
for such transformation (e.g.

how many intermediate points to add to line to transform it precisely enough
without adding of useless points).

Anyway, it will be interesting to read a discussion on that if there will be
any on public.

 

Also, if it is possible, I still would like to ask you to create a task
regarding support of grid-based transformations.

 

A common example is a datum transformation. You can use:

- Molodensky's formula (~5 meters accuracy);

- Bursa Wolf 7 parameter transformation (~1 meter accuracy);

- Coordinate shift grid (generally better than 50mm).

 

As you can see, without support of grid shift files the additional accuracy
provided by ttmath becomes simply 

useless, as the error introduced by transformation model is much higher than
numeric precision.

 

Best regards, 

Denis Kurilov 

 

From: ggl-bounces_at_[hidden] [mailto:ggl-bounces_at_[hidden]] On
Behalf Of Barend Gehrels
Sent: Saturday, 30 April 2011 12:44 a.m.
To: Generic Geometry Library Discussion
Subject: Re: [ggl] proj4 transformer design approach

 

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/20110503/66a5870b/attachment-0001.html