Geometry Boost List: [ggl] proj4 transformer design approach

Subject: [ggl] proj4 transformer design approach
From: Barend Gehrels (barend)
Date: 2011-05-03 12:53:56

Hi Denis,

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

Welcome ;-)

> 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.
>
Yes, I agree fully.

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

The idea is to project all the points of (e.g.) a linestring, than take 
per segment a point in the middle and project it and check the distance 
from that segment. If it is larger than a certain (specified) measure, 
it continues with the two new segments, etc.

So basically a measure which would be exactly the same as for the 
Douglas-Peucker simplify algorithm would stop adding unnecessary points.

It is not worked out more than this, but I think it will work well.

Vice versa, points can also become redundant during (inverse) 
projections, as Hartmut mentioned to me during BoostCon. So if a curved 
line becomes a straight line, we might omit points afterwards. This is a 
bit more difficult (because you only know if after projection, so if the 
work already has been done).

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

Sure, I agree.

Yes, as you noticed, the transformations were not yet done or even 
started with. I will create a "task" (we didn't use the osgeo tasks for 
a while and now are on the point to choose between that or probably just 
a ticket at Boost is a more logical choice).

Thanks, Barend

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