Shared CRS and CRS Transformation Library - Revision history

Wiki-Mays: /* Existing Libraries */

2010-04-19T09:28:57Z

Existing Libraries

Wiki-Sunburned Surveyor at 19:04, 5 May 2008

2008-05-05T19:04:43Z

Wiki-Sunburned Surveyor at 14:53, 5 May 2008

2008-05-05T14:53:50Z

Wiki-Sunburned Surveyor at 17:25, 2 May 2008

2008-05-02T17:25:37Z

Wiki-Sunburned Surveyor at 17:25, 2 May 2008

2008-05-02T17:25:24Z

Wiki-Sunburned Surveyor at 17:12, 2 May 2008

2008-05-02T17:12:28Z

Wiki-Sunburned Surveyor at 17:12, 2 May 2008

2008-05-02T17:12:18Z

Wiki-Sunburned Surveyor: 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...

2008-05-02T17:11:41Z

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...

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 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.

I believe that we can move forward with the following tasks:

[1] 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.

[2] 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.

[3] 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.

[4] 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

@@ Line 44: / Line 44: @@
 == Existing Libraries ==
-* [[Java CRS: Details on Deegree CRS Code]]
+* [[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]]

← Older revision		Revision as of 19:04, 5 May 2008
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]]

← Older revision		Revision as of 14:53, 5 May 2008
Line 32:		Line 32:

	'''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?

← Older revision		Revision as of 17:25, 2 May 2008
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'''

@@ Line 13: / Line 13: @@
 I believe that we can move forward with the following tasks:
-# Identify what the GeoTools and deegree CRS source code is
+*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
+*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
+*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
+*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
@@ Line 31: / Line 31: @@
 libraries that grow closer together instead of farther apart.
-The Sunburned Surveyor
+''The Sunburned Surveyor''