Hi, investigating a little more, my assumption on the shrinking oft he decimal count on each saving (see below) is wrong, since the length keeps being constant. I played around with the code of the ShapefileFeatureWriter, not rebuilding the header inside the constructor. All tests pass fine, but ShapefileDataStoreTest.testWriteBiggerNumbersWithCheck. The test basically writes big numbers to shapefiles and then reads them out and tries to compare them, although the purpose of this specific test is to get an IllegalArgumentException on write, since the BigInteger cannot be read the same way, it will be written. After investigating a little more with debug I found out, that the reason for the reconstruction of the dbf header inside the writer (which should be consistent already on calling the constructor, through createSchema or an existing header) is to validate read/write equality. The tests does two basic steps, when writing:
1. create schema on shapefile datastore. 2. write feature with big number to shapefile After step 1, the schema is written as according to the given feature type (BigInteger resolves to dbf N with field length of 33). Since the Writer rewrites the header, after parsing the schema again from the dbf file (where every N field above length 10 gets a Long binding class), it writes N with field length of 19 to the dbf and then throws an exception, because the feature tob e written has a value with a higher length. So my assumptions are: (a) GeoTools wants to support all Java types on a createSchema, no matter if they can be read (b) The ShapefileFeatureWriter rewrites the header after parsing to guard read/write equality Are these assumptions right? If these assumptions are right, I need a valid way to make GeoTools not change the decimal count on writing to an existing shapefile (see below). Any ideas on this? Thanks, Hendrik Peilke Von: Peilke, Hendrik <[email protected]> Gesendet: Dienstag, 27. November 2018 10:14 An: [email protected] Betreff: [Geotools-devel] Shapefile datastore changes definition of number attribute decimal count upon saving Hi, when I use the shapefile datastore to open up an existing shapefile with a number attribute including a decimal count, then add a feature and finally save, I find the definitions of number columns changed: I initially have a number attribute with a field length of 18 and a decimal count of 4. If I add a feature and then save this column definition gets changed to a field length of 18 and a decimal count of 15. The reason is the static createDbaseHeader method in https://github.com/geotools/geotools/blob/master/modules/plugin/shapefile/src/main/java/org/geotools/data/shapefile/ShapefileDataStore.java, which is called everytima a Shapefile is written down (see constructor of ShapefileFeatureWriter: https://github.com/geotools/geotools/blob/master/modules/plugin/shapefile/src/main/java/org/geotools/data/shapefile/ShapefileFeatureWriter.java) . This method does a lot of magic and sets for double and float the decimal count to Math.min(Math.max(l - 2, 0), 15); where l is the field length cut at an upper bound. When creating the simple feature type on reading in shapefiles the decimal count is just ignored and fieldlength is set to the fieldlength (18 in my example). So the formula above would give a shrinking decimal at every save at a field length of 16 and below (-2 on each saving). Where does the -2 come from? As a general solution, not regarding fixing the formula above, I see two possibilities: - change the ShapefileFeatureWriter to just create a new Header if it is a new shapefile and use the old one if it is available - not loosing the decimal count on building the feature type (how are other formats doing this? As a user property?) and then use this value upon creating the new header Can you please provide some thoughts on the formula above and the solution of the general problem? Thank you, Hendrik Peilke ________________________________ IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter, Eckehart Klingner Vorsitzender des Aufsichtsrates: Dr. Helmut Vorndran ________________________________ IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter, Eckehart Klingner Vorsitzender des Aufsichtsrates: Dr. Helmut Vorndran
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
