Thread: [Mapbuilder-proj] cscs/Proj4js

I am copying this to the mapbuilder-proj list. This is a reply to an
off-list discussion between Mike Adair and myself. I'll use 'cscs'
below when referring to the JavaScript.

Following on one of my suggestions from September, I'd like the core
of cscs to be a subset of cs2cs.c. The core would closely parallel
cs2cs.c. I would like to go back and modify some of my work to move it
closer to the C code.  e.g. the forward/inverse functions should
return an XY or LP object rather than modifying the input values by
reference. Returning XY or LP is consistent with cs2cs.c, modifying by
reference is the gctpc convention. Keeping the core close to cs2cs.c
makes maintenance easier, and it makes it easier for other people to
help with porting.

I'd like the core to be very lean, and have no dependencies on other
JS libraries. I would like to leave out lookups. e.g. support
from_greenwich but not pm, to_wgs84 but not datum, etc.

A wrapper could provide a superset of functionality: dynamic loading,
lookups, functionality required by specific implementations like
OpenLayers, etc.

I am in complete agreement on having a unique namespace, but I would
like to see the core stay closer to cs2cs.c. The wrapper could be as
object oriented as you like, because it is original work. There is a
temptation when porting to 'improve' on the original. But those
improvements should go into the original C code first.

For each projection added to the project, I would like to see the
following metadata in comments:
	who added it
	date added
	source (Proj.4, gctpc, other) and version of source
	tests (which forms were tested, which hemispheres, etc.)

With regard to name, I am as opposed to a Proj*.* type name as I ever
was. Naming a new project on a colloquialism is unprofessional, and it
is a disservice to non-English speakers. I've never found GDAL or OGR
especially catchy, but that doesn't appear to have hindered their
adoption. 'CRS' and 'SRS' are commonly used abbreviations. Combined w/
JS that would yield: CRS-JS, JS-CRS, SRS-JS, JS-SRS. I prefer to see a
'G' in there since we are working with specifically with geodetic
coordinate systems.

I am skiing into a yurt for the rest of the week and will not have
email, but I think this is an important discussion.

Rich


-- 
Richard Greenwood
ric...@gm...
www.greenwoodmap.com

Some context for Richard's message below.  We have also determined that 
much of our disagreement in the past stems from the fact that Richard 
viewed cscs as starting a whole new project, whereas I viewed it as the 
evolution of the Proj.js library included in MapBuilder to make it a 
standalone library.

We can really use some input from the community on the architectural 
discussions.  Please comment.

Mike





Richard,

Below I'll use proj4js because it's easier than saying <projectName> but 
I am open to a new name.

Richard Greenwood wrote:
> Mike Adair wrote:
>> Yes, I am always open to discussion.  What code do you want to revert?  
>
> Ideally I'd like to see it revert back to where it was prior to your 
> August 07 changes, and then discuss those changes together. I realize 
> that with the amount of work you have done that is not practical.
>
> I guess before we get into that, the question is whether you will 
> accept input from me on the overall architecture of the project, or if 
> I am just the datum guy.
Yes I will accept input/discussion on the architecture but I don't see a 
whole lot that should be reverted.  The way proj4js works now is pretty 
much the same as cscs worked with the single .transform(src, dest, pt) 
interface.  Some of the things that I think are essential:
- the library must use it's own namespace
- individual 'Proj' objects initialized from the proj4 def string
- allow automatic lookup of def strings from a service like 
spatialreference.org (note that this doesn't preclude an application 
loading a specific set of def files to avoid the automatic lookup)

