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

[Jukka Rahkonen]

Even Rouault <even.rouault <at> spatialys.com> writes:

> 
> Hi Jukka,


> > but I can still save for example
> > EPSG:3067 geometries without transforming them into EPSG:4326.
> 
> On-the-fly reprojection should occur normally (provided that your source
layer 
> has explicit SRS)


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.

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
- 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.

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

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 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.

-Jukka-

-Jukka-