Spatial reprojection ingest processor
Lucenia’s spatial reprojection ingest processor enables automatic transformation of geometries into a target coordinate reference system (CRS) at index time. This simplifies your geospatial pipeline by eliminating the need for external ETL (Extract, Transform, Load) tools or maintaining duplicate indexes for each projection. Whether your data sources use EPSG codes (standard identifiers for coordinate systems defined by the European Petroleum Survey Group), UTM zones, or custom local grids, Lucenia can reproject them directly during ingestion into a consistent CRS for fast and accurate spatial indexing.
By performing reprojection during ingestion, Lucenia ensures that all spatial data is stored in the optimal format for querying - enabling consistent integration with search tools, mapping clients, analytics pipelines, or STAC catalogs without requiring runtime transformations or projection-aware query logic.
Request fields
The following table lists all available request fields.
| Field | Type | Description | Required |
|---|---|---|---|
field | String | The source geometry field to reproject. Either a string in WKT format or a GeoJSON is expected. | Yes |
ignore_missing | Boolean | If true and field does not exist, the processor quietly exits without modifying the document (Defaults to false) | Yes |
target_field | String | The new runtime field to assign the reprojected geometry to. (Defaults to the same as the field) | Yes |
source_crs | String | The coordinate reference system used by the field. (Defaults to "EPSG:4326") | No |
target_crs | String | The coordinate reference system to reproject the field into. (Defaults to "EPSG:4326") | No |
shape_type | String | Which field mapping type is used when processing the field. (Defaults to geo_shape) | No |
provider | String | The processor's identifier. (Defaults to "sis") | No |
Example
The following examples demonstrate how to creat and use an ingest pipeline with a reproject processor to transform geometries from the standard World Geodetic System of 1984 latitude, longitude (decimal degrees) projection to the Mercator X, Y (meters) projection commonly used by Web Mapping applications. This ensures that incoming data is consistently stored in the desired spatial reference system at the time of indexing.
Create an Index Reprojection Processor
The example below creates an ingest processor to reproject incoming document geometry from Mercator into WGS84 projection.
PUT /_ingest/pipeline/reproject_to_wgs84
{
"description" : "reproject spatial geometries from EPSG:3857 X,Y coordinate system to EPSG:4326 lat,lon coordinate system during ingest",
"processors" : [
{
"reproject" : {
"field" : "geometry",
"source_crs" : "EPSG:3857",
"shape_type" : "shape"
}
}
]
}
The input geometry field in the document is treated as a shape and dynamically reprojected from the EPSG:3857 (X, Y) coordinate system to EPSG:4326 (lat, lon), using the same field name. This enables conversion of a user-provided shape query in Easting/Northing (X, Y) to a geo_shape query in (lat, lon), aligning with the coordinate system of the indexed data.
Using the Ingest Reprojection Processor
To reproject geometries at ingest time, specify the pipeline name using the pipeline parameter when indexing documents. For example, the following request ingests data provided in the EPSG:3857 (X, Y) coordinate system and uses the ingest pipeline to reproject it into EPSG:4326 (latitude, longitude) before storing it in the index.
PUT /wgs84_data/_doc?pipeline=reproject_to_wgs84
{
"geometry" : {
"shape" : {
"type" : "envelope",
"coordinates": [ [1812358.0, 6139791.0], [1812369.2, 6139780.1]]
}
}
}
Now the user can query the geometry field in the wgs84_data index using the native WGS84 coordinate system.
GET /wgs84_data/_search
{
"query" : {
"geo_shape" : {
"geometry" : {
"shape" : {
"type" : "envelope",
"coordinates": [ [16.2806889, 48.1975963], [16.2807895, 48.1975310] ]
},
"relation" : "intersects"
}
}
}
}
An example result is provided below:
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 0,
"hits": [
{
"_index": "wgs84_data",
"_id": "roads_1_0",
"_score": 0,
"_source": {
"filename": "roads_1",
"feature_id": 0,
"geometry": "LINESTRING (16.2806999 48.1975878,16.2806995 48.1976023,16.2806986 48.1976328,16.2807182 48.1984326)",
"properties": {
"osm_id": 149673,
"fclass": "tertiary",
"code": "5115",
"maxspeed": 30,
"length": 92,
"edge_id": 1,
"oneway": "B",
"speed": 27,
"layer": 0,
"ref": null,
"ete": 13,
"name": "WaidhausenstraÃe",
"bridge": "F",
"lastchange": "2022-01-23T01:36:31Z",
"tunnel": "F"
}
}
}
]
}
Registering a Custom Reprojection Provider
Developers can also implement their own reprojection logic by implementing the CRSProviderInterface and registering it via the Java Service Provider Interface (SPI) system through their own search plugin.
Below is an example class for implementing a custom projection provider:
public class MyReprojectionProvider implements CRSProviderInterface<MyCRS, MyTransform> {
private static final String NAME = "my_crs_provider";
@Override
public String getName() {
return NAME;
}
@Override
public MyTransform getTransform(final MyCRS fromCRS, final MyCRS toCRS, Object... extraArgs) throws Exception {
MyBBox bbox = (extraArgs != null && extraArgs.length > 0 && extraArgs[0] instanceof MyBBox)
? (MyBBox) extraArgs[0]
: null;
return MyCRS.findMathOperation(fromCRS, toCRS, bbox).getMathTransform();
}
@Override
public MyCRS getCRS(final String crsString) throws Exception {
return AccessController.doPrivileged((PrivilegedAction<MyCRS>) () -> {
try {
return MyCRS.forCode(crsString);
} catch (FactoryException e) {
throw new RuntimeException(e);
}
});
}
@Override
public CRSHandler<MyCRS> createCRSHandler(
final String fromCRS,
final String toCRS,
final GeometryProcessorFieldType shapeFieldType
) throws Exception {
MyCRS toReferenceSystem = toCRS != null ? getCRS(toCRS) : MyHandler.DEFAULT_TO_CRS;
return new MyHandler(getCRS(fromCRS), toReferenceSystem, getTransform(getCRS(fromCRS), toReferenceSystem), shapeFieldType);
}
static class MyHandler implements CRSHandler<MyCRS> {
static final MyCRS DEFAULT_TO_CRS;
private final MyTransform transform;
private final MyPoint reusableFrom;
private final MyPoint reusableTo;
static {
try {
DEFAULT_TO_CRS = MyCRS.forCode(DEFAULT_TARGET_CRS_EPSG_CODE);
} catch (FactoryException e) {
throw new RuntimeException(e);
}
}
MyHandler(
final MyCRS fromCRS,
final MyCRS toCRS,
final MyTransform transform,
final GeometryProcessorFieldType shapeFieldType
) {
this.transform = transform;
this.reusableFrom = new MyPoint(fromCRS);
this.reusableTo = new MyPoint(toCRS);
}
@Override
public MyCRS getFromCRS() {
return reusableFrom.getCoordinateReferenceSystem();
}
@Override
public MyCRS getToCRS() {
return reusableTo.getCoordinateReferenceSystem();
}
@Override
public void reproject(final double[] from, double[] to, final double tolerance) throws Exception {
// Custom reprojection logic
}
}
}
To activate the provider with Java SPI, add the following line to ./resources/META-INF/services/io.skylite.geographic.referencing.CRSProviderInterface in the generated jar file in your plugin zip: com.example.geographic.referencing.MyReprojectionProvider
You will now be able to use your custom provider by providing it's registered NAME in the provider parameter of the search processor:
PUT /_ingest/pipeline/reproject_to_wgs84
{
"description" : "reproject spatial geometries from EPSG:3857 X,Y coordinate system to EPSG:4326 lat,lon coordinate system during ingest",
"processors" : [
{
"reproject" : {
"field" : "geometry",
"source_crs" : "EPSG:3857",
"shape_type" : "shape",
"provider" : "my_crs_provider"
}
}
]
}
Lucenia will discover and register your custom provider automatically on startup.
Summary
Lucenia’s reprojection processors allow seamless integration of data and queries across coordinate systems without requiring reindexing or external tools. Whether your users operate in Web Mercator, UTM zones, or Mars-based CRS, Lucenia handles the transformation transparently using robust, high-performance ingest pipelines.