[OpenLayers-Dev] Projection Support

[Mike Adair]

> To actually do any work, OpenLayers depends on proj4js, a library which
> is, at the moment, in a state of flux. 
>   
The API as defined now should be pretty stable from now on.  What's left 
to do is converting existing projection class code and port of new 
classes from Proj.4 to Proj4js (sounds like a good summer of code 
project).  Also left for me is to check in the code I have to the cscs 
directory which has all the dynamic loading stuff that is in the OL demo.

>  * Where is the current canonical home for the code? There is definitely a 
>    version of it in Mapbuilder's cscs/trunk, but the version in
>    http://svn.openlayers.org/sandbox/madair/lib/proj4js/ seems to have
>    most of the remote loading stuff added on to it, and so I think
>    that's the newer version of the code. 
>   
Definitive version should be in 
http://svn.codehaus.org/mapbuilder/cscs/trunk/cscs but as I said I have 
stuff to check in still.  I'll do that ASAP.
>  * Where should the code live? I'm happy putting it anywhere, but right
>    now it feels scattered and I'm lost as to where improvements should
>    be done. I'd like to start hacking on the library, as well as
>    documenting it better. I think we need to be looking at making it a
>    full on library in and of itself, which (again) can live wherever.
>
>    Eventually, I think it seems likely that we will want to move this
>    into an OSGeo code repository. In the short term, I think that
>    identifying a single SVN repository and keeping it there, and 
>    documenting where 'there' is, is the first step forward.
>
>    Mike, where would you like to keep this code? For the purposes of
>    provenance review and the like, I'd like to keep it out of OL SVN as
>    a primary home -- you have commit access to the Mapbuilder SVN, and
>    I'm happy to maintain it there while pursuing possible future
>    arrangements. 
>   
Frank W. has started a discussion on the OSGeo list to resolve this, and 
it is also related to the supporting new projects thread there. 
Personally I think it is a great idea to consolidate coordinate 
transformation stuff on OSGeo somewhere, both client side and 
server-side stuff.  We should be able to gather enought of a community 
around that to make it viable in the long term.  In the meantime, the 
mapbuilder/csc svn should be the definitive repository for this.

>  
>  * How is the code managed? I don't know much about the code, but I do
>    know that right now, there are things like API naming and the like
>    that bother me. Who do I take that to? 
>
>    Specifically, I don't like the '_reportError' style naming, and I'd
>    like to do a number of cleanups to make proj4js more
>    "OpenLayers-like" in style. (Dropping _, picking a standard for
>    whitespace, stuff like that.) I don't mind leaving things the way
>    they are if someone else is going to be maintaining the library, but
>    right now, it feels like it's not usable in OpenLayers, and I'd like
>    to change that.
>   
Right now it seems to be Richard and myself.  I was using the _ 
prepending to indicate private methods, but I'm open to other 
suggestions.  The point is that any automatically generated 
documentation should just show the Proj constructor and the .transform() 
method.  Users should never have to worry about any of the other methods 
in the library.
>  * Creating a service where you can build your own projection javascript
>    library based on the appropriate pieces from proj4js and the EPSG
>    data seems like a good thing that we should work on. I'm happy to
>    take the lead on that and building other similar tools for managing
>    the proj code based on the OpenLayers stuff. 
>   
Yes some experimentation on how best to load the required data and code 
is needed.  I'm also interested in seeing some other metadata around 
projections be supported (e.g. bbox for applicability of a particular 
projection, a set of test points for each code, etc.)  ie. some of the 
same metadata that is available to the spatialreference.org pages.

Mike