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
