I did a very dangerous thing today and downloaded the source code for GeoTools. I got the source code for the shapefile module loaded into Eclipse and set-up the libraries it required. I thought this was the best way to avoid asking stupid questions Joday and Andrea have to answer.
At any rate, I started poking around in the DbaseFileHeader class looking for some answers I couldn't find in the Javadoc. I had originally planned on sending Andrea just a couple of patches, but I think there may be more opportunities to improve the code comments/functionality. I was wondering if I could get a little space in the SVN to do some work on the code. This would be a fork of the Shapefile module obviously, and I would get approval from Andrea and others before any changes were commited to the trunk. Here is an example of some things I am thinking could be improved: - The Javadoc comment for the getFieldType(int) method is a little sparse. I thought it would be helpful to add a listing of the character codes used in DBF files that could be returned by the method. - I thought we might explain what field types we don't support (and why) in the javadoc comment for the getFieldClass(int) method. Right now we only list the codes we support, and just say we return a String for anything we don't recognize. - I figured I would add some statements to the main Javadoc comment of the class explaining some of the ways an instance of the class can be obtained. I think it might also be important to point out that you must call the readHeader method before using many methods of the class in this section. - It might not hurt to explain how to get the ReadableByteChannel that is needed as an argument for the readHeader method in its Javadoc comments. That tripped me up a little bit. - It doesn't look like we are supporting some of the DBF field types that we could be. I'd like to modify the class to support the additional field type codes: O (DBF Double) -> Mapped to java.lang.Double F (DBF Float) -> Mapped to java.lang.Double @ (DBF Timestamp) -> Mapped to java.util.Date I (DBF Long) -> Mapped to java.lang.Double + (DBF Autoincrement/Long) -> Mapped to java.lang.Double It doesn't look like we need these codes, since client code is using the library to read shapefiles successfully, but our library would be more robust if we recognized these additional field type codes instead of converting them to Strings. I don't think it will be that hard to make this change. - I don't know if it makes sense to convert OLE and Binary field types to Strings. Perhaps we should ignore them or find another way to handle them in the code? I may find other places I can make small improvements as I work with the code. Having a little slice of the SVN will let you guys review and monitor my work. Maybe I can relieve some of the load Andrea has as the sole maintainer of this module. This is just a suggestion. I know the code is functional as it is. At OpenJUMP they don't really like to tweak things that are already working, but I am always looking for ways to make small improvements. :] Let me know what you guys think. Landon ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
