ThinkGeo.com    |     Documentation    |     Premium Support

Deserializing Error for Layer Overlay

#1

Hi,


I've been loading and saving serialized LayerOverlays for several months now and it's become clear in my user base that there are some seemingly random failures to deserialize some files even though the session they worked in showed no failures in the save process.


The error messages are typically as follows:


Object of type 'ThinkGeo.MapSuite.Core.InMemoryFeatureSource' cannot be converted to type System.Collections.ObjectModel.Collection`1[ThinkGeo.MapSuite.Core.FeatureSourceColumn]'.


I have tracked the majority of errors to single layer elements in the serialization file.  I can't say for certain, but I believe in some instances the hash codes are not being written correctly when I serialize the file and this is why it's confused as to converting the inherited member.  The errors typically only occur in files where there are > 1000 layer elements, so possibly some IO issues going on as well.


I have sent 2 example files in a zip file to support@thinkgeo.com with the name of this post as the email subject.  The two files are identical with the exception of 1 layer element named Rx119-2 has been removed.  With this 1 layer element removed, I can successfully read back the file and display in winforms map.


I have also sent in the same email a test project that can be used to load the two files individually so you can trigger the error and see how the good file displays properly.  Since I can't interrogate the GeoSerializer class, I've no idea how to interprete the stack trace or even which line from the input file is causing the problem.


Please look at this as soon as possible.  The failures in saving files people have spent a lot of time working on is resulting in some credibility issues.


Thanks and Regards,


Damian


 



#2

Update: 
  
 Hash code "22170731" is indeed assigned in lines 11081, 11121, 11123 to define the featureSource. 
  
 It is then further referenced in lines 320860 and 320876 to define the featureSourceColumns of the offending layer element. 
  
 So, seems we just need to understand how the GeoSerializer could write out the data in this manner and prevent it from reusing hash codes for different types of objects. 
  
 Regards, 
 Damian

#3

 


Hi Damian,
We have got the zip file you provided, thanks for your detailed information. We can reproduce the issue with your sample and data, the problem is that one FeatureSource and FeatureColumn have the same Hashcode, that’s very weird, normally, we get the hashCode using code “object.GetHashCode()”, one instance should be one HashCode, there shouldn’t be any exception. So we was wondering how to generate a demo serialized string, the attached is the demo what we tried, but all works fine, can you do a check for us if there is anything different with yours? 
Thanks,
Johnny  

Program.zip (1.06 KB)

#4

Hi Johnny,


I've updated your .cs file with what I'm doing.  See attached.


The big difference is that I am sending full Overlays which can each contain many Layers to the serializer.  Your code is just serializing a collection of layers. 


The other thing that I see is that I seem to have left a "var" type for my foreach loop when populating the globalRecord object with Overlays.  This is a remnant from when I used standard MS serializer, but I am guessing VS is able to correctly interprete var to Overlay anyway.


Thanks,


Damian



Program_DH.zip (1.29 KB)

#5

 Damian,


We modified your code a bit to make it running, and everything looks good without any exception. Could you try this modifed code on your machine and let us know what the result is? it will be great if you can provide us a runable program to recreate this issue.


Thanks,


Ben




Program_DH_Modified.zip (1.01 KB)

#6

Ben, 
  
 Fundamentally, nothing’s any different with this code.  Sorry, I wasn’t trying to be programmatically correct with your console app.  Anyway, I am doing some additional testing by making multiple overlays with many layers and trying to read them back with my test utility from above.  I am seeing some indexing issues in the winformsMap control when I use an additional for loop to make 11 overlays with 1000 objects in them.  The file it creates is about 130Mb, so I’ll let you modify and test this on your end. 
  
 Unfortunately, since the save files that are generated with the errors are completely intermittent with the exception of them being large files, there is likely no way I can provide for you an example that writes the error seen previously consistently.  One thing is certain though.  I do have save files where the geoserializer has reused hash codes.  I don’t do anything to the geoserializer output except write it to the FileStream. 
  
 Is there someway we can put a trace on the issue?  Maybe I can interrogate geoserializer prior to writing if you had some kind of test procedure we could run.  Then I could output some debug of the processes that occured prior to write. 
  
 There are some other details as to why this test project would be different than ones generated by my users.  Basically, there is a lot of editing of shapes going on prior to writing a save file.  In the console app you provided, we are just writing out 2000 instances of the same objects which are never edited prior to save.  Are there any properties of shape objects or the winformsMap control which should be set prior to saving?  For example, should a shape layer always be open when saving? 
  
 Regards, 
 Damian 
  


#7

 


Damian,
We are still unable to reproduce the problem what you mentioned that making 11 Overlays with 2000 objects for WinformsMap, and then serializing the “WinformsMap” into “*.txt” file. It created a file about 180MB, the Deserialize works great as well. Can you try the attached demo on your end and let us know if it works fine?
Thanks,

Johnny





GeoSerializer_Test_20120719.zip (3.28 KB)

#8

Hi Johnny, 
  
 I will keep looking for why this occurrs.  So far, no more reports of late. 
  
 One thing to check maybe is that I’ve been using 5.5.155.0 library up until last week.  I’m now on 6.0.0.65.  Is there maybe something between these versions that might make a difference? 
  
 Thanks, 
 Damian

#9

Hello Damian, 
  
 Yes, probably this is the reason, because from 5.5.155.0 to 6.0.0.55, we did a lot of changes and bug fix. 
  
 So feel free to let us know if you still meet this. 
  
 Regards, 
  
 Gary

#10

Damian, 
  
 Hard to say, I guess the "5.5.155.0" is a temporary version from development branch. After that, we did do some changes to the GeoSerializer. Maybe you need abstract the code about serialize out and test it separately.  
  
 Thanks, 
 Johnny