From: Adair, M. <adair@NRCan.gc.ca> - 2007-05-14 17:29:33
|
=20 > -----Original Message----- > From: Richard Greenwood [mailto:ric...@gm...]=20 > Sent: Sunday, May 13, 2007 10:46 > To: Adair, Mike > Cc: olivier.terral; Cameron Shorter;=20 > map...@li...;=20 > map...@li... > Subject: Re: [Mapbuilder-devel] Mapbuilder projections and CSCS >=20 > Mike and I seem to have somewhat different visions of what=20 > cscs should be, and definitely have different priorities. I=20 > don't feel that I have been successful in communicating my=20 > position in previous posts, but I'll give it one last try=20 > here. This is long. >=20 > My vision for cscs: > 1. Client-side (web-browser) JavaScript coordinate=20 > transformation, including datum transformation. > 2. Based on Proj4 code. > 3. Modular, so that the client only has to load code required=20 > for their transformation(s). > 4. Server agnostic (no server-side requirements beyond=20 > serving static JavaScript files). I agree with all the above, with the exception that we can also add some (optional) server-side functionality to help with projection definitions. >=20 > My 'high' priorities, in order: > 1. Substitute cscs for Proj.js in MB. I'll come back to this later. > 2. Port all existing projection functions in Proj.js to cscs=20 > (I've only got Transverse Mercator in there now). > 3. Split all existing EPSG definitions into separate js files. > 4. Add additional projection functions from Proj4, and=20 > associated EPSG definitions. > 5. Add grid shift datum transformation support. (Currently only 3 and > 7 parameter transformations are in there) >=20 > My 'low' priorities, which keep coming up in these exchanges: > 1. JSON. I have nothing against this, but I don't see that it=20 > adds much meaningful functionality. It allows easy run-time=20 > transformation selection, but 99% of the time, the web-app=20 > developer will know what projections/transformations there=20 > app requires ahead of time. Is somebody asking for this? Is=20 > this holding up integration of cscs into MB? If somebody=20 > wants run-time coordinate system selection, we can very=20 > easily provide a single, huge js file containing everything=20 > that we have (same as Proj.js now, but with datum=20 > transformations thrown > in!) This could be part of the build script. Yes most of the time a developer knows what projections will be used and can include them statically, but how often do we get the "how do I get support for EPSG:xyz"? A simple lookup service will solve that problem. This doesn't have to hold up MB integration. > 2. Adopting an OL object style. Again, I have nothing against this. > I've never looked at the OL code, so I don't know what is=20 > really involved here. Can some discussion of this be added to=20 > the MB coding style page in Confluence? I hope this is not=20 > holding up integration of cscs into MB as there are only two=20 > functions that a client needs to call to access cscs=20 > functionality. I want cscs to be an independent library, and=20 > it does not need to adopt the object style du jour to do that. In my opinion, this does hold up MB integration (more than just OL coding style, but the object structure). To get the Proj.js equivalent, you need two cscs objects and there are differences in how the functions get called and it's not just a straightforward substitution as it stands. > 3. WKT coordinate system definitions. This would be a ton of work. > Personally I don't see the need to do it on the client. If=20 > somebody needs this, I think it would be better done on the=20 > server. Can you provide an example of how this would be used?=20 > Is somebody asking for it? Do they have money? Actually a JSON service to return proj4 command line settings is dead simple. And there is demand for this, c.f. the "how do I support EPSG:xyz" questions. Mike |