I do see a possible solution to the problem of limiting field sizes when saving changes to shapefiles. If it is an existing shapefile, and the user is simply making changes, then the "Save Selected Datasets" option will be used. We could simply create a new version that included the option to keep the original field sizes. This would be relatively easy to implement, I think.
Larry On Wed, May 19, 2010 at 4:26 PM, Larry Becker <becker.la...@gmail.com>wrote: > Hi Michaël, > > I agree that 24,15 for doubles is insufficient to prevent all overflows. > In fact I just did an experiment and 33,16 is also too small. I think it > should be 34, 16. > > Regarding compatibility of numeric size, I found conflicting references. > Most drivers are probably reasonably tolerant. > > Larry > > 2010/5/19 Michaël Michaud <michael.mich...@free.fr> > > 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 >> > >
------------------------------------------------------------------------------
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
