[MetaCRS] Proj4js

[Andreas Hocevar]

Hey,

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.

Andreas.


On Tue, Jun 18, 2013 at 1:05 PM, Calvin Metcalf <calvin.metcalf at gmail.com>wrote:

> I 100% agree with Andreas with a couple additional goals,
>
> -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.
> -unit tests and documentation
> -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).
> -more unit tests and documentation.
> -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.
>
> I'm excited to help it seems to be such a wonderful resource wasting away.
>
> _______________________________________________
> MetaCRS mailing list
> MetaCRS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/metacrs
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
>
>  <http://lists.osgeo.org/mailman/listinfo/metacrs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/metacrs/attachments/20130618/34bda4f7/attachment.html>