<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 4:55 PM, Greg Troxel <span dir="ltr"><<a href="mailto:gdt@ir.bbn.com" target="_blank">gdt@ir.bbn.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
Frank Warmerdam <<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>> writes:<br>
<br>
> Folks,<br>
><br>
> To smooth out deployment of PROJ.4 at my workplace, I have made some<br>
> changes so that all file access can go through a virtual layer. This<br>
> virtual file<br>
> api looks like the following, and is associated with a "context" (projCtx).<br>...<br>
<br>
</div>This strikes me as adding extra complexity into proj and implementing<br>
features that really belong as a separate package. I'm guessing that<br>
there is something broken about the environment that you are working in<br>
that installing a package to a standard path that has a binary or<br>
library and data files is just too awkward. Is that a windows-only<br>
issue?<br></blockquote><div><br></div><div>Greg,</div><div><br></div><div>Quite possibly there are many things broken about the environment I work in, but running things on windows is certainly not one of them.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
If this sort of thing really is needed, it seems better to have a<br>
package that supports building and accessing files from within a library<br>
as a function that can be hooked into any library's build. PROJ.4 is<br>
not special in needing to read data files.</blockquote><div><br></div><div>It might possibly be nice to have a generic cross platform way for software to hook stdio so as to redirect file access, but that does not seem to be part of the standard C libraries. I'm sure there are libraries which could offer an appropriate indirection api, but I'm hesitant to add dependencies to PROJ.4 without a large need. </div>
<div><br></div><div>But the point I'd like to stress is that I believe it is generally a good practice for low level libraries to provide a way to hook IO so that applications can do a variety of things around file access. Libraries like libtiff, GDAL, shapelib and libpng have done this for a long time. I'm extending it to PROJ.4.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Has anyone else had this problem? On what OS?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What do people do about window installers, in terms of interacting with<br>
(surely there must be) the native packaging system?<br></blockquote><div><br></div><div>I'm not clear exactly what information you are looking for. Normal practice with applications installers using PROJ.4 would be to install the files somewhere in the file system, and to call pj_set_searchpath() to look in the directory in which things were installed from their application initialization. The pj_set_searchpath() and pj_set_finder() were intended to make finding the data files tractable in cases where applications didn't mind writing them to disk. </div>
<div><br></div><div>Best regards,</div></div>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush | Geospatial Software Developer<br>
</div></div>