Geometry Boost List: [ggl] proj4 transformer design approach

Subject: [ggl] proj4 transformer design approach
From: Barend Gehrels (barend)
Date: 2011-04-28 03:15:01

Hi Denis,

Thanks for your ideas, I'll come back to it soon.

Regards, Barend

Sent from iPad.
Barend Gehrels
www.barendgehrels.nl

Op 28 apr. 2011 om 00:37 heeft "Denis Kurilov" <denis_at_[hidden]> het volgende geschreven:

> 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
> 
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110428/d1b02589/attachment-0001.html