Open eskibars opened 7 years ago
We discussed this in the team meeting. There are two approaches to handling projections:
This requires a new lucene field to handle indexing and searching Geometries in cartesian or other (non-wgs84) spheroid space. While this is being worked on (reusing logic from LatLonShape
) it will take a bit longer to fully support indexing in original CRS.
The idea here is to reproject the provided data from the native CRS to WGS84 Lat/Lon prior to indexing. Whether its done at the field mapper level (requiring a change to the DSL so users can provide the CRS) or as an ingest node feature is an implementation detail.
Both approaches first require code to perform the reprojection. Preference is to use Proj4j as a third party API. Some benefits / drawbacks include:
Benefits | Drawback |
---|---|
Apache licensed | How to handle CRS updates / changes |
EPSG database is local / shipped with ES | performance unknown |
Easy to use | project support / maintenance |
Available now |
Given the outstanding questions and ideas I'm going to mark this issue as a meta issue to several sub tasks and use this issue to facilitate high level discussion / decision making.
Putting this one on hold- keep on the roadmap until we are able to prioritize it.
Pinging @elastic/es-analytical-engine (Team:Analytics)
Describe the feature: When talking with geo users, we often hear requests to re-project coordinates from WGS84 to another coordinate system. Doing query-time reprojection may be a heavy lift, but it may be easier to offer an ingest node plugin to do the reprojection. It would be a lossy approach, but it may simplify the data loading aspect for users on other coordinate systems. Downside is that the user would still need to reproject their query to WGS84 if it wasn't already there.
Talked this over briefly with @nknize but wanted to open it up for discussion