What a mess of compromises, CSV is such a popular “format” that it is impossible to do all the data cleaning that will come up ... why not accept passing out with nulls as a step too far?
I am sensitive to your rant about this community module being pushed into use by GeoServer. What do you think it would take to make it production ready? On Fri, Dec 13, 2019 at 6:53 PM Ian Turton <ijtur...@gmail.com> wrote: > While fixing an issue with the GeoServer Importer module I stumbled across > an issue with the CSV data store ( > https://osgeo-org.atlassian.net/browse/GEOT-6471) basically, if > you happen to have a blank line at the end of your file you end up with a > feature that contains a set of null features. When I fixed this it broke > another test testDataDoesNotContainAllFields in CSVLatLonState - this is > why the parser trys to add nulls to "pad" out the record. > > I'm proposing to replace this with returning a NULL which will signal to > the FeatureIterator that the stream has stopped as my feeling is that an > invalid record should be an error and we should bail rather than hoping for > the best and ploughing on, which is unlikely to be the best approach? See > https://github.com/geotools/geotools/pull/2707 for the actual changes. It > seems not to break any other modules. > > > Ian > -- > Ian Turton > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- -- Jody Garnett
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
