MapSuiteFdoExtensionx64 version 3.7 throws an exception

Richard5 · March 22, 2016, 7:27am

We are in the process of upgrading our application from x86 to x64. We use MapSuite Desktop Edition and I currently have the daily Production build 6.0.0.352. I can seem to get the MapSuiteFdoExtensionx64 merge module which is built with version 3.7 of the Gdal to run. I am attempting to open a "ADRG" map file as a GdalRasterLayer. Below is a stack trace from the exception:

[10] 2013-05-13 11:06:23,111 ERROR STTI.FAC.MapControl2d.MapControl2DMapSuite Unable to Load a Map Layer. Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> OSGeo.FDO.Common.Exception: FDO Provider 'OSGeo.Gdal.3.5' Not Registered

   at OSGeo.FDO.IConnectionManagerImp.CreateConnection(String providerName)

   at MapSuiteFdoExtension.GeoFdoRasterSource.Open(String providerName, String connectionString, String featureSchemaName, String featureClassName, String rasterColumnName)

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)

   at ThinkGeo.MapSuite.Core.FdoRasterSource.OpenCore()

   at ThinkGeo.MapSuite.Core.RasterSource.Open()

   at ThinkGeo.MapSuite.Core.RasterLayer.OpenCore()

   at ThinkGeo.MapSuite.Core.Layer.Open()

   at STTI.FAC.MapControl2d.MapControl2DMapSuite.OpenLayer() in D:\P4V\richard.styer_STTI_dev\STTI\Trunk\MapControl2d\MapSuiteSrc\MapSuite.PrintExtensions.cs:line 589

I have also attempted to open the "ADRG" file using a daily development build 6.0.311.0 but it also thrown an exception:

