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

[Even Rouault]

> I made a test and it appears to work but isn't is confusing because it
> makes a different effect than with most other drivers? Manual page
> http://www.gdal.org/ogr2ogr.html tells "-a_srs srs_def:     Assign an
> output SRS " . With Elastic Search if you use -a_srs epsg:3067 the output
> SRS will actually be epsg:4326. Let's keep this secret and teach the users
> always use explicit -s_srs  and t_srs.

Well, it assigns the SRS before the driver enter into action. Drivers tend to 
do nasty things due to format constraints ;-) But yes, that's a particular 
case.

> 
> My test data in JML format contains this DATETIME
>  <property name="JATTOPVM">2015-06-14T22:29:15.454+0300</property>
> 
> It leads to this ElasticSearch error which I took from the ES console:
> Caused by: org.elasticsearch.index.mapper.MapperParsingException: failed to
> pars e date field [2015/06/14 22:29:15.454+03], tried both date format
> [yyyy/MM/dd HH
> 
> :mm:ss.SSS||yyyy/MM/dd], and timestamp number with locale []

OK there was indeed an issue with the declared format not allowing timezones. 
Just fixed.

> 
> When I convert JML into GML with ogr2ogr the DATETIME comes into GML as
>  <ogr:JATTOPVM>2015/06/14 22:29:15.454+03</ogr:JATTOPVM>
> This is OK for Elastic Search. I do not see any difference but there must
> be some. 

Yes, the GML driver does not support yet properly DateTime fields. So they are 
converted just as string...

> JML failed for me because of this parsing error. ogr2ogr does not
> catch the error, not even when run with --debug on.

Indeed the bulk uploading code didn't detect errors reported by the server. 
Now errors are reported back.

Thanks for your testing and reports !

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