Difference between revisions of "MetaCRS"

From OSGeo
Jump to navigation Jump to search
 
(41 intermediate revisions by 14 users not shown)
Line 1: Line 1:
 +
'''NOTE: This document has migrated to the MetaCRS Trac Wiki, and is now at: http://trac.osgeo.org/metacrs/wiki/WikiStart'''
 +
 +
------
 +
 +
 
== Background ==  
 
== Background ==  
  
This page is intended as an initial anchor for an OSGeo Project encompassing several projections, and coordinate system related technologies.   
+
MetaCRS is a project encompassing several projections, and coordinate system related technologies.  Our plan is to treat a variety of coordinate system activities as one Project from an OSGeo point of view.  This helps provide enough "project mass" to justify the full OSGeo project treatment.  But more importantly it would give us a forum to cooperate.  Sharing things like coordinate system dictionaries, test suites and mathematical formulations.
 +
 
 +
== Project Steering Committee ==
 +
 
 +
The project steering committee consists of the following individuals and operates according to the [[MetaCRS PSC]] procedures.
 +
 
 +
* Frank Warmerdam (chair)
 +
* Simon Liu
 +
* Norm Olsen
 +
* Mike Adair
 +
* Howard Butler
 +
* Martin Davis
  
My (FrankW) hope was that we could treat a variety of coordinate system activities as one Project from an OSGeo point of view.  This helps get us past the issue that some (all?) of them are rather small in terms of teams
+
== Sub-projects ==
to justify the full "OSGeo project treatment". 
 
  
But more importantly it would give us a forum to cooperate.  Sharing things like coordinate system dictionaries, test suites and such. 
+
The following are sub-projects of MetaCRS:
  
