[OpenLayers-Dev] Fwd: Proj4js updates
madair at dmsolutions.ca
Fri Sep 21 12:06:48 PDT 2012
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
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
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
> glenn at gbrauen.ca <mailto:glenn at gbrauen.ca>
> Begin forwarded message:
>> *From: *Amos Hayes <ahayes at gcrc.carleton.ca
>> <mailto:ahayes at gcrc.carleton.ca>>
>> *Date: *September 10, 2012 1:38:38 PM EDT
>> *To: *JP Fiset <jp at fiset.ca <mailto:jp at fiset.ca>>, Glenn Brauen
>> <glenn at gbrauen.ca <mailto:glenn at gbrauen.ca>>
>> *Subject: **Fwd: [OpenLayers-Dev] Proj4js updates*
>> Amos Hayes
>> Geomatics and Cartographic Research Centre
>> Carleton University, Canada
>> ahayes at gcrc.carleton.ca <mailto:ahayes at gcrc.carleton.ca>
>> Begin forwarded message:
>>> From: Michael Adair <madair at dmsolutions.ca>
>>> Date: September 10, 2012 1:24:44 PM EDT
>>> To: "metacrs at lists.osgeo.org" <metacrs at lists.osgeo.org>,
>>> openlayers-dev at lists.osgeo.org
>>> 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
>>> Dev at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev