[postgis-users] shp2pgsql fails on malformed integer attribute

Andrea Peri aperi2007 at gmail.com
Sun Aug 15 14:09:54 PDT 2010


>I don't quite understand your example :
>
>"if the field numeric in the shapefile instead of be fill with numbers was filled with '1', '2', '3', etc...
>where the number are however not really numbers but text based, an action of importing always 0.

>Will be more confusing. The user don't understand why a number (or simil-number) became a '0'."
>
>In the DBF file itself, there is no difference between a 'text-based number' and normal numbers. Whether I declare the column as numeric or text, the data for the number one (1) will look the same. That will never be an issue.


Hi,

Unfortunately some difference in the declaration there are.

the dbf specific are bit old-style and so are no fully coherent.

See-ing the specific for the DBF III version (
http://www.wotsit.org/download.asp?f=dbase&sc=335163169 )


The char fields must contains always a set of chars filled with
spaces. Not \0 termined.

Unfortunately a quite famous tools of that time (clipper) redefine the
db3 format (called xbase format) with a their version using the \0 to
terminate the

strings. (I think - to avoid the copyright put on the db3 format from
original owner ashton-tate)

So now there are tools that use the \0 terminate strings and tools
that use the space-fill for the text fields.


Instead for a numeric field nothing is say about how it must be filled
because it is assume is always filled with digits.

But if you put a text based value "27.57" in a numeric field of 18 digit.

You can have many ambiguos situations


For a 10.5 numeric field , I think the right version will be this
"0027.57000"

or

"000027" (i think but I'm not sure) for a numeric 6.0 field

so no space based and no \0 terminated because nothing is say about
this in db3 format.


instead if it is text based it can be for example:

"27.57\0" and the remainis are spurious digits -> "27.57\0123"
or
"27.57" + "some spurious values" -> "27.57436x6"


or for the 6.0 numeric field

"27****" or "27\0**"

Another situation where the interpretation is really impossibile is
the Logical Field.

In the db3 format It is define exactly with 1 chars using one of this:
(YyNnTtFf space)

But if I find a 'S' char value in a logical field of a db3.

I cannot decide if it is a true of false value.
So use a default to a False or True value is always an opinion.

Andrea.

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20100815/a8bdbd58/attachment.html>


More information about the postgis-users mailing list