== Potential Participants ==
+
* [http://trac.osgeo.org/proj PROJ.4] - lead - Frank Warmerdam
 +
* [http://trac.osgeo.org/proj4js Proj4js] - lead - Mike Adair
 +
* [http://trac.osgeo.org/csmap CS-Map] - lead - Simon Liu
 +
* [http://geotiff.osgeo.org/ GeoTIFF/libgeotiff] - lead - Frank Warmerdam
 +
* [http://spatialreference.org/ SpatialReference.org] - lead - Howard? Chris?
 +
* [http://trac.osgeo.org/proj4j/ Proj4J] - lead - Martin Davis
  
* [http://docs.codehaus.org/display/MAP/Proj4js proj4js] (Javascript: Rich Greenwood and Mike Adair )
+
== Committers ==
* [http://proj.maptools.org proj.4]
 
* [http://members.verizon.net/~vze2hc4d/proj4/ libproj4] (the projection-only library maintained by Gerald Evenden)
 
* [http://www.gdal.org/ogr/osr_tutorial.html OSGSpatialReference] (GDAL coordinate system translation classes)
 
* CS-Map (the recently open sourced library from Norm Olsen/Autodesk)
 
  
I'm also hopeful that folks from GeoTools, and OSSIM who maintain their own projections code would participate to take advantage of the dictionaries and test suites even though their libraries wouldn't be part of the project.
+
Committers are technically able to commit on any part of MetaCRS but traditionally they have sub-projects on which they focus, and they will avoid commits on other sub-projects without discussion with the project lead.  New committers may be [https://www.osgeo.org/cgi-bin/auth/ldap_group.py?group=metacrs added] after a vote of the PSC.
 +
 
 +
* Howard Butler (hobu): libgeotiff, spatialreference.org
 +
* Mike Adair (madair): Proj4js
 +
* Norm Olsen (normolsen): CS-Map
 +
* Paul Ramsey (pramsey): libgeotiff
 +
* Frank Warmerdam (warmerdam): PROJ.4, libgeotiff
 +
* Chris Schmidt (crschmidt): spatialreference.org
 +
* Richard Didier (drichard): PROJ.4
 +
* Martin Davis (?): Proj4J
 +
* Landon Blake (surveyor): Proj4J, testsuite
 +
* Martin Desruisseaux (desruisseaux): testsuite
  
 
== Mailing list ==
 
== Mailing list ==
Line 36: Line 63:
 
I imagine we will want to use the ''lieutenant model'' of development where particular components are essentially maintained by a chief maintainer.  The project steering committee would establish broad policy (such as contributor rules) and facilitation for shared components (perhaps some dictionaries) while leaving technical direction of some components to their primary maintainer (ie. Norm for CS-Map).  
 
I imagine we will want to use the ''lieutenant model'' of development where particular components are essentially maintained by a chief maintainer.  The project steering committee would establish broad policy (such as contributor rules) and facilitation for shared components (perhaps some dictionaries) while leaving technical direction of some components to their primary maintainer (ie. Norm for CS-Map).  
  
=== So will all these packages live in a single subversion respository with a single Trac instance? ===
+
=== So will all these packages live in a single subversion repository with a single Trac instance? ===
  
This is unclearThis would reduce overhead complexity from a SAC point of view, but it might not have many other benefits. It is important to realize different components will be released on different schedules and so forth. So if they do live in one subversion instance, they would each need their own versioning urls. This could result in svn trees something like:
+
The current plan is to use a single SVN repository for MetaCRS projects (http://svn.osgeo.org/metacrs) with distinct subtrees for each projectBut each project has the option of it's own distinct Trac instance - for example  http://trac.osgeo.org/proj and http://trac.osgeo.org/proj4js.
  
  http://svn.osgeo.org/metacrs/proj4/trunk/
+
=== What are Java developers doing on the mailing list? ===
  http://svn.osgeo.org/metacrs/proj4/branches/4.6.0/
 
  http://svn.osgeo.org/metacrs/csmap/trunk/
 
  ...
 
  
Trac (in my experience) is normally setup with the assumption that it represents one project with a unified concept of versions (for milestones, etc).  To me this seems incompatible with having libraries on their own release cycles.
+
The Java developers come from a range of projects; and are very interested in geeking out about correctness and accuracy issues. There are also a couple opportunities for collaboration (shared testing scripts and the like).   
 +
 
 +
We will seek close cooperation with a variety individuals and organizations interested in interchange of spatial reference system descriptions, and related standards including other open source projects, organizations like OGC, national mapping agencies, and proprietary software developers.
  
 
== Non-Programming Collaboration ==
 
== Non-Programming Collaboration ==
What opportunities are there for collaboration with projection libraries in languges that are not directly compatable with C programming language or C++ programming language libraries? (For example: GeoTools includes functional code for spatial reference systems in Java based on the ESPG database.)
+
What opportunities are there for collaboration with projection libraries in languages that are not directly compatible with C programming language or C++ programming language libraries? (For example: GeoTools includes functional code for spatial reference systems in Java based on the ESPG database.)
  
 
Suggestions:
 
Suggestions:
 
* Common Spatial Reference System or Coordinate Reference System Names and Descriptions
 
* Common Spatial Reference System or Coordinate Reference System Names and Descriptions
* Transformations, calculations, and algorithms written in pseudocode.
+
* Coordinate System (and CRS related object) dictionaries.  Stuff like the EPSG dictionary.
 +
* Datum shift lists (towgs84), and datum grid shift files (NTv1, etc).
 +
* Transformations, calculations, and algorithms written in pseudocode that can be edited in different languages.
 
* Descriptions of spatial reference systems that can be used by developers in different programming languages.
 
* Descriptions of spatial reference systems that can be used by developers in different programming languages.
 +
* Notes on transformation from different representations of a CRS (WKT, PROJ.4, GCTP, GML,...).
 +
* Test suites with test points in a variety of coordinate systems and their lat/long and WGS84 equivalents).
 +
* Articles on spatial reference systems and translations useful for programmers interested in spatial reference system implementations. For example:
 +
** Understanding The Difference Between National Vertical Datum of 1929 and the North American Datum of 1988
 +
 +
== Standard MetaCRS Test Data Files ==
 +
 +
Work has begun on a set of standard test data files that can be used to verify the coordinate transformations/conversions performed by
 +
the various OSGeo projects that fall under the MetaCRS umbrella. You can learn more on the [[Standard MetaCRS Test Data Files]] wiki page.

Latest revision as of 04:58, 8 August 2016

NOTE: This document has migrated to the MetaCRS Trac Wiki, and is now at: http://trac.osgeo.org/metacrs/wiki/WikiStart



Background

MetaCRS is a project encompassing several projections, and coordinate system related technologies. Our plan is to treat a variety of coordinate system activities as one Project from an OSGeo point of view. This helps provide enough "project mass" to justify the full OSGeo project treatment. But more importantly it would give us a forum to cooperate. Sharing things like coordinate system dictionaries, test suites and mathematical formulations.

Project Steering Committee

The project steering committee consists of the following individuals and operates according to the MetaCRS PSC procedures.

  • Frank Warmerdam (chair)
  • Simon Liu
  • Norm Olsen
  • Mike Adair
  • Howard Butler
  • Martin Davis

Sub-projects

The following are sub-projects of MetaCRS:

Committers

Committers are technically able to commit on any part of MetaCRS but traditionally they have sub-projects on which they focus, and they will avoid commits on other sub-projects without discussion with the project lead. New committers may be added after a vote of the PSC.

  • Howard Butler (hobu): libgeotiff, spatialreference.org
  • Mike Adair (madair): Proj4js
  • Norm Olsen (normolsen): CS-Map
  • Paul Ramsey (pramsey): libgeotiff
  • Frank Warmerdam (warmerdam): PROJ.4, libgeotiff
  • Chris Schmidt (crschmidt): spatialreference.org
  • Richard Didier (drichard): PROJ.4
  • Martin Davis (?): Proj4J
  • Landon Blake (surveyor): Proj4J, testsuite
  • Martin Desruisseaux (desruisseaux): testsuite

Mailing list

In order to facilitate further discussion I have created a mailing list. Please join if you have an interest.

 http://lists.osgeo.org/mailman/listinfo/MetaCRS

Practical Questions

Answers are not authoritative - they are one opinion on possible answers.

Are we trying to merge the source into one super-library?

No, though there may be opportunities that arise for consolidation over time.

Is my library/component going to be subject to the whim of other contributors?

I imagine we will want to use the lieutenant model of development where particular components are essentially maintained by a chief maintainer. The project steering committee would establish broad policy (such as contributor rules) and facilitation for shared components (perhaps some dictionaries) while leaving technical direction of some components to their primary maintainer (ie. Norm for CS-Map).

So will all these packages live in a single subversion repository with a single Trac instance?

The current plan is to use a single SVN repository for MetaCRS projects (http://svn.osgeo.org/metacrs) with distinct subtrees for each project. But each project has the option of it's own distinct Trac instance - for example http://trac.osgeo.org/proj and http://trac.osgeo.org/proj4js.

What are Java developers doing on the mailing list?

The Java developers come from a range of projects; and are very interested in geeking out about correctness and accuracy issues. There are also a couple opportunities for collaboration (shared testing scripts and the like).

We will seek close cooperation with a variety individuals and organizations interested in interchange of spatial reference system descriptions, and related standards including other open source projects, organizations like OGC, national mapping agencies, and proprietary software developers.

Non-Programming Collaboration

What opportunities are there for collaboration with projection libraries in languages that are not directly compatible with C programming language or C++ programming language libraries? (For example: GeoTools includes functional code for spatial reference systems in Java based on the ESPG database.)

Suggestions:

  • Common Spatial Reference System or Coordinate Reference System Names and Descriptions
  • Coordinate System (and CRS related object) dictionaries. Stuff like the EPSG dictionary.
  • Datum shift lists (towgs84), and datum grid shift files (NTv1, etc).
  • Transformations, calculations, and algorithms written in pseudocode that can be edited in different languages.
  • Descriptions of spatial reference systems that can be used by developers in different programming languages.
  • Notes on transformation from different representations of a CRS (WKT, PROJ.4, GCTP, GML,...).
  • Test suites with test points in a variety of coordinate systems and their lat/long and WGS84 equivalents).
  • Articles on spatial reference systems and translations useful for programmers interested in spatial reference system implementations. For example:
    • Understanding The Difference Between National Vertical Datum of 1929 and the North American Datum of 1988

Standard MetaCRS Test Data Files

Work has begun on a set of standard test data files that can be used to verify the coordinate transformations/conversions performed by the various OSGeo projects that fall under the MetaCRS umbrella. You can learn more on the Standard MetaCRS Test Data Files wiki page.