[10] 2013-05-13 09:41:19,698 ERROR STTI.FAC.MapControl2d.MapControl2DMapSuite Exception in Timer Tick event while refreshing the Map2D. Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Can not read the image file.

   at MapSuiteFdoExtension.GeoFdoRasterSource.GetScaledBitmap(Double centerX, Double centerY, Int32 overlapWidth, Int32 overlapHeight, Int32 returningWidth, Int32 returningHeight)

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)

   at ThinkGeo.MapSuite.Core.FdoRasterSource.rBM=(Double rRM=, Double rhM=, Int32 rxM=, Int32 sBM=, Int32 sRM=, Int32 shM=)

   at ThinkGeo.MapSuite.Core.FdoRasterSource.GetImageCore(RectangleShape worldExtent, Int32 canvasWidth, Int32 canvasHeight)

   at ThinkGeo.MapSuite.Core.RasterSource.GetImage(RectangleShape worldExtent, Int32 canvasWidth, Int32 canvasHeight)

   at ThinkGeo.MapSuite.Core.RasterLayer.DrawCore(GeoCanvas canvas, Collection`1 labelsInAllLayers)

   at ThinkGeo.MapSuite.Core.Layer.Draw(GeoCanvas canvas, Collection`1 labelsInAllLayers)

   at ThinkGeo.MapSuite.DesktopEdition.LayerOverlay.DrawCore(GeoCanvas canvas)

   at ThinkGeo.MapSuite.DesktopEdition.Overlay.rRM=(GeoCanvas rhM=)

   at ThinkGeo.MapSuite.DesktopEdition.Overlay.Draw(GeoCanvas canvas)

   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.1BU=(IEnumerable`1 1RU=)

   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.0hU=(RectangleShape 0xU=)

   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.IRY=()

   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.HRY=(Int32 HhY=)

   at ThinkGeo.MapSuite.DesktopEdition.WinformsMap.Refresh()

   at STTI.FAC.MapControl2d.MapControl2DMapSuite.timerRefresh_Tick(Object sender, EventArgs evtArgs) in D:\P4V\richard.styer_STTI_dev\STTI\Trunk\MapControl2d\MapSuiteSrc\MapSuite.EventHandlers.cs:line 69

I can get the "ADRG" file to display if I regress back to the MapSuiteFdoExtension using the Gdal 3.5. However I have to add the following to the app.config file:

because of the following exception:

[11] 2013-05-13 09:46:44,455 ERROR STTI.FAC.MapControl2d.MapControl2DMapSuite Unable to Load a Map Layer. Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

at MapSuiteFdoExtension.GeoFdoRasterSource.Open(String providerName, String connectionString, String featureSchemaName, String featureClassName, String rasterColumnName)

--- End of inner exception stack trace ---

Does anyone have any idea why the GDAL 3.7 is giving these exceptions? I assume that since I can get the newer FDO merge module to run with either a Development or Production build that I will not be able to upgrade to MapSuite Desktop Editon 7.0.0.0 when it becomes available.

Thanks for any input.

Richard

Richard5 · March 22, 2016, 9:17am

sorry the change to the app.config was stripped out of the original post.

startup useLegacyV2RuntimeActivationPolicy="true">
     supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
     requiredRuntime version="v4.0.20506" />
   </startup

Johnny · March 22, 2016, 9:17am

Hi Richard,

Thanks for your post and sorry for the inconvenience, would you please send us the “ADRG” file to test. Also can you let me know the configuration of your test OS and project?

Waiting for your further information.

Johnny

Richard5 · March 22, 2016, 9:17am

Johnny,

Thanks for the quick response.

You will have to tell me how I can upload a large file to you. I zipped the ADRG file and it is still 500MB. I tried to attach it using the Attachments and upload on the page below but the upload so goes into a wait with the spiraling wait cursor and never comes back.

As far as the configuration, I am not sure what you need. We are running on Windows 7 Professional SP1 as 64-bit OS. We build using Visual Studio 2010 SP1 C# as a .Net 4.0 application. I am building with MapSuite Desktop Edition and as stated above I have tried the Daily Production Build 6.0.0.352 and Daily Development Build 6.0.311.0.

Our application uses the winformsMap control with GoegraphyUnit.DecimalDegree. I do not currently have the Baseshape.GeometryLibrary = GeometryLibrary.Managed enabled in our application (it does not work with Daily Production build). We use the WorldMapDataKit loaded locally with WorldMapKitRenderLayer to render the map (we are not connected to the internet).

I am using the following to load the ADRG layer:

                        GdalRasterLayer layer = new GdalRasterLayer(sFilePath);

                        layer.Open();

                        layer.Name = layerName;

                        // Set the fullExtent to layerBoundingBox.

                        if (layer.HasBoundingBox)

                        {

                            fullExtent = layer.GetBoundingBox();

                        }

                        staticLayerOverlay.Layers.Add(layer.Name, layer);

                        layer.Close();

winformsMap1.Overlays.MoveToTop(staticLayerOverlay);

winformsMap1.Refresh();

Let me know if you need any additional information.

Richard

Let me know

Johnny · March 22, 2016, 9:17am

Hi Richard,

Thank you very much for providing the further detailed information, seems like all are what we are looking forward to. To upload a big file, can you contact support@thinkgeo.com to let them to open a FTP address for you?

P.s. after uploaded successfully, can you let support guys forward the address to me?

Thanks,
Johnny

Johnny · March 22, 2016, 9:17am

Hi Richard,

Thanks for uploading the test data, we have got it and now we are working on it, any workable solution is avaiable, I will update it here.

Regards,
Johnny

Johnny · March 22, 2016, 9:18am

Hi Richard,

Thanks for your data, but we met a problem while unzip it shown in following picture, we tried several times, but always failed, can you do a double-check of the data?

We clicked “skip”, but the data can’t be open.

Waiting for your futher information.

Johnny

Richard5 · March 22, 2016, 9:18am

Johnny,

I’m sorry that the file will not unzip for you.  I tried to unzip it from the location that I copied from during the ftp and it unzips and looks fine on my end.   I believe there must have been some problem during ftp that corrupted the file.  I did you the Win 7 Professional built in zip application to make the zipped file.  I don’t know if the Microsoft zip applicaiton has any incomptibilities with only zip applications.

I guess all we can do is try the ftp process over again.  Do I need to contact someone to get access to your ftp again?

I don’t know what order the files in the ADRG folders are unzipped.  There are three separate “img” files in this ADRG with supporting files for each.  Since the failure above is indicating that it failed during the 2nd “img” maybe you have enough files unzipped to display the 1st image.  There was some bug in the open source FDO code for release 3.5 that only displayed the 1st “img” anyway.  We were hoping that version 3.7 would have fixed this problem but instead it doesn’t seem to work at all with this ADRG file.  I had worked with your support on this issue before and we were just waiting for version 3.7 to see if the original issue would be resolved.  If all the supporting files are there for the 1st “img” you might be able to test without the 2nd and 3rd “img”.

Richard

Johnny · March 22, 2016, 9:18am

Hi Richard,

The ftp can still be used, new ftp is not needed. And I also tried only load JNUS0101.GEN, but the file still can’t be open.

Following is the upziped files, would you please check if IMG1’s files are all in there?

Waiting for your further information

Johnny.

Richard5 · March 22, 2016, 9:18am

Johnny,

If all of the files which show sizes contain all their data, the only files missing are JNUS0102.IMG and JNUS0103.IMG. These are the second and third "img" so it appears the first "img" is complete. As long as the TransH01.THF file is good in the directory above the one you have shown, and the subdirectory JNUS0101 contians the 5 "L01" files then I think you should be able to the use the first image. I have not verfied that this works and I am not an expert on ADRG but I think it is worth a try.

I do have a smaller ADRG file from Alaska if this one is not good. The Alaska file only has one "img" in it. I would need to have the ftp connection again to upload it.

Thanks for your help.

Richard

Johnny · March 22, 2016, 9:18am

Hi Richard,

Thank you very much for for the data and your detailed information. I guess we have recreated your problems on our end, but sorry that I guess it’s a complicated for us to resolve it in a short time, these days we are busy with upcoming 7.0 release and have frozen the code, besides, we don’t have enough resource now, would you please wait some time and we will try doing more investigations after release. Sorry for the inconvenience.

Best Regards

Johnny

Richard5 · March 22, 2016, 9:18am

Johnny,

Yes, it is okay that you take the time to investigate. We have our application working with FDO extension merge module that was first delivered with the 6.0.0.0 using OsGeo FDO 3.5. We will just be stuck with this version until we can get the 3.7 version to work as well as the 3.5 and hopefully it will work better.

Thanks for all of your effort.

Richard

Johnny · March 22, 2016, 9:18am

Hi Richard,

I guess we still need more days to work on it. We will update the states once we fix it.
Thanks for your understanding.

Thanks,
Johnny

Richard5 · March 22, 2016, 9:18am

Johnny,

I have uploaded the TempResult50001.zip to the ThinkGeo ftp site. You should be able to extract the file from the zip and use that with DisplayIsoLines. It should contains a grid which is about 2750 x 2100. This causes it to take over six minutes to zoom or pan the map once the isoline layer, labels, and background color layer (FeatureLayer) are displayed. I haven’t timed it if only the Isoline layer is defined. It should be less than siz minutes but I’m not sure how much.

Thanks for looking at this.

Richard Styer

Johnny · March 22, 2016, 9:18am

Hi Richard,

Thanks for your further information. For FDO stuff, I guess we have updated Fdo extension project to support Fdo 3.7 in the latest public release 7.0, so, could you download and have a try?. By the way, I haven’t anyone ADRG file, can you send small one to me?

For the IsoLine problem,I downloaded the IsoLine sample to try to reproduce this issue. But seems like I didn't get the same problem, maybe we didn't follow the same styles, background etc. with you,I just have one ClassBreakStyle in this sample, it just take less than 5 seconds on CPU: I7 and Memory:16G machine, can you send your codes to me? Following the is screenshot we got:

Thanks,

Johnny

Richard5 · March 22, 2016, 9:18am

Johnny,

I have uploaded new ADRG files to the ftp site. I uploaded an Alaska ADRG file which works correctly with both the older 3.5 and the newer 3.7 version of the FDO extensions. I also am uploading another copy of the San Diego ADRG which you reported had some type of error which I assumed you were getting during the un-zip operation.

I am also attaching a text file with the stack trace from the exception that we are getting with the San Diego ADRG. The unhandled exception is “System Exception: Could not read the image file”. I am getting this exception for both the 3.7 version of FDO included with the recent builds of 6.0.0.0 of MapSuite Desktop Edition (version 6.0.311.0 through the final build of 6.0.0.0) and also with the 3.7 version of the FDO extensions included in Desktop Edition 7.0.0.0. The San Diego ADRG would display the first image in the file with version 3.5 without throwing any exceptions. It did not however display the other two images. Now with 3.7 version it does not display any of the images but only throws the unhandled exception. Ideally we would like it to display all the images in the San Diego ADRG but at a minimum it would be nice if it would at least handle the exception so that we could see at least the same image we had with 3.5.

I hope this is helpful and that we can track down this issue.

Thank you for your help with this problem.

Richard

FDO-ADRGexception.txt (19.1 KB)

Summer1 · March 22, 2016, 9:18am

Hi Richard,

Thanks for your data, The Alska file can be opened by 3.7, I traced the process with native c++, as the following source code:

::GDALAllRegister();
        char* path = "Alaska ADRG\TRANSH01.THF";
        GDALDatasetH ds = GDALOpen(path, GDALAccess::GA_ReadOnly);
        const char* projString = ::GDALGetProjectionRef(ds);
        int rasterCount = ::GDALGetRasterCount(ds);

The “rasterCount” is 3. But changing “path” to “San Diego ADRG”(the new one), the “rasterCount” is 0, so, the fdo 3.7 can’t get raster image data.
And while unziping "SanDiegoADRGnew.zip", it failed again, and the error message is the same with the last time.Would you please check if it is to change a zipper?

Waiting for your further information

Summer

Richard5 · March 22, 2016, 9:18am

Summer,

Thanks for looking at this issue.

I have created a new zip file for the San Diego ADRG using Winzip 11.1 with the "Superfast" compression. I uploaded this zip file to the ftp site. Hopefully, you will have better luck unzipping this version. If not, please suggest which zip tool will work best for you.

We also can load and view the Alaska ADRG. The San Diego file would load the first image with the FDO Extensions 3.5 but fails with the unhandled exception with any of the FDO extensions 3.7.

Thanks again

Richard

Summer1 · March 22, 2016, 9:18am

Hi Richard,

Thanks for your new data, it could be unzipped successfully, after a deep investigation, it turn out to be a fdo problem.

In Fdo 3.5, the gdal.dll version is 1.6.Gdal 1.6 can parse “San Diego ADRG\TRANSH01.THF”, the raster count is 3 shown in following picture:

In Fdo 3.7, the gdal.dll version is 1.7, and the raster count value is 0, so the file can’t be opened shown in following picture:

So, would you please use fdo 3.5 temporarily.

Hope it helps

Summer