Re: [gdal-dev] [RFC] [GDAL] Idea for GSoC, 2014
Kshitij, As suggested you should plan to allow user to select the algorithm for key point detection and matching. I'll explain how to do that later. But essentially you may get some input from the user to change the default algorithm to something else. So, all the steps should be done independent of each other. -- Best regards, Chaitanya Kumar CH On 16-Mar-2014 2:58 am, Dmitriy Baryshnikov bishop@gmail.com wrote: Hi, I only proposed to use the exist API - GDALComputeMatchingPoints, or modify it to support new method BRISK. You have not to modify SimpleSurf, but only make it still working as now. GDAL is library, not the Automatic geo-referencer utility and some common methods and functions should be developed. This does not deny that such a tool can be developed but it must use this common methods and functions. For example see the console utilities in apps folder of GDAL source tree. They use GDAL functions and methods. Best regards, Dmitry 16.03.2014 1:15, Seth Price пишет: I have done something like this recently. You would be better off tearing out SURF linking to OpenCV for all feature detection and extraction. Here is a link to the patch that OpenCV needs to support large 16 bit imagery. https://github.com/Itseez/opencv/pull/1932 ~Seth via iPhone On Mar 15, 2014, at 12:50 PM, Kshitij Kansal kansa...@gmail.com wrote: Hello Again, @Dimitriy - Currently the GDALComputeMatchingPoints is using the SimpleSurf algorithm for matching points. Are you proposing that, I should implement the BRISK and then provide user the option of using either this or SimpleSurf(already implemented)? This is indeed a very interesting thought but the problem in this is that, the GDALComputeMatchingPoints is developed with respect to the correlator project and I feel that SimpleSurf algorithm implemented there won't work on my Automatic geo-referencer as I would be considering the Multispectral Imagery and Large Datasets which are not handled in the current implementation.* So this will require modification to SimpleSurf as well.* I hope I have made my doubt clear? Please convey your views on this. @Chaitanya - In comparison to the SURF, BRISK can definitely handle the large imagery to great extent. But there is going to be some threshold upto which this algorithm will work because we must not forget that these algorithms are developed for Normal RGB images for Computer Vision related work and there usage to Remote Sensing requires some modification. I will try to look for this thing in more detail and then get back to you. Also, should I prepare my initial draft of proposal based this BRISK idea only? I have already started work in this direction and will soon post it, for review. With Regards, Kshitij Kansal Lab For Spatial Informatics, IIIT Hyderabad On Sat, Mar 15, 2014 at 12:29 AM, Chaitanya kumar CH chaitanya...@gmail.com wrote: Kshitij, What is the performance of the proposed algorithms for very large rasters? If one of them is good with large images that's a cleaner choice without all the workaround with scaling the rasters. -- Best regards, Chaitanya Kumar CH On 15-Mar-2014 12:22 am, Dmitriy Baryshnikov bishop@gmail.com wrote: Hi, I think we need to decide it here, not to create lot of proposals. The second idea is very interesting. Maybe it worth to create some common interface (or API) to add new methods BRISK, SURF, SIFT etc. You can develop you realisation of BRISK and demonstrate how-to one can use it via such common interface. E.g. in GDALComputeMatchingPoints add enum for algorithms or use exist papszOptions. Best regards, Dmitry ___ 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 ___ gdal-dev mailing listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev ___ 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
[gdal-dev] Non-default drivers from packaged installation
Hi list, my question is whether the drivers which are /not/ compiled by default in GDAL (because they depend on some other library) are checked at run time. I guess no. I am installing gdal-bin from APT, so if I need to enable a driver (JP2OpenJPEG in my case) that is not shipped in my precompiled version, I need to install GDAL from source. Is that right? Indeed I installed openjpeg v2, but then the JP2OpenJPEG driver is not listed (--formats). thanks, Piero http://www.gdal.org/formats_list.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Non-default drivers from packaged installation
Le dimanche 16 mars 2014 12:50:39, Piero Campalani a écrit : Hi list, my question is whether the drivers which are /not/ compiled by default in GDAL (because they depend on some other library) are checked at run time. I guess no. I am installing gdal-bin from APT, so if I need to enable a driver (JP2OpenJPEG in my case) that is not shipped in my precompiled version, I need to install GDAL from source. Is that right? Yes Indeed I installed openjpeg v2, but then the JP2OpenJPEG driver is not listed (--formats). Yes, you need to compile from source. There's no magic. If at built time of the Debian GDAL binary, the openjpeg v2 headers and libraries were not available, GDAL will not recompile itself automagically when they are available ;-) thanks, Piero http://www.gdal.org/formats_list.html -- 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
[gdal-dev] GML box in .JP2 image
Hi list, I am using GDAL 1.10 + JP2OpenJPEG driver to encode .JP2 files including a GML metadata box. http://www.gdal.org/frmt_jp2openjpeg.html I used it successfully to gdal_translate a JP2 from a GeoTIFF image, but then: what are the read/write options for the user with regards to the GML box? Can gdalinfo extract the GML information and display it? When creating a JP2 image, can I specify my own GML fragment? Best, Piero ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GML box in .JP2 image
Le dimanche 16 mars 2014 19:23:18, Piero Campalani a écrit : Hi list, I am using GDAL 1.10 + JP2OpenJPEG driver to encode .JP2 files including a GML metadata box. http://www.gdal.org/frmt_jp2openjpeg.html I used it successfully to gdal_translate a JP2 from a GeoTIFF image, but then: what are the read/write options for the user with regards to the GML box? As far as writing is concerned, the GMLJP2 creation option controls whether the GML box should be written or not. It defaults to YES, as documented. Can gdalinfo extract the GML information and display it? Yes, this is done automaticaly when trying to get the SRS and geotransformation matrix. With GDAL trunk (not 1.10), you can the GML fragment with the -mdd all option of gdalinfo. When creating a JP2 image, can I specify my own GML fragment? Yes, you must define the GMLJP2OVERRIDE configuration option to be the name of a file that contains the GML fragment. This is admitedly an undocumented feature. e.g : gdal_translate my.tif my.jp2 -of JP2OpenJPEG --config GMLJP2OVERRIDE my.gml Best, Piero -- 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] Recommended strategy to handle MIF file with a few big multipolygons
Hello, On Tue, Mar 11, 2014 at 12:05 AM, Even Rouault even.roua...@mines-paris.org wrote: Well, attach a debugger to the ogr2ogr process and see where the time is spent. your SQL clause could be replaced by -fid 1, but I'm not sure that the reason for the slowness. Don't know. I could handle to load it in PostGIS using ogr2ogr and changing some Postgres parameters. Thanks anyway! Hello, I'm working with a MIF file, contaning just 5 multipolygons (in form of regions, in MapInfo terms). But the file weights 700MB. So, the multipolygons are really big. I'd like to transform my file to SHP or PostGIS using ogr2ogr, but any operation takes forever. My current approach is to use -sql flag this way: ogr2ogr -sql select * from my_layer where fid = 1 my_layer.shp my_layer.mif But after 2 hours, it still continues working. I've activated debug, and last text I've seen is: Shape: Treating as encoding 'ISO-8859-1'. All the clip operations I've tried with ogr2ogr have the same problems: I have to wait hours, and after that, I just get a SHP of 100 Bytes. So, I kill the process. Should I be more patient? Or is there any smarter approach to handle this kind of file? Best regards, -- Geospatial professional services http://even.rouault.free.fr/services.html -- Jorge Arevalo Freelance developer http://about.me/jorgeas80 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
