ThinkGeo.com    |     Documentation    |     Premium Support

Problem loading shape files that appear valid

#1

Green_polygon1.zip (74.0 KB)
I’ve attached a shape file that was sent to me for not loading correctly. The logic that loads these shape files is unchanged for quite some time, and works fine on thousands of others in a released product, but now fails on several files from this set. The attached zip contains one of those files. Opening it in SAGA GIS shows what appears to be a valid polygon file. Our logic is as follows using a ShapeFileFeatureLayer instance.
.
mapLayer.Open( );
try
{
features = mapLayer.QueryTools.GetAllFeatures( ReturningColumnsType.AllColumns );
validation = mapLayer.Validate( );
}
catch( Exception ex )
{
exceptionMessage = ex.ToString( );
// for future reference, the “validation” dictionary contains info about exactly what was bad.
validation = mapLayer.Validate( );
}

This code throws the following exception at the GetAllFeatures line.

System.IO.FileLoadException: The record is invalid, please call Validate method to check the failed reason.Record index: 20
at ThinkGeo.MapSuite.Core.ShapeFile.mhY=(Int32 recordIndex)
at ThinkGeo.MapSuite.Core.ShapeFileFeatureSource.GetAllFeaturesCore(IEnumerable1 returningColumnNames) at ThinkGeo.MapSuite.Core.FeatureSource.<GetAllFeatures>b__175_0(IEnumerable1 cns)
at ThinkGeo.MapSuite.Core.FeatureSource.YxY=(IEnumerable1 returningColumnNames, Func2 getFeatures, IEnumerable1 filters) at ThinkGeo.MapSuite.Core.FeatureSource.GetAllFeatures(IEnumerable1 returningColumnNames)
at ThinkGeo.MapSuite.Core.FeatureSource.GetAllFeatures(ReturningColumnsType returningColumnNamesType)
at ThinkGeo.MapSuite.Core.QueryTools.GetAllFeatures(ReturningColumnsType returningColumnNamesType)

The call to Validate inside the exception handler returns an empty collection, the same result I get on all the successful files after a successful call to GetAllFeatures…

Can you tell me why this shape file is not loading and displaying properly?

#2

Hi Russ,

I tested your data and it looks works well:

Pasted image686×502 7.03 KB

As below is the test code:

        ShapeFileFeatureLayer.BuildIndexFile(@"D:\8453\Green_polygon1.shp", BuildIndexMode.DoNotRebuild);
        ShapeFileFeatureLayer mapLayer = new ShapeFileFeatureLayer(@"D:\8453\Green_polygon1.shp");
        mapLayer.ZoomLevelSet.ZoomLevel01.DefaultAreaStyle = AreaStyles.Country1;
        mapLayer.ZoomLevelSet.ZoomLevel01.ApplyUntilZoomLevel = ApplyUntilZoomLevel.Level20;

        Dictionary<string, string> validation = new Dictionary<string, string>();

        mapLayer.Open();
        try
        {
            Collection<Feature> features = mapLayer.QueryTools.GetAllFeatures(ReturningColumnsType.AllColumns);
            validation = mapLayer.Validate();

            LayerOverlay overlay = new LayerOverlay();
            overlay.Layers.Add(mapLayer);

            winformsMap1.Overlays.Add(overlay);

            winformsMap1.CurrentExtent = mapLayer.GetBoundingBox();
        }
        catch (Exception ex)
        {
            string exceptionMessage = ex.ToString();
            // for future reference, the "validation" dictionary contains info about exactly what was bad.
            validation = mapLayer.Validate();
        }

        winformsMap1.Refresh();

Regards,

Don

#3

I wonder if it’s version specific? I should have included that we are currently running on version 9.5.0.100. But that file throws the indicated exception on our code base, and we really need to know why this set of files throws that exception on maybe half the file set (roughly 20 or so files I think).

#4

Hi Russ,

Because 9.0.0.100 is an early 9.0 version, we did many changes between it and our latest version.

I don’t know why some files met this exception, please try to use latest dlls and see whether it works well.

Regards,

Don

#5

