[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[udig-devel] Proposals / Summary
|
We need an RnD confluence space to track this stuff, perhaps the
community space will work? I would like to try out ideas in the
community space, and only when people are really happy roll the changes
into uDig trunk. Or for some services package them up as a formal uDig
extension with their own update site.
As a conclusion I briefly count domains we are interested in and going
to add/improve into/in UDIG:
· Topology Data Model as an internal optional “feature” to represent
vector data inside of memory to perform different editing actions and
preserve topology consistence between features.
This can be done, I do not know of any open/source implementations of
Topology off the top of my head. There is interest, someone mentioned it
to geotools as a need about every six months. It should be noted that
many systems "fake it" with a combination of polygons and constraints.
Having real topology is better, but hard to do.
· Rich functionality for vector data validation as for standalone
features with geometry as for the whole layers with dozens of objects
to be validated. Seems great job is being done based on GeoTools
validation functionality and integration it into UDIG.
It is rich, but it will only be complete when users start to make use of
it. Note some work should be done to optimize once random access is
available for shapefile and Postgis.
· MIF support for reading at least. Writing is optional.
There is a MIFDataStore:
-<http://www.geotools.org/MIFDataStore>
I have never used it, we should contact the Module Maintainer.
· Rich functionality for direct communication with databases,
especially Oracle. Creation various complex queries to get only piece
of data we are interested in.
This has seen a lot of recent work, I am the module maintainer and will
be happy to help as I am available. I am CCing Marc Risney who has
offered up an Oracle server for testing, and is being to encouraged to
join geotools in a bit more of a formal capacity.
· Export functionality: export selected layers with vector data in one
shapefile. Probably spatial operations (merging, etc) should be
performed automatically. It concerns cases when attribute data is not
important, only geometry is subject for editing inside of UDIG.
That did not make sense to me :-) There is a gap between exporting,
combining layers and editing. We better break out a separate email.
· Functionality to create and even edit feature type for the whole
layer, setting default value automatically for example, with editing
in the next. Solve all problematic issues that appear with this
functionality.
We have talked about a FeatureType editor, currently the geotools
feature Type model is under revision. After this is completed we should
have something rich enough to build a GEF editor ontop of. Note
FeatureType often gets confused with mutability issues, you can see an
experiment called Meta Information Infrastructure where the Feature
Model was patched a mutable (richer) system in order to specify how
FeatureTypes should be created/generated.
-<http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal>
-<http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastructure>
· Do all this stuff in a such way that is would be acceptable for the
existing plugins, architectures, libraries, data models, object
models, etc…
Well you are already doing just fine - we are talking on the email list.
We should set up a confluence space, so this writing of yours does not
go to waste.
So, I suggest to discuss these questions between all stakeholders to
find the best solutions, not to invent the wheel and determine what we
are really need J
Traditionally we do a breakout IRC session to communicate with all the
open-source stakeholders, if you simply want to talk to Refractions you
can. To communicate with GeoTools you can attend their weekly IRC
meeting and ask for an introduction.
Jody