ThinkGeo.com    |     Documentation    |     Premium Support

GeoTiffRasterLayer Bug

#1

Hello,


I am experiencing a bug with the GeoTiffRasterLayer object type. I am attaching a sample. This error occurs only with GeoTiffRasterLayer so far. I have used Jpeg2000RasterLayer and MrSidRasterLayer in exactly the same manner with total success, so it is definitely something specific to the GeoTiffRasterLayer. It's worth noting that the size of the file I am trying to use is 390MB. I don't have any smaller ones so when testing, it may be best to use a GeoTiff of similar size.


I recieve an "Exception has been thrown by the target of an invocation." error on map.refresh after adding the layer to the overlay. The inner exception reads: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."


I created a project with the path to the file hardcoded and the layer draws correctly. But that won't work for my application. The user must be able to select any TIF they want. So, I resort to using an OpenFileDialog. That seems to be the start of the problem.


When using the OpenFileDialog.FileName as the source of the filepath for the layer, on map.refresh the above error occurs. Please advise..


Thanks,


Nelson



1961-GeoTiff.zip (66.9 KB)

#2

Nelson, 
  
 Thanks for your post and sample code. 
  
 First, in our installer package, we attached a small tif file,  against which you can tested: 
 C:\Program Files\ThinkGeo\Map Suite Desktop Full Edition 3.0\Samples\SampleData\Data World.tif 
  
 I tested the sample with the world.tif and it works fine, even with the OpenFileDialog. I reviewed the code in this sample, could you have a try by removing those locking statements? We do not suggest using lock system in single threaded mode.  
  
 If you still have problem, if possible, could you send us your tif file ? 
  
 Thanks. 
  
 Yale 


#3

Yale, 
  
 Thanks for the suggestions. Removing the overlay.locks had did not remove the exception with my 390MB tif files. However, the World.tif did not cause an exception at all.  
  
 Do you have larger TIFs you can test with? It looks like the world.tif is very small and perhaps file size may have something to do with it. I can try to send you one of our files but it will likely take forever to finish.  
  
 It’s important to note that if you remove the OpenFileDialog from the project and hardcode the path to the file, it adds correctly. I am wondering if somehow the dialog acan be locking the file? I suppose it probably isn’t though because we can use the world.tif with success… Still very strange. Please let me know if you have large TIFs available for testing or if we need to come up with a means for me to send one to you. 
  
 Thanks, 
 Nelson

#4

Nelson,


Thanks for your post and feedback.
 
I spent a couple of hours downloading Sid file from following website, while it seems that their data standard is different , we cannot support it right now.
collections.sdsc.edu/dac2/te...a/onearth/
 
Before sending the data, could you have a try to comment out the second map on the winforms.

'Me.Controls.Add(Me.map2)
Me.Controls.Add(Me.map1)

 
 
If this still cannot work properly , you can contact our support(support@thinkgeo.com) to send me the file to recreate this problem.
 
Thanks.


Yale

#5

Yale, 
  
 I deleted the second map altogether and the problem still persists. I am doubtful I will be able to e-mail a 400MB file, I think our e-mail server has a limit of 16MB in and out. Do you have an FTP server I can try to transfer to? Do you think it will timeout? 
  
 Thanks, 
 Nelson

#6

Nelson, 
  
 That is very strange problem. I did not find anything else very special except 2 map control involved. 
  
 Could you contact our support (support@thinkgeo.com) to provide you a FTP account to upload your data? I am sorry for the inconvenience now. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#7

I’ve e-mailed support for some FTP credentials. Our upload speed is not great so I won’t be able to do this during the day. I will have to wait until we close and then start the upload. I would suggest that if the file isn’t roughly 390MB that the FTP probably timed out. Hopefully not though. I will update this thread after I try to send the file. Thanks again.

#8

Nelson, 
  
 OK, let us know when it is ready and we will test with it.  
  
 Ben

#9

Sorry for the delay guys. I was going to send it late yesterday afternoon, but I completely forgot to ask permission of the data-owners if it would be ok to send it over. I heard this morning that it is infact ok to send one over so probably around 4:30PM-5:00PM EST I’ll begin the transfer. Thanks for all the help again.

#10

It doesn’t matter, just let us know when you think the data is ready :)

#11

I was able to upload the data last night. Please take a look and see if you are able to load the file correctly or not. Thanks.

#12

Nelson, I’ve just got your data and we will start to work on it tomorrow.

#13

Great. I look forward to hearing back. Thanks!

#14

Nelson,


Thanks for your feedback and data.
 
I am sorry to say that I could not recreate the problem with the data provided at least in my current environment (Win7 32 bit). See following code and its corresponding running screenshot by panning map1 to the edge of the raster image.
 
 

2127-ScreenShot_20100603.jpg613×562 123 KB

 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale

2126-GeoTiff_20100603.zip (16.4 KB)

#15

Please test Windows XP Professional 32-bit as that is the system that is generating the erros. I still generate the errors with the attached project. Thank you.

#16

Also, the DLL version I am using is 3.1.299.138.

#17

I hit the same error message when calling the Open method on a GeoTiffRasterLayer (or GdiPlusRasterLayer) to display a TIFF image. 
  
 The difference is that I only encountered the error on x64 environments with Map Suite 3.1.299. The error never occurred on x86 environments. 
  
 The problem seems not to occur with Map Suite 4.

#18

Hmm. That’s an interesting note Daniel. It would be nice to confirm whether this was a bug in 3.1.299.138 that has been resolved as of 4. I have avoided trying to update so as not to run into any breaking changes.

#19

Daniel thanks for your sharing. 
  
 Nelson, I have to say that up to now, I still cannot recreate the problem you mentioned exactly.  While, probably a quick tests is you could pull down the latest DLLs and do a run time tests to see if this problem is fixed in latest package.  
  
  Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale