Further testing revealed that CoordinateReferenceSystem was much too fragile because:
The CoordinateReferenceSystem name changes depending on how it was constructed. For instance name may be EPSG:3857 if CRS was constructed by EPSG code or merc-CS if it constructed from Proj4 string.
Proj4 parameters are stored as provided. +lat_0=0 and +lat_0=0.0 are obviously the same but will trip up equality
Proj4 parameters are stored in order provided, this will trip up array equality check
Some parameters may be read from default file if +no_def is not present and thus will not be reflected in parameter string at all
So basically the situation is pretty dire and this PR attempts to remedy that.
It's worth noting that Projection class is highly mutable which makes checking for equality a little tricky. While the mutability is used primarily by the Proj4Parser to "build up" the projection its obviously possible that this is not the only place that mutation will happen because life.
In this PR:
Base Projection.equals checks that left and right side are the same class. This represents the implementation of project method.
Base Projection.equals checks the state of protected and private stateful fields that have setters
Subclasses of Projection check equality of their additional stateful fields and delegate to super equality afterwards.
isSouth and heightOfOrbit fields are moved to their corresponding subclasses. Getters and setters for those fields will throw NoSuchElementException if used at any other time.
This is follow-up PR to https://github.com/locationtech/proj4j/pull/33
Further testing revealed that
CoordinateReferenceSystem
was much too fragile because:CoordinateReferenceSystem
name changes depending on how it was constructed. For instance name may beEPSG:3857
if CRS was constructed by EPSG code ormerc-CS
if it constructed from Proj4 string.+lat_0=0
and+lat_0=0.0
are obviously the same but will trip up equality+no_def
is not present and thus will not be reflected in parameter string at allSo basically the situation is pretty dire and this PR attempts to remedy that.
It's worth noting that
Projection
class is highly mutable which makes checking for equality a little tricky. While the mutability is used primarily by theProj4Parser
to "build up" the projection its obviously possible that this is not the only place that mutation will happen because life.In this PR:
Projection.equals
checks that left and right side are the same class. This represents the implementation ofproject
method.Projection.equals
checks the state of protected and private stateful fields that have settersProjection
check equality of their additional stateful fields and delegate to super equality afterwards.isSouth
andheightOfOrbit
fields are moved to their corresponding subclasses. Getters and setters for those fields will throwNoSuchElementException
if used at any other time.Also ... Closes: https://github.com/locationtech/proj4j/issues/38