Hi Landon - you are brave today! Normal svn branching would be fine (it is some times easier to assemble a patch in svn for review).
You already have commit access; we have a list of branches here if you want to take notes: - http://docs.codehaus.org/display/GEOTOOLS/Branch You can see a couple of branches already listed: - http://svn.osgeo.org/geotools/branches/ Indeed we could clean out some of those branches since the work they represent is now complete. The branches in that directory range from an entire copy of the library; to just a single module. Jody On 17/09/2009, at 10:13 AM, Sunburned Surveyor wrote: > 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 > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
