Without opening the TAB within a GIS package, is it possible to determine which feature class it contains?
Could the TAB file be open in notepad and assessed for example?
1
-
I think an important question here is: why? Why do you need to do this? If we knew that, someone might have an alternative solution. – Mark Ireland Aug 20 '14 at 14:38
-
Because these tab files need sorting depending on the feature class contained. The systems being used are unable to have a GIS package installed. – BobJim Aug 20 '14 at 14:40
1
A TAB file can contain multiple object types at one time, both points, lines, polygons etc. But starting from byte 316 in the map file you can read number of points, number of lines, number of polygons and finally number of text objects. That was 4 int32 integers. But I am not sure if that information is still uptodate, considering more object types has been added later on to the TAB format. But notepad is surely not the answer here.
-
-
I don't think you can use notepad as the information about geometry is in a compiled file (.map). Might be worth a look at this post [link]gis.stackexchange.com/questions/94070/… – ian Aug 21 '14 at 9:35
1
Uffe's answer is still correct in current versions of the .map file as far as I can tell. In order to do this you would need to open the file in a hex editor (or programatically read the binary file) and read the binary values from byte 316. These will be displayed as hexadecimal format in a hex editor.
As an example, I used a hex editor to open a .MAP file which I know has 1627 region objects in it. I found byte 316 and read the bytes up to 319 - all 0's which means there are no point objects, bytes 320 to 323 all 0's also so no linear objects, bytes 324 to 327 - ah ha! I get the 4 bytes as hexadecimal 5B 06 00 00.
To convert this to decimal (base 10) from hexadecimal (base 16) we need to know that hex values run from 1-9, then A, B, C, D, E, F are 10 - 16.
So to convert 5B: B = 11 and the 5 is equal to 5 * 16 = 80. So 5B equals the sum of those, 91. Following the same convention, 06 is equal to just 6 in decimal.
So these are the binary values stored in the file. To get the actual int32 value we need to convert this to decimal. 6*256 = 1536 then add the 91 = 1627. That's confirmation that we have 1627 region objects in our map file.
Assuming you're not concerned with the number of features but just the type stored in the file then you can simply check those 4 byte chunks for non-zero values to determine if each feature type exists in the file.
There's a good description of the .MAP file format here: http://spatialnews.geocomm.com/features/mif_format/
Hopefully I've explained this in an understandable manner, but depending on your knowledge of binary and hex it may be worth reading up about it if you decide to take this approach.
