Hey, Others will have better answers I'm sure but here's 2cents.
On Thu, 2006-09-28 at 13:07 -0700, Sunburned Surveyor wrote: > I had a couple of quick questions about UDig. I'll be designing a > couple of new tools for OpenJUMP, and was trying to think about how I > can make them easier to port to UDig. > > Basically, I want to facilitate some code sharing if possible. > > Here are my questions: > > [1] Is there any documentation that explains UDig's data source > framework? ( By data source, I mean something that represents a source > of features, like an ESRI Shapefile, for instance.) If there isn't any > of this documentation, where would I look in UDig's source code for > the appropiate classes? Getting access to data involves two separate layers in uDig. The first is the catalog (for now, part of uDig) and the second is the DataStore which is part of geotools. In uDig the user can add the shapefile to the catalog through the GUI. You can then get at the features programmatically if you have the name of the shapefile, which gets used in the form of a URI. You ask the catalog to give you a handle and then use that handle to get a FeatureSource or some simliar generator of features from the shapefile. There are some docs on the uDig wiki about this---poke around. > > [2] Jody had mentioned something about a "generic" geometry classes > that might become a part of GeoTools. I'll be working on some > precision drafting tools for OpenJUMP. Instead of having these tools > "hardwired" to JTS I'd like to use a "generic" geometry system. (This > will allow OpenJUMP to more easily support multiple geometry libraries > in the future.) > > Does UDig have any plans to implement this abstraction of objects used > to represent feature geometries? This work has been pushed back until (1) geotools gets a clean factory system and (2) the new feature model lands. The 'generic' geometries will be implementations of geoapi so you should look at the bleeding edge of that project to see the interfaces which will eventually be used. Be sure to keep separate the pure geometric side from the georeferenced 'directposition' side. > > If UDig and OpenJUMP used the same abstraction of objects that > represent feature geometries the "engine" of most of my CAD tools > could be ported to UDig. (I think the GUI portions of the tools > wouldn't be of much use to you guys, because they'll be built on > Swing. > > [3] Have you guys ever discussed a "native" data storage format that > doesn't rely on an external database like PostgreSQL but overcomes the > limitations of ESRI Shapefiles? I've given a lot of thought to this > concept, which I called the "Open Geospatial Database" and I think it > would be great if both OpenJUMP and UDig adopted the same native data > storage format. There are 'in memory' databases if that's of interest. There's also GML. It's not really clear what you mean by this concept but uDig/geotools have a bunch of different formats each with its very own benefits and tradeoffs. --adrian > > Let me know what you guys think. If I can design these new tools for > OpenJUMP in a way that plays nice with UDig, I'd like to do that. > > The Sunburned Surveyor > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
