[gdal-dev] using gdalwarp: defining target_spatial resolution
Greetings I'm using a bash script to reproject an image, using gdalwarp, to a set of Coordinates/Projection systems. I'm using -tr flag to define output spatial resolution. Since, i'm using UTM WGS84 I have this information in Meters (e.g. 30) so far, so good. The thing is that i need to reproject to this system +proj=longlat +no_defs +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 So, I'm getting an error because this system uses degrees not meters as units. and, I will probably get more problems in the near future with other systems My questions are: 1- from PROJ.4 format, how can I tell the units of the target coordinate/projection system 2- Since it's in degrees, does anyone suggest any (really good) tool to convert meters to degs? In order to parameterize -tr parameter? Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5832 (20110130) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Interrupt long operation
Hello, I need to interrupt a RasterIO and warp calls before they have been ended. The call is invoked in a background thread and It may happen that the user changes the requested area in the main thread (GUI) (eg. a pan/scroll operation). Any suggestion, Stefano Dr.Eng. Stefano Moratto stefano.mora...@gmail.com stefano.mora...@csiat.it http://www.csiat.it - Traffic Optimization Software ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bogus gml:Face interpretation
On Sun, Jan 30, 2011 at 01:51:08PM +0100, strk wrote: On Sun, Jan 30, 2011 at 01:24:08PM +0100, Even Rouault wrote: So we should implement detection of cycles to emit as many rings as necessary. Yes. This for each face. To add some more about the topic, I'm not sure the directedEdge tags should be ordered, so when detecting cycles the code might be better not rely on any specific ordering. Does anyone have evidence of requested ordering ? --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] Bogus gml:Face interpretation
strk, You are right. The sequence of the elements _can_ be specified explicitly using a sequence tag. Without that it will just be a guess work, especially if any of the rings have a common point. On Mon, Jan 31, 2011 at 3:38 PM, strk s...@keybit.net wrote: On Sun, Jan 30, 2011 at 01:51:08PM +0100, strk wrote: On Sun, Jan 30, 2011 at 01:24:08PM +0100, Even Rouault wrote: So we should implement detection of cycles to emit as many rings as necessary. Yes. This for each face. To add some more about the topic, I'm not sure the directedEdge tags should be ordered, so when detecting cycles the code might be better not rely on any specific ordering. Does anyone have evidence of requested ordering ? --Strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- 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
On 11-01-29 03:44 PM, Frank Warmerdam wrote: To that end, I have prepared an RFC which attempts to address this at the GDAL driver registration level. I'd appreciate feedback: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy Kudos for coming up with what sounds like a viable solution to this complicated licensing mess. -- 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 11-01-29 03:44 PM, Frank Warmerdam wrote: To that end, I have prepared an RFC which attempts to address this at the GDAL driver registration level. I'd appreciate feedback: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy I'm asymptotically approaching -1 on this RFC. My concern is that it misplaces the apparent responsibility for managing licensing constraints on *us*. It should always be the responsibility of users of the software to know, care, and mange the licensing of the software they're using. What happens if we mislabel a driver? Or not realize that a driver links to A, which links to B, which is GPL? It's still the user's responsibility, but we've just done them a disservice. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. Another reason I don't like this is that it puts us square in the middle of the GPL vs commercial software war which I don't think we have been so interested in fighting. IMO, we shouldn't try to protect users from having to care about this stuff, because they clearly need to understand the ground rules if they're going to choose to make a porridge of GPL and proprietary software. There's nothing preventing a user from manually registering only the drivers they need at runtime now. If they need to register only non-GPL drivers, or non-proprietary ones, they can do so. I completely agree this doesn't solve OSGeo4W's problem. I do not formally object to this RFC with a veto, and I expect that it will be implemented, but I wanted to voice my opinion that I think this is a slippery, slippery slope. Howard___ 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
Frank, I've reviewed the document and it looks good to me, though it seems better to enforce these constraints rather at deployment time and not at run-time. However I would have some further questions: 1. With regards to GDAL_APPLICATION_LICENSE_POLICY=DEFAULT does this mean that GDAL will provide an error if a licensing violation is happening at run-time? For example when MapServer attempts to display an ECW and a MySQL layer at the same time? If this is not the case, I would prefer changing 'DEFAULT' to 'NONRECIPROCAL' and it would prevent from loading the GPL drivers during the default operation. Having GDAL_APPLICATION_LICENSE_POLICY=NONRECIPROCAL would provide better match with the licensing policy of GDAL itself which intends to be MIT/X. 2. In my opinion the user shouldn't override any specific settings (like RECIPROCAL or PROPRIETARY) being enforced by the application. In this regard the user is allowed to violate the GPL like loading proprietary drivers in QGIS. I don't think if USE_ALL should be a valid environment setting either. This should only be allowed by a compilation flag which is not intended to be used for distribution purposes. 3. I think the user should only be allowed to override GDAL_APPLICATION_LICENSE_POLICY=DEFAULT either by the environment settings or in the SWIG interface. 4. I don't really understand the rationale behind the PREFER_PROPRIETARY and PREFER_RECIPROCAL settings. Shouldn't we raise an error if a licence violation is detected? I think we might have to decide which kind of the licensing enforcement should be applied in GDAL, like: Version 1, The actual licensing mode is predefined within the scope of the execution (either by the applevel or environment setting) and GDAL should avoid to load any incompatible drivers. Version 2, The actual licensing mode may be controlled by the drivers loaded and provide an error if an incompatible driver is about to be used. I'm a bit hesitant to think Version 2 would be sufficient which allows to change the licensing mode of the application at run-time. I think we should enforce the same licensing mode at least during the scope of the execution or the within a single deployment if possible. Best regards, Tamas 2011/1/29 Frank Warmerdam warmer...@pobox.com Folks, I have been thinking about how to adjust OSGeo4W in particular, and GDAL in general to make it easier to distribute software in a way that complies with the conflict between GPLed software and proprietary software. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. To that end, I have prepared an RFC which attempts to address this at the GDAL driver registration level. I'd appreciate feedback: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Interrupt long operation
On 11-01-31 04:26 AM, Stefano Moratto wrote: Hello, I need to interrupt a RasterIO and warp calls before they have been ended. The call is invoked in a background thread and It may happen that the user changes the requested area in the main thread (GUI) (eg. a pan/scroll operation). Stefano, Algorithms which take a GDALProgressFunc are likely to be interruptable. Each time the progress function is invoked it has the opportunity to return an indicate that the operation has been cancelled by the user. So the warper can be canceled if you provide a customized progress function. But RasterIO cannot since it has no progress function. If you want IO to be interruptible you would normally do it in modest sized chunks, though this can interfere with optimization of the IO in some cases. 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
On 11-01-31 11:30 AM, Tamas Szekeres wrote: Frank, I've reviewed the document and it looks good to me, though it seems better to enforce these constraints rather at deployment time and not at run-time. However I would have some further questions: 1. With regards to GDAL_APPLICATION_LICENSE_POLICY=DEFAULT does this mean that GDAL will provide an error if a licensing violation is happening at run-time? For example when MapServer attempts to display an ECW and a MySQL layer at the same time? Tamas, Note that the intent of the RFC is that in a case of incompatible drivers and the default policy one or more drivers would be de-registered to bring things into compliance. So, for instance the MySQL driver might be de-registered and that means any effort to use MySQL would result in an error message about it being an unsupported format since no driver would recognise it. It would *not* be a license error. If this is not the case, I would prefer changing 'DEFAULT' to 'NONRECIPROCAL' and it would prevent from loading the GPL drivers during the default operation. Having GDAL_APPLICATION_LICENSE_POLICY=NONRECIPROCAL would provide better match with the licensing policy of GDAL itself which intends to be MIT/X. I can see that NONRECIPROCAL might be a better term than DEFAULT but I don't want to avoid loading reciprocal (ie. GPL) drivers in a default situation. 2. In my opinion the user shouldn't override any specific settings (like RECIPROCAL or PROPRIETARY) being enforced by the application. In this regard the user is allowed to violate the GPL like loading proprietary drivers in QGIS. I don't think if USE_ALL should be a valid environment setting either. This should only be allowed by a compilation flag which is not intended to be used for distribution purposes. I disagree strongly! The end user always has the legal and moral right to mix proprietary and free software. The purpose of the override operation is for them to knowingly make the decision that they want to do this. 3. I think the user should only be allowed to override GDAL_APPLICATION_LICENSE_POLICY=DEFAULT either by the environment settings or in the SWIG interface. 4. I don't really understand the rationale behind the PREFER_PROPRIETARY and PREFER_RECIPROCAL settings. Shouldn't we raise an error if a licence violation is detected? I think we might have to decide which kind of the licensing enforcement should be applied in GDAL, like: Version 1, The actual licensing mode is predefined within the scope of the execution (either by the applevel or environment setting) and GDAL should avoid to load any incompatible drivers. This was my intent, though because of the way we get metadata from drivers to examine their license constraints it is necessary for us to load them and then deregister them if they are in violation. Version 2, The actual licensing mode may be controlled by the drivers loaded and provide an error if an incompatible driver is about to be used. 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
On 11-01-31 10:45 AM, Howard Butler wrote: http://trac.osgeo.org/gdal/wiki/rfc34_license_policy I'm asymptotically approaching -1 on this RFC. My concern is that it misplaces the apparent responsibility for managing licensing constraints on *us*. It should always be the responsibility of users of the software to know, care, and mange the licensing of the software they're using. What happens if we mislabel a driver? Or not realize that a driver links to A, which links to B, which is GPL? It's still the user's responsibility, but we've just done them a disservice. Howard, I do not believe we are taking on any legal or moral responsibility if a driver is mislabelled. I think a best effort on our part is fine. In the case of OSGeo4W the main restrictions is that we should not be distributing GRASS in such a way that proprietary drivers like the MrSID driver can be used without the user having knowingly combined them by themselves. Another reason I don't like this is that it puts us square in the middle of the GPL vs commercial software war which I don't think we have been so interested in fighting. I'll just note I do not see this as a war to fight. I am just trying to make it easier for software distributors to act responsibly with regard to licensing requirements of various components. IMO, we shouldn't try to protect users from having to care about this stuff, because they clearly need to understand the ground rules if they're going to choose to make a porridge of GPL and proprietary software. There's nothing preventing a user from manually registering only the drivers they need at runtime now. If they need to register only non-GPL drivers, or non-proprietary ones, they can do so. I completely agree this doesn't solve OSGeo4W's problem. You refer to user above, but I assume you are referring to application developers and software distributors. I agree that this RFC is not intended to absolve them of all awareness of the licensing of components they are distributing. I do not formally object to this RFC with a veto, and I expect that it will be implemented, but I wanted to voice my opinion that I think this is a slippery, slippery slope. You concerns have moderately sapped my interest in the RFC. As discussed in IRC it seems that the fact that the user must separately select packages like gdal-mrsid may be sufficient to protect OSGeo from license violation claims. I am going to try seeking input from the QGIS, and perhaps GRASS communities about their intent when applying the GPL license to their software. Beyond the strict legalities, I am interested in accounting for the intent of developers of GPL software. 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
I think Mr. Butler makes a good point. Maybe just have folders in the source tree called frmts/reciprocal and frmts/proprietary and the same for any libs. That way it's in people's face all the time and impossible not to be conscious of what is licenced how. And easy to exclude such drivers, just skip building that folder's makefile. If I want total certainty, I can even delete those folders. And if someone makes a classification mistake, it'll be more obvious too (hey, driver XXX shouldn't be in that folder). Ray Gardener Daylon Graphics Ltd. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ERROR 1: tolerance condition error when projecting to gnomonic
Hello, I'm running into some problems warping to gnomonic projection. I'm trying to warp a TIFF in azimuthal-equidistant projection (covering North America, including the north pole and centered on 46°N, 95°W) to gnomonic. These are the relevant details and coverage of the input TIFF: http://dpaste.com/hold/372063/ Here's what I'm trying: gdalwarp -t_srs +proj=gnom +lat_0=0 +lon_0=0 -te -6378137 -6378137 6378137 6378137 -ts 512 512 NAPHY_r-latlon.tif NAPHY_r-gnom.tif Here's what I'm seeing: ERROR 1: tolerance condition error ERROR 1: tolerance condition error ... ERROR 1: tolerance condition error ERROR 1: Reprojection failed, err = -20, further errors will be supressed on the transform object. The output looks to be a black square. I've successfully reprojected this same input TIFF to both spherical mercator and latlon, so I tried converting to one of those first and then gnomonic second, but still got the same errors. For what it's worth, the geographic info for the projected all-black TIFF looks right: http://dpaste.com/hold/372080/ I found this from six years ago and tried adding the recommended -wo SOURCE_EXTRA=100 -wo SAMPLE_GRID=YES parameters to gdalwarp, but I'm still seeing the same tolerance condition errors: http://trac.osgeo.org/gdal/ticket/642 Any ideas? -mike. michal migurski- m...@stamen.com 415.558.1610 ___ 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-01-31 12:28 PM, Ray Gardener wrote: I think Mr. Butler makes a good point. Maybe just have folders in the source tree called frmts/reciprocal and frmts/proprietary and the same for any libs. That way it's in people's face all the time and impossible not to be conscious of what is licenced how. And easy to exclude such drivers, just skip building that folder's makefile. If I want total certainty, I can even delete those folders. And if someone makes a classification mistake, it'll be more obvious too (hey, driver XXX shouldn't be in that folder). Ray, That would be adequate for those who are building things from source and wanting to distribute the resulting binaries under a single consistent licensing policy. However it does not help me for the OSGeo4W need. OSGeo4W is a unified installer that can install a wide variety of OSGeo project binaries for windows into one unified tree. So, for instance if you install QGIS, MapServer and GRASS which all use GDAL they will end up using a common copy of GDAL. Users also often want proprietary format drivers for formats like MrSID and there is an optional package offered for this. In this situation MapServer and GDAL are under a non-reciprocal open source licenses and there is no problem using them with proprietary drivers. However, QGIS and GRASS are GPL and it is improper to distribute them with proprietary drivers. I am *hoping* to be able to deliver a solution that lets users have proprietary drivers easily with MapServer or GDAL commandline, while not letting them use these drivers with QGIS or GRASS unless they make a deliberate decision to do so even though it abridges the freedoms they would normally have with GPLed software. In the RFC I have also tried to offer a way for proprietary software to avoid loading GPLed drivers accidentally. But as you note most proprietary software distributors will just take care to avoid building in any GPLed dependencies at compile time. However, I do like to imagine a time in which even proprietary software distributors might be able to take advantage of common system level installations of GDAL in which case greater care about licenses might be appropriate. 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
On 1/31/2011 12:32 PM, Frank Warmerdam wrote: That would be adequate for those who are building things from source and wanting to distribute the resulting binaries under a single consistent licensing policy. However it does not help me for the OSGeo4W need. OSGeo4W is a unified installer... [snip] Well, I'm definitely not a lawyer, but it sounds to me that OSGeo4W is in violation. I mean, they take GDAL, combine it with GPL'd code, and expect you to help bless the marriage. Why not just let OSGeo4W do its own licence management, since it's the one that's creating the problem. It can embed a little table inside itself that says which drivers are under which licence. If you move that logic into GDAL itself, then you'll share responsibility if a ruling occurs against OSGeo4W. If you keep the logic outside, then you can honestly claim that any violation happened beyond your control, and that conflicting drivers were combined into a package against your stated policies. The moment you have that logic internalized, you explicitly authorize -- or at the very least facilitate -- third parties to combine conflicting code in a distributable. The fact that the real damage doesn't happen until runtime (that the app in question happens to be an installer) may be a distinction that offended parties won't care to make. I'd prefer any perceived wrongdoing by OSGeo4W to stay firmly on its side. Stallman is very leery of any tricks to workaround GPL, and this creative bundling using evil bits will smell of that. To him, the mere mixture in a distribution will be damage enough. At the very least, I'd check with him first if you haven't already, and get whatever concessions are offered in writing. Ray ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata
Thanks for all the suggestions. The following website: http://sites.google.com/site/bpederse/caliwms gave me an idea of how to treat the JPEG artifacts. Going back to our previous discussion, the OpenJPEG implementation of JPEG2000 creates very clean (at the boundary of data/nodata) compressed images when compared to JPEG. But, because it's a new format, I'll have to wait until it's implemented in the jai-imageio-ext package. -marius Le samedi 29 janvier 2011 22:40:20, Marius Jigmond a écrit : The link should work for another day or so (automatic server purge). I can re-upload it if you don't get the chance to download it. Warning: 1.2GB. https://www.twdb.state.tx.us/filetxfr/emaillinkdownload.aspx?id=FileTransf erID=289562464 ok, I've reproduced the bug and fixed it in http://trac.osgeo.org/gdal/ticket/3938 This was one of the most interesting bug since months I had to track down ! Thanks for reporting. Even ___ 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
then you can honestly claim that any violation happened beyond your control ...except that Frank is the principle organizer/maintainer behind OSGeo4W as well as GDAL. Not that this necessarily contravenes your main point, that since the gray area is in o4w and not gdal that's where the license agreeing/denying logic should take place. I do hope this policy or something like it come to be, whether in gdal or osgeo4w. I work in both worlds and a more easeful coexistence, without obscuring or hiding the legal differences and responsibilities, is welcome. Personally I don't see osgeo4w's bundling or the current RFC under discussion to be much different from enabling Ubuntu's universe and restricted-driver repositories. 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
[gdal-dev] creating .VRT files with the python bindings
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] Licensing Policy for drivers and applications
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. Ray ___ 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 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
