No subject


Tue Nov 10 08:34:52 EST 2015 

high accuracy geodata results in unexpected and innovative uses, leading to
request for even higher accuracy. In other words: accuracy is addictive.
And without proper geodetic handling of transformations, you will never
consistently approach an accuracy much better than metre level (consistent
with the difference between global and plate fixed coordinates).

Geodetic transformations are typically not algorithmically complex,
compared to what is already included in proj.4 - we just need a platform
for handling the metadata and stringing together elementary
transformations. As already hinted at above, the overall weight of the
functionality will be only a fraction of the existing library.

Form the geodetic side, I see proj.4 with the pipeline extension as the
only viable road to a successful dissemination of the functionality
required. And from the proj.4 side, I see extended geodetic functionality
as the only viable road for continued relevance in an increasingly
always-connected 3D society.

/Thomas

2016-10-13 10:41 GMT+02:00 NDavid <ericnico.david at gmail.com>:

> Sorry for the (very) late reply,
>
> I've read the discussion about this pipelines feature at github and your
> proj4 page and
> I've definitely see such coordinate transformation pipeline as very usefu=
l.
> BUT I'm more incline to keep only cartographic projection inside proj4 an=
d
> to implement
> pipeline and other coordinate transformation outside proj4 in another
> library/librairies.
> And perhaps with a more C++ style than ANSI C.
>
> Some potential coordinate transform that, I think, could fit into a
> pipeline
> are
> - cartographic projection (of course)
> - datum conversion with planar gridshift or use of geoid.
> - unit transform
> - cartesian <-> polar <-> cylindric coordinate
> - temporal transform (gps time to utc time ? )
> - trajectory georeferencing (for point cloud, mobile mapping camera)
> - conversion between sensor coordinate system and platform/IMU
> - ..
> Some of this coordinate transformation need additional data (trajectory
> files, grid files,
> datum/ellispoid dictionnary) and if implement inside proj4 that could lea=
d
> to insert
> into proj4 some dependencies or making it a bigger library.
> And so people who are only interrested in cartographic transformation
> functions of
> proj4 will have to pay for something they don't want.
> I know that pj_transform/cs2cs/pj_apply_gridshift are not only about
> cartographic
> projection but also about datum transform. I understand to keep such
> function
> inside proj4 for historical and compatibility reasons but I don't think
> this
> is
> their "right" place.
>
>  just my 2 cents about this pipeline proposal.
> Nicolas
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/Transformation-pipelines-your-opinion-tp5269960p5290527.html
> Sent from the PROJ.4 mailing list archive at Nabble.com.
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>

--001a114ba91e7eadd7053f5f8e30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Nicolas, I understand, and respect, your opinion, but=
 i disagree for a number of reasons. Let me start with the simplest, and th=
