[PROJ] cs2cs in a pipe

[Roger Oberholtzer]

On Tue, Nov 17, 2020 at 1:18 PM Schmitz, Uwe <
uwe.schmitz at bezreg-koeln.nrw.de> wrote:

> Roger,
>
> You didn't post sample code, so I only can guess some things.
> In addition, you haven't written what you have tried so far,
> so maybe the following is not unknown to you.
>
> First, I suppose that you set up a pipe to cs2cs like:
>
> set fid [open "|cs2cs" r+]
>

Pretty much.

Second, to send line by line to the pipe you should do
>
> chan configure $fid –buffering line
>

This is also done. That's why cs2cs reads the first line I send. It is not
buffered out from tcl.

Finally, you have to make sure that the output is not buffered.
> I assume that cs2cs buffers its output. That seems to be your problem,
> I guess. You can verify this by sending say 10000 or more transformation
> lines to the pipe. At some point cs2cs may flush its output and you will
> see
> it by reading the pipe.
> IMHO, there is no way to prevent cs2cs from buffering.
>

I think that's the case. So, I have made my own program for doing this. And
it works. I was just hoping to use an existing program instead of
reinventing the wheel.

But... under Linux you can try unbuffer:
> https://linux.die.net/man/1/unbuffer
>
> E.g.:
> set fid [open "|unbuffer cs2cs" r+]
>

I did not know about this program. I don't see how it can make cs2cs change
it's behavior.


> If you really consider using the bare C-Api, I recommend
> using the great Ffidl package:
>
> https://wiki.tcl-lang.org/page/Ffidl


We already use the C API in a library that simplifies access to proj for
our use. I will actually be using that in the program.

I wonder how one defines proj data structures in a useful way for Ffidl.
That seems like an interesting task. We have done similar things with SWIG.
I'm not a fan of how SWIG accesses shared data structures in tcl. So we
have usually written our own C interface between Tcl and the rest of the
world as needed. Mainly because of tracking changing data structures (the
C/C++ ones).

Thanks for the information!

-- 
Roger Oberholtzer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201118/c42ebbe6/attachment.html>