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
CoordinateReferenceSystemwas much too fragile because:CoordinateReferenceSystemname changes depending on how it was constructed. For instance name may beEPSG:3857if CRS was constructed by EPSG code ormerc-CSif it constructed from Proj4 string.+lat_0=0and+lat_0=0.0are obviously the same but will trip up equality+no_defis 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
Projectionclass is highly mutable which makes checking for equality a little tricky. While the mutability is used primarily by theProj4Parserto "build up" the projection its obviously possible that this is not the only place that mutation will happen because life.In this PR:
Projection.equalschecks that left and right side are the same class. This represents the implementation ofprojectmethod.Projection.equalschecks the state of protected and private stateful fields that have settersProjectioncheck equality of their additional stateful fields and delegate to super equality afterwards.isSouthandheightOfOrbitfields are moved to their corresponding subclasses. Getters and setters for those fields will throwNoSuchElementExceptionif used at any other time.Also ... Closes: https://github.com/locationtech/proj4j/issues/38