Hi,

Good catch Larry.
I have changed that for integers at a time, but lost it when JUMP moved 
to OpenJUMP.
 From this doc, Numeric types should not be more than 18/20 bytes 
length, (which is quite restrictive) : 
http://www.clicketyclick.dk/databases/xbase/format/data_types.html#DATA_TYPES
I always let 33,16 for double, because when doubles are transformed from 
floating points to fixed points, it is not possible to know how many 
digits are needed before the decimal point and after the decimal point. 
So the risk to loose information is not null.
I don't know why OGR choose 24 with 15 decimal places. It seems not very 
high in precision to me (ex. limited to -9 999 999 in negative numbers) 
but already out of the spec.

I agree integers can be changed to 11 bytes length
I'm not in a hurry to limit double to 24,15 as I think there is a 
(small) risk of loss in precision, and I'm not sure that changing that 
to 24,15 will solve any compatibility or storage issue (but I maybe 
wrong about these points)

Any other advices ?

Michaël

Larry Becker a écrit :
> I just had a look at the package 
> com.vividsolutions.jump.feature.AttributeType and found:
>
>     /** For long values (64-bit) */
>     public final static AttributeType INTEGER = new 
> AttributeType("INTEGER", Integer.class);
>
> The comment is at odds with the type, and I can't see why 
> ShapeFileWriter allocates 16 bytes if all we can store is an Integer.  
> If we were to store a Long it would take 20 bytes 
> (-9,223,372,036,854,775,808).
>
>             if (columnType == AttributeType.INTEGER) {
>                 fields[f] = new DbfFieldDef(columnName, 'N', 16, 0);
>                 f++;
>             } else if (columnType == AttributeType.DOUBLE) {
>                 fields[f] = new DbfFieldDef(columnName, 'N', 33, 16);
>                 f++;
>             }
>
> We should be able to reduce the allocation to 11 for Integers 
> (-2,147,483,648).
>
> To follow the GDAL/ORG lead (http://www.gdal.org/ogr/drv_shapefile.html):
>
>    *
>
>       Integer fields without an explicit width are treated as width 11.
>
>    *
>
>       Real (floating point) fields without an explicit width are
>       treated as width 24 with 15 decimal places of precision
>
> Unfortunately this would not help with Michele's problem, but it would 
> make smaller dbf files.
>
> regards,
> Larry
>
> On Tue, May 18, 2010 at 9:05 AM, <totenfe...@email.it 
> <mailto:totenfe...@email.it>> wrote:
>
>     Hi Stefan,
>     i'm sorry if i wasn't clear enough. The first row af a dbf file
>     describes the content of each
>     column. For an area field we can have "AREA,N,6" and 6 is what i
>     mean as
>     field size.
>     I need to change this value from the standard "16" that openjump uses.
>     Thanks!
>     Michele
>
>     > Hei,
>     >
>     > I would say "no" - but I am also not sure if I understand correctly
>     > what you mean by "length of a integer field".
>     >
>     > stefan
>     >
>     > Totenfeier wrote:
>     >> Hi all!
>     >> i'm a fellow worker of Politecnico di Milano and i'm working on a
>     >> project that need to manage field length of a shapefile.
>     >> Notably i have to set different dimension of integer fields in
>     a dbf
>     >> file.
>     >> I'm wondering if this is possible with Openjump now or somebody is
>     >> working on that.
>     >> Thanks!
>     >>
>
>
>
>      --
>      Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP,
>     POP3 e SMTP autenticato? GRATIS solo con Email.it
>     http://www.email.it/f
>
>      Sponsor:
>      Conto Arancio ti regala 50 Euro da spendere su Media World on
>     line. Cosa aspetti, aprilo subito!
>      Clicca qui:
>     http://adv.email.it/cgi-bin/foclick.cgi?mid=10036&d=18-5
>     <http://adv.email.it/cgi-bin/foclick.cgi?mid=10036&d=18-5>
>
>     
> ------------------------------------------------------------------------------
>
>     _______________________________________________
>     Jump-pilot-devel mailing list
>     Jump-pilot-devel@lists.sourceforge.net
>     <mailto:Jump-pilot-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>   


------------------------------------------------------------------------------

_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to