<div dir="ltr">Well, the pipeline code is under reconstruction: Having had to build a large amount of infrastructure while implementing the pipeline code, the pull request ended up somewhat messy, and I closed it,<div><br></div><div>I am now in the process of refactoring in order to first build the infrastructure, then the solution on top of it. The first part appeared as pull request #431 yesterday (cf. <a href="https://github.com/OSGeo/proj.4/pull/431">https://github.com/OSGeo/proj.4/pull/431</a> - I would be thankful for any comments you may have to offer).</div><div><br></div><div>Next steps will probably be to reintroduce the +proj=pipeline "pseudo projection", followed by the elementary operations (Helmert, Horner, Cartesian/Ellipsoidal)., and finally the 3D-transformation program "tran", and some documentation.</div><div><br></div><div>The intention is to make pipelines work transparently also for the original proj.4 2D API calls, and the more recently added 3D calls (pj_fwd3d/pj_inv3d): All the ugly stuff is taken care of inside the pipeline-pseudo-projection driver, so given the transformation intended makes sense in 2D it should work once I get around to polish it up - although the main intention of the work is to facilitate full 3D geodetic transformations in all their glorious convolution :-)</div><div><br></div><div>So Vincent, as Even points out: The pipeline stuff may be what you need - but it is not ready for prime time yet.</div><div><br></div><div>I do, however, believe that the refactoring of the code will make it much more comprehensible, and probably also more stable. But stability is correlated with usage as well, so I will highly appreciate any test efforts and/or guidance you may be able to provide as the work proceeds.</div><div><br></div><div>Best regards</div><div>Thomas</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-05 12:18 GMT+02:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le mercredi 05 octobre 2016 10:21:31, Vincent Mora a écrit :<br>
> Hi,<br>
><br>
> I need to draw terrain sections for several projects (hydrology, geology).<br>
><br>
> The vertical section is defined by a linestring in the (x,y) plane (e.g.<br>
> +proj=lcc). Data in the vicinity of the section are ortho-projected on<br>
> the folded plane with coordinates (s,z), where s is the point location<br>
> on the line (meters or feet).<br>
><br>
> For the moment the CRS part of the QGis plugin we are developping is a<br>
> bit of a hack, and I'd like to introduce that kind of projection in<br>
> proj4 since I believe it belongs there.<br>
><br>
> A projection on a folded plane is rather common, but in this case:<br>
> - the folds are sharp,<br>
> - the projection is not well defined for points that lie on the bisector<br>
> of two line-segments<br>
> - the projection is meaninigless for points that are not in the plane<br>
> vicinity.<br>
><br>
> The proj4 string should contain:<br>
> - the line definition (e.g. +wkt=LINESTRING(...))<br>
> - the classical definition of the CRS of the line,<br>
> - and a thickness (vicinity of the plane)<br>
><br>
> Questions:<br>
> - has such a CRS it's place in proj4 ?<br>
> - do you see obvious errors/misconceptions ?<br>
<br>
</span>Vincent,<br>
<br>
The fact that the line definition can be defined in any CRS handled by proj.4<br>
would make it quite a odd object for proj.4 if we used current mechanisms.<br>
You'd need to have a definition like :<br>
+proj=vertplane +wkt=LINESTRING(...) +wkt_proj=lcc +wkt_proj_lat_1= ...<br>
<br>
Probably a better fit would be to rely on Thomas Knudsen's ongoing work on<br>
transformation pipelines (<br>
<a href="http://osgeo-org.1560.x6.nabble.com/Transformation-pipelines-your-opinion-td5269960.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.<wbr>nabble.com/Transformation-<wbr>pipelines-your-opinion-<wbr>td5269960.html</a> ,<br>
<a href="http://thomasknudsen.net/tran_users_guide.html" rel="noreferrer" target="_blank">http://thomasknudsen.net/tran_<wbr>users_guide.html</a> ).<br>
I'm not sure this has yet landed into master. Perhaps Thomas can confirm ?<br>
<br>
With that framework, I think you could define a 2 stage pipeline :<br>
- first converting from geographical coordinates to LCC projected ones<br>
- then doing the projection onto the vertical plane<br>
<br>
+proj=pipeline +step=lcc +lat_1=... +step +proj=vertplane +wkt=LINESTRING(...) +thickness=<br>
<br>
Regarding QGIS integration, this would require some changes, due to pipeline support<br>
requiring a new dedicated API in proj.4 "TRIPLET pj_apply_projection (TRIPLET point, int direction, PJ *P)" since you cannot use the<br>
existing int pj_transform( projPJ srcdefn, projPJ dstdefn, long point_count, int point_offset, double *x, double *y, double *z )<br>
<br>
By the way, Thomas, wouldn't that make sense to have a pipeline transformation<br>
API that would accept several points at once ? The default implementation could<br>
just loop over them, but that would be a provision for potential later optimizations<br>
where you could potentially vectorize computations.<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br></div>