Proj4js updates

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proj4js updates

Michael Adair
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proj4js updates

Timothy Astle
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev



--
Tim Astle
Development Manager
Web Technologies

CARIS
115 Waggoners Lane
Fredericton, New Brunswick
Canada    E3B 2L4
Tel: +1.506.458.8533     Fax: +1.506.459.3849
www.caris.com

Connect with CARIS
Twitter | LinkedIn | Facebook | Google+ | YouTube

Download your free copy of CARIS Easy View today!
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proj4js updates

Michael Adair
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev



--
Tim Astle
Development Manager
Web Technologies

CARIS
115 Waggoners Lane
Fredericton, New Brunswick
Canada    E3B 2L4
Tel: +1.506.458.8533     Fax: +1.506.459.3849
www.caris.com

Connect with CARIS
Twitter | LinkedIn | Facebook | Google+ | YouTube

Download your free copy of CARIS Easy View today!
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev