[Proj] Re: [kergis_bugs] Re: What proj library version is best?

[Thierry Laronde]

Hello Paul,

On Mon, Jul 05, 2004 at 10:55:15AM +0100, Paul Kelly wrote:
> Hello Thierry,
> (cc to Kergis, GRASS and PROJ lists and Maciek who was also interested in 
> this)
>
[snipped]

While the documentation is still under construction, if you agree I will
put a copy of your message under the "documentation" part of the KerGIS
site, so that people can have access to your explanations (and,
hopefully, so that french people at least can read your page about
projection studies about french systems [1]).
.
This is meant to be a temporary solution since I do believe that I (and
others) need to provide an up-to-date and summarizing documentation
pointing to more in-depth discussion of important points [and once 1.0
is obtained I will focus on the documentation].

And indeed projection management is an essential part of a GIS software
so that is why the proj library has to be provided by KerGIS (and not
put as an external dependency). So from your explanations and my
feelings :
> > 
> > I tend to want to put libproj4 in place of old PROJ.4, but since this is
> > a field you know far better than me I'd like to have your advice.
> > libproj4 is the library minus the programs. But I'm not fear anymore of
> > writing new things or updating old ones...
> 
> Yes well as I said above, I think libproj4 should slot in easily enough to
> any version of GRASS prior to 5.0.0pre4, so that certainly applies to the 4.x
> version KerGIS is based on. Then in the future perhaps datum transformation
> could be implemented with the datum information as attributes of the pj_info
> (i.e. co-ordinate system) struct rather than the PJ (i.e. projection) struct.
> 
> You (or me or whoever ends up making the change) could possibly even re-use
> Frank's datum transformation code from remotesensing.org PROJ, in a
> re-arranged format.

I do prefer this solution of handling datum through attributes via
pj_info since it will allow:

1) a more fine grained handling of conversions without the side-effect
of the PJ integration in the present PROJ.4

2) an extension that will be compatible enough so it can be scheduled
for the 1.x serie of KerGIS.

Since I have already discovered that some of my initial feelings about
future implementations (for example of the textual attributes
management) have to be revised with the understanding I have gained of
the logic of the historical GRASS code, the goal is to experiment,
use intensively and extend to the limits _inside its present logic_ the
4.0 kernel in order to obtain clear indications about what are the
bottlenecks and the impossibilities and how some changes will impact the
whole.

Handling of the datum will be a neat progress, but will not impose a
complete revolution ;) so I'm for it. And there is a lot of good stuff
that can fit easily in the actual base of the code.

> 
> Good luck in the continuing efforts with KerGIS. I know there is a lot of
> background work in tidying up the code structure and preparing it all for
> one day when it will be used by many other developers in diverse GIS projects;
> hopefully this will not be too far away.

Thanks! We are at a couple of months from the whole sources fixed
(alpha-5) but I want to be more conservative with the 1.0 since the
directory tree, the function naming scheme and the organization of the
libraries shall be stable for the 1.x serie and I will try to minimize
the mistakes (the dramatic changes, not in the logic but in the
organization must be done now so that people can rely on stable features
while improvements continue to come in).

Thanks for taking time to answer thoroughly.

Cheers,

1: The projection stuff should be study carefully by all people dealing
with georeferencing, and the comparison and distorsions studies for
example in France with different projection systems ---as is illustrated
by your paper--- should convince people to use libre GIS software to
visualize them, simply because these have practical consequences. 
I once have seen people puzzled because the
establishment on the ground of a building more than 400 meters long was
giving, when verifying the coordinates of the corners, "wrong" results.
The explanation was that the coordinates were in Lambert II, so with a
conformal conic projection i.e. with a projection that keeps the angles
but not the distances. And the establishment on the ground by the
construction industry was using true distance (local coordinates system)
while the surveyor was putting everything in Lambert II. With 400 meters
or more there were several cm of difference...
And going form Lambert II étendu to Lambert-93 should make clear that
great care has to be taken...
-- 
Thierry Laronde (Alceste)  <tlaronde at polynum.com>
http://www.kergis.org/  |  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C