e one I think will probably also be the most convincing counterargument for=
 your major concern (=E2=80=9C...people who are only interrested in cartogr=
aphic transformation functions of proj4 will have to pay for something they=
 don&#39;t want...=E2=80=9D):</div><div><br></div><div>If you take an archi=
tectural look at the proj.4 library, it consists of (currently) 146 differe=
nt projections, each adding in the range of 2-10 kilobytes to the library f=
ootprint.</div><div><br></div><div>The pipeline functionality is typical in=
 that respect: it is organized as a (small) number of additional projection=
s (yes really: the pipeline driver itself is, architectually speaking, just=
 another projection). And, as you can see in the (edited) compilation resul=
t below, the current weight of the pipeline package is only approximately t=
wice the weight of the probably most used projection (the Engsager extended=
 transverse mercator, etmerc):</div><div><font face=3D"monospace, monospace=
"><br></font></div><div><font face=3D"monospace, monospace">$ gcc -I. -W -W=
all -Wextra -pedantic -O2 -c PJ_pipeline.c PJ_horner.c PJ_cart.c PJ_helmert=
.c proj_etmerc.c</font></div><div><font face=3D"monospace, monospace">$ dir=
 *.o</font></div><div><font face=3D"monospace, monospace"><br></font></div>=
<div><font face=3D"monospace, monospace">=C2=A02.655 horner.o</font></div><=
div><font face=3D"monospace, monospace">=C2=A03.576 PJ_cart.o</font></div><=
div><font face=3D"monospace, monospace">=C2=A06.465 PJ_helmert.o</font></di=
v><div><font face=3D"monospace, monospace">=C2=A08.382 PJ_pipeline.o</font>=
</div><div><font face=3D"monospace, monospace">10.733 proj_etmerc.o</font><=
/div><div><font face=3D"monospace, monospace"><br></font></div><div>Let us =
assume that the final pipeline functionality may end up weighing 3 times th=
at, it is still only 6 times the weight of etmerc, and all in all less than=
 10% of the total weight of the library on my test platform (gcc under Wind=
ows 7).</div><div><br></div><div>For these, say, 60 kB, you buy an infrastr=
ucture for implementing a large number of transformations through use of ex=
ternal parameter files, rather than by letting them add to the direct weigh=
t of the library, by implementing them as hard coded projections.</div><div=
><br></div><div>My colleague Kristian Evers and I are in the process of add=
ing proj.4 support for a number of Danish, Faroese and Greenlandic systems,=
 each of which (due to a very large number of parameters) will weigh a subs=
tantial fraction of 60 kB if not implemented using pipelines and external p=
arameter files.</div><div><br></div><div>Hence, I believe that even if you =
have no use for the pipeline functionality, it will cost you only a modest =
amount of additional weight - much less weight than the addition of, say, 1=
0 extra hard coded projections</div><div><br></div><div>Now, add to this, t=
hat the conceptual simplicity of a projection library in comparison to the =
complexity of a full geodetic framework, really is an illusion: While in th=
eory projections are simple (in the sense =E2=80=9Cmathematically well defi=
ned=E2=80=9D) transformations from angular to linear coordinates, in realit=
y they are not at all simple, if you want them to relate to any kind of rea=
l world.</div><div><br></div><div>Evidently, if you only need to relate a l=
atitude/longitude pair in a given horizontal datum, to a set of projected c=
oordinates in the same horizontal datum, a projection library is all you ne=
ed.</div><div><br></div><div>But that is very seldom the case, as also indi=
cated by the fact that NAD27-to-NAD83 transformation was part of the proj b=
undle right from the start, and the fact that sponsors during the years hav=
e found value in sponsoring Frank Warmerdam=E2=80=99s work on implementing =
first horizontal datum shifts, later on also vertical.</div><div><br></div>=
<div>The latter also hints at the fact that today, the vast majority of coo=
rdinate-capture is done by GPS/GNSS, and hence natively 3D, although not ne=
cessarily referred to a system that makes much sense, except for low accura=
cy work.</div><div><br></div><div>To preserve the high geometrical accuracy=
 from the global system, when transforming to a regional reference system (=
e.g. ETRS89) and vertical datum (e.g. NAP/EVRS), you need access to more fu=
ndamental geodetic functionality (although not much more than already inclu=
ded in the pipeline package), before you can finally transform your latitud=
e, longitude, and elevation data into traditional map coordinates, using th=
e projection functionality already existing in proj.4.</div><div><br></div>=
<div>When moving away from the stable parts of tectonic plates, you also ne=
ed support for intra plate deformation models. This is the case for large p=
arts of Scandinavia, which are heavily influenced by post-glacial uplift. U=
sing the pipeline metaphor, this can be expressed in fairly simple terms, m=
aking it accessible to end users through direct support from their domain s=
pecific software, using proj.4 for georeferencing.</div><div><br></div><div=
>From airborne LiDAR mapping, we have learned the lesson, that provision of=
 high accuracy geodata results in unexpected and innovative uses, leading t=
o request for even higher accuracy. In other words: accuracy is addictive. =
And without proper geodetic handling of transformations, you will never con=
sistently approach an accuracy much better than metre level (consistent wit=
h the difference between global and plate fixed coordinates).</div><div><br=
></div><div>Geodetic transformations are typically not algorithmically comp=
lex, compared to what is already included in proj.4 - we just need a platfo=
rm for handling the metadata and stringing together elementary transformati=
ons. As already hinted at above, the overall weight of the functionality wi=
ll be only a fraction of the existing library.</div><div><br></div><div>For=
m the geodetic side, I see proj.4 with the pipeline extension as the only v=
iable road to a successful dissemination of the functionality required. And=
 from the proj.4 side, I see extended geodetic functionality as the only vi=
able road for continued relevance in an increasingly always-connected 3D so=
ciety.</div><div><br></div><div>/Thomas</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">2016-10-13 10:41 GMT+02:00 NDavid <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ericnico.david at gmail.com" target=3D"_blank=
">ericnico.david at gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Sorry for the (very) late reply,<br>
<br>
I&#39;ve read the discussion about this pipelines feature at github and you=
r<br>
proj4 page and<br>
I&#39;ve definitely see such coordinate transformation pipeline as very use=
ful.<br>
BUT I&#39;m more incline to keep only cartographic projection inside proj4 =
and<br>
to implement<br>
pipeline and other coordinate transformation outside proj4 in another<br>
library/librairies.<br>
And perhaps with a more C++ style than ANSI C.<br>
<br>
Some potential coordinate transform that, I think, could fit into a pipelin=
e<br>
are<br>
- cartographic projection (of course)<br>
- datum conversion with planar gridshift or use of geoid.<br>
- unit transform<br>
- cartesian &lt;-&gt; polar &lt;-&gt; cylindric coordinate<br>
- temporal transform (gps time to utc time ? )<br>
- trajectory georeferencing (for point cloud, mobile mapping camera)<br>
- conversion between sensor coordinate system and platform/IMU<br>
- ..<br>
Some of this coordinate transformation need additional data (trajectory<br>
files, grid files,<br>
datum/ellispoid dictionnary) and if implement inside proj4 that could lead<=
br>
to insert<br>
into proj4 some dependencies or making it a bigger library.<br>
And so people who are only interrested in cartographic transformation<br>
functions of<br>
proj4 will have to pay for something they don&#39;t want.<br>
I know that pj_transform/cs2cs/pj_apply_<wbr>gridshift are not only about<b=
r>
cartographic<br>
projection but also about datum transform. I understand to keep such<br>
function<br>
inside proj4 for historical and compatibility reasons but I don&#39;t think=
 this<br>
is<br>
their &quot;right&quot; place.<br>
<br>
=C2=A0just my 2 cents about this pipeline proposal.<br>
Nicolas<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href=3D"http://osgeo-org.1560.x6.nabble.co=
m/Transformation-pipelines-your-opinion-tp5269960p5290527.html" rel=3D"nore=
ferrer" target=3D"_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/Transfor=
mation-<wbr>pipelines-your-opinion-<wbr>tp5269960p5290527.html</a><br>
Sent from the PROJ.4 mailing list archive at Nabble.com.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
Proj mailing list<br>
<a href=3D"mailto:Proj at lists.maptools.org">Proj at lists.maptools.org</a><br>
<a href=3D"http://lists.maptools.org/mailman/listinfo/proj" rel=3D"noreferr=
er" target=3D"_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj<=
/a><br>
</div></div></blockquote></div><br></div>

--001a114ba91e7eadd7053f5f8e30--

More information about the Proj mailing list