Boost logo

Geometry :

Subject: [ggl] proj4 transformer design approach
From: Denis Kurilov (denis)
Date: 2011-04-27 18:38:40


Hello,

 

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.

 

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.

 

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

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.

 

Best regards,

Denis Kurilov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110428/fc8324d3/attachment.html


Geometry list run by mateusz at loskot.net