Ciao Alistair,
please read below...
On Fri, Sep 12, 2008 at 10:02 AM, Alistair Edwardes <
[EMAIL PROTECTED]> wrote:
> Hi Simone,
>
> Thanks for your response. I'm cc-ing this on to the geo-tools users list
> now for any one else who might be interested. So, I succeeded to convert
> your code to use an http url (also for the pyramids), actually it was
> relatively straightforward.
I would be interested in seeing a patch for this in order to check if we can
apply it to trunk or not.
> The problem I was having was caused by closing the InputStreams too early,
> i.e. before I performed the histogram operation on the coverage I had read
> in. I was closing them because I had been using reader.read(null) which was
> quite a stupid thing to do! It opened so many connections my computer seized
> up. Anyway, giving an mbr in the parameters made this manageable,
> particularly when also using pyramids. I didn't really find a particularly
> satisfactory solution for when/how to close the streams though. I didn't
> want to put the close calls in the dispose method since it would mean having
> to construct a new reader every time I wanted to read a coverage, though I
> guess since the overhead of reading the metadata/spatial index is relatively
> low this might actually be the most sensible thing to do.
This makes me think about something I have done lately but not yet
committed, which is the possibility to specify if using JAI ImageRead or
direct ImaegReader read calls behind the scenes. With this option you can
decide to do a straight read, load all that you need in memory at once and
forget about open streams. It might be something you need.
> Instead I added an additional method that closes the open connections,
> though I was loath to do this because it changes the interface. Perhaps you
> have a better idea? I guess standards-wise a WPS implementing the histogram
> operation and a WCS as a data store will be the way to go but for the
> moment a simple static webserver and htaccess gives me everything I need.
>
>
I am working right now on a somewhat similar problem, in order to extract
statistics from coverages stored in GeoServer. WCS is pretty flawed IMHO,
there is no way to get statistics out of a coveraage, there is no way to get
the actual data type for a coverage, there is no way to have a third
dimension which does not have equally spaced values. I am looking at WPS in
order to solve the statistics problem, and I think it should solve your
problem as well. Anyhow, I think that these operations should be probably
part of the WCS interface sooner or later.
Ciao,
Simone.
>
> Cheers Alistair
>
>
> Simone Giannecchini wrote:
>
>> Ciao Alistair,
>> please read below...
>>
>> On Tue, Sep 9, 2008 at 11:35 AM, Alistair Edwardes <
>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>> wrote:
>>
>> Hi Simone,
>>
>> I hope it's okay to contact you directly about this rather than
>> via the geo-tools user list.
>>
>> In principle using the list is a better approach. Other people might be
>> interested in the discussion, moreover we could make it persistent as well
>> which means that later on anyone else can find it recorded in archives :-)
>>
>> I'm using your ImageMosaic plugin within a web service that
>> queries (by point or range) pixel values in discrete coverage
>> (Corine land cover data). I can do this fine if the data are
>> stored on the local file system but now, for various reasons, I
>> want to access the data from a webserver. I've created a set of
>> classes that mirror your ImageMosaicFormat,
>> ImageMosaicFormatFactory and ImageMosaicFormatReader and changed
>> where the code assumes a File to use a URL or stream from a URL.
>> The code seems to run ok and loads the metadata/spatial index and
>> (I think) the tiff files from localhost. However when I query the
>> mosaic, basically using a Histogram operation, I get blank
>> results. Is there any reason you can think why this might occur?
>>
>> Mmmmhh, not right off-the-top of my head. I might have to dig a bit deeper
>> this in order to be of help, probably have a quick look at the code.
>>
>>
>> Also is what I'm doing sensible (probably a wcs solution would be
>> better)?
>>
>> Well, I guess doing the query on a server and just returning the results
>> would be better. With a few more details and a use case (and some coffee as
>> well :-) ) I might be able to propose something performant for this. An
>> enormous flow of WCS is the inability to get statistics on the server data,
>> but you could work this around.
>>
>>
>> I think I was assuming that you only store in memory those tiles
>> that are required for an operation at runtime but it seems that
>> you read every tile in and store the entire mosaic in memory, is
>> that correct?
>>
>>
>> I try to use as less memory as possible. Note however that the histogram
>> operation is untiled, which means it will load whatever are it needs,
>> walking through the input pixel 1 by 1.
>> There is one caveaut. If you are using an inputstream opened from a url it
>> might be that dependending on the underlying ImageInputStreamSPI you are
>> downloading the whole file you working on at once from the server. As I
>> said, I might need to dig the case a bit more deeper.
>>
>> Ciao,
>> Simone.
>>
>>
>>
>> Cheers Alistair
>>
>>
>>
>>
>>
>> --
>> -------------------------------------------------------
>> Eng. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Owner - Software Engineer
>> Via Carignoni 51
>> 55041 Camaiore (LU)
>> Italy
>>
>> phone: +39 0584983027
>> fax: +39 0584983027
>> mob: +39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://www.geo-solutions.it/simone.giannecchini
>>
>> -------------------------------------------------------
>>
>
--
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://www.geo-solutions.it/simone.giannecchini
-------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
