<div dir="ltr">I would like to achieve agreement on some basics for a sane collaboration environment, and avoid shuffling repositories between organizations. So if you can't wait to dive into the code, you can fork <a href="http://github.com/ahocevar/proj4js/">http://github.com/ahocevar/proj4js/</a>, because this is the svn clone I'm going to push to either the proj4js or the metacrs org once it's decided.<div>
<br></div><div style>Andreas.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 1:27 PM, Calvin Metcalf <span dir="ltr"><<a href="mailto:calvin.metcalf@gmail.com" target="_blank">calvin.metcalf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Though these are details you can probably set up a repo in an Org account with the caveat that if people object you are happy to change the name of it to an unofficial fork</p>
<div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Jun 18, 2013 7:15 AM, "Andreas Hocevar" <<a href="mailto:ahocevar@opengeo.org" target="_blank">ahocevar@opengeo.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Hey,<div><br></div><div>thanks for your support Calvin. Using a js based build system (npm and grunt) was my goal anyway. Thinking about minification, uglifyjs could indeed be a viable alternative. Closure's line-based dead code elimination will probably not give us much smaller sizes anyway, with the self contained transform functions.</div>


<div><br></div><div>Andreas. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 1:05 PM, Calvin Metcalf <span dir="ltr"><<a href="mailto:calvin.metcalf@gmail.com" target="_blank">calvin.metcalf@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I 100% agree with Andreas with a couple additional goals, </p>
<p dir="ltr">-Get it to pass jshint on fairly strict settings.  The current code is idiosyncratic in places (see the parseWKT function which has a recursive nested switch statement) Which makes hacking it hard. <br>
-unit tests and documentation <br>
-Sensible defaults. 90% of JavaScript maps are going to be going dealing with to/from Lambert conic conformal, transverse Mercator, wgs84 and Google Mercator (maybe one more).  I would like an emphasis on getting those cases yo work out of the box with no downloads, (ie from prj files or based on common epgs numbers). <br>




-more unit tests and documentation. <br>
-lastly and less if a biggie would be to look into tools used by the js community, I. E. Instead of a python build system use grunt or Jake and instead of closure compiler look into uglify. </p>
<p dir="ltr">I'm excited to help it seems to be such a wonderful resource wasting away. </p>
<br>_______________________________________________<br>
MetaCRS mailing list<br>
<a href="mailto:MetaCRS@lists.osgeo.org" target="_blank">MetaCRS@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/metacrs" target="_blank">http://lists.osgeo.org/mailman/listinfo/metacrs</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Andreas Hocevar<br>OpenGeo - <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>Expert service straight from the developers.<br>
</div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
MetaCRS mailing list<br>
<a href="mailto:MetaCRS@lists.osgeo.org">MetaCRS@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/metacrs" target="_blank">http://lists.osgeo.org/mailman/listinfo/metacrs</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Andreas Hocevar<br>OpenGeo - <a href="http://opengeo.org/">http://opengeo.org/</a><br>Expert service straight from the developers.<br>
</div>