Hi Christian,
I guess this approach doesn't solve the original problem. (test data is too heavy in size).

Now a question for the GeoTools people:
should a single 250K file be "size-acceptable"? I'm asking if having a single 250K zip file to be extracted during tests, could make sense.

Please, before committing other stuff let's find a good solution.

Cheers,
Daniele


On Fri, May 30, 2008 at 4:06 PM, Christian Müller <christian.mueller@nvoe.at> wrote:
I refactored the tests and save 8 MB, now using 7.8 MB.
The changes have been commited.

Renaming will be done next week since I am out of time now

Cheers
christian


Daniele Romagnoli writes:

> On Fri, May 30, 2008 at 3:04 PM, Andrea Aime <aaime@openplans.org> wrote:
>
>> Christian Müller ha scritto:
>>
>>> Some questions:
>>> 1)
>>> Should I rename gt-imagemosaicJDBC to gt-imagemosiac-jdbc ?
>>>
>>
>> This would be consistent with the other modules, so it's a good idea.
>
>
> A small trivial note to avoid misunderstandings: we are talking about the
> directory name within the physical svn repo. (As suggested here:
> http://docs.codehaus.org/display/GEOT/5.2+Naming+Conventions)
>
> Since actually it is imagemosaicJDBC you can rename it as imagemosaic-jdbc.
> (Note that there aren't directories starting with "gt-").
>
>
>>
>>
>>  2) For testing I decided to use 3 pyramids, the third pyramid contains
>>> only 1 image. The biggest dir contains the tiles for the original image,
>>> using 9.6 MB. The whole  src dir needs 16 MB. I found some modules which
>>> have equal size, e.g widgets-swing-pending needs about 15 MB, or the ogc
>>> module.
>>>
>>
>> Wow, this is bad. How can widgets-swing-pending need that much data?
>> Are you sure you're not including in your size count stuff that is
>> generated during the build?
>>
>> Please avoid that, you don't need that much data. You can make a pyramid
>> we a few hundreds of kilobytes, size does not matter for unit testing,
>> and for performance testing, the current 12MB are not enough anyways.
>>
>> The ideal (but this is more work, so nobody is asking you to do so) would
>> be to generate your test data on the fly. I mean, you don't really
>> need a specific image content, so you can just generate buffered images on
>> the fly, draw a number or something inside of them, and save them on the
>> disk.
>>
>>  The tiles for itself will not change. I know the binary file problem from
>>> CVS assuming there are the same problems with SVN. Since mosaicing and
>>> selecting the correct pyramid is the key feature, I need these images for
>>> testing.
>>>
>>
>> The problem is not about how svn handles svn data, but put yourself
>> in the pants of someone that has to check out geotools from a country
>> with slow internet connection. Moreover, I believe there are performance
>> issues in svn when the repository becomes too big.
>>
>> Cheers
>> Andrea
>>
>
> Cheers,
> Daniele
>
> --
> -------------------------------------------------------
> Eng. Daniele Romagnoli
> Software Engineer
>
> GeoSolutions S.A.S.
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 328 0559267
>
>
> http://www.geo-solutions.it
>
> -------------------------------------------------------



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel




--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267


http://www.geo-solutions.it

-------------------------------------------------------