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