[Proj] Virtual File Access

[Greg Troxel]

Paul Kelly <paul-grass at stjohnspoint.co.uk> writes:

> What's to say a gridshift file might not also be user-supplied? What do 
> you do then if you want to use a grid file you've created yourself (e.g. 
> as I did a few years ago: 
> <http://www.stjohnspoint.co.uk/gis/france.htm>), or got from an external 
> source, and don't have root access to install it in the "single correct 
> place"?

Well, if you don't have root, you can build and install proj in your own
directory with a coherent prefix, and you'll have to do that anyway for
various things you want that the system doesn't have..  And proj lets
you set a search path or environment variable.  That's easier than
configuring the faux VFS layer.  So I don't see how this mechanism is
needed or even useful for the use case you describe.

> Or what if you're running PROJ.4 on some obscure embedded system that 
> doesn't have the concept of a conventional filesystem and you need to 
> access the gridshift data over a network connection, or even embed it in 
> the binary?

Probably such systems have some sort of in-ram pseudofileystem, because
the issue of needing to read files is hardly unique to proj.  (The
notion of an embedded system with an os without a filesystem that is
then going to load grid-shift files over the net sounds highly contrived
to me.)  If someone actually has an issue like that, it would be
interesting to hear from them.  But if feels like post hoc positing of
odd situations.

> The solution Frank has implemented looks to me flexible enough to handle 
> any such unusual situations, as long as you write the necessary 
> interface functions to make whatever way you've stored the gridshift 
> data appears to the PROJ.4 library as if its seeking around in a file. 
> Seems to me a lot more elegant than the old pj_set_finder() solution - 
> although for simple cases of the gridshift files being stored in a 
> non-standard directory that's obviously simpler to use.

What I don't like about it is that if feels like reinventing the VFS
layer in a program-specific way.   But I'm not involved enough in proj
to have my opinion count for much, so I'll be quiet now unless I have
something actually new to say
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20130726/b33cd13e/attachment.pgp