Hi Andrea
I have implemented something very similar for importer, when working on an
importer interface that has an upload functionality. Currently, Importer
does provide a way to access all the files associated with a Task (ie.
layer) using the ImportData object, specifically the SpatialFile subclass:
File SpatialFile.getFile()
FileSpatialFile.getPrjFile()
List<File> SpatialFile.getSuppFiles()
The way I implemented this was to do an import against all of the initial
files, then move any files that got imported to the final destination (by
looking at the ImportData of the completed tasks), and finally update the
URL of the store to that destination.
If you are applying the transformations to the files before determining
whether or not to keep them, this feels like a case where the ImportData
may be a better indicator of what files you want to be working with, since
it only deals with a single Spatial file plus any supplementary fles,
whereas some File-based stores may include several sets of shapefiles (This
may not be an issue with raster stores, but I know shapefile stores at
least can include any number of spatial files).
Another thing that I ran into is the case where not all the shapefiles
included in the initial store generated by the importer may get moved to
the final store - they may get cancelled if the transformation failed, or
if the importer threw an error, or they might be excluded from the import
by the user. If we are applying the transform after the import completes
then this is fine, we would only get the files that were actually imported
into the store. However, if we are applying the transform before the import
(At (1), see below), then the store will have all the files, even ones we
may not be importing.
Importer.createContext()
(1) --> Files staged. Store created, does not yet exist in GeoServer
catalog. Store contains all files included in the upload.
Importer.run(context)
(2) --> Files imported. Store created, exists in GeoServer catalog. Store
contains all files that were imported
All this aside, some sort of ResourceInfo.getFiles() sounds like it would
be quite usefull.
TL;DR: SpatialFile.getSuppFiles() in Importer may be closer to what you
want for this specific use case.
Torben
On Wed, May 13, 2015 at 10:47 AM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> You mean, sub-interfaces of ServiceInfo and ResourceInfo, right?
>>
>
> I do.
>
> interface FileServiceInfo extends ServiceInfo {
> /**
> * File or directory providing service content.
> * Optional information provided to facilitate moving, renaming to
> deleting service contents on disk.
> *
> * For services specified by a single directory location check
> individual ResourceInfo.getFiles() for more information.
> *
> * @return files or directory locating service content.
> List<File> getFiles();
> }
>
> interface FileResourceInfo extends ResourceInfo {
> /**
> * File or directory providing resource content.
> * Optional information provided to facilitate moving, renaming or
> deleting resource contents on disk.
> *
> * For resources specified using a directory (such as a tileset) the
> entire directory contents are considered to define the resource.
> * @return files or directory providing resource content
> */
> List<Files> getFiles();
> }
>
>>
>>> I had a question about coverage readers and getSource() - for a moasic
>>> the source probably points to the directory rather than listing all the
>>> files ... is that sufficient for your needs?
>>>
>>
>> This goes beyond the scope I can work on, but for the sake of discussion,
>> for a mosaic I would still list all files, not the directory,
>> as there is no guarantee that the mosaic files are inside that directory,
>> and with netcdf around, you might also have support
>> files in even other places (as in the mosaic in one directory, the netcdf
>> in a second, and the support files in a third)
>>
>
> Interesting, please feel free to modify my proposed javadoc above.
>
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/NWWaa2 for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> -------------------------------------------------------
>>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
