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- _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
