ThinkGeo.com    |     Documentation    |     Premium Support

OGR-Feature-Layer showing MapInfo-File crashes application

#1

Hello (Yale),


another OGR-FeatureLayer issue.


If I display MapInfo-File with OGR-FeatureLayer the application throws an error after I performed some map actions (zooming, panning).


I have made a sample application I send you through ThinkGeo-Support.


To create that error please perform some action on map control  - e.g. pan, zoom in/out, switch map to full screen.


 It seems the error is not thrown if i change the following line in my custom FeatureSource.



oFeatureCollection = m_oOgrFeatureSource.GetFeaturesInsideBoundingBox(boundingBox, ThinkGeo.MapSuite.Core.ReturningColumnsType.AllColumns)



 


to



 


 


oFeatureCollection = m_oOgrFeatureSource.GetFeaturesInsideBoundingBox(boundingBox, ThinkGeo.MapSuite.Core.ReturningColumnsType.NoColumns)



Thanks Thomas



#2

Thomas, 
 This problem is caused by the threading stuff in third library, if we force the application to run only in one thread, should fix the problem. 
  
 I will send you the code snippet to solve the problem via email. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 
  


#3

Hello Yale, 
  
 I tried your code in my sample application in single thread mode and also multithread mode. But the error still exists. Is this really a threading problem? Remember-  if I change my code to return no column data, I don’t get any error. 
  
 oFeatureCollection = m_oOgrFeatureSource.GetFeaturesInsideBoundingBox(boundingBox, ThinkGeo.MapSuite.Core.ReturningColumnsType.NoColumns) 
  
 Thomas

#4

Thomas, 
  
 As far as I understanding, the difference between the two APIs is whether to get the extra information except the shape, which will cause much difference in performance. The exception is easily to be thrown out when it is very slow to get the data when achieve. 
  
 We have a post related with the FDO threading stuff, and I tested the sample in the same way, and found that the exception will not be thrown out even though I get features with AllColumns. You can have a try if you are interested. 
 gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/7442/afv/topic/Default.aspx 
  
 The code I sent to you via email seems the way to force the application in only one thread. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#5

Yale thanks for information. 
  
 This is no good news. I tried your suggestion in related post gis.thinkgeo.com/Support/Dis...fault.aspx and the error is not thrown any more. 
 At last this means your code you send to me to force the application to run in one thread did not work. Moreover I dont want to force my application in one thread mode. This may be a good solution for a sample application but nor for productive end user application. Our application is an ERP-System for public transport where the GIS-Modul is only one part of the whole system. So I don’t want to use the single thread solution for whole system. 
  
 For now I will work without the column data and have to think about conversion to shape file. 
  
 Thanks Thomas

#6

Thomas, 
  
 Thanks for your sharing. 
  
 We may will upgrade the FDO library to V3.5 in future, which probably has solved this problem. And I will try to let you know after that.  
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
   
 Yale 


#7

Thomas, 



Just to let you know we found a way to set the affinity in code. Just add the following line in your app (C#) and you can make it woking only on one Core. 



Process.GetCurrentProcess().ProcessorAffinity = (System.IntPtr)1; 



Sure we are still looking for the "real solution" to make the FDO support multi cores. 



Thanks, 



Ben



#8

Hello Yale,


I implemented your suggested code and it seems to work fine. Although I would prefer a multi core solution. Maybe with newer version of OGR library.


Thanks Thomas



#9

Thomas, 
  
 Thanks for letting us know your status; we will also keep an eye on the new version of FDO library. 
  
 Thanks. 
  
 Yale