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

Francisco José Peñarrubia fjp at scolab.es
Tue Jan 12 14:29:14 CET 2010 

Yes, this is the behaviour I supposed.

Your idea about looking better to the file and test if it can be "real" 
editable make sense, and maybe done with a few lines of code. Maybe we 
can fix this, if testing people agree.

Come on, go sleep ;-)

Fran.

Simon Cropper (Botanicus Australia Pty Ltd) escribió:
> 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
>>
>>
>>    
>>     
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
>

More information about the Gvsig_internacional mailing list