ThinkGeo.com    |     Documentation    |     Premium Support

Output Shapefile has bad DbfColumns

I’m using the following snipit to build a shape file with a set of column data from an InMemoryFeatureLayer.  This worked well in version 7, but I am now finding that it is garbling the output columns in version 8.0.0.52 which I upgraded to a couple weeks ago.  The garbled DbfColumns makes the shapefile unreadable in all systems I have tested.  If I switch back to version 7, the code works fine.



I also notice that the TypeName property of the FeatureSourceColumn is always null which means I am forced to set the DbfColumnType to string as opposed to setting it automatically.




    // Get the columns 
    Collection<DbfColumn> allColumns = new Collection<DbfColumn>();
 
    fl.Open();
    foreach (FeatureSourceColumn column in fl.FeatureSource.GetColumns())
    {
 
    if (column.ColumnName == “Shape” || column.ColumnName == “SHAPE”) continue;
 
    DbfColumnType colType = new DbfColumnType();
 
    // Not sure what TypeName is as it’s always Null???
    switch (column.TypeName)
    {
 
        default:
        colType = DbfColumnType.String;
        break;
    }
 
    // Need to make the column maximum a high number as we don’t know what it could be
    allColumns.Add(new DbfColumn(column.ColumnName, colType, 500, 0));
 
        }
 
 
ShapeFileType shapeFileType = ShapeFileType.Polygon;
 
        ShapeFileFeatureLayer.CreateShapeFile(shapeFileType,
            shapeName, allColumns, Encoding.ASCII, OverwriteMode.Overwrite);
 
        ShapeFileFeatureLayer shapeFileLayer = new ShapeFileFeatureLayer(
            shapeName, ShapeFileReadWriteMode.ReadWrite);
 
        fl.Open();
        foreach (Feature feature in fl.FeatureSource.GetAllFeatures(ReturningColumnsType.AllColumns))
        {
            shapeFileLayer.Open();
            try
            {
                Feature convertedFeature = proj4.ConvertToInternalProjection(feature);
 
                shapeFileLayer.EditTools.BeginTransaction();
                shapeFileLayer.EditTools.Add(convertedFeature);
                TransactionResult result = shapeFileLayer.EditTools.CommitTransaction();
            }
            finally
            {
                shapeFileLayer.Close();
            }
        }
        fl.Close();






Hi Damian,



I followed your case to convert an inMemoryFeatureLayer to a shape file but it works fine. Would you please attach your codes like how you defined the InMemoryFeatureLayer? An concrete sample is better.



Thanks,

Troy

Hi Troy,



I have created a test project, but the shape file I am using to base the experiment on is too big to include in the project code.  So, I emailed it to support@thinkgeo.com.



Regards,

Damian


Hi Damian,



Thanks for the sample.



We found in your code, it didn’t specify a column type for the featuresourcecolumn in inmemoryfeaturelayer around 71 line. I think we should specify a column type and the max length for it. The codes is like below:



//imfl.Columns.Add(new FeatureSourceColumn(column.ColumnName));
imfl.Columns.Add(new FeatureSourceColumn(column.ColumnName, column.TypeName, column.MaxLength));



Btw, we tested both map suite 7.0 and 8.0 with your sample, but all of them works fine. Here is a test video, please check it.screencast.com/t/D65wrXfnOBQb



Hope it helps.

Thanks,

Troy








Hi Troy,



There has been a little bit of confusion here.  When I first started experiencing problems, I was using MapSuite and working from a FileGeoDatabase which managed to produce a shapefile which was unreadable by either MapSuite or ArcMap.  In my attempt to simplify my test project for you to try and replicate the issue, I produced a single input shapefile that had the very problem in it that I was trying to show you, so the test was a bit off.



I now have a new input test shape file exported directly from my FileGeoDatabase using ArcMap.  Additionally, I attach two images from ArcMap which show the input and output shapes data tables.  As you can see, the input shape data table looks okay, but the output shape table has many missing fields and/or values in incorrect columns.



However, if you read output shape back into your LoadShapeFile console app, you will not see this problem.  Note that you should expand your code to write all columns to verify as OBJECTID always appears to be correct in this case.



My suspicion is still that there is something wrong with the DbfColumnType setting. I modified the FeatureSourceColumn to include TypeName and MaxLength and also cast this into DbfColumnType in my SaveShapeFile procedure.  This does change the results of the data table some, but there are still problems with the columns being jumbled.



Now that my sample shape is so much smaller, I’ve gone ahead and attached my updated project for your comment.



Regards,

Damian

ThinkGeoSaveShapeDbfColumnsProblem.zip (89.7 KB)

Hi Damian,



Thanks for the details and I am guessing the column
type length should be the crime of the issue, for instance, the range
length of the numeric column type is from 1 to 32. 

