Difference between revisions of "Shared CRS and CRS Transformation Library"
| Line 18: | Line 18: | ||
this functionality I'll get it posted to the OSGeo Java Collaboration | this functionality I'll get it posted to the OSGeo Java Collaboration | ||
page. | page. | ||
| − | |||
# Identify the things that we can share without major changes to | # Identify the things that we can share without major changes to | ||
each library. I would think at a minimum this would include CRS | each library. I would think at a minimum this would include CRS | ||
definitions and common transformation algorithms. | definitions and common transformation algorithms. | ||
| − | |||
# Identify interfaces in each library that serve the same purpose or | # Identify interfaces in each library that serve the same purpose or | ||
close to the same purpose. These can be targets for interfaces that | 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 | can be moved to a common package shared by both libraries at some | ||
point in the future. | point in the future. | ||
| − | |||
# Determine the development road plan for each library. What changes | # Determine the development road plan for each library. What changes | ||
will be coming to each library in the next month, 6 months, year? If | will be coming to each library in the next month, 6 months, year? If | ||
Revision as of 09:12, 2 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