Re: Fwd: Proj4js updates

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Fwd: Proj4js updates

Michael Adair
Hi Glenn,

Your WMS Context document use-case is exactly the same one I had when I was originally working on Proj4js, and that is where the dynamic loading requirement came from.  However at the time, we didn't have the JavaScript frameworks available which could do that so code for dynamic loading of the defs was included in the library. 

The proposal is to optimize the size of the library (mostly for mobile but it doesn't hurt on the web either) which means removing that code.  I suppose we could keep it as a separate file and include in the build if required, but it would still be up to the calling program to handle the asynchronous nature of loading the definitions.  I suspect JavaScript frameworks such as ExtJs and jQuery have much better was to handle this though.  Would you prefer including a function in the lib or do you have something like jQuery available?


On 21/09/2012 1:48 PM, Glenn Brauen wrote:
Hi Mike,

I've been using proj4js with OpenLayers in a couple of contexts for atlas projects at Carleton University's Geomatics and Cartographic Research Centre.  In one case, I've been using it for map pages where, as you suggest, the selection of the projection to be used in decided as part of the design and loading the projections statically is fine.

In another case though I've been using OpenLayers to load WMS Context documents and these can include extent definitions which are specified in projected coordinates.  In that case, I have a plan that would include, if possible, being able to dynamically load projection information for proj4js after the WMC document is uploaded and processed to create a map panel.  So in this case, being able to load projections dynamically would be useful.

Right now, this case is using a couple of statically defined projections, I know what they are, and I stick with them.  But if I wanted to make this available for use in a classroom situation or similar, it would quickly get beyond the point where I could predict in advance which projections may be used.

So will your changes rule out this possibility in a future version?  That is how I read your proposal.

Thanks for your work on proj4js!

Best regards,
Glenn Brauen, Ph.D.
SSHRC Postdoctoral Fellow
Geomatics and Cartographic Research Centre
Department of Geography and Environmental Studies
Carleton University

Begin forwarded message:

From: Amos Hayes <[hidden email]>
Date: September 10, 2012 1:38:38 PM EDT
To: JP Fiset <[hidden email]>, Glenn Brauen <[hidden email]>
Subject: Fwd: [OpenLayers-Dev] Proj4js updates


Amos Hayes
Geomatics and Cartographic Research Centre
Carleton University, Canada
[hidden email]

Begin forwarded message:

From: Michael Adair [hidden email]
Date: September 10, 2012 1:24:44 PM EDT
To: [hidden email] [hidden email], [hidden email]
Subject: [OpenLayers-Dev] Proj4js updates

Sorry for crossposting but I suspect there are a lot of Proj4js devs on the OL list that aren't on the MetaCRS list and I'd like to get their feedback on this as well.

In any case, as part of getting Proj4js to compile using the Closure library in advanced mode, there is some cleanup that I would like to do at the same time.  I am proposing the following changes:

1. remove the dynamic loading of defs:  this implies that to use Proj4js you would need to have the 'defs' already loaded in your app before trying to create the Proj4js.Proj objects.   Most app frameworks like jQuery support AJAX calls that can be used to load defs dynamically  if required otherwise, I think apps typically know what coordinate systems will be used a priori so they can include the required defs statically.

2. if the library is no longer asynchronous, I suggest we can remove the callbacks passed to the constructor

3. the projection code gets included at compile time, so you can pick some or all of the projection code in a build config file. (eg. if you only need LCC, just include the LCC code in the build).  If you don't know which projection class you need, you can always build with the full code base.

I've got much of this working now (but not checked in yet) and there is some internal changes to the code structure but the external interface remains unchanged, ie. you still call Proj4js.transform() and the Proj4js.Proj constructors are the same except for removing the optional callbacks argument.

Comments welcome,


Dev mailing list
[hidden email]

Dev mailing list
[hidden email]