Difference between revisions of "Shared CRS and CRS Transformation Library"
| Line 41: | Line 41: | ||
* Can we come up with a list of classes or interfaces that the GeoTools and deegree libraries have in common, and then work on refactoring out a common set of interfaces that can be placed in a shared library? | * Can we come up with a list of classes or interfaces that the GeoTools and deegree libraries have in common, and then work on refactoring out a common set of interfaces that can be placed in a shared library? | ||
* What are the sources of projection information available to us (EPSG, PROJ4) and how will a shared library incorporate or integrate those sources? Will we define our own "open" format for CRS definitions? How will this be maintained? | * What are the sources of projection information available to us (EPSG, PROJ4) and how will a shared library incorporate or integrate those sources? Will we define our own "open" format for CRS definitions? How will this be maintained? | ||
| + | |||
| + | == Existing Libraries == | ||
| + | |||
| + | * [[Java CRS: Details on Deegree CRS Code]] | ||
| + | * [[Java CRS: Details on GeoTools CRS Code]] | ||
| + | * [[Java CRS: Details on GeoAPI CRS Code]] | ||
| + | * [[Java CRS: Details on CRS Code By Paul Austin]] | ||
| + | * [[Java CRS: Details on CRS Code By Michael Michaud]] | ||
Revision as of 11:04, 5 May 2008
Introduction
This page was created for information and discussion on a library for CRS and CRS transformations that might be shared among Kava GIS programs.
Moving Forward
I don't think it is realistic for us to expect either GeoTools or deegree to abandon their existing CRS code. However, I think we can start laying the foundation for a shared library at some point in the future, even if it is a couple of years away. This is the approach Jody and I discussed with the DataObjects framework for obtaining a generic Feature object from common spatial file formats.
Proposed Tasks
I believe that we can move forward with the following tasks:
- Identify what the GeoTools and deegree CRS source code is
currently capable of. What can each library do and what can't it do? If a programmer from each project can send me a short description of this functionality I'll get it posted to the OSGeo Java Collaboration page.
- Identify the things that we can share without major changes to
each library. I would think at a minimum this would include CRS definitions and common transformation algorithms.
- Identify interfaces in each library that serve the same purpose or
close to the same purpose. These can be targets for interfaces that can be moved to a common package shared by both libraries at some point in the future.
- Determine the development road plan for each library. What changes
will be coming to each library in the next month, 6 months, year? If we can answer this question we can find opportunities to build similarities into each library as they develop. The result will be two libraries that grow closer together instead of farther apart.
The Sunburned Surveyor
Issues For Discussion
- Use of ISO 19111 as a document to guide implementation of any library or shared interfaces.
- Use of JSR-275 in any library.
- Where do we want to strike the balance between complexity and simplicity? Can we have a simple core set of packages for the most common use scenarios, and an extended set of packages for the hard core geodesists among us?
- How will we handle licensing and copyright issues? Can we host the code for any shared library in an existing project like GeoTools, GeoAPI, or deegree?
- Can we come up with a list of classes or interfaces that the GeoTools and deegree libraries have in common, and then work on refactoring out a common set of interfaces that can be placed in a shared library?
- What are the sources of projection information available to us (EPSG, PROJ4) and how will a shared library incorporate or integrate those sources? Will we define our own "open" format for CRS definitions? How will this be maintained?