Difference between revisions of "MetaCRS"
(add mailing list.) |
|||
| Line 23: | Line 23: | ||
http://lists.osgeo.org/mailman/listinfo/MetaCRS | 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 respository with a single Trac instance? === | ||
| + | |||
| + | This is unclear. This 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: | ||
| + | |||
| + | http://svn.osgeo.org/metacrs/proj4/trunk/ | ||
| + | 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. | ||
Revision as of 10:48, 18 January 2008
Background
This page is intended as an initial anchor for an OSGeo Project encompassing several projections, and coordinate system related technologies.
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 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.
Potential Participants
- proj4js (Javascript: Rich Shepard and Mike Adair )
- proj.4
- libproj4 (the projection-only library maintained by Gerald Evenden)
- 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.
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 respository with a single Trac instance?
This is unclear. This 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:
http://svn.osgeo.org/metacrs/proj4/trunk/ 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.