Hi Landon, Glad my ideas are not too crazy :). And you raise a good point with the manpower thing. And indeed many of the geotools developers will be core implementors in this library as well. And hopefully the udig developers, jump developers, etc...
The reason I don't want it part of geotools is that geotools is so big and its api is too complex. This raises the bar too high for someone who wants to implement a new format imho. An easier api to implement makes it easier to maintain, which i think leads to stability, and better quality data format support. Right now in geotools 90% of formats are "unsupported", because they are too much work to maintain. Developers who originally contributed don't have the time to keep up the unmaintainance. And when api is changing constantly around them it just makes it too hard. But yeah, i am happy to start throwing around ideas on the wiki. -Justin Sunburned Surveyor wrote: > Justin, > > It sounds like you and I think alike. I believe that all of your ideas > have merit. I wonder though, if the library could still be > "maintained" and hosted by GeoTools. I realize the man power for this > might not be available, but I would be willing to give some time to > this effort if GeoTools programmers approved. > > Let me get some information about the DataObjects format up on the > Java GIS Collaboration page at the OSGeo, which will include a link to > the source code we've come up with so far. (The source code is hosted > in the SurveyOS SourceForge SVN Respository.) > > I will also post a brief message to the OSGeo discussion list, > throwing this idea out to get trampled on. > > Landon > > On Nov 13, 2007 1:05 PM, Justin Deoliveira <[EMAIL PROTECTED]> wrote: >> Hi Landon, >> >> I never jumped into this thread last time it came around but it is >> something i am very interested in. As of late I have become quite >> frustrated with geotools data access support. And compared to other >> projects like ogr the number of formats we actually do support is laughable. >> >> When jody explained this idea to me I thought it was a very good idea. I >> think we should set up a breakout irc for this. >> >> I would also like to say a few things while they are on my mind. And >> this is just my opinion so take it with a grain of salt: >> >> * keep this library standalone: >> >> I would like to see a new, very lightweight library that just does >> spatial data format access for java projects. All the projects that >> would use it, geotools, jump, udig, geoserver are too heavy to have the >> library incorporated into it. >> >> * keep this thing far away from geoapi >> >> geotools has had a bad tendency to try to invent standard interfaces >> when its not necessary. That is not a use case for this library imho. It >> should just be a library which allows you get java objects from spatial >> data formats, end of story. Not something that toolkits like geotools >> and jump will need to "plug into" to interoperate. >> >> Anyways, my 2c. >> >> -Justin >> >> >> Sunburned Surveyor wrote: >>> A while back I worked with another OpenJUMP Developer and a couple of >>> guys from GeoTools on a framework for what we called DataObjects. A >>> DataObject class could represent simple spatial features or >>> non-spatial features at a very low or abstract level. The goal was to >>> eventually create a DataSource framework providing DataObjects that >>> could be slowly adopted by different Java FOSS GIS programs. This >>> would allow us to share support for common file formats like Shapefile >>> or DXF across programs. >>> >>> We got a couple of interfaces designed, but our energy seemed to taper >>> off when we got close to implementing some code that could actually >>> use DataObjects to translate from GeoTools feature objects to OpenJUMP >>> feature objects or the other way around. >>> >>> Is there any remaining interest in this? I was thinking about seeing >>> if we could get the OSGeo in the involved in the framework at some >>> level. Even if this was just some space on the wiki (a page under >>> http://wiki.osgeo.org/index.php/Java_GIS_Collaboration perhaps) and >>> providing a forum for discussion. I wonder if this would make the >>> framework seem more "neutral" to projects and/or programmers that >>> aren't intimately involved in GeoTools or OpenJUMP. >>> >>> Are there any comments on this? >>> >>> The Sunburned Surveyor >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >> >> -- >> Justin Deoliveira >> The Open Planning Project >> http://topp.openplans.org >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,473a149749822092453641! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
