Hello,
I've an issue with ArcGIS.
Shapefile produced by MS 2 are compliant
Shapefile produced by MS 3 are not compliant.
I guess it's because the .idx file has changed between MS 2 and MS 3.
As a test, you can try to open a MS 3 shapefile with index on MS 2 and it does not work.
The same occurs with ArcGIS.
How to workaround and keep MS 3 compliant with other shapefile based product ?
Regards,
Patrick.
Patrick,
I just want to verify that you are saying that the shape files created with MS3 did not open in ArcGis? Of course the index is not the same with the propietary ESRI index but the shp, shx and dbf should be compatible. Can you provide a small sample of the kind of data you are using? Maybe there is something specific to your data.
David
I’m not sure if this will or won’t apply, but IIRC when I generated a shapefile with no data attributes, I ran into an issue loading the shapefile in ArcMap. Not sure if that applies here, but just throwing that out there.
Hi,
I found my error and it’s not a bug.
ArgGIS does not accept dbf fieldname containing spaces.
Idx produced by MS2 were compliant with ArgGIS;
Idx produced by MS3 are not compliant with ArcGIS.
So to export to ArcGIS, one must check that IDX is excluded and there are no spaces in field names.
Regards,
Patrick.
Patrick,
The IDX files are own proprietary standard and we never released the format. We would have used the sbn and sbx formats but they are ESRI proprietary so we couldn’t go with them. I am not sure how ArcGis could be “compatable” with them. This is a bit confusing.
David
David, I think Patrick was just a little confused about what is actually breaking in ArcGIS.
If what he says is true (I haven’t looked it up, but IIRC it is), in the DBF file ESRI standards do not allow for column names to have spaces in them, among other restrictions.
Going by what Patrick detailed, it looks like he generates the non-compliant DBF using Map Suite without any issues arising. The issue comes when he loads the shapefile / dbf file in ArcMap and the validation is run and essentially enforces the standard.
It’s possible that running the ShapeFileFeatureLayer.Validate command would yield a similar result.
All guys, Thanks for your posts and discussions, I learnt a lot from it
I will try to close this thread on the Christmas day, if you have any problem, just let it alive.
Thanks.
Yale
Just to close this thread, few words:
My initial analysis was wrong;
the thing is that MS allow to use space and underline in field names.
However, products such as ArcGIS does not support it, so the file generated by MS is considered as unreadable.
I don’t know if it’s a bug or not; but to be compliant, I had to add some check to avoid this.
Regards,
Patrick.
Patrick, in my world (agriculture), shapefiles are an ugly fact of life. There are lots of tools that can create and/or consume shapefiles that are not 100% technically correct. ArcView was one such tool. It is funny that, conversely, ArcGIS is one of the most unforgiving tools. However, I’m pretty sure that underlines are consider valid column name characters. Dashes are not, but underlines are used widely across many products that I have to deal with. They are frequently used to separate a logical column name from a trailing unit of measure, such as P_PPM, K_LBS, etc.
FWIW
you’re right, my english is not perfect and I mismatch - and _
for me, are to avoid
field name starting with “_”
field name containing “-”
field name containing " "
agree ?
Patrick.
Patrick,
I did not do tests against the Arc Gis etc to see it allows dashes or not, personally speaking, in your stand, it is very safe to cause any problem related with it especially when we do SQL query on it.
Thanks.
Yale
I have not personally experienced any shapefiles with a leading underline. You are probably right on that one.
Yes, I agree.
As to whether MapSuite should enforce this... I'm not sure. Where do you draw the line? We have in-memory feature layers that don't have any column naming issues... people us long names, etc. And "missing values" can truly be null. When we want to "export" these feature sources to shapefiles, should we expect that the MapSuite tools will somehow make good filenames for us? What would be the rule for handling column names that are too long? What would be the rule for handling null values? Historically, we have always just accept responsibility for these things in our own export wrappers. Not sure if that is the right approach, or not.
Should the export routine throw exceptions on known issues, and let you fix them, like the layer redraw exceptions?
Maybe we should convince the world to move to something better than a shapefile :)
Hi Gentlemen,
Thanks for your sharing, you’re very professional, I am so proud of out discussion forum has you guys.
That’s might be worth trying to make our MapSuite more intelligent, I think that would be more helpful to user, but to be honest it’s not easy to implement that we need consider many related things. If we decide to enhance our shape file system eventually, we need research some detail things.
In a word, thank you, Patrick, Nelson, Ted.
Any more suggestion in the future if you think about, just put to here.
James
Ted,
It is unfortunate that the shapefile still haunts GIS. Don’t get me wrong I think what keeps it around is the fact it is well known and that it is laid out rather well for fast access. Many people want to move everything to databases and while this is a great move for some things, in many cases it misses a bunch of requirements of speed and being able to distribute it. What we need is a modern file layout that is open, built for speed and is easy to understand. It also needs to be modern in the sense of accepting long file names with strange characters etc. It needs to handle compression and encryption as well. We need a new and improved DBF type of standard to handle modernity. I personally would like to see one optimized for rendering and spatial query. It seems like all of the other formats out there are proprietary and it is so hard to start a standard without looking like you are trying to lock people in to your standard.
David