Description
Proposal
- Change all references to
lat
,lon
andalt
withx
,y
, andz
- Change the order of the parameters in constructors from
lat
,lon
,alt
tox
,y
,z
- Move Geometry hierarchy from
org.elasticsearch.geo.geometry
toorg.elasticsearch.geometry
Rationale
I think I made a mistake of going with lat
, lon
notation instead of x
, y
notation when I first introduced the Geometry
hierarchy and the window of opportunity to rectify this mistake with a limited impact on end users is quickly closing. I have been recently doing a lot of refactoring work with Geometry
classes and was constantly struggling with the order and naming of parameters for the following reasons:
- the current order and naming defers from most of the other libraries and standard that we are using in elasticsearch including JTS, WKT, GeoJSON and naming convention used in geosql functions.
- we are in process of extending use of
Geometry
classes in the context ofXYShapes
and different projections, which makes genericx
andy
more appropriate thanlat
andlon
. - the hierarchy is based on
Geometry
(not Geography) in the first place, so member naming based onlat
andlon
doesn't seem to be consistent with the class naming.
Reducing the impact
If we make the transition before 7.4 the only users who would be affected are JDBC users that are using geosql features. The feature is currently marked as beta and JDBC driver is setup in such a way that it doesn't provide any compatibility between version, so migration will mean recompiling with a new version of the driver. Since we are change the order of the parameters in constructor but not the type we will bring users attention to this issue by also changing the package name for Geometry classes. However, there is no way to avoid changing the code for JDBC geosql users. On the positive side, switching to x, y, z naming convention will make interface it more consistent for goesql users as well. Considering that the feature is really, I don't think that a lot of users will be affected by this change.
In 7.4 the Geometry hierarchy will become the part of QueryBuilder
interface, so any changes will have much bigger impact.