Justin, You wrote: "Sure thing. We just implemented it in geotools. Its a good feature model..."
You probably know a lot more about the GeoAPI feature model than I do. You wrote: "...but the more i think about it the more i feel that keeping data format access independent of the feature model is a crucial design decision." That was our goal with the original DataObject concept. You wrote: "Also note that the geoapi feature model adds a significant amount of complexity over whats in jump and geotools. The reason in order to support complex features that rob eludes to." I understand. The main goal of the DataObject framework was to keep things as simple as possible, and to allow projects to add their own brand of complexity, if it is needed, higher up in the stack. I'm going to bounce this off of the OSGeo discuss list and will get back to you. Landon On Nov 14, 2007 9:32 AM, Justin Deoliveira <[EMAIL PROTECTED]> wrote: > Landon, > > Sure thing. We just implemented it in geotools. Its a good feature > model... but the more i think about it the more i feel that keeping data > format access independent of the feature model is a crucial design > decision. Also note that the geoapi feature model adds a significant > amount of complexity over whats in jump and geotools. The reason in > order to support complex features that rob eludes to. > > > Sunburned Surveyor wrote: > > 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 > >>> > >>> > >>> > >> > >> -- > >> > >> Justin Deoliveira > >> The Open Planning Project > >> http://topp.openplans.org > >> > > > > !DSPAM:4007,473b3034208834901796417! > > > > > -- > > 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
