[gdal-dev] SRS of the Elastic Search geometries?

[Even Rouault]

> 
> Probably that's it, the explicit SRS. I started with data that have native
> SRS epsg:3067 and OpenJUMP JML format which has no means for holding SRS.
> Conversion into ES gives always an empty layer, just the schema gets
> inserted but no geometries, even is I use -s_srs and -t_srs.
> 
> Next trial was to convert JML into GML without assigning SRS. GML has an
> undefined SRS and conversion without -s_srs and -t_srs leads to a situation
> where metadata sayes that ES is using epsg:4326 but the features are in
> epsg:3067. With proper -s_srs and -t_srs the result is good.

You can also use -a_srs for that.

> 
> If I convert JML into GML and assign SRS with -a_srs epsg:3067 the result
> is the same as above. Each GML feature has SRS defined as <gml:Polygon
> srsName="EPSG:3067"> but perhaps it is not explicit because conversion
> into ES gives correct result only when -s_srs and -t_srs are defined.
> 
> So, two problems:
> - No way at all to use Jump JML as input format

Are you sure about that ? I've just tried the following and it works:

$ ogr2ogr simple_EPSG_32631.jml simple_EPSG_32631.shp -f jml
$ ogr2ogr  -update es: simple_EPSG_32631.jml -overwrite -s_srs EPSG:32631 -
t_srs EPSG:32631
(or with -a_srs EPSG:32631)

The behaviour with JML and GML inputs should be the same.

> - With GML parameters -s_srs and -t_srs must be defined even if each GML
> feature has srsName and all features in the GML file have same srsName.

The issue with GML is complex. Basically, the GML driver is very cautious and 
doesn't report a layer SRS since there's no way to know if all features have 
the same SRS without exploring the whole file, which he will avoid if there's a 
.xsd that it can understand. If you remove the .xsd, then a full initial scan 
will be done and if the driver realizes that all features have the same SRS, 
this will be written in the .gfs file, and thus reported as the SRS layer.
With some particular formulations of GML (like a WFS GetFeature response where 
we know that the SRS is homogenous), the driver will use the SRS of the top 
Envelope as the layer SRS.

> 
> A warning like "No explicit SRS found, use -s_srs and -t_srs" might be good
> to have.

Should be addressed by my latest commit:
"ES: add warnings at layer creation if no SRS is specified, and at feature 
insertion, in the case where no layer SRS is defined when the bounding box 
isn't valid for long/lat"

> 
> I know very little about Elastic Seaach, just started experiments a week
> ago. I have concluded that what is layer for GDAL is "index", and what is
> feature, is "document", and that documents are somehow saved as-is

That really depends. You may choose to store or not the _all fields or 
individual fields.

> and
> clever indexes are built on top of them. Therefore I was thinking that
> perhaps everything is OK on the ES side even if the documents come out from
> it with epsg:3067 geometries.

The spatial indices made assumption on the coordinates. For example a geohash 
really assumes the [-90,90]x[-180,180] range. Not sure how geo_shape indexing 
works.

> 
> -Jukka-
> 
> -Jukka-
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com