Justin, Let me investigate the feature model maintained by GeoAPI. I remember looking at it when this issue came up before, but I can't remember why we decided not to use it. I should have good reasons for suggesting something new, as Rob stated.
I'll poke around on the GeoAPI list. I may respond to this list with some questions and more comments. Landon On Nov 14, 2007 8:13 AM, Justin Deoliveira <[EMAIL PROTECTED]> wrote: > 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
