Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
On 27 May 2014 01:24, Ivan Lucena lucena_i...@hotmail.com wrote: What I am most interested is to have two driver (that uses the same data container) sharing a little bit of code. [...] In my case I would like to have a folder structure to keep my two driver under the same folder. Something like that: /frmts/container/ /frmts/container/vector /frmts/container/raster But that idea doesn't help with your concern about a large number of sub-folders under /frmts. Ivan, You've touched an important issues - sharing of code between drivers that connect to the same data provider. My understanding is that drivers like Oracle or PostGIS would have the following structure: /frmts/mixed/oracle /frmts/mixed/postgis I'm not sure if I've grasped the idea well though. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Selon Mateusz mate...@loskot.net: I'd rather see frmts/mixed/X if X is a single driver that can return both raster and vector content. If you have a X (GeoRaster) and YY (OGR OCI) drivers that use common code but remain separate, I'd say you can have frmts/raster/X and frmts/vector/Y and make one of them include headers from the other one. Like it has been done up to now. Well if you want it to be cleaner, you could have frmts/common/oracle and put in there the common code. However, if they are plugins and not build-in driver, you should however make sure that both drivers are bundled in the same shared object. On 27 May 2014 01:24, Ivan Lucena lucena_i...@hotmail.com wrote: What I am most interested is to have two driver (that uses the same data container) sharing a little bit of code. [...] In my case I would like to have a folder structure to keep my two driver under the same folder. Something like that: /frmts/container/ /frmts/container/vector /frmts/container/raster But that idea doesn't help with your concern about a large number of sub-folders under /frmts. Ivan, You've touched an important issues - sharing of code between drivers that connect to the same data provider. My understanding is that drivers like Oracle or PostGIS would have the following structure: /frmts/mixed/oracle /frmts/mixed/postgis I'm not sure if I've grasped the idea well though. Best regards, -- Mateusz Åoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Date: Tue, 27 May 2014 11:46:35 +0200 From: even.roua...@mines-paris.org To: mate...@loskot.net CC: lucena_i...@hotmail.com; even.roua...@mines-paris.org; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited Selon Mateusz mate...@loskot.net: I'd rather see frmts/mixed/X if X is a single driver that can return both raster and vector content. If you have a X (GeoRaster) and YY (OGR OCI) drivers that use common code but remain separate, I'd say you can have frmts/raster/X and frmts/vector/Y and make one of them include headers from the other one. Like That is fine. That will be just a matter of adding some -I include path. it has been done up to now. Well if you want it to be cleaner, you could have frmts/common/oracle and put in there the common code. However, if they are plugins and not build-in driver, you should however make sure that both drivers are bundled in the same shared object. I don't think that will be necessary. I mean, the /common folder. But let me through another idea, if you don't mind. What if the folder under /frmts where organized by software/company name, not by container? BTW, that is what I did on my first GDAL driver, I used the software name not the format or driver name as the folder name. IMHO there is no need for /vector, /raster or /mixed sub-folder. It really doesn't matter if a driver is mixed or not, in terms of folder structure. That should be dictated by the code. Inside the software/company sub-folder, the developer could organize folder names in the anyway they want, as long as there is a main makefile to be called. Or maybe not even that, because a driver could be plugin-only. Inside that folder you could have one, two, three or more drivers, mixed or not. And we could still have formats independent from software/companies seating on the /frmts folder just like he have now. Would that be too much freedom? Would make it more organized or messier? Like I said before, I am fine with what you proposed. I am just giving some ideas. I am not concerned about my two drivers but about the health of the overall GDAL code. My best regards, Ivan On 27 May 2014 01:24, Ivan Lucena lucena_i...@hotmail.com wrote: What I am most interested is to have two driver (that uses the same data container) sharing a little bit of code. [...] In my case I would like to have a folder structure to keep my two driver under the same folder. Something like that: /frmts/container/ /frmts/container/vector /frmts/container/raster But that idea doesn't help with your concern about a large number of sub-folders under /frmts. Ivan, You've touched an important issues - sharing of code between drivers that connect to the same data provider. My understanding is that drivers like Oracle or PostGIS would have the following structure: /frmts/mixed/oracle /frmts/mixed/postgis I'm not sure if I've grasped the idea well though. Best regards, -- Mateusz Åoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Selon Ivan Lucena lucena_i...@hotmail.com: Date: Tue, 27 May 2014 11:46:35 +0200 From: even.roua...@mines-paris.org To: mate...@loskot.net CC: lucena_i...@hotmail.com; even.roua...@mines-paris.org; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited Selon Mateusz mate...@loskot.net: I'd rather see frmts/mixed/X if X is a single driver that can return both raster and vector content. If you have a X (GeoRaster) and YY (OGR OCI) drivers that use common code but remain separate, I'd say you can have frmts/raster/X and frmts/vector/Y and make one of them include headers from the other one. Like That is fine. That will be just a matter of adding some -I include path. it has been done up to now. Well if you want it to be cleaner, you could have frmts/common/oracle and put in there the common code. However, if they are plugins and not build-in driver, you should however make sure that both drivers are bundled in the same shared object. I don't think that will be necessary. I mean, the /common folder. But let me through another idea, if you don't mind. What if the folder under /frmts where organized by software/company name, not by container? My feeling is that there are not so many drivers that are unambiguously associated with a software/company. And if you take a particular company, the common points between shape file, PGeo, FileGDB, OpenFileGDB, SDE or ArcObjects are rather small (I can only think to shapefile blob encoding/decoding for pgeo/mdb and filegdb/openfilegdb). And it would be rather amusing to place OpenFileGDB under an E$RI directory. And sometimes the company name changes many times, but the format remains (ECW...) BTW, that is what I did on my first GDAL driver, I used the software name not the format or driver name as the folder name. IMHO there is no need for /vector, /raster or /mixed sub-folder. It really doesn't matter if a driver is mixed or not, in terms of folder structure. That should be dictated by the code. I agree. There's no technical necessity in that /vector, /raster and /mixed possible structure. I've just had a look at how QGIS ogranize their providers - https://github.com/qgis/QGIS/tree/master/src/providers - and it is flat, mixing raster and vector. But they have only 15 of them. Inside the software/company sub-folder, the developer could organize folder names in the anyway they want, as long as there is a main makefile to be called. Or maybe not even that, because a driver could be plugin-only. Inside that folder you could have one, two, three or more drivers, mixed or not. And we could still have formats independent from software/companies seating on the /frmts folder just like he have now. Would that be too much freedom? Would make it more organized or messier? No definitive conclusion from myself. The frmts/raster frmts/vector approach was a no-brainer adaptation of the current organization. Like I said before, I am fine with what you proposed. I am just giving some ideas. I am not concerned about my two drivers but about the health of the overall GDAL code. My best regards, Ivan On 27 May 2014 01:24, Ivan Lucena lucena_i...@hotmail.com wrote: What I am most interested is to have two driver (that uses the same data container) sharing a little bit of code. [...] In my case I would like to have a folder structure to keep my two driver under the same folder. Something like that: /frmts/container/ /frmts/container/vector /frmts/container/raster But that idea doesn't help with your concern about a large number of sub-folders under /frmts. Ivan, You've touched an important issues - sharing of code between drivers that connect to the same data provider. My understanding is that drivers like Oracle or PostGIS would have the following structure: /frmts/mixed/oracle /frmts/mixed/postgis I'm not sure if I've grasped the idea well though. Best regards, -- Mateusz Åoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Hi there, I can also confirm that the trunk builds without any problems in OS X 10.9.3. The version number is correct at this time however I don't think the released information is quite clear: $ gdalinfo --version GDAL 2.0.0dev, released 2014/04/16 The RFC 46 propose moving the OGR drivers from ogr/ogrsf_frmts/ to frmts/ and I am looking forward to do that. When can we start? Is it going to be a GDAL's maintainer task or it is something that the driver's maintainer will do? Great Job Even! Regards, Ivan Date: Sat, 24 May 2014 14:07:07 -0700 From: mate...@loskot.net To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited Hi, I can confirm the trunk builds without any problems with VS2013. Thanks Even! Best regards, Mateusz Loskot -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-RFC-46-GDAL-OGR-unification-adopted-and-commited-tp5142327p5142357.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Hi Ivan, The RFC 46 propose moving the OGR drivers from ogr/ogrsf_frmts/ to frmts/ and I am looking forward to do that. When can we start? When you want. There's no particularly emergency to do that IMHO, and the move should be done properly with svn mv, so that the traceability of files doesn't suffer too much. One thing that just came to my mind is if we want every drivers to stay under frmts, or if we want more structure like frmts/raster, frmts/vector, frmts/mixed. I dunno. Is it going to be a GDAL's maintainer task or it is something that the driver's maintainer will do? I consider that anyone with commit rights is a GDAL maintainer. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
On 26 May 2014 17:21, Even Rouault even.roua...@mines-paris.org wrote: One thing that just came to my mind is if we want every drivers to stay under frmts, or if we want more structure like frmts/raster, frmts/vector, frmts/mixed. IMO, the frmts folder as a single bag for all drivers will quickly become difficult to navigate through. I'm very supportive to Even's idea of introducing the extra level that would indicate type of a driver. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Hi Mateusz, That seems like a good idea. But I don't know if I should unify two drivers an put then on frmts/mixed. It will certainly works in the new structure proposed by RFC 46 but it might create some problems for me. What I am most interested is to have two driver (that uses the same data container) sharing a little bit of code. The RFC 46 says Various data containers can accept both data types and by that I understand it means at the same time. The same dataset can contain Vector and Raster. If I understood it correclty, if you use gdalinfo with one of those dataset it will call GDALOpenEx with GDAL_OF_RASTER and if you use ogrinfo with the same dataset it will call GDALOpenEx with GDAL_OF_VECTOR. So nothing new under the sun here, from the user point of view. What is a very good thing. But it might be a case where you would like to develop or unify some drivers and put then into the mixed folder. I don't know. In my case I would like to have a folder structure to keep my two driver under the same folder. Something like that: /frmts/container/ /frmts/container/vector /frmts/container/raster But that idea doesn't help with your concern about a large number of sub-folders under /frmts. What do you think? Regards, Ivan From: mate...@loskot.net Date: Mon, 26 May 2014 17:36:49 +0200 Subject: Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited To: even.roua...@mines-paris.org CC: lucena_i...@hotmail.com; gdal-dev@lists.osgeo.org On 26 May 2014 17:21, Even Rouault even.roua...@mines-paris.org wrote: One thing that just came to my mind is if we want every drivers to stay under frmts, or if we want more structure like frmts/raster, frmts/vector, frmts/mixed. IMO, the frmts folder as a single bag for all drivers will quickly become difficult to navigate through. I'm very supportive to Even's idea of introducing the extra level that would indicate type of a driver. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Le samedi 24 mai 2014 21:28:39, Etienne Tourigny a écrit : Hi Even, great work! Quick testing was fine and revealed no errors. I was able to compile it in QGIS master very easily. The only issue I encountered was related to GDALRegisterAll() and OGRAllRegister() registering all drivers (raster and vector), requiring to ignore the vector-only drivers in the raster-only related code in QGIS. Yeah, I've noticed a similar issue in PostGIS because they unload now all drivers by default except those in a white list, and they still needed a OGR driver. May I suggest a change that would improve backwards-compatibility and avoid unwanted issues? Perhaps these 2 functions should only register raster or vector drivers (as in GDAL 1.x), instead of all drivers, and a new function would register both raster and vector drivers. This would ensure old code behaves as previously, and ensure that no extra drivers are loaded and probed when only raster/vector drivers are needed. Just to be clearer here is how I would see it: GDALRegisterAll() - registers raster drivers (those with GDAL_DCAP_RASTER=YES) OGRAllRegister() - registers vector drivers (those with GDAL_DCAP_VECTOR=YES) GDALRegisterDrivers() - registers all drivers On the other habd, I imagine this may not be easy to implement and could cause some confusion in the future. That could be done, although I'm not sure it is really worth doing. There will be likely other changes in GDAL 2.0 development that will require adjustments in calling code. In your suggestion a driver that has a raster and vector face (like the re- unified PDF and PCIDSK done in RFC 46) should be listed in the two lists. Actually in QGIS case, the issue is likely not driver registration, but driver listing (in QGIS, both GDAL and OGR driver should be registered). So that wouldn't help. Also, probing optimization can instead be achieved using GDALOpenEx() specifying raster vs.vector drivers. GDALOpen() will only probe drivers that have raster capabilities. It is an alias of GDALOpenEx(filename, GDAL_OF_RASTER | update_flag ) Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
On Sat, May 24, 2014 at 4:54 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le samedi 24 mai 2014 21:28:39, Etienne Tourigny a écrit : Hi Even, great work! Quick testing was fine and revealed no errors. I was able to compile it in QGIS master very easily. The only issue I encountered was related to GDALRegisterAll() and OGRAllRegister() registering all drivers (raster and vector), requiring to ignore the vector-only drivers in the raster-only related code in QGIS. Yeah, I've noticed a similar issue in PostGIS because they unload now all drivers by default except those in a white list, and they still needed a OGR driver. May I suggest a change that would improve backwards-compatibility and avoid unwanted issues? Perhaps these 2 functions should only register raster or vector drivers (as in GDAL 1.x), instead of all drivers, and a new function would register both raster and vector drivers. This would ensure old code behaves as previously, and ensure that no extra drivers are loaded and probed when only raster/vector drivers are needed. Just to be clearer here is how I would see it: GDALRegisterAll() - registers raster drivers (those with GDAL_DCAP_RASTER=YES) OGRAllRegister() - registers vector drivers (those with GDAL_DCAP_VECTOR=YES) GDALRegisterDrivers() - registers all drivers On the other habd, I imagine this may not be easy to implement and could cause some confusion in the future. That could be done, although I'm not sure it is really worth doing. There will be likely other changes in GDAL 2.0 development that will require adjustments in calling code. In your suggestion a driver that has a raster and vector face (like the re- unified PDF and PCIDSK done in RFC 46) should be listed in the two lists. Actually in QGIS case, the issue is likely not driver registration, but driver listing (in QGIS, both GDAL and OGR driver should be registered). So that wouldn't help. sort of - the side effect of registering all vector drivers was that vector drivers were listed, so I filtered them using the GDAL_DCAP_RASTER Also, probing optimization can instead be achieved using GDALOpenEx() specifying raster vs.vector drivers. GDALOpen() will only probe drivers that have raster capabilities. It is an alias of GDALOpenEx(filename, GDAL_OF_RASTER | update_flag ) right- got confused there anyway - if important issues come up it might be worth changing this, if not no biggie. Again congrats! Etienne Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 46 GDAL/OGR unification adopted and commited
Hi, I can confirm the trunk builds without any problems with VS2013. Thanks Even! Best regards, Mateusz Loskot -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-RFC-46-GDAL-OGR-unification-adopted-and-commited-tp5142327p5142357.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
