[Proj] RFC Javascript Proj

[Richard Greenwood]

Hello Proj List Members,

Below is a RFC that I sent to the Mapbuilder developer mailing list.
Mapbuilder is a WMS client:
   http://mapbuilder.sourceforge.net/
   http://mapbuilder.codehaus.org/
It has with a fledgling set of client-side javascript projection
functions. There is considerable interest in extending the functions
into a stand alone library. While the RFC below is aimed at the
Mapbuilder developer community, I would very much appreciate any
comments from the Proj community.

Rich


=== RFC for Proj.js Future Development ===

I would like to share my observations regarding Proj.js and get a
better understanding of what other people's expectations are.
Improvements that have been discussed:

  1. split it into dynamically loaded js files
 2. add more projections
 3. add datum shift support
 4. create an interface that other projects can use
  5. move proj.js into it's own library
 6. give it a new name
  7. setup a new email list to support Proj.js

Item discussion:

  1. split it into dynamically loaded js files

Proj.js is already the largest javascript file in the lib/model
directory. Currently it supports fewer than 200 coordinate systems
(CS), as opposed to >2500 supported by Proj.4
(http://proj.maptools.org/).  Most maps would require only one or two
CS so loading all the code and data to support hundreds or thousands
of Css is undesirable in a web environment.

I suggest a separate javascript file for each supported CS using a CS
definition format similar to the existing one. I suggest a second set
of javascript files for the projection classes, for example:
  ps.js     polar stereographic    containing psinit(), ll2ps(), ps2ll()
  tm.js    transverse mercator    containing tminit(), utminit(),
ll2tm(), tm2ll()
Each CS definition file would then load the appropriate projection
class functions file.

 2. add more projections

This item probably does not require much discussion.

 3. add datum shift support

Currently, Proj.js only converts between spherical to cartesian
coordinates (projects and un-projects).  However a CS is a combination
of 3 things: a projection, a datum, and an ellipsoid. (I am not a
geodecist, so please don't flame me if you don't like my
presentation). An EPSG code defines a CS, not just a projection.
Proj.js assumes that the spherical and planar CSs refer to the same
datum and ellipsoid, or put more bluntly, Proj.js ignores the datum
and ellipsoid.

Skip the next couple paragraphs if you are a geodecist, or if your are
not interested. A datum can be thought of as the origin of a CS. The
origin is the center of the earth, and different datums define
different locations for the center of the earth. Proj.4 defines these
different locations relative to WGS84. Looking in the Proj.4 EPSG file
at the first 3 parameters of +towgs84=x, y, z, ... gives you a feel
for the magnitude of these variations (the parameters are in meters).

An ellipsoid is the definition of the size and shape of the spherical
model. An ellipsoid often has an implied datum, and a datum often has
an implied ellipsoid. The point is that a given point on the earth
will have a different longitude and latitude if that long/lat are
referenced to the Clarke 1866 ellipsoid or the GRS80 ellipsoid.

Users expect to take a WMS map layer in WGS84 and "project" it into
their local CS, but simply projecting it will not give correct results
if their local CS is on a different ellipsoid, or datum.

Proj.js is based on the US Geological Survey's General Cartographic
Transformation Package (GCTP) which, as far as I can see, does not
support transformation between datums or ellipsoids. Datum
transformations range from simple to quite complex. Complex
transformations like NAD27 <=> NAD83 may be outside of the scope of a
client-side browser-based program. The simplest transformation is just
an X, Y, Z shift so that is where I would suggest starting.

 4. create an interface that other projects can use

Various other projects might benefit from a projection, or coordinate
transformation library.
OpenLayers, ka-map, and Mapblender were mention. It would be important
to survey interested projects before any any significant changes were
made to the interface.

  5. move proj.js into it's own library

This relates to item #4 above, i.e. make it broadly useful.

 6. give it a new name

I have two concerns about the name "Proj" or "Proj.js". First, it's
sounds a lot like Proj.4, the existing OS library, but it is currently
based on GCTP. And second, I would to see it go beyond just projection
and provide functionality for full fledged CS transformations.

  7. setup a new email list to support Proj.js

This goes with items #4 and #5 above.

--
Richard Greenwood
richard.greenwood at gmail.com
www.greenwoodmap.com