Hello,


i have attached a small manual with sample files. Read the pdf, test the files and have fun.


Best wishes
fjordfisher


Please Matt upload the files. Thanks!

Thanks Jorg!

PDF can be read here.

Zip containing files can be downloaded here (zip also contains the pdf manual).

In the case of hundreds of points with the same value in the attribute table, there is a helpful tool in qGIS (attachment).

Best wishes
fjordfisher

fjordfisher wrote:
Is that a problem in the at5-file or why does this need special treatment?

/Martin

This is an additional help for saving time and not a problem for the AT5.

E. g. if You have a file with > 200 points, and mostly all should have the same entry in
- U_LIMIT
- FONT
- MODE
- COLOR
....

You can edit by hand or You use the field calculator.
The field calculator is much faster than each separate entry by hand!

Best wishes
fjordfisher

Ah, OK!

I use Excel for "bulk editing" shapefile attributes.

/Martin

This can make problems and i cannot recommend this.

The problem is, that the IMC required a special format (column width) in a few columns, espacially in text fields.

With save in Excel, You can destroy this structure and the IMC can't read the informations correctly.

I also use Excel, but not in this form, in connection with ArcGIS.
I save the dbf as xls and fill the xls-columns with help of pulling with the mouse. Than i copy the colum content in the edit mode into the attribut table. With Excel i also can use the sort function.

Or i use the field calculator in ArcGIS.

Best wishes
fjordfisher

Hi Jorg,

Re: "IMC required a special format (column width) in a few columns". Really ?

It is (was?) crucial that some attributes are defined properly, which can be problematic in GM, for example if a set of labels consist of numbers (buoy numbering etc..), in which case GM will auto assign a numeric format to the attribute instead of a text attribute. I was unaware of a problem with column width.

T

As far as I know, there are no restrictions on column width that aren't already imposed by the DBase4 format (0 <= Column Width <= 255).

fjordfisher wrote:
The dbase support varies from Excel version to Excel version, true. I know of the issues I think you hint at and on some PCs I have to take the route via Access to make it all work OK. But Excel is an awesome tool for many things. :)

Haven't searched for it but I presume there should be some sort of dbase plugin for current excel versions, dbase isn't dead after all!

/Martin

I wrote: It can be a problem, not it must be a problem.

And this is a manual for beginners, not for professionals. A beginner should not use Excel!

I know min 3 other persons, in the past they have any problems, after Excel use in dependance from its Excel Version (e. g. text lenght loss after save).

Here is a small, still harmless sample (not in context with column width, but with the language):





GPIVERSON wrote:

As far as I know, there are no restrictions on column width that aren't already imposed by the DBase4 format (0 <= Column Width <= 255).

But why i can find a defined column wide in the IMC sample files?
I know: In ArcGIS i receive a error message, if i exceed the column wide, but unfortunately not in qGIS.




i find also:

attribute..........column wide

ICON..................50
MAJ_CAT...............50
MIN_CAT...............50
MODE...................1
VALUE.................50
INFO_BOX.............254
P_ICON................50
BFR_PATTER............32
FONT (points).........10
FONT (lines)...........5
PATTERN...............32
BDR_PATTER............32
VALUE2................50

I believe that is a restriction/limitation for the IMC, mostly not relevant in practice, but some already.

Best wishes
Jörg

Post your DBF file along with the associated CPG file if one exists.

I wrote my own Shapefile reader/writer because I needed to more control over how this was done. I wrote my own Shapefile replacement format (LSF) because of all the limitations (real or artificial) with Shapefiles.

IMC defaults to Win 1252 unless the codepage is overwritten through the CPG file for standard behavior over lots of different Operating Systems. Maybe Excel is writing out using your Windows localized codec which may or may not move the expected position of U-umlaut.

If it's using UTF-8, for example, that is fine...the IMC just needs to know that.

en.wikipedia.org/wiki/Windows-1252
en.wikipedia.org/wiki/Unicode
en.wikipedia.org/wiki/Utf-8

As far as the fixed width thing, that is a behavior of the DBase4 format. Unfortunately, the limitation is a bit silly because you can just traverse the entire database to determine what fields must be extended. If it's processed sequentially, it's not really possible to extend the width. The Attribute Mode, for example, will extend the widths based on the values in the data.

The samples may be defined where the widths are not adequate. If that is the case, simply extend the width in a field calculator first.

I also wouldn't base support on how other applications handle the files. For example, ESRI is adamant that shapefiles can only go to 2 GB size and they use the file reference size to back their claim on that. But all file positions and file lengths are in signed words where the negative spectrum of numbers are completely ignored. So if the references are interpretted unsigned, the max file size is 8 GB and if the references are interpretted signed, the max file size is 4 GB. They insist the same thing for DBF files which have an enormous maximum size 255 Max Fields with 255 Max Length and 2^32 - 1 Max Records = 279,280,248,357,375 (~279 TB).

The one type of geometry per file issue is a rule imposed by ESRI when the format was created. A geometric type is identified before every feature but if this geometric type does not match the one identified in the header or is a NULL record, you need to assert the problem since no reader will be able to work with it.

There are also incongruences with how to handle NULL field values. There is one consistent way and 2 other ways that aren't supported by several applications. Several GIS applications have chosen their own way to encode this and any full reader needs to be able to read all these variations and only write out the consistent way. ESRI does not support NULL field values and replaces them with either empty strings or 0's if numeric.

Most readers only work with 254 character field lengths and 10 character field names but this isn't format imposed. The maximum width of fields is 255 characters and 11 characters for the field names but all the readers out there require that their header strings be NULL terminated in the file...which makes absolutely no sense when working with fixed length strings...you know where your string ends because you know how long the string can be.