[OpenLayers-Users] cscs/Proj4js

[Mike Adair]

(Moving this to the mapbuilder-proj list with a proper subject line.  
Please reply to that list only)

Richard,

I really hope we can resolve your concerns over the recent work done on 
this project.  I have no intention of "duking it out", I only want to 
end up with a solid coordinate transformation library, with a small 
footprint and one that makes it as easy as possible for the end-user to 
do coordinate transformations in the browser.  This piece is too 
important for the whole JS client community to let it flounder in an 
argument like this.

The work that you and others have done to date to get cscs where it is, 
is great and in fact I haven't touched the actual code within the 
various methods, all I've done is to change the way the various objects 
are structured to use modern JavaScript techniques. 

Perhaps by listing the issues (as I see them) we can resolve them 
together.  Feel free to add your own issues to the list:

1. The name of the project:  just about anyone I talk to about this has 
no idea what 'cscs' is.  I think that Proj4js is a much more descriptive 
name in  that it tells where it came from (Proj4), it deals with 
Projections, and it is a JS library for browser clients.  I can live 
with  'cscs' as the name , but I feel that we would loose many potential 
end-users because no one really knows what 'cscs' is.

2. Object-oriented-ness:  Any external library like this that is to be 
included in other projects should use it's own namespace so that you 
avoid naming collisions and re-defining functions and properties 
accidentally.  This also allows us to define things like Proj4js.const 
which includes library-wide constants and methods that get used over and 
over (e.g. all the msfnz, tsfnz, etc. methods that are repeated in every 
projection class code).  I think this should be done no matter what the 
project is called because it is just good programming technique.

3. dynamic loading of defs and projection class code: this is something 
I had always intended to implement, no matter what the project is 
called.  The issue is that in cscs, you always need to specify the 
cslist.defs files and projection code (e.g. lcc.js) when an application 
is being created.  That is fine if you know beforehand what projections 
your application is dealing with, but in my experience, there are many 
cases where you don't know that beforehand.  Dynamic loading of this 
information allows the library to handle practically any projection, 
which is a huge bonus in my opinion.

4. Proj objects: I feel that the changes I made to the Proj objects make 
a lot of sense.  You still have the transform() method available, 
passing in a second Proj object, but in a lot of cases the coord 
transformation required is simply a MapXY to Lon/Lat and vice versa, 
without creating a second Proj object.  I've also defined aliases for 
forward()/inverse() methods as mapXYToLonLat() and lonLatToMapXY() to 
make them easier to understand.

Like I said above, my intention here is to end up with the best 
coordinate transformation library possible, and I think these are some 
of the steps needed to move cscs to get there.  The work you have done 
on cscs to date is invaluable, so I really hope your contributions to 
this project continue. Maybe all it will take is for us to sit down over 
a beer and a scratch pad at FOSS4G next week, but hopefully we can come 
to an agreement sooner than that.  Comments from the community are also 
welcome.

Mike



Richard Greenwood wrote:
> On 9/17/07, Mike Adair <madair at dmsolutions.ca> wrote:
>   
>> Yes cscs did have that problem.  However the Proj4js version loads only
>> the projection class code required based on the projection definition so
>> you never need to worry about that.   If you know beforehand what
>> projections your app will be dealing with, you can also load the code
>> statically.
>>     
>
> cscs does not "have that problem" if you are referring to functions
> being duplicated. cscs transformation functions are only defined once.
> It's a bummer that cscs and Proj4js have split so early in their
> respective development. And it's a bummer that we need to "duke it
> out" next week. Seems like we'd get a lot further by working together.
>
>   
>> The advantage of the Proj4js approach is that as long as the Proj4
>> initialization parameters are available somewhere (statically on disk,
>> or in a Web Service like spatialreference.org, or a local interface to
>> PostGIS) any projection can be handled.
>>     
>
> There's a lot more to a coordinate system transformation than its
> Proj4 initialization parameters. You need the forward/inverse
> functions, and you need the appropriate datum transformation
> functions. And they need to be in JavaScript if you're going to do it
> on the client.
>
>