Hi Tim,
Yes the changes would go directly into trunk. If you are including this
in other software, it's probably best to use a released version (which
is basically a zipped up SVN repo)
http://trac.osgeo.org/proj4js/wiki/Download
Mike
On 10/09/2012 1:42 PM, Timothy Astle wrote:
Hi Michael,
Is this commit going straight into the trunk? If I recall, most work
is done on the trunk of Proj4js.
The reason that I ask is because we provide Proj4js as part of our
software. I'd like to get a feeling on how this change is being
managed so we can be prepared for the in behaviour. It'd be good to
know the last revision (or have a tagged release) prior to this change.
I do like your proposition. Using AJAX calls for loading definitions
would open doors to using Proj4js. We can then handle cases where an
AJAX call fails to load the definition.
Cheers!
Tim
http://ucode.caris.com/oscar/
On 10/09/2012 2:24 PM, Michael Adair wrote:
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
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
--
Tim Astle
Development Manager
Web Technologies
*CARIS* <http://www.caris.com>
115 Waggoners Lane
Fredericton, New Brunswick
Canada E3B 2L4
Tel: +1.506.458.8533 Fax: +1.506.459.3849
www.caris.com <http://www.caris.com>
*Connect with CARIS*
Twitter <http://www.twitter.com/CARIS_GIS> | LinkedIn
<http://www.linkedin.com/groups?mostPopular=&gid=3217878> | Facebook
<https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878>
| Google+
<https://plus.google.com/b/114389770462919844434/114389770462919844434/posts>
| YouTube <http://www.youtube.com/user/CARISGIS>
Download your free copy of CARIS Easy View today!
www.caris.com/easyview <http://www.caris.com/easyview>
_________________________________________________________________________
This email and any files transmitted with it are confidential and
intended only for the addressee(s). If you are not the intended
recipient(s) please notify us by email reply. You should not use,
disclose, distribute or copy this communication if received in error.
Any views or opinions expressed in this email are solely those of the
author and do not necessarily represent those of the company. No
binding contract will result from this email until such time as a
written document is signed on behalf of the company.
_______________________________________________
Dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
