<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Glenn,<br>
    <br>
    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.  <br>
    <br>
    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?<br>
    <br>
    Mike<br>
    <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 21/09/2012 1:48 PM, Glenn Brauen
      wrote:<br>
    </div>
    <blockquote
      cite="mid:8F433257-537D-43CE-AB57-003117C79F2A@gbrauen.ca"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=us-ascii">
      Hi Mike,
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>So will your changes rule out this possibility in a future
        version?  That is how I read your proposal.</div>
      <div><br>
      </div>
      <div>Thanks for your work on proj4js!</div>
      <div><br>
      </div>
      <div>Best regards,</div>
      <div>Glenn</div>
      <div>===</div>
      <div>
        <div>Glenn Brauen, Ph.D.</div>
        <div>SSHRC Postdoctoral Fellow</div>
        <div>Geomatics and Cartographic Research Centre</div>
        <div>Department of Geography and Environmental Studies</div>
        <div>Carleton University</div>
        <div><a moz-do-not-send="true" href="mailto:glenn@gbrauen.ca">glenn@gbrauen.ca</a></div>
        <div><a moz-do-not-send="true"
            href="https://gcrc.carleton.ca/confluence/x/EoAH">https://gcrc.carleton.ca/confluence/x/EoAH</a></div>
        <div><br>
        </div>
      </div>
      <div>
        <div>
          <div>Begin forwarded message:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div><span><b>From: </b></span><span>Amos Hayes <<a
                  moz-do-not-send="true"
                  href="mailto:ahayes@gcrc.carleton.ca">ahayes@gcrc.carleton.ca</a>><br>
              </span></div>
            <div><span><b>Date: </b></span><span>September 10, 2012
                1:38:38 PM EDT<br>
              </span></div>
            <div><span><b>To: </b></span><span>JP Fiset <<a
                  moz-do-not-send="true" href="mailto:jp@fiset.ca">jp@fiset.ca</a>>,
                Glenn Brauen <<a moz-do-not-send="true"
                  href="mailto:glenn@gbrauen.ca">glenn@gbrauen.ca</a>><br>
              </span></div>
            <div><span><b>Subject: </b></span><span><b>Fwd:
                  [OpenLayers-Dev] Proj4js updates</b><br>
              </span></div>
            <br>
            <div><br>
              FYI.<br>
              <br>
              --<br>
              Amos Hayes<br>
              Geomatics and Cartographic Research Centre<br>
              Carleton University, Canada<br>
              <a moz-do-not-send="true"
                href="mailto:ahayes@gcrc.carleton.ca">ahayes@gcrc.carleton.ca</a><br>
              +1.613.520.2600x8179<br>
              <br>
              <br>
              <br>
              Begin forwarded message:<br>
              <br>
              <blockquote type="cite">From: Michael Adair
                <a class="moz-txt-link-rfc2396E" href="mailto:madair@dmsolutions.ca"><madair@dmsolutions.ca></a><br>
              </blockquote>
              <blockquote type="cite">Date: September 10, 2012 1:24:44
                PM EDT<br>
              </blockquote>
              <blockquote type="cite">To: <a class="moz-txt-link-rfc2396E" href="mailto:metacrs@lists.osgeo.org">"metacrs@lists.osgeo.org"</a>
                <a class="moz-txt-link-rfc2396E" href="mailto:metacrs@lists.osgeo.org"><metacrs@lists.osgeo.org></a>,
                <a class="moz-txt-link-abbreviated" href="mailto:openlayers-dev@lists.osgeo.org">openlayers-dev@lists.osgeo.org</a><br>
              </blockquote>
              <blockquote type="cite">Subject: [OpenLayers-Dev] Proj4js
                updates<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">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.<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">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:<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">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.<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">2. if the library is no longer
                asynchronous, I suggest we can remove the callbacks
                passed to the constructor<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">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.<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">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.<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">Comments welcome,<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">Mike<br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite"><br>
              </blockquote>
              <blockquote type="cite">_______________________________________________<br>
              </blockquote>
              <blockquote type="cite">Dev mailing list<br>
              </blockquote>
              <blockquote type="cite"><a class="moz-txt-link-abbreviated" href="mailto:Dev@lists.osgeo.org">Dev@lists.osgeo.org</a><br>
              </blockquote>
              <blockquote type="cite"><a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/openlayers-dev">http://lists.osgeo.org/mailman/listinfo/openlayers-dev</a><br>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>