This gets to an issue thats been bothering me for some time - the separation
of concerns with geotools. Generally speaking, there are some operations
that require a trivial view of business data, such as rendering to a map,
and others that require manipulation of the data, and others that require
high integrity transfer. By forcing all these concerns into a single
datastore interface, you get the inevitable "you can any color as long as
its black" (simple features). And even then we get tripped up by native
operations on the data store vs representation of data (passing a filter).
Rendering or simple GIS operations only requires an efficient conversion of
a set of objects into geometries with identity.
We have been caught in the middle doing neither job well.
IMHO, a datastore supporting "complex features" is required to handle the
operations properly (i.e. to be able to run queries with joins eventually).
We are getting close to this, but now realising that that the format
conversion is now hidden deep inside this module, when its potentially
reusable.
So, how do we promote a simple "turn an identified set of objects into a set
of geometries in Java" without getting caught in the trap of creating two
code bases? My gut feel is to keep the concept of feature (an object with
identity and behaviours) from some sort of "renderable geometry set".
Alternatively, we need to abstract the filter handling from the data
conversion, and create something like:
Query -> virtual set of objects using native format API ->
nativeFormatconvert -> feature (or lightweight geometry set)
this could then be used as suggested
file -> nativeFormatconvert -> lightweight geometry set
The puts an extra burden on each data store to expose the selected data as
if it was the native format.
anyway, 2c worth :-)
Rob A
On 11/14/07, Sunburned Surveyor <[EMAIL PROTECTED]> 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
> > >
> > > !DSPAM:4007,4739fb94297381431913854!
> > >
> >
> >
> > --
> > 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
>
-------------------------------------------------------------------------
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
