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
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 comp
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
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 i
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
h
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 GeoTool
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 jod
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
