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?
Mike
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
===
Glenn Brauen, Ph.D.
SSHRC Postdoctoral Fellow
Geomatics and Cartographic Research Centre
Department of Geography and Environmental Studies
Carleton University
gl...@gbrauen.ca <mailto:gl...@gbrauen.ca>
https://gcrc.carleton.ca/confluence/x/EoAH
Begin forwarded message:
*From: *Amos Hayes <aha...@gcrc.carleton.ca
<mailto:aha...@gcrc.carleton.ca>>
*Date: *September 10, 2012 1:38:38 PM EDT
*To: *JP Fiset <j...@fiset.ca <mailto:j...@fiset.ca>>, Glenn Brauen
<gl...@gbrauen.ca <mailto:gl...@gbrauen.ca>>
*Subject: **Fwd: [OpenLayers-Dev] Proj4js updates*
FYI.
--
Amos Hayes
Geomatics and Cartographic Research Centre
Carleton University, Canada
aha...@gcrc.carleton.ca <mailto:aha...@gcrc.carleton.ca>
+1.613.520.2600x8179
Begin forwarded message:
From: Michael Adair <mad...@dmsolutions.ca>
Date: September 10, 2012 1:24:44 PM EDT
To: "meta...@lists.osgeo.org" <meta...@lists.osgeo.org>,
openlayers-dev@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,
Mike
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
