Re: [Mapbuilder-proj] [OpenLayers-Dev] Projection Support

[Cameron S. <cam...@gm...>]

Chris,
The two key developers behind the proj4js code to date have been Richard 
Greenwood and Mike Adair - as you have noted and discussion has been on 
the mapbuilder-proj email list (copied). I suggest that we continue 
discussion on that list until such time as we as a group decide to move 
elsewhere.

I'm excited to hear of your interest and feedback toward the project. It 
can only take us forward.

Until the code sprint, the master repository has been in the mapbuilder 
repository. While I'm not fussed about where mapbuilder-proj ends up 
(Mike/Richard I think were considering OSGeo) I would like to ensure 
that we keep the svn history. Ie, can we please keep using the 
mapbuilder repository until such time as the whole subversion repository 
is moved. This provides an audit trail which we can use to credit 
developers and keep a copywrite ownership record.

We can organise svn access to mapbuilder if that is required.

Christopher Schmidt wrote:
> Mike Adair worked on some great projection support stuff for OpenLayers
> at the code sprint, and I've been working on making the underlying
> infrastructure for his changes come together. 
>
> The basic principle is that you should not need projection support for
> anything, but if you want it, you can include the proj4js library, and
> it will be there.
>
> To that end, there is:
>
>  * OpenLayers.Projection class, a wrapper around proj4js projection, 
>    and provider of transform function. (#1035)
>  * displayProjection support for controls, so that MousePosition, 
>    Permalink, and ArgParser can display coordinates in a different
>    projection than the projection of the map. (#1036)
>  * geometry.transform function, which transforms a geometry from one
>    projection to another in place. (#1037)
>  * Format internalProjection and externalProjection support, so that
>    geometries are transformed in/out as requested. (#1039)
>  * Vector Layer support for reprojection using format classes (not yet
>    complete)
>
> There are still some API discussions happening here -- Tim had a
> different vision in mind for transformation, and is going to comment at
> some point. Other feedback would also be appreciated: I don't do much
> with transformations, so I don't know what I'm missing here.
>
> To actually do any work, OpenLayers depends on proj4js, a library which
> is, at the moment, in a state of flux. 
>
> Thus far, in order to create code which doesn't need things like proxies
> or remote access, I've been including .js files and projection
> definitions manually. This seems to work relatively well. In order to
> have projection support, you simply include proj4js.js in your page,
> along with the projection:
>     
>     <script src="../lib/proj4js/proj4js.js"></script>
>     <script src="../lib/proj4js/defs/EPSG900913.js"></script>
>
> It seems likely that we will want to assemble tools that let you build a
> customized projection library with all the bits you need put together.
>
> Mike Adair has been working on proj4js, based on Richard Greenwood's
> cscs code, as I understand it. I'm looking at it, and I have a couple
> questions.
>
>  * 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. 
>
>  * 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. 
>  
>  * 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.
>
>  * 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. 
>  
> Mike, I think most of these are directed at you: can you offer feedback
> when you get a chance? (And if you're the wrong person, direct me in the
> right direction?)
>
> In the short term, I'm going to copy the proj4js code into a seperate
> sandbox, which anyone can feel free to hack on, and attempt to build
> what I think I would like to see and help maintain for OpenLayers users.   
>
> Regards,
>   


-- 
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254