Difference between revisions of "(Java FOSS GIS) DataObject Framework"
| Line 2: | Line 2: | ||
One great opportunity for GeoJOP's (Geospatial Java Open Source Programs) to share code is by writing components responsible for moving "features" to and from data sources. Some initial work has been done on a framework that would allow GeoJOP's to do just that. This framework focuses on a highly abstract and very simple representation of a feature known as a DataObject. A DataObject is simply a collection of named attributes whose data types and values match a schema. A DataObject can be used to represent a Simple Feature, but could also be used to represent a non-spatial feature, since there is no requirement for a spatial attribute. (The DataObject is not required to contain an attribute that stores a representation of feature's location.) | One great opportunity for GeoJOP's (Geospatial Java Open Source Programs) to share code is by writing components responsible for moving "features" to and from data sources. Some initial work has been done on a framework that would allow GeoJOP's to do just that. This framework focuses on a highly abstract and very simple representation of a feature known as a DataObject. A DataObject is simply a collection of named attributes whose data types and values match a schema. A DataObject can be used to represent a Simple Feature, but could also be used to represent a non-spatial feature, since there is no requirement for a spatial attribute. (The DataObject is not required to contain an attribute that stores a representation of feature's location.) | ||
| + | |||
| + | Programs like UDig or OpenJUMP will need to convert DataObjects to their own internal feature model before use. This can be done "higher in the software stack" allowing programmers to work together on lower levels of the stack, such as data access. | ||
== Our Goal == | == Our Goal == | ||
Latest revision as of 13:31, 14 November 2007
Introduction
One great opportunity for GeoJOP's (Geospatial Java Open Source Programs) to share code is by writing components responsible for moving "features" to and from data sources. Some initial work has been done on a framework that would allow GeoJOP's to do just that. This framework focuses on a highly abstract and very simple representation of a feature known as a DataObject. A DataObject is simply a collection of named attributes whose data types and values match a schema. A DataObject can be used to represent a Simple Feature, but could also be used to represent a non-spatial feature, since there is no requirement for a spatial attribute. (The DataObject is not required to contain an attribute that stores a representation of feature's location.)
Programs like UDig or OpenJUMP will need to convert DataObjects to their own internal feature model before use. This can be done "higher in the software stack" allowing programmers to work together on lower levels of the stack, such as data access.
Our Goal
To have a simple API that can be used to represent features in a highly abstract and simple way. This representation should accomplish the following goals:
- Facilitate easy conversion to and from more complex feature models.
- Serve as vehicle that can be used to move data between more complex feature models and data sources, like an ESRI Shapefile or DXF file.
Why Aren't We Using GeoTools or GeoAPI
- We want to keep data source access independent of more complex feature models. (We don't want a programmer writing and maintaining a data source reader/writer to worry about a more complex feature model. Leave that to the program using the more complex feature model.)
- We want a simple feature model whose API is stable, so maintenance of data source reader/writers is as low as possible.
Data Source We Would Like To Support
- ESRI Shapefiles
- AutoDESK DXF
- Paul Austin's TOF Format (Comma Separated Values)
- GML 2.0
Get The Code
Initial source code can be found at the SurveyOS Subversion Repository.
http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/collaboration/