Re: [Mapbuilder-proj] cscs/Proj4js

[Mike A. <ma...@dm...>]

Richard,

Great, this sounds like a better dialog.  It seems like the only issues 
to be decided are the name and the API.  (Datums are disabled for the 
moment only because I haven't had time to convert that code over to the 
new format.)

For the API, I can be convinced that transform() could be a 'global' 
method since it depends equally on a source and destination proj 
object.  I think the individual proj objects should still expose 
forward() and inverse(), since they will always be there and are very 
useful in themselves, but I also like the aliases because I can never 
remember which one goes to lon/lat and vice versa.  Using XYZ as the 
project name, the API would look like this:

sourceProj = new XYZ.Proj(projCode1);
destProj = new XYZ.Proj(projCode2);
XYZ.transform(sourceProj, point, destProj);    <- the alternative is 
sourceProj.transform(point, destProj);
lonlat = sourceProj.mapXYToLonLat(XYpoint);
xyPoint = sourceProj.lonLatToMapXY(llPoint);

For the name issue, I'm really not sure what to say. I know that it is 
more technically correct to call these objects coordinate systems, but 
with my (limited) marketing hat on, CSCS just doesn't mean anything to 
me, and I suspect it would be the same  for the large majority of users, 
these are just called projections in the common terminology.  I think we 
would get much more uptake of this library with a better name than CSCS.

Anyone have another suggestions?  Maybe I should ask for a show of hands 
at the demo next week?  I hope you will be in attendance.

Mike


Richard Greenwood wrote:
> Mike,
>
> The project rename and major structural changes certainly leaves me
> feeling disenfranchised. One man's refactroing may be another man's
> hostile take over.
>
> I prefer the term "coordinate system" over "projection" because a
> coordinate system is made up of both a projection and a datum. Adding
> support for datum transformations was the impetus for me to start the
> project.
>
> I think a single entry point is preferable (transform()) to exposing
> forward() and inverse() and aliases thereof. Encouraging the use of
> forward() is going to perpetuate the issues that were coming up on the
> list with the use of proj.js: users will attempt to project WGS84
> lat/long into their local grid, which in many parts of the world is
> not on WGS84, and then be frustrated when they get incorrect results.
>
> You've disabled datum transformation in Proj4.js. As a minimum there
> should be an alert if you're going to encourage people to test and
> integrate the library.
>
> Making transform() a method of a cs does not make sense to me. To
> transform a point you use a method of a cs and then pass another cs as
> a parameter. Kind of reminds me of the ArcView 3.2 transformer. What's
> wrong with transform(src, dest, pt)? If you're determined that
> transform must be a method of something, then making it a method of a
> point seems more logical, e.g. p2 = p1.transform(); Or better,
> overload the equals, e.g. p1 = p2; where a point is comprised of X,Y,
> cs.
>
> I am in favor of putting it into its own namespace.
>
> Dynamic loading of defs and projection class code: I am in favor of
> this. I had the definitions loading dynamically but did not commit it
> because I doubted that my method was consistent with MapBuilder's. I
> had asked about dynamically loading the projection code but didn't get
> an answer. Are you dynamically loading the functions? If so, is there
> an example?
>
> I've never felt like the destination between cs definitions and
> functions was fully respected. Looking up a definition is no big, it's
> just a bunch of ASCII. But spatialreference.org, PostGIS, etc. don't
> provide the functions in JavaScript run by the browser. That's what
> this project is about. By saying that any projection can be handled by
> looking it up in some existent location isn't quite accurate.
>
> Rich
>
> On 9/18/07, Mike Adair <ma...@dm...> wrote:
>   
>> (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 <ma...@dm...> 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.
>>>
>>>
>>>       
>>     
>
>
>