(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 <[EMAIL PROTECTED]> 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. > > _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
