Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
On Fri, Nov 15, 2019 at 9:55 AM Even Rouault wrote: > > > The old driver pages > > (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats > > .html) were tables that very effectively conveyed the capabilities (or > > limitations) of the drivers and allowed for scanning for drivers that > > had the capabilities that you wanted. > > The information in individual pages is roughly the same as in the global > table. > > > Would a similar table be possible or desirable? > > A few people have indeed noted the absence of the table. Not sure if this is > usual "resistance to change" phenomenon or if there is there really a strong > use case for "I don't want which format to use: let's look at the summary page > to select one". I've certainly found myself shopping for a format with that table. Usually some middle format in an ETL toolchain, sometimes complicated by cross platform considerations for driver availability. > > If so, then yes if someone contributes it, that'd be welcome. However I think > we'd want it to be generated from a Python script from the individual .rst > pages, by parsing the directives like ".. supports_create::" that are in those > .rst files. That way that would make maintainance of the summary easier (and > initial version less tidious that doing that manually) Contributing it as a python script is an opportunity for someone other than me. > > > There are a few things that might be missing. The new page has > > https://gdal.org/programs/raster_common_options.html#raster-common-options > > and > > https://gdal.org/programs/vector_common_options.html#vector-common-options > > I wonder if a list of uncommon options like this would be helpful, > > https://trac.osgeo.org/gdal/wiki/ConfigOptions? > > Migrating the wiki page to the doc could be useful. My own opinion is that > driver specific configuration options should be documented in the driver > specific page, rather than in a global config option page. Same with /vsi I'll try moving some of these over and see how it goes. > specific options that should go to > https://gdal.org/user/virtual_file_systems.html if not already there. > > Or if a global list is needed, I'd say a bit the same as for driver summaries, > have a way to compile the list of options from .rst files where they would be > mention and link from the summary to the actual page. But we don't have > currently any explicit directive for configuration options. I'll start with driver specific. Thanks, Eli > > > I was also curious to see if the OSGeo technical writing project would > > impact any of the documentation. > > There was initial discussion but no follow-up as far as GDAL is concerned. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
Hi, Two most often needed items from the old format list for me as a community helper were "Creation" to answer "Why gdalwarp to format x fails" and "Compiled by default" to answer "Why everything with my GDAL to format x fails". The list was useful. -Jukka- -Alkuperäinen viesti- Lähettäjä: Even Rouault Lähetetty: perjantai 15. marraskuuta 2019 19.55 Vastaanottaja: ea...@co.lincoln.or.us Kopio: gdal-dev@lists.osgeo.org; Rahkonen Jukka (MML) Aihe: Re: [gdal-dev] How to know which formats allow editing with ogrinfo? > Can this be partly inferred from driver pages with the presence (or > absence) of items? For instance, > https://gdal.org/drivers/vector/gml.html#driver-capabilities Not really. They are only high level capabilities. Vector editing capabilities are not reported in driver pages > The old driver pages > (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_f > ormats > .html) were tables that very effectively conveyed the capabilities (or > limitations) of the drivers and allowed for scanning for drivers that > had the capabilities that you wanted. The information in individual pages is roughly the same as in the global table. > Would a similar table be possible or desirable? A few people have indeed noted the absence of the table. Not sure if this is usual "resistance to change" phenomenon or if there is there really a strong use case for "I don't want which format to use: let's look at the summary page to select one". If so, then yes if someone contributes it, that'd be welcome. However I think we'd want it to be generated from a Python script from the individual .rst pages, by parsing the directives like ".. supports_create::" that are in those .rst files. That way that would make maintainance of the summary easier (and initial version less tidious that doing that manually) > There are a few things that might be missing. The new page has > https://gdal.org/programs/raster_common_options.html#raster-common-opt > ions > and > https://gdal.org/programs/vector_common_options.html#vector-common-opt > ions I wonder if a list of uncommon options like this would be > helpful, https://trac.osgeo.org/gdal/wiki/ConfigOptions? Migrating the wiki page to the doc could be useful. My own opinion is that driver specific configuration options should be documented in the driver specific page, rather than in a global config option page. Same with /vsi specific options that should go to https://gdal.org/user/virtual_file_systems.html if not already there. Or if a global list is needed, I'd say a bit the same as for driver summaries, have a way to compile the list of options from .rst files where they would be mention and link from the summary to the actual page. But we don't have currently any explicit directive for configuration options. > I was also curious to see if the OSGeo technical writing project would > impact any of the documentation. There was initial discussion but no follow-up as far as GDAL is concerned. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
> Can this be partly inferred from driver pages with the presence (or > absence) of items? For instance, > https://gdal.org/drivers/vector/gml.html#driver-capabilities Not really. They are only high level capabilities. Vector editing capabilities are not reported in driver pages > The old driver pages > (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats > .html) were tables that very effectively conveyed the capabilities (or > limitations) of the drivers and allowed for scanning for drivers that > had the capabilities that you wanted. The information in individual pages is roughly the same as in the global table. > Would a similar table be possible or desirable? A few people have indeed noted the absence of the table. Not sure if this is usual "resistance to change" phenomenon or if there is there really a strong use case for "I don't want which format to use: let's look at the summary page to select one". If so, then yes if someone contributes it, that'd be welcome. However I think we'd want it to be generated from a Python script from the individual .rst pages, by parsing the directives like ".. supports_create::" that are in those .rst files. That way that would make maintainance of the summary easier (and initial version less tidious that doing that manually) > There are a few things that might be missing. The new page has > https://gdal.org/programs/raster_common_options.html#raster-common-options > and > https://gdal.org/programs/vector_common_options.html#vector-common-options > I wonder if a list of uncommon options like this would be helpful, > https://trac.osgeo.org/gdal/wiki/ConfigOptions? Migrating the wiki page to the doc could be useful. My own opinion is that driver specific configuration options should be documented in the driver specific page, rather than in a global config option page. Same with /vsi specific options that should go to https://gdal.org/user/virtual_file_systems.html if not already there. Or if a global list is needed, I'd say a bit the same as for driver summaries, have a way to compile the list of options from .rst files where they would be mention and link from the summary to the actual page. But we don't have currently any explicit directive for configuration options. > I was also curious to see if the OSGeo technical writing project would > impact any of the documentation. There was initial discussion but no follow-up as far as GDAL is concerned. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
On Fri, Nov 15, 2019 at 3:58 AM Even Rouault wrote: > > On vendredi 15 novembre 2019 08:52:48 CET Rahkonen Jukka (MML) wrote: > > Hi, > > > > Shapefile can be edited with ogrinfo > > ogrinfo -dialect SQLite -sql "update foo set bar='14'" foo.shp > > > > GML opens always as read-only with -sql option > > ogrinfo -sql "select * from foo" foo.gml > > Had to open data source read-only. > > INFO: Open of `foo.gml' > > using driver `GML' successful. > > > > How can I know which formats support editing with -sql and which not? I > > could not find any obvious metadata by checking the capabilities of a few > > different drivers. > > There's indeed no driver-level metadata indicating support for updates (update > through SQL is just a particular case). With a dataset opened, on a layer, > with the API you can query for fine grain capabilities with > TestCapability(OLCRandomWrite/OLCDeleteFeature/etc...) Can this be partly inferred from driver pages with the presence (or absence) of items? For instance, https://gdal.org/drivers/vector/gml.html#driver-capabilities The old driver pages (https://web.archive.org/web/20190211030817/https://www.gdal.org/ogr_formats.html) were tables that very effectively conveyed the capabilities (or limitations) of the drivers and allowed for scanning for drivers that had the capabilities that you wanted. Would a similar table be possible or desirable? This got me thinking about the Sphinx migration a bit, https://lists.osgeo.org/pipermail/gdal-dev/2019-May/050273.html. It looks great and the website is easy to use. Thanks to everyone who updated that! There are a few things that might be missing. The new page has https://gdal.org/programs/raster_common_options.html#raster-common-options and https://gdal.org/programs/vector_common_options.html#vector-common-options I wonder if a list of uncommon options like this would be helpful, https://trac.osgeo.org/gdal/wiki/ConfigOptions? Same with some overview table of driver capabilities? If it is just a matter of recreating a new page copied from the old, I would be up trying to contribute to that. I lack the detailed knowledge of the drivers to be able to create it from scratch. I was also curious to see if the OSGeo technical writing project would impact any of the documentation. Best regards, Eli > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to know which formats allow editing with ogrinfo?
On vendredi 15 novembre 2019 08:52:48 CET Rahkonen Jukka (MML) wrote: > Hi, > > Shapefile can be edited with ogrinfo > ogrinfo -dialect SQLite -sql "update foo set bar='14'" foo.shp > > GML opens always as read-only with -sql option > ogrinfo -sql "select * from foo" foo.gml > Had to open data source read-only. > INFO: Open of `foo.gml' > using driver `GML' successful. > > How can I know which formats support editing with -sql and which not? I > could not find any obvious metadata by checking the capabilities of a few > different drivers. There's indeed no driver-level metadata indicating support for updates (update through SQL is just a particular case). With a dataset opened, on a layer, with the API you can query for fine grain capabilities with TestCapability(OLCRandomWrite/OLCDeleteFeature/etc...) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev