[OpenLayers-Users] proj4js question
Patrick Valsecchi
patrick.valsecchi at camptocamp.com
Wed Jul 23 14:34:10 EDT 2008
Hi Bart,
On Wednesday 23 July 2008, you wrote:
> I am using the transform function of OpenLayers, which in its turn calls
> proj4js, should it change the transformed property for all the points in a
> geometry in your opinion? That does not seem effective does it?
Like Christopher said, you shouldn't have any reason to transform your
coordinates twice.
But, if you are like me and your application allows the user to switch
projections multiple times by using a combobox, then your application may
apply transformation more than once on your objects. Or you should always
keep a copy of the geometries in the original projection to avoid
approximation errors.
On one hand, proj4j is sparing some memory (I'm the first one to encourage
that, especially with a garbage collector in the way) by replacing the values
in the passed object, but, on the other hand, it adds a field to this object
eating some more memory. If it's for avoid some bugs, then it's a good idea,
but it's done wrong. A lib should not ignore a API call because it thinks its
a bug. Then how can the programmer notice he has something wrong in his code?
Proj4j is not OpenLayers. So maybe it's not the good place to discuss this
problem here.
If we broaden the discussion, the javascript world has IMHO way too much
places where the errors are silent and the input are assumed to be correct
(defined, of the good type and consistent) and never checked. I think the
debug version of the libs (OpenLayers, Ext, proj4j, ...) should have extra
code checking the consitency and reporting all errors (throwing exceptions).
For example, a constructor should check that all the mandatory settings are
set, of the good type and consistent. That would help the developper to find
errors as soon as possible. This code could be tagged and be removed by the
scripts building the compressed/merged release version to avoid performance
impacts. This kind of code could also check and document the expected state
of an object at the start of a method. This technique is called "Design by
Contract" [1]. An excellent article [2] from my friend Adrian will explain
the concept better than me.
CU
[1] http://en.wikipedia.org/wiki/Design_by_Contract
[2] http://kosmaczewski.net/2007/08/23/design-by-contract/
More information about the Users
mailing list