I'd like to hear specifically what you don't like about the current code 
base and we can discuss.  I would be willing to drop the automatic 
loading of projection class code because the compressed version of the 
library only comes to 57kb which should be acceptable to most.  That 
part was included to minimize that amount of JS code that is loaded.  
And I did intend to remove the .mapXYtoLatLon aliases, but just haven't 
got around to that yet.
>
>> Do you have a suggestion for the name? (I'm sorry but cscs just 
>> doesn't work for me at all)
>
> Proj*.* just doesn't work for me. I am interested in more than a 
> projection library.
The reason that cscs doesn't work for me is because we need a name that 
has a little more marketability, i.e it needs to be catchier than that.  
Yes I agree that is a pretty shallow reason but it is important 
nonetheless if you want people to actually use the library and remember 
it when they hear about it.  The vast majority of people out there don't 
understand or care about the difference between a coordinate system and 
a projection (including me until it was explained to me) and in their 
minds they are simply dealing with projections, and so even if Proj* 
might not be rigorously accurate, that sort of things happens all the 
time for marketing purposes.

Mike




Richard Greenwood wrote:
> I am copying this to the mapbuilder-proj list. This is a reply to an
> off-list discussion between Mike Adair and myself. I'll use 'cscs'
> below when referring to the JavaScript.
>
> Following on one of my suggestions from September, I'd like the core
> of cscs to be a subset of cs2cs.c. The core would closely parallel
> cs2cs.c. I would like to go back and modify some of my work to move it
> closer to the C code.  e.g. the forward/inverse functions should
> return an XY or LP object rather than modifying the input values by
> reference. Returning XY or LP is consistent with cs2cs.c, modifying by
> reference is the gctpc convention. Keeping the core close to cs2cs.c
> makes maintenance easier, and it makes it easier for other people to
> help with porting.
>
> I'd like the core to be very lean, and have no dependencies on other
> JS libraries. I would like to leave out lookups. e.g. support
> from_greenwich but not pm, to_wgs84 but not datum, etc.
>
> A wrapper could provide a superset of functionality: dynamic loading,
> lookups, functionality required by specific implementations like
> OpenLayers, etc.
>
> I am in complete agreement on having a unique namespace, but I would
> like to see the core stay closer to cs2cs.c. The wrapper could be as
> object oriented as you like, because it is original work. There is a
> temptation when porting to 'improve' on the original. But those
> improvements should go into the original C code first.
>
> For each projection added to the project, I would like to see the
> following metadata in comments:
> 	who added it
> 	date added
> 	source (Proj.4, gctpc, other) and version of source
> 	tests (which forms were tested, which hemispheres, etc.)
>
> With regard to name, I am as opposed to a Proj*.* type name as I ever
> was. Naming a new project on a colloquialism is unprofessional, and it
> is a disservice to non-English speakers. I've never found GDAL or OGR
> especially catchy, but that doesn't appear to have hindered their
> adoption. 'CRS' and 'SRS' are commonly used abbreviations. Combined w/
> JS that would yield: CRS-JS, JS-CRS, SRS-JS, JS-SRS. I prefer to see a
> 'G' in there since we are working with specifically with geodetic
> coordinate systems.
>
> I am skiing into a yurt for the rest of the week and will not have
> email, but I think this is an important discussion.
>
> Rich
>
>
>   

Looks like we've been Warnocked [1] on Richard's previous email [2], but 
there are important design questions posed in that email that need 
discussion so I will pose the questions separately and hopefully get 
some discussion on these points:

- in the transform method, should the point be passed in by reference 
and coordinates transformed in place, or should transform just use the 
x,y,z values passed in and return a new point object to the caller?

My preference is to transform the coordinates in place, mostly because 
that is a lot more convenient and efficient in JavaScript than having to 
copy object properties before and after a transformation.  Also, any 
kind of 'point' object can be passed in and as long as it has x,y(z) 
properties, the transform will modify those properties leaving the rest 
of the object intact.

Comments?

Mike



[1] http://en.wikipedia.org/wiki/Warnocked
[2] 
http://sourceforge.net/mailarchive/forum.php?thread_name=ae9185aa0802110929t7dd45f74q78855b9f3b53e065%40mail.gmail.com&forum_name=mapbuilder-proj