[Gvsig_english] Feature request: progress bar when loading big layers

[Marcel Schoolmeesters]

Yep,....better showing an error message than loading wrong layers (e.g. 
either shown in map OR shown in ToC...not in both...)

...perhaps adding the problem of loading layer from wms...there are 
similar problems of empty layers (I think) although the source problem 
there is not the same, of course...


Regards



Am 31.03.2011 19:19, schrieb Cèsar Ordiñana:
> El 31/03/11 18:50, Antonio Falciano escribió:
>>> The question about loading vectorfiles is interesting, I think. As
>>> I've got already problems with raster files @ 25MB...(start parameter
>>> at 256MB)
>>>
>>> I've tested some shapefiles (from http://downloads.cloudmade.com)
>>> with the gvSIG Mobile src running in Eclipse (OS: Windows 7):
>>>
>>>       File: france_highways.shp (size = 336277700)
>>>       Error: "Error while opening file: Not enough memory" =>   no layer
>>>       in ToC, but it is loaded into the map view!??
>>>
>>>       File: spain_highways.shp (size = 185766396)
>>>       Error: same error message
>>>
>>>       File: germany_natural.shp (size = 152891836)
>>>       Error: no problems!
>>>
>>>       File: germany_highways.shp (size = 810905604)
>>>       Error: not enough memory - of course
>>>
>>>
>>> The problems seem to start at about 150MB? Does it depend on the
>>> computer or does it depend on java itself? is there any differences
>>> using gvsig mobile or gvsig desktop (while loading shape files) ?
>> Your test is very interesting and useful for debugging, I think. The
>> bottleneck should depend by a combination of these factors, plus the
>> particular used driver. For instance, I was not able to load a DXF layer
>> of 60 MB on gvSIG Desktop 1.10 today.
>>
>> Cheers,
>> Antonio
> Yes, one of the main factors is the driver, some of them load everything
> into memory (ex: DXF), others read everything from disc (ex: SHP).
>
> I think it's very difficult to define a size limit for vectorial layer
> files, because there are a lot of factors involved:
>
> - Driver type.
> - Geometry complexity.
> - Available alphanumeric data.
> - If any operation has been performed in the layer: symbology, labeling,
> ordering, filtering, etc.
> ...
>
> At least, a better behavior when loading a layer which does not fit in
> memory could be developed, notifying about the error and not loading an
> empty layer. But its only a supposition, some investigation would need
> to be performed to see if it is feasible.
>
> About the progress bar, I agree also. At least a waiting cursor could be
> used.
>
> I think you could create two new feature requests about those two
> problems, so they don't get forgotten.
>
> Regards,
>