Re: [gdal-dev] identifying the fields from the .osm file

Thank you Etienne. I am very interested in your reply, but I haven't quite understand you. The ogr2ogr.exe file is using a particular python script to read the .osm file and identify its unique fields? Can you be a bit more specific please? Solving this issue will mean a lot to me. Sorry for distu

Re: [gdal-dev] CAD (DWG) Driver

I commented out the C++11 mutex in gdaldrivermanager.cpp - this helps. OSX CI test passed successfully. https://travis-ci.org/OSGeo/gdal/jobs/177297023 Best regards,

Re: [gdal-dev] CAD (DWG) Driver

On samedi 19 novembre 2016 10:06:26 CET Kurt Schwehr wrote: > I'm really not sure. Not sure that the crash mentionned by Dmitry is related to that ? It looks like a really good canditate to me. That's the only C++11 mutex in GDAL, with 2 other ones in the GeoTIFF driver (and those are likely no

Re: [gdal-dev] CAD (DWG) Driver

I'm really not sure. You can certainly try removing that C++11 mutex. It was added based on the comment at that point in the code. We'll just have to keep an eye out for possible occasional flakes. If that's the case, we'll need to carefully work through the logic and try to figure out a soluti

Re: [gdal-dev] CAD (DWG) Driver

On samedi 19 novembre 2016 19:34:02 CET Dmitry Baryshnikov wrote: > Hi Even, > > The big_endian test now is ok. But osx crash at the exiting of python > after all test finished successfully. > > This is error message: > > libc++abi.dylib: terminating with uncaught exception of type > std::__1::s

Re: [gdal-dev] CAD (DWG) Driver

Hi Even, The big_endian test now is ok. But osx crash at the exiting of python after all test finished successfully. This is error message: libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument ./gdal/ci/travis/osx/script.sh:

Re: [gdal-dev] CAD (DWG) Driver

Hi Jeff, This driver has no external dependencies (we use an internal copy of OpenCAD library). So it builds without any problem. Best regards, Dmitry 19.11.16 18:42, Jeff McKenna пишет: On 2016-11-19 9:52 AM, Dmitry Baryshnikov wrote: Hi, I fixed all reported by Even and Kurt errors a

Re: [gdal-dev] identifying the fields from the .osm file

The parsing is done using python in the plugin. We can just use the parser by calling the python file. Python is included when you install osgeo4w. Yes you can set the osmconf.ini or directly use the goal ogr api to write the output file. On 19 Nov 2016 18:00, "Djordje Spasic" wrote: > Thank yo

Re: [gdal-dev] ogr2ogr PG->SHP lacks EPSG code

On samedi 19 novembre 2016 16:34:16 CET Martin Landa wrote: > Hi, > > 2016-11-13 13:29 GMT+01:00 Even Rouault : > > thanks for detailed insight. BTW, ogr2ogr couldn't also generates .qpj > when srs epgs code is given? It could certainly do this, but the question is more: should it do it ? Adding

Re: [gdal-dev] CAD (DWG) Driver

On 2016-11-19 9:52 AM, Dmitry Baryshnikov wrote: Hi, I fixed all reported by Even and Kurt errors and recommendations in CAD (DWG) driver and most of recommendations in OpenCAD library. The pull request (https://github.com/OSGeo/gdal/pull/164) passed all the checks successful. It seems to me the

Re: [gdal-dev] ogr2ogr PG->SHP lacks EPSG code

Hi, 2016-11-13 13:29 GMT+01:00 Even Rouault : thanks for detailed insight. BTW, ogr2ogr couldn't also generates .qpj when srs epgs code is given? Martrin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ gdal-d

[gdal-dev] Changing layer name of GeoJSON datasets

Hi Currently the GeoJSON datasource always return "OGRGeoJSON" as a layer name, which is quite boring (if you convert the geojson into a multi-layer capable dataousrce, you always have to rename the layer to something more meaningful) I'd consider changing that to take the basename of the datas

Re: [gdal-dev] CAD (DWG) Driver

On samedi 19 novembre 2016 16:52:09 CET Dmitry Baryshnikov wrote: > Hi, > > I fixed all reported by Even and Kurt errors and recommendations in CAD > (DWG) driver and most of recommendations in OpenCAD library. The pull > request (https://github.com/OSGeo/gdal/pull/164) passed all the checks > suc

[gdal-dev] CAD (DWG) Driver

Hi, I fixed all reported by Even and Kurt errors and recommendations in CAD (DWG) driver and most of recommendations in OpenCAD library. The pull request (https://github.com/OSGeo/gdal/pull/164) passed all the checks successful. It seems to me the driver is ready to merge to the trunk. This w