would you please try the below codes to see if that works?:


//allColumns.Add(new DbfColumn(column.ColumnName, colType, 500, 0));
allColumns.Add(new DbfColumn(column.ColumnName, colType, column.MaxLength, 0));     

Please let us know if any questions.

Thanks,

Troy

Hi Troy,



Sorry for the delay in reply.  I’ve been travelling.



This solution did indeed fix the issue with the test application; however, when I went back to my main solution where I am using file geodatabase as the base input, the original error message I received started to appear again.  See attached what I see when I try and load the exported shape file.



Inspection of the column values from the geodatabase shows the following.  I see a blob type and an OID type that look suspicious.



OBJECTID, OID

BLOCK_NAME, String

COUNTRY, String

CATEGORY, String

OPERATOR, String

COOPERATOR, String

LICENCE, String

ROUND, String

LICENCE_STATUS, String

AWARD_DATE, String

EXPIRY_DATE, String

PHASE1_DATE, String

EXTENSION_PERIOD_YEARS, Integer

LICENCE_TYPE, String

AREA_SQKM, Double

AREA_SQMI, Double

DOC_NAME, String

BLOCK, String

ALT_BLK_NAME, String

OFF_ON_SHORE, String

DEAL_PENDING, String

BASIN_NAME, String

FARM_OUT_OFFERED, String

LICENCED_FLAG, String

CO__1, String

CO__2, String

CO__3, String

CO__4, String

CO__5, String

CO__6, String

CO__7, String

CO__8, String

CO__9, String

CO_10, String

CO_11, String

CO_12, String

CO_13, String

CO_14, String

CO_15, String

DELOITTE_ID, Integer

SE_ANNO_CAD_DATA, Blob

SHAPE_Length, Double

SHAPE_Area, Double



I tried all manner of removing columns or changing the types to strings to try and get the shape to load, but could not get any result using version 8 libraries.  In fact, you can not even create the shape if the OBJECTID or SE_ANNO_CAD_DATA columns are included as there is no associated DbfColumnType for OID or Blob fields.



When I switched to version 7 libraries, all looks correct and the shapes load into ArcGIS and also any Mapsuite apps I have built.



Can you please have a look at potential issues with column type support for file geodatabase?



Regards,

Damian


Hi Damian,



The OID type and Blob type are supported field type of Geodatabase in Map Suite. Below is the geodatabase FieldType enumeration. For more details about geodatabase field type, please refer to  webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Geodatabase_field_data_types .
public enum FieldType
    {
        SmallInteger = 0,
        Integer = 1,
        Single = 2,
        Double = 3,
        String = 4,
        Date = 5,
        OID = 6,
        Geometry = 7,
        Blob = 8,
        Raster = 9,
        GUID = 10,
        GlobalID = 11,
        XML = 12,
}



As for the issue that cannot load file geodatabase, we are very sorry to say we still cannot reproduce that. Attached sample is our test sample based on sample you sent to us in above reply. Would you please try to modify the sample and recreate it for us?



Hope we can resolve your issue.
Thanks,

ThinkGeoSaveFileGeodatabase.zip (47.6 KB)

Troy, 
  
 You misunderstand my last point.  The fact is that I query the File Geodatabase and return a subset of data to an InMemoryFeatureLayer with all column data as shown above.  Then, I attempt to write those features and column data to a shapefile.  When it comes time to convert Blob and OID type to DBFColumnType for the shapefile, those are not valid column types for the enumeration.  The point of OID and Blob type support within a File Geodatabase is not in question here. 
  
 Regardless, if I exclude those columns because they don’t have a valid type to convert to, I can only write the shapefile out using version 7. 


Hi Damian,



Sorry for my misunderstanding.

Is it convenience for you to send us your fileGeodatabase and our test sample together? I think this is the quickest way for us to debug the issue. If the data is beyond the limit size of our forums, would you please send it to  forumsupport@thinkgeo.com or set up a ftp site by sending the request for support@thinkgeo.com and they will send you the account and password.



Btw, not pretty sure if I recreated your issue before, but I remembered this is something related with projection, so, would you please comment out the projection codes to see if it is related?



Thanks,

Troy

Hi Troy, 
  
 I’ll see what I can get for you.  The File GeoDatabase is a subscription from a 3rd party vendor, so I am not sure I can provide it to you in whole. 
  
 Commenting out the projection codes has no effect.  I’m glad though as this would be really bad news. 
  
 Regards, 
 Damian

Hi Damian, 
  
 Actually, we don’t need the whole data but a few data is fine. Once we can recreate the issue, I think that would be very easy for us to fix it. 
  
 Thanks, 
 Troy

Troy, 
  
 I made a small export area and sent it to forumsupport email.  I made sure using this sample db that the problem is recreated.  The resultant shapefile from using v8 library and the small test db is also included in the zip file. 
  
 Thanks, 
 Damian

