Subject: [ggl] proj4 transformer design approach
From: Barend Gehrels (barend)
Date: 2011-05-03 12:53:56
> 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.
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).
-------------- next part --------------
An HTML attachment was scrubbed...
Geometry list run by mateusz at loskot.net