[Gvsig_english] QUESTION gvSIG 1.9 (BN 1253) -- Hoes does gvSIG reference shapefiles in ToC

Tue Jan 12 14:17:05 CET 2010

Fran,

I tried this 3-way.

The same layer open in gvSIG, ArcView and OpenJUMP. None complained.

Started editing in all the programs simultaneously, still no complaints.

Start changing data and eventually a Java Heap Error and the file become 
corrupt.

Cheers Simon

Simon Cropper
Botanicus Australia Pty Ltd
PO Box 160, Sunshine, Victoria 3020.
P: 9311 5822. M: 041 830 3437.
mailto: scropper at botanicusaustralia.com.au 
<mailto:scropper at botanicusaustralia.com.au>
web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au>

On 12/01/2010 9:20 PM, Francisco José Peñarrubia wrote:
> Hi Simon.
>
> I'm wondering if you sleep some time.... ;-)
>
> I mean: to workarround the problem (yes, it can be seen as a bug), you
> shouldn't edit a shape file (or another layer like PostGIS) if you have
> more than one instance in your view (or in another view). Even I would
> say if other person is reading this file, he will have problems.
> gvSIG can edit, and is intended to use to that, but is not prepared
> (yet) to be a concurrent editor.
>
> About adding fields and drivers autonomy.... It depends if the driver is
> opening-reading-closing all the time, which is a time consuming task.
> The driver may not read always the number of records, or use some
> buffering that will not be synchronized with the other drivers. That's
> why you will end with Java Heap crashes. Maybe the solution can be to
> use the same driver object, but these things will change in 2.0 release,
> so, I think we cannot dedicate more time to this issue. That's why I
> suggested the workarround.
>
> Best regards.
>
> PS: About concurrent modification and multi user editing, I have some
> old ideas to develop, but honestly, I don't have time for now.
>
> Fran Peñarrubia
> gvSIG Team
>
>
> Simon Cropper (Botanicus Australia Pty Ltd) escribió:
>    
>> Fran,
>>
>> "So, you shouldn't edit your file [2], and about names, you can change manually the name of the layer. Maybe some errors will disappear then [1]."
>>
>>      [1] I tested having all the names the same and different. This is
>>      not a problem. The trigger appears to relate to symbology and
>>      labeling when two instances of the same shapefile are in the ToC.
>>
>>      [2] How can you "not edit a file" in gvSIG, isn't this what it is
>>      for? If having multiple instances in the ToC causes a crash then
>>      this is a bug.
>>
>>
>> "If you edit one of them [3], the others will not be aware of changes, and the application will crash."
>>
>>      [3] If you add a field in one instance, it appears in the other
>>      instances, so the drivers can't be that autonomous.
>>
>> I will watch this behaviour and report it as a bug once I can pin down the causal factor.
>>
>> Cheers Simon
>>
>> Simon Cropper
>> Botanicus Australia Pty Ltd
>> PO Box 160, Sunshine, Victoria 3020.
>> P: 9311 5822. M: 041 830 3437.
>> mailto: scropper at botanicusaustralia.com.au
>> <mailto:scropper at botanicusaustralia.com.au>
>> web: www.botanicusaustralia.com.au<http://www.botanicusaustralia.com.au>
>>
>>
>> On 12/01/2010 8:19 PM, Francisco José Peñarrubia wrote:
>>
>>      
>>> Hi Simon.
>>>
>>> Yes, I think so.
>>>
>>> If you have multiple shp files in TOC, each one will have its own driver
>>> reading from the .shp, .shx, .dbf files. If you edit one of them, the
>>> others will not be aware of changes, and the application will crash.
>>> So, you shouldn't edit your file, and about names, you can change
>>> manually the name of the layer. Maybe some errors will desappear then.
>>>
>>> BTW, I sow (among many others ;-) ) some mails about FrameViews in a
>>> Layout. (Some FrameViews referring to the same View in the same Layout).
>>> I did some tests and I agree there are many bizarre behaviours, but I
>>> wonder if you are using the tools
>>>
>>>
>>>
>>> to position your ViewFrame from the Layout window. They are activated
>>> when you select your ViewFrame.
>>>
>>> To summarize: If I remember to ALWAYS (it's a bug) select the right View
>>> in the combo from Properties and uncheck Active Link and select Mantain
>>> View Scale, it seems it works well. (Any other combination don't work
>>> well and we should revise it).
>>>
>>> Thanks for your time, and keep going.
>>>
>>> Fran
>>>
>>> Simon Cropper (Botanicus Australia Pty Ltd) escribió:
>>>
>>>
>>>        
>>>> Hi,
>>>>
>>>> When you have multiple instances of the same shapefile in the Table of
>>>> Contents how does gvSIG know which your are referencing with the
>>>> extensions or plug-ins?
>>>>
>>>> I presume it would need to be as "ToC layer #1", "ToC layer #2", "ToC
>>>> layer #3" rather than referencing by name as the ToC allows you to add
>>>> multiple instances of the same shapefile.
>>>>
>>>> I have had a lot of java heap errors since presenting multiple instances
>>>> of the same shapefile in the ToC and creating separate labeling and
>>>> symbology for each. I suspect that some subroutines don't explicitly
>>>> reference the ToC list but rather the file name if that is possible.
>>>> Crashes appear to centre around labeling and symbology issues. One wierd
>>>> thing I have noted is the propensity of the "other values" option keeps
>>>> reappearing even though I have it unchecked - particularly if I edit a
>>>> file. That is, "other values" will be unchecked but when I edit the
>>>> shapefile it reappears.
>>>>
>>>> The question then is "Could the presence of multiple instances of the
>>>> same file in the ToC, each with differing labeling and symbology, cause
>>>> a memory leek?"
>>>>
>>>>
>>>>
>>>>          
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at listserv.gva.es
>>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>>
>>>
>>>
>>>
>>>        
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at listserv.gva.es
>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>>
>>      
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>
>
>    