Message-ID: <1867168713.3769.1422764080590.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3768_2063008904.1422764080589" ------=_Part_3768_2063008904.1422764080589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Make GeoAPI implementation class names consi= stent
Implementation of GeoAPI classes have different naming pattern in differ=
ent modules. In the referencing module, they are prefixed with
Abstract. In the metadata module, they are suffixe=
Impl. This proposal is about a more consistent pattern =
to be applied at least accross the metadata, referencing and coverage modul=
es. More specifically we suggest to adopt the
stract prefix scheme used in referencing, and rename all metadata im=
plementation classes accordingly.
Imp= lsuffix was to preserve alphabetical order. However experience sugg= ests that it is not so convenient, since it is often more useful to disting= uish between GeoAPI implementations and GeoTools specific classes. The GeoA= PI implementation could be hiden from the "beginer" javadoc (make= is visible only to "advanced" users). Most users could be encour= aged to read the GeoAPI javadoc instead.
AbstractCS(the base class for
DefaultVerticalCS, etc.) is abstra= ct according ISO, but not in the Java sense since it can be instantiated. A= ctually
AbstractCSis really instantiated in = a few cases by the WKT parser, meaning "I really don't know what this = coordinate system is; I just know its axes" (this case occurs because = of limitations in WKT syntax).
Example: The CRS package has the following cla=
sses. We can see immediately that
DerivedCRS are abstract (in ISO sense), and that
refixedMap has nothing to do with GeoAPI classes. We would like the =
same advantages for metadata.
Impl suffix by
Abstractdepending on w= hatever the class is abstract or not according ISO.
Implclasses as extending the new renamed= classes, and deprecate them for GeoTools 2.5 release.
Implclasses on trunk after GeoTools= 2.5 release.
No other classes than metadata would be renamed at this stage; current c= lass names in referencing and coverage are considered okay.=20
Note that a few referencing and coverage classes use other prefix than <=
Default. For example "General&quo=
GeneralEnvelope to stress-out its n-dimensionsl=
aspect compared to
Envelope2D, or "Grid" in
ridSampleDimension to stress-out that they apply to
ge rather than arbitrary
Coverage. This is okay and don=
't need to be forced into a
ng scheme. The above is just a proposed rule of thumbs, not a strict rule.<=
Voting is open:=20