Hi Damian,



Sorry for the delay and I get some feedback from our development team.



In general, the common dbf column length can’t beyond 10 characters and based on this, we limit the max column length as 10 in map suite 7.0. But, in map suite 8.0, as we start to support a new Dbf file type named Visual FoxPro and this type length can beyond 10. 

So, I guess the reason should be there are some column length beyond 10 and this will result the output dbf transfer to a FoxPro type file. The unfortunate thing  is most of the GIS software don’t support this type yet.



Here we created a sample for you, would you please check it?

Thanks,

Troy

Post12195.zip (14.1 KB)

Hi All,



It’s been nearly a year since this VisualFox Pro style of field has been implemented and to this date, no other software I or my clients use will read these shapes properly.  Also, it seems that even if I limit the shapes to less than 10 characters that I still cannot get the format to default back to what worked well in version 7 of mapsuite.



Can I request that you add some kind of switch to disable this field type from being used?  Perhaps an overload method to DbfColumn with optional False value.  



All of my clients use industry standard ArcGIS products and they can’t read any shape files that I export out of my system.



Regards,

Damian

Hi Damian,



Since the column name length is large than 10 is not the root of the issue, then I can only guess if there is a memo column in your file? A quick way is you can try to use our latest GisEditor to check if it can export your FileGeodatabase to shape file. Normally, it will give you some messages if any unexpected data. thinkgeo.com/gis-editor/



In our GisEditor, which is an end-user application built on Map Suite, When I tried to export your fileGeodatabase to shape file, it gave me an alert that some column length is large than 10 and need to truncate such columns. After the truncating, I can view the exported shape files in other software like GlobleMapper. So, I guess this is your original issue.



But now, since the truncating can’t fix your issue, the only other possible reason is memo column, which is also not supported in some other soft wares. If memo column, we need to truncate the column values limit in 254.



I attached some snippet  codes from GisEditor, the codes include all the cases and show how to convert any features to a shape file. Please check it.



So, two cases we may need to consider:


bool hasMemoColumn = columns.Where(c => c.TypeName.Equals(“Memo”, StringComparison.InvariantCultureIgnoreCase)).Any();

bool hasLongColumn = columns.Any(c => c.ColumnName.Length > 10);



Thanks,



Troy

exportToShapeFile.txt (13.8 KB)

Troy,



You will see that I tried to use GIS Editor to export a layer from my GeoDatabase to shape, but got an error on the save part and can not proceed.  I used the feedback form in GIS Editor to submit this error.  I will note that reading the GeoDatabase in GIS Editor and also viewing the metadata works great just as it does in my software. 



I am also a Global Mapper user.  You will find that Global Mapper can load the shapes to display on screen, but the metadata is all garbled.  Attached is an example when reading the column data.  I would suggest you get with GM support and see if they can fix this so at least GM fully supports your output. 



As far as ArcGIS products, the shape will fail to load always on any setting.  I even tried not exporting any column data from the features.  This is the root of the problem and I believe ThinkGeo needs to give this some serious consideration.  Regardless of MapSuite’s pursuit of better technology, the support of industry standard interchangeable formats must come first.  I’m not asking that you don’t support the newest stuff, but you need to make it optional.  ArcMap is the defacto GIS product in the industry and you are alienating potential consumers.



Regards,

Damian  




Hi Damian,



I can also see the issue that the column data is missing in Global Mapper after exporting from GisEditor, I’ve reported it to our GisEditor team to see if anything is missing in GisEditor. Now, looks like we are facing the same issue and we are working on it. I will update here once we make the exported files works fine in other software. Btw, we are using the file you send on 9/11/2014.



For the new features support consideration you mentioned, Whether following industry standard or not depends on how we specify the columns. If we specify the columns limiting in the standard, then the exported shape file would be a standard file and can be shared between difference software. But if we allow such special columns, map suite will treat it as a new format shape file and may result in un-support issue at some software. 



Thanks,



Troy




Damian,



We fixed the GisEditor bug and the Global mapper can view the exported file’s column now. You can update GisEditor to 7.0.794.0 packages under development mode.(Menu=>Options=>Updates=>Update Channel=> checked as Developer)



I also built a sample that can export a fileGeodatabate to shape file and the exported shape file can view in other software, please check it.



Thanks,

Troy

ExportToShapeFile.zip (114 KB)

Damian,



We fixed the GisEditor bug and the Global mapper can view the exported file’s column now. You can update GisEditor to 7.0.794.0 packages under development mode.(Menu=>Options=>Updates=>Update Channel=> checked as Developer)



I also built a sample that can export a fileGeodatabate to shape file and the exported shape file can view in other software, please check it.



Thanks,



Troy

ExportToShapeFile.zip (114 KB)