Difference between revisions of "Shared CRS and CRS Transformation Library"
Jump to navigation
Jump to search
(New page: This page was created for information and discussion on a library for CRS and CRS transformations that might be shared among Kava GIS programs. I don't think it is realistic for us to exp...) |
|||
| (6 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | =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. | 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 | 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 | deegree to abandon their existing CRS code. However, I think we can | ||
| Line 8: | Line 10: | ||
generic Feature object from common spatial file formats. | generic Feature object from common spatial file formats. | ||
| + | =Proposed Tasks= | ||
I believe that we can move forward with the following 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? | 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 | 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 | 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 | |
| − | |||
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 | |
| − | |||
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 | |
| − | |||
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 | ||
we can answer this question we can find opportunities to build | we can answer this question we can find opportunities to build | ||
| Line 31: | Line 31: | ||
libraries that grow closer together instead of farther apart. | libraries that grow closer together instead of farther apart. | ||
| − | The Sunburned Surveyor | + | '''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? | ||
| + | |||
| + | == 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]] | ||
Latest revision as of 01:28, 19 April 2010
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?