[gdal-dev] Geometric Correction and Resampling
Dear all, I need, using GDAL, a Geometric Correction and Resampling program for ERDAS img in C++/MFC. Can you please help me. If you don't have the source code, would you please mail me the detailed algorithm(s) to accomplish the task. With many thanks, Ramesh ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geometric Correction and Resampling
Ramesh, Look at the GDAL command line utility list at http://www.gdal.org/gdal_utilities.html and decide on the functionality you want out of them. You can use their source code at http://trac.osgeo.org/gdal/browser/trunk/gdal/apps . On Tue, Feb 1, 2011 at 5:53 PM, user gdal userofg...@gmail.com wrote: Dear all, I need, using GDAL, a Geometric Correction and Resampling program for ERDAS img in C++/MFC. Can you please help me. If you don't have the source code, would you please mail me the detailed algorithm(s) to accomplish the task. With many thanks, Ramesh ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
This is exactly why many commercial applications do not or can not port to Linux. The GPL is a virus license, if you really wanted the code to be free it would be released under an MIT style license. The GPL/LGPL is just another proprietary license scheme that is meant to prevent people from using the code in any commercial venture. Which is OK if you are a government agency or a school. There are many format suppliers that do not allow their IP to be exposed, Maptech is a good example. The BSB 3 format was reverse engineered but, no one has gotten permission to publish the BSB 4 or 5 formats. We supported this format on Linux and Mac and have signed license agreements that prevent the release of the code. Which means we can not utilize tainted GPL/LGPL code in our applications. Which is unfortunate for the users, as they do not have the choice of turning on other drivers. I would agree with Ray, do not put the limiter in GDAL instead put it in the OSGeo4W code base. Best regards, Patrick Cannon Barco Software LLC www.barcosoft.com www.barcosoft.net This message is intended solely for the use of the designated recipient(s), and may contain confidential information. Any unauthorized disclosure; copying or distribution of its contents is strictly prohibited. If you have received this message in error, please destroy it and advise the sender immediately by phone or facsimile. Reproduction or distribution of this message and any attached materials is strictly prohibited. On Tuesday 01 February 2011 12:49:19 am strk wrote: On Mon, Jan 31, 2011 at 08:59:25PM -0800, Ray Gardener wrote: I should ask, is it okay for commercial apps to include GPL'd drivers currently? What would happen if my app included one? Do I have to wait for it to be under LGPL? I don't mind at all sharing any changes I may make to such drivers, but if I can't even include the drivers, that seems excessive. You can include the drivers, and your application can be commercial. Only, you have to give your customers the rights to get your application's source code, to modify it and to redistribute it. If you don't want to do that, ask the GPL driver copyright holders if they agree on you putting the code they allowed you to use, look at, modify and distribute into something they can NOT look at, modify or distribute. Sounds kind of unfair to me, but they may have a different opinion (or business plan) on the matter. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ 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] Licensing Policy for drivers and applications
On Tue, Feb 01, 2011 at 07:04:44AM -0600, Patrick Cannon wrote: This is exactly why many commercial applications do not or can not port to Linux. Again: you mean closed-source applications here, not commercial, right ? The GPL is a virus license, if you really wanted the code to be free it would be released under an MIT style license. The GPL/LGPL is just another proprietary license scheme that is meant to prevent people from using the code in any commercial venture. Which is OK if you are a government agency or a school. I don't get this. What prevents you from talking with the copyright holder of a GPL/LGPL licenced software the same way you'd talk with the copyright holder of a proprietary licensed software ? There are many format suppliers that do not allow their IP to be exposed, Maptech is a good example. The BSB 3 format was reverse engineered but, no one has gotten permission to publish the BSB 4 or 5 formats. This is a very good reason for NOT using such formats. I don't see how you can blame people giving you the grant to USE and MODIFY and REDISTRIBUTE their code for not helping the spread of such trap formats. You should be grateful. We supported this format on Linux and Mac and have signed license agreements that prevent the release of the code. Which means we can not utilize tainted GPL/LGPL code in our applications. Which is unfortunate for the users, as they do not have the choice of turning on other drivers. They have the choice of not using your software, being tainted by a restricting license preventing them from looking at the code. They do have the choice of using free software (be it commercial or not). --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-02-01 09:21 AM, strk wrote: On Tue, Feb 01, 2011 at 07:04:44AM -0600, Patrick Cannon wrote: The GPL is a virus license, if you really wanted the code to be free it would be released under an MIT style license. The GPL/LGPL is just another proprietary license scheme that is meant to prevent people from using the code in any commercial venture. Which is OK if you are a government agency or a school. I don't get this. What prevents you from talking with the copyright holder of a GPL/LGPL licenced software the same way you'd talk with the copyright holder of a proprietary licensed software ? Unfortunately, due to the collaborative nature of open source software, there is not always (and actually very rarely) a single copyright holder to talk to in order to request a license change or exception. Take for instance GRASS and QGIS: who should one talk to? I speak from experience: I had to refrain from using QGIS in a (closed-source) project for a client not long ago because of its GPL license. If there had been a single copyright holder I'd have talked to that person instead of starting from scratch, but with multiple copyright holders that simply made QGIS a no-go and the QGIS project as a whole lost some potential users and contributors. -- Daniel Morissette http://www.mapgears.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On Tue, Feb 01, 2011 at 10:33:20AM -0500, Daniel Morissette wrote: I speak from experience: I had to refrain from using QGIS in a (closed-source) project for a client not long ago because of its GPL license. If there had been a single copyright holder I'd have talked to that person instead of starting from scratch, but with multiple copyright holders that simply made QGIS a no-go and the QGIS project as a whole lost some potential users and contributors. How much did starting from scratch cost to you or your client ? Was it worth the closed-source choice ? I guess it was (or the client wouldn't have taken it) Well, my hope is that choosing proprietary software will be increasly less worth, thus I prefer licenses on the free plate of the balance. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
On 11-02-01 11:04 AM, Ray Gardener wrote: Oh man. So over time, as more GPL'd drivers are written, the very purpose of GDAL gets watered down. It's not like people are going to develop MIT-licenced drivers if they see an existing GPL driver that does the job. At the very least, the motivation will be blunted. The whole reason I went with GDAL was that it was reasonable in regards to commercial devs. Now there's going to be a situation where they get increasingly treated as second-class citizens. It's unreasonable to disclose a large application just because drivers are GPL'd. It should be submission policy to GDAL that they're LGPL'd. Frank's gone to the trouble of creating an environment that is commercial agnostic, and now it's being undone. Folks, I would prefer that this RFC discussion not turn into a broad license argument. I accept the rights of software developers to offer their product under proprietary, recriprocal or non-reciprocal licenses and we as consumer need to take or leave the offered components on their own terms. GDAL is released under an MIT/X nonrecriprocal open source license because I and others believe this allows us to serve and involve the largest possible community. When we have an option between a proprietary driver or a nonreciprocal driver then we will choose the nonreciprocal driver. When we have a chose between a reciprocally licensed driver and a non-reciprocally licensed driver we will choose the nonreciprocally licensed driver. But I do not accept a that GDAL is made poorer by also having options for proprietary and reciprocal drivers for purposes that we could not otherwise serve. I don't see any evidence that GDAL is becoming more dependent on GPL or proprietary drivers as time goes on. Care has always been called for by distributors of software based on GDAL. Ray, Patrick and Howard have argued against taking on runtime responsibility for license checking in GDAL. I only very weakly grasp the argument so it might be worth expanding on it. But this RFC is not about whether there will be proprietary GDAL drivers, or reciprocally licensed drivers. There have been, are and will be. The question is in what ways does it make sense for the project to help support application developers and distributors in being license compliant. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Licensing Policy for drivers and applications
Well said Frank. Thank you. matt wilkie Geomatics Analyst Information Management and Technology Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Gdalwarp -crop_to_cutline results in shifted raster
Submitted as ticket# 3947 but I had to link the sample data because of size. -marius Date: Tue, 1 Feb 2011 19:00:13 +0530 Subject: Re: [gdal-dev] Gdalwarp -crop_to_cutline results in shifted raster From: chaitanya...@gmail.com To: mariusjigm...@hotmail.com CC: gdal-dev@lists.osgeo.org Marius, Can you provide some sample data to investigate this? You can raise a ticket at http://trac.osgeo.org/gdal/newticket and attach the data. On Tue, Feb 1, 2011 at 8:12 AM, Marius Jigmond mariusjigm...@hotmail.com wrote: Hi Everyone, I am using the -crop_to_cutline option of gdalwarp but the resulting raster is slightly shifted. Both cutline shapefile and raster are using the same projection. On the sample raster dataset (pixel=28.5m) the shift is about 5m to the east and 3.5m to the north. Pixel values remain the same (so resampling doesn't take place, as expected). I should add that not adding -crop_to_cutline results in no shift. Commands I ran: (1) gdalwarp -cutline mask.shp -crop_to_cutline sample.tif cropped.tif result is shifted (2) gdalwarp -cutline mask.shp sample.tif out.tif result is not shifted A workaround would be using gdal_rasterize on after option (2) above. -marius ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] creating .VRT files with the python bindings
Ricardo, Basically the XML you pass with SetMetadataItem() is deserialized and serialized again, but the relativeToVRT element isn't part of the internal model of the VRT driver and is recomputed at serialization time, so this explains why it can change behind your back. I think however that this has been fixed in GDAL 1.8.0 in http://trac.osgeo.org/gdal/changeset/20939 Best regards, Even Le mardi 01 février 2011 02:27:36, Ricardo Filipe Soares Garcia da a écrit : Hello list I am trying to create a .VRT file to mosaic a bunch of HDF5 files. It is starting to work, except for the fact that I can't seem to set the relativeToVRT attribute of the SourceFilename tag to 0. I've been adapting the online vrt tutorial[1] from C++ to Python. The tutorial says that relativeToVRT will default to 0, but I'm getting the exact opposite. It is defaulting to 1, and even if I try to set it to 0 explicitly when using the SetMetadataItem method, it will still be saved as a 1. I have included an excerpt of the code at the end of this message. I'll post the rest of it if it is relevant. After saving the file, I can open a text editor and replace all the 1 with 0 and this fixes it, allowing me to get the desired visualization (on QGIS). Am I doing something wrong here? Or is this possibly a bug? I'm using gdal 1.7.3, as available on the ubuntugis-unstable repository. Another question: is it possible to use derived bands via python bindings? I guess I'll have to write a pixel function and somehow register it with gdal... [1] - http://www.gdal.org/gdal_vrttut.html [2] - python code follows: def get_xml_source(fileName, dataSet, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize, relToVRT=0, band=1): template = SimpleSource SourceFilename relativeToVRT='%i'HDF5:%s://%s/SourceFilename SourceBand%i/SourceBand SourceProperties RasterXSize='%i' RasterYSize='%i' DataType='%s' BlockXSize='%i' BlockYSize='%i' / SrcRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / DstRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / /SimpleSource return template % (relToVRT, fileName, dataSet, band, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize) somewhere down the code... xmlSource = get_xml_source(lit, dataSet, xResolution, yResolution, Int16, blockXSize, blockYSize, 0, 0, xResolution, yResolution, xOff, yOff, xResolution, yResolution) outBand.SetMetadataItem(teste, xmlSource, new_vrt_sources) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] creating .VRT files with the python bindings
Hi Even, list Since I don't have a chance to test gdal 1.8.0 at my machine, I decided to apply an (ugly) hack to alter the VRT file after it is created, changing all the 'relativeToVRT' values to '0'. It is working fine. About my other question: - Is it possible to use derived bands via python bindings? I guess I'll have to write a pixel function and somehow register it with gdal... My HDF5 files have a scaling factor that I'd like to correct through the VRT. I guess this is one of the points in using derived bands. If it can't be done with a derived band, is there other option? Thanks On Tue, Feb 1, 2011 at 6:50 PM, Even Rouault even.roua...@mines-paris.org wrote: Ricardo, Basically the XML you pass with SetMetadataItem() is deserialized and serialized again, but the relativeToVRT element isn't part of the internal model of the VRT driver and is recomputed at serialization time, so this explains why it can change behind your back. I think however that this has been fixed in GDAL 1.8.0 in http://trac.osgeo.org/gdal/changeset/20939 Best regards, Even Le mardi 01 février 2011 02:27:36, Ricardo Filipe Soares Garcia da a écrit : Hello list I am trying to create a .VRT file to mosaic a bunch of HDF5 files. It is starting to work, except for the fact that I can't seem to set the relativeToVRT attribute of the SourceFilename tag to 0. I've been adapting the online vrt tutorial[1] from C++ to Python. The tutorial says that relativeToVRT will default to 0, but I'm getting the exact opposite. It is defaulting to 1, and even if I try to set it to 0 explicitly when using the SetMetadataItem method, it will still be saved as a 1. I have included an excerpt of the code at the end of this message. I'll post the rest of it if it is relevant. After saving the file, I can open a text editor and replace all the 1 with 0 and this fixes it, allowing me to get the desired visualization (on QGIS). Am I doing something wrong here? Or is this possibly a bug? I'm using gdal 1.7.3, as available on the ubuntugis-unstable repository. Another question: is it possible to use derived bands via python bindings? I guess I'll have to write a pixel function and somehow register it with gdal... [1] - http://www.gdal.org/gdal_vrttut.html [2] - python code follows: def get_xml_source(fileName, dataSet, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize, relToVRT=0, band=1): template = SimpleSource SourceFilename relativeToVRT='%i'HDF5:%s://%s/SourceFilename SourceBand%i/SourceBand SourceProperties RasterXSize='%i' RasterYSize='%i' DataType='%s' BlockXSize='%i' BlockYSize='%i' / SrcRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / DstRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / /SimpleSource return template % (relToVRT, fileName, dataSet, band, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize) somewhere down the code... xmlSource = get_xml_source(lit, dataSet, xResolution, yResolution, Int16, blockXSize, blockYSize, 0, 0, xResolution, yResolution, xOff, yOff, xResolution, yResolution) outBand.SetMetadataItem(teste, xmlSource, new_vrt_sources) -- ___ ___ __ Ricardo Garcia Silva ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] creating .VRT files with the python bindings
Le mardi 01 février 2011 22:57:10, Ricardo Filipe Soares Garcia da a écrit : Hi Even, list Since I don't have a chance to test gdal 1.8.0 at my machine, I decided to apply an (ugly) hack to alter the VRT file after it is created, changing all the 'relativeToVRT' values to '0'. It is working fine. I imagine ubuntugis will be updated at some point to use GDAL 1.8.0 About my other question: - Is it possible to use derived bands via python bindings? I guess I'll have to write a pixel function and somehow register it with gdal... I don't think it is possible via python bindings. You probably need to use C++ for that. My HDF5 files have a scaling factor that I'd like to correct through the VRT. I guess this is one of the points in using derived bands. If it can't be done with a derived band, is there other option? Yes, instead of adding a SimpleSource use a ComplexSource than is an extension of SimpleSource that can have a ScaleRatio sub element. See http://www.gdal.org/gdal_vrttut.html Thanks On Tue, Feb 1, 2011 at 6:50 PM, Even Rouault even.roua...@mines-paris.org wrote: Ricardo, Basically the XML you pass with SetMetadataItem() is deserialized and serialized again, but the relativeToVRT element isn't part of the internal model of the VRT driver and is recomputed at serialization time, so this explains why it can change behind your back. I think however that this has been fixed in GDAL 1.8.0 in http://trac.osgeo.org/gdal/changeset/20939 Best regards, Even Le mardi 01 février 2011 02:27:36, Ricardo Filipe Soares Garcia da a écrit : Hello list I am trying to create a .VRT file to mosaic a bunch of HDF5 files. It is starting to work, except for the fact that I can't seem to set the relativeToVRT attribute of the SourceFilename tag to 0. I've been adapting the online vrt tutorial[1] from C++ to Python. The tutorial says that relativeToVRT will default to 0, but I'm getting the exact opposite. It is defaulting to 1, and even if I try to set it to 0 explicitly when using the SetMetadataItem method, it will still be saved as a 1. I have included an excerpt of the code at the end of this message. I'll post the rest of it if it is relevant. After saving the file, I can open a text editor and replace all the 1 with 0 and this fixes it, allowing me to get the desired visualization (on QGIS). Am I doing something wrong here? Or is this possibly a bug? I'm using gdal 1.7.3, as available on the ubuntugis-unstable repository. Another question: is it possible to use derived bands via python bindings? I guess I'll have to write a pixel function and somehow register it with gdal... [1] - http://www.gdal.org/gdal_vrttut.html [2] - python code follows: def get_xml_source(fileName, dataSet, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize, relToVRT=0, band=1): template = SimpleSource SourceFilename relativeToVRT='%i'HDF5:%s://%s/SourceFilename SourceBand%i/SourceBand SourceProperties RasterXSize='%i' RasterYSize='%i' DataType='%s' BlockXSize='%i' BlockYSize='%i' / SrcRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / DstRect xOff='%i' yOff='%i' xSize='%i' ySize='%i' / /SimpleSource return template % (relToVRT, fileName, dataSet, band, xSize, ySize, dType, blockX, blockY, sXOff, sYOff, sXSize, sYSize, dXOff, dYOff, dXSize, dYSize) somewhere down the code... xmlSource = get_xml_source(lit, dataSet, xResolution, yResolution, Int16, blockXSize, blockYSize, 0, 0, xResolution, yResolution, xOff, yOff, xResolution, yResolution) outBand.SetMetadataItem(teste, xmlSource, new_vrt_sources) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
