Geo: Refactors libs/geo parser to provide serialization logic as well #43717
Conversation
Enables libs/geo parser to return a geometry format object that can perform both serialization and deserialization functions. This can be useful for ingest nodes that are trying to modify an existing geometry in the source.
imotov
added
:Analytics/Geo
|
Pinging @elastic/es-analytics-geo |
|
@elasticmachine run elasticsearch-ci/default-distro |
|
Hi @imotov, I noticed that my initial intentions of using this parser in #43851 via XContent is not exactly what I needed. Since IngestNode already converts the xcontent into a Map, it would be great if there was a way to parse a Map with these libs. Do you think it is fine to convert back from the Map into XContent? I think I need to think about this some more, but I wanted to avoid going from Map -> XContent -> Circle. So I ended up parsing the Circle definition manually in the processor. I do not like this, but I am not sure how to best update these libs to support this, since it is unique to how Ingest Node parses the document. |
I think we should start with that and then I can add another implementation of XContentParser that would "traverse" a map. We will be able to reuse it in other places as well. |
|
oh cool. good to know this is similarly done elsewhere and can be improved. |
| /** | ||
| * Geometry serializer/deserializer | ||
| */ | ||
| public interface GeometryFormat { |
There was a problem hiding this comment.
should we have these formats be required to provide their name via something like a String getName()? or type?
There was a problem hiding this comment.
Do you have any particular use for that?
Enables libs/geo parser to return a geometry format object that can
perform both serialization and deserialization functions. This can
be useful for ingest nodes that are trying to modify an existing
geometry in the source.
Relates to #43554