Description
At the moment shapeBuilders perform much more functionality than just shape building. We have serialization, parsing logic plus logic necessary for handling dateline transformation and conversion of shapes for lucene indexing in both libs/geo and S4J formats. As we are removing support for the S4J shapes, I would like to propose refactoring ShapeBuilder set of classes.
In #36477 we introduced a hierarchy of geo classes that can replace the hierarchy build with ShapeBuilder as a root. This hierarchy has pretty much all functionality except GeoJson parser and logic that is needed to convert shapes into the format consumable by Lucene, if we could add the GeoJson parser to libs/geo, and extract the logic we can remove the entire ShapeBuilder hierarchy and significantly simplify the geo processing pipeline structure. I think it will also simplify switching to different reference system, since it will allows us to have the reference system-specific logic separate from the geo hierarchy.
It will also remove the issue that we are facing in geosql at the moment. The only way to retrieve a shape in geo at the moment is through theShapeParser.parse(....).buildGeometry() path, which converts some shapes into somewhat equivalent set of shapes for lucene consumption, among other things it changes the order of coordinates of polygons, splits polygons on dateline, simplifies collections, etc. This can be really confusing for geosql users, since they will get shapes different from what they put into elasticsearch.
To summarize the following actions will be required:
- Add GeoJson Parser to libs/geo Geo: Add GeoJson parser to libs/geo classes #41575
- Extract dateline decomposition and other Lucene-specific transformation into a separate set of classes. Geo: extract dateline handling logic from ShapeBuilders #44187
- Remove Shape Builder together with S4J logic and replace it with libs/geo and extracted transformation classes.