I agree. And if we were not in the final stages of putting together our first RC offering, I would have already proposed this as a potential low impact solution. But we are (hopefully) within a few weeks of a blessed RC, so updating a component by several steps is just not in the card. All t his tiem we’ve been through hundreds of maps weach with 20-40 or more shape files, and this is the first we’ve run into this; and it hits half the shape files on that one site with NO feedback as to what it didn’t like, and nothing told in the call stack. If we have to update the TG component version, there will be much yelling and gnashing of tetth as test runs get invalidated and started over, demos and early adopters get pushed back, and customers desperately waiting are put off. Not a good scenario.

However, if you could tell me exactly what produced that exception, then that we may be able to address. The AutoCAD file used to produce the shape files defines that whole course, and undoubtedly has some construct that is not common in such maps, and that is producing something the TG code does not like at all. Just dig in and figure out what that thing is, and we can likely patch the converter, to recognized and avoid those issues, which will not have near the impact on our sdchedule. I would do it myself, except your obfuscated code makes it a huge pain to dig into the code, so hopefully you guys can find the answers quickly enough.

In summary, all I want to know is exactly what is different between shape files that work and those that don’t and fail as indicated (in our version). With that information describing “Correct X to be Y and it will avoid the exception and display correctly”, I expect I can do the rest easily enough. I just need the details of what it didn’t like, and what lead it to be in that state it didn’t like.

Baring that, I need to get a very clear understanding of major architectural and “breaking” changes that connect the 2 disparate versions. Only then can I made a rational decision about the level of risk to just upgrade your component.

Please advise, thank yo.

#6

Now I’m getting a bit more confused. Our existing binaries indicated 9.5.0.100 for DesktopEdition and MapSuiteCore, both in the file properties and the manifest. Yet your comment refers to 9.0.0.100, and the Product Center is showing 9.0.0.633. That makes no sense to me.

#7

I thought maybe something was wrong with my Product Center on this VM, so reinstalled with a freshly downloaded msi (http://download.thinkgeo.com/ThinkGeoProductCenter.msi), and it still shows the same versions.

#8

Hi Russ,

Thanks for your description, I understand about upgrade dll will introduce possible issue, so I will find the version near 9.0.0.100 and see which version is helpful for solve your exception.

Our version only contains two types: x.0.0.x and x.0.x.0, so the 9.5.0.100 is strange and not our standard dll version. If your dll shows that, I guess that’s an incorrect dll version before.

And I viewed our daily build list, it looks we hadn’t built the version 9.0.0.100, I can only find the nearest version 9.0.0.97 and 9.0.0.125, so I even cannot test the version 9.0.0.100.

Our product center only can download the latest version dll, if you want to download some specified version please ask us provide the download link.

Regards,

Don

#9

Hi Russ,

I compare all old versions, and found that’s fixed in 9.0.0.337 version (2015.5.25).

We fixed that because other user reported this exception and we finally found that’s because some shape file contains invalid inner ring.

As below is the detail comment about that: We have a simple validation to determine whether the ring of polygon is closed. To close a ring the last point must be the same as the first point. All rings must have at least four points.

I think you can did a small project to double check all your features in your shape file, to make sure the OuterRing and InnerRing is valid, you can validate that like this:
ring.Validate(ShapeValidationMode.Simple).IsValid

And if you found some data is invalid, you can remove them or fix them.

Wish that’s helpful.

Regards,

Don

#10

Thank you for the additional insight. We (rather someone that knows more ACAD than I) are currently examining the original DXF file as well as the resulting shape files to try to find an answer for the near term. Once we wrap this version, we will likely be updating, probably to version 10.x.

As for the weird version number, I seem to recall getting a “patched” build or something, but can’t recall at the moment. All I can say is that the numbers appear consistent throughout the metadata of the desktop binaries we are using.

#11

Hi Russ,

If you remembered what’s the reason of the strange version please let us know, we can also try to find what’s the special change for your version.

If you want to upgrade to 10.0, please notice 10.0 get big changes on structure and distribution.

You can read more detail information in our homepage.

Regards,

Don

#12

I just confirmed that 9.5.0.100 is the private build provided by Ben addressing the OOM exception. Unfortunately, the reason I had to dig out the old email is because we just experienced it again and I had to be sure the site had the build that was supposed to fix the issue.

#13

Hi Russ,

Thanks for your update, it looks you talked with Ben in the post 2576 about that, but I hadn’t found you mentioned about this private version in that post before, so that’s maybe from the old email.

If you found any question need our assistance please let us know.

Regards,

Don