[gdal-dev] Image compositing in VRT files
Hello, I have two sets of tiles. The first one contain RGB tiles, let us call it orthophotos. The first one contain RGBA tiles, let us call it roads (with transparent background) Is it possible to write a VRT file, so that the resulting image would have only 3 channels RGB, and show the roads on the orthophotos ? Regards, Alain ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Image compositing in VRT files
On Fri, Feb 11, 2011 at 12:23 PM, Alain Cembro acem...@yahoo.com wrote: Hello, I have two sets of tiles. The first one contain RGB tiles, let us call it orthophotos. The first one contain RGBA tiles, let us call it roads (with transparent background) Is it possible to write a VRT file, so that the resulting image would have only 3 channels RGB, and show the roads on the orthophotos ? Regards, Alain ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Hello Alain, You probably can use gdal_vrtmerge.py script in this way: gdal_vrtmerge.py -o out.vrt list of tiff files You can modify the out.vrt file to include only the bands you're interested in. Best regards, -- Jorge Arévalo Internet Mobilty Division, DEIMOS jorge.arev...@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://www.twitter.com/jorgeas80 http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Reviving the PHP Bindings
Hello, This is a reply to the PHP Bindings thread that has been started by Mike Leahy.I have just registered with the list, so I was not able to reply to the thread. I am also interested in getting the PHP bindings for GDAL up to date. Right now we're using the gdal command line utilities a lot from within PHP. We're relying on regular expressions to parse the output at the moment. So it would make development a lot easier if we could use the internal GDAL classes and functions from within PHP. A few months ago I have created a little PHP module that converts projection strings from wkt to proj format (and vice versa) using the SpatialReference class. But it would be great if more functionality could be used from inside PHP. What can be done to revive the PHP bindings? Are more people interested I am a PHP developer with some knowledge of C/C++. My main interest at the moment are: 1. Using the SpatialReference class from within PHP 2. Retrieving map(meta)data like gdalinfo does from within PHP Regards, Joris van de Sande ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Image compositing in VRT files
Hello Jorge, --- On Fri, 2/11/11, Jorge Arévalo jorge.arev...@deimos-space.com wrote: You probably can use gdal_vrtmerge.py script in this way: gdal_vrtmerge.py -o out.vrt list of tiff files You can modify the out.vrt file to include only the bands you're interested in. Sorry, it doesn't work : If I put the roads.tif first, there is an exeption : $ gdal_vrtmerge.py -o test.vrt roads.tif photos.tif Traceback (most recent call last): File /usr/share/gdal/samples/gdal_vrtmerge.py, line 320, in module fi.write_source(t_fh, geotransform, xsize, ysize, band) File /usr/share/gdal/samples/gdal_vrtmerge.py, line 150, in write_source data_type_name = gdal.GetDataTypeName(self.band_types[s_band]) IndexError: list index out of range If I put the photos.tif first, a VRT file is created, but I can only see the roads on a white background instead of the photos background. $ gdal_vrtmerge.py -o test.vrt photos.tif roads.tif More infos : $ gdalinfo roads.tif Band 1 Block=256x256 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=256x256 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=256x256 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=256x256 Type=Byte, ColorInterp=Alpha $ gdalinfo photos.tif Band 1 Block=256x256 Type=Byte, ColorInterp=Red Band 2 Block=256x256 Type=Byte, ColorInterp=Green Band 3 Block=256x256 Type=Byte, ColorInterp=Blue $ gdalinfo test.vrt Band 1 Block=128x128 Type=Byte, ColorInterp=Red Band 2 Block=128x128 Type=Byte, ColorInterp=Green Band 3 Block=128x128 Type=Byte, ColorInterp=Blue ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Image compositing in VRT files
2011/2/11 Alain Cembro acem...@yahoo.com: Hello Jorge, --- On Fri, 2/11/11, Jorge Arévalo jorge.arev...@deimos-space.com wrote: You probably can use gdal_vrtmerge.py script in this way: gdal_vrtmerge.py -o out.vrt list of tiff files You can modify the out.vrt file to include only the bands you're interested in. Sorry, it doesn't work : If I put the roads.tif first, there is an exeption : $ gdal_vrtmerge.py -o test.vrt roads.tif photos.tif Traceback (most recent call last): File /usr/share/gdal/samples/gdal_vrtmerge.py, line 320, in module fi.write_source(t_fh, geotransform, xsize, ysize, band) File /usr/share/gdal/samples/gdal_vrtmerge.py, line 150, in write_source data_type_name = gdal.GetDataTypeName(self.band_types[s_band]) IndexError: list index out of range If I put the photos.tif first, a VRT file is created, but I can only see the roads on a white background instead of the photos background. $ gdal_vrtmerge.py -o test.vrt photos.tif roads.tif More infos : $ gdalinfo roads.tif Band 1 Block=256x256 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=256x256 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=256x256 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=256x256 Type=Byte, ColorInterp=Alpha $ gdalinfo photos.tif Band 1 Block=256x256 Type=Byte, ColorInterp=Red Band 2 Block=256x256 Type=Byte, ColorInterp=Green Band 3 Block=256x256 Type=Byte, ColorInterp=Blue $ gdalinfo test.vrt Band 1 Block=128x128 Type=Byte, ColorInterp=Red Band 2 Block=128x128 Type=Byte, ColorInterp=Green Band 3 Block=128x128 Type=Byte, ColorInterp=Blue Hello, The error is caused because both files have different band number. If you put road.tif first (4 bands), the script tries to fetch 4 bands from all files, and fails with the 3-bands tif photos.tif. When you put photos.tif in first place, then the scripts takes 3 bands for all files, and you lose the alpha band (that's the reason of white bg instead a transparent one) I'm not sure if I'm talking nonsense, but you may use one of the bands from photos.tif as alpha channel for the resulting vrt file. You can change the VRT file by hand (http://www.gdal.org/gdal_vrttut.html) Sorry, I don't know if it really helps... Maybe I'm wrong -- Jorge Arévalo Internet Mobilty Division, DEIMOS jorge.arev...@deimos-space.com http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://www.twitter.com/jorgeas80 http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdapwarp problem
I am having a problem trying to use gdalwarp. Perhaps I am just missing something, but I figured I would see if someone can help. I downloaded some aerial imagery from here: http://www.michigan.gov/dnr/0,1607,7-153-10371_14546-30211--,00.html I want to import it into a UTM zone 17 project. So I did the following: gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid gdapwarp responds with an error, but then continues with the conversion: ERROR 6: Failed to initialize PROJ.4 with `+proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs '. lat_0 = 0 or 90 or alpha = 90 0...10...20...30...40...50...60...70...80...90...100 - done. It does complete, but the area of interest is in the range of UTM (254500,4734000) and the output of gdalwarp is around 663144,240035. Any suggestions for what I might be doing wrong? If I do gdalinfo on the original file here is what I get: Driver: MrSID/Multi-resolution Seamless Image Database (MrSID) Files: oakgrove_sw.sid oakgrove_sw.sdw oakgrove_sw.sid.aux.xml Size is 6415, 8061 Coordinate System is: PROJCS[IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection = Oblique Mercator (Hotine)|IMAGINE, GEOGCS[NAD83, DATUM[North_American_Datum_1983, SPHEROID[GRS 1980,6378137,298.2572221010002, AUTHORITY[EPSG,7019]], AUTHORITY[EPSG,6269]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4269]], PROJECTION[Hotine_Oblique_Mercator], PARAMETER[latitude_of_center,0], PARAMETER[longitude_of_center,0], PARAMETER[azimuth,0], PARAMETER[rectified_grid_angle,90], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (663144.500,240035.500) Pixel Size = (1.000,-1.000) Metadata: IMAGE__INPUT_NAME=K:\blk18\oakgrove_sw.tif IMAGE__INPUT_FILE_SIZE=155199578.00 GEOTIFF_NUM__1024__GTModelTypeGeoKey=1 GEOTIFF_CHAR__GTModelTypeGeoKey=ModelTypeProjected GEOTIFF_NUM__1025__GTRasterTypeGeoKey=1 GEOTIFF_CHAR__GTRasterTypeGeoKey=RasterPixelIsArea GEOTIFF_NUM__1026__GTCitationGeoKey=IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection Name = Oblique Mercator (Hotine) Units = meters GeoTIFF Units = meters| GEOTIFF_NUM__2048__GeographicTypeGeoKey=4269 GEOTIFF_CHAR__GeographicTypeGeoKey=GCS_NAD83 GEOTIFF_NUM__2060__GeogAzimuthUnitsGeoKey=9102 GEOTIFF_CHAR__GeogAzimuthUnitsGeoKey=Angular_Degree GEOTIFF_NUM__3072__ProjectedCSTypeGeoKey=32767 GEOTIFF_CHAR__ProjectedCSTypeGeoKey=User-Defined GEOTIFF_NUM__3073__PCSCitationGeoKey=IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection Name = Oblique Mercator (Hotine) Units = meters GeoTIFF Units = meters| GEOTIFF_NUM__3074__ProjectionGeoKey=32767 GEOTIFF_CHAR__ProjectionGeoKey=User-Defined GEOTIFF_NUM__3075__ProjCoordTransGeoKey=3 GEOTIFF_CHAR__ProjCoordTransGeoKey=CT_ObliqueMercator GEOTIFF_NUM__3076__ProjLinearUnitsGeoKey=9001 GEOTIFF_CHAR__ProjLinearUnitsGeoKey=Linear_Meter GEOTIFF_NUM__3088__ProjCenterLongGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 GEOTIFF_NUM__3089__ProjCenterLatGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 GEOTIFF_NUM__3090__ProjCenterEastingGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 GEOTIFF_NUM__3091__ProjCenterNorthingGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 GEOTIFF_NUM__3093__ProjScaleAtCenterGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 GEOTIFF_NUM__3094__ProjAzimuthAngleGeoKey=0.999600,45.309167,2546731.496000,-4354009.816000,337.255560,-86.00 IMAGE__Z_RESOLUTION=0.00 GEO__ModelTypeGeoKey=1 GEO__ProjectedCSTypeGeoKey=32767 GEO__PCSCitationGeoKey=IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $ Projection = Oblique Mercator (Hotine)|IMAGINE GeoTIFF Support Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: egtf.c $ $Revision: 1.7 $ $Date: 2001/09/27 14:59:29EDT $
Re: [gdal-dev] gdapwarp problem
On 02/11/11 19:20, Adam Dershowitz, Ph.D., P.E. wrote: +proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs Hello, PROJ.4 is more verbose about the problem: $ proj +proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs Rel. 4.7.1, 23 September 2009 proj: projection initialization failure cause: lat_0 = 0 or 90 or alpha = 90 Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdapwarp problem
On Feb 11, 2011, at 10:59 AM, Jean-Claude Repetto wrote: On 02/11/11 19:20, Adam Dershowitz, Ph.D., P.E. wrote: +proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs Hello, PROJ.4 is more verbose about the problem: $ proj +proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs Rel. 4.7.1, 23 September 2009 proj: projection initialization failure cause: lat_0 = 0 or 90 or alpha = 90 Jean-Claude Thanks. I see that, but I am not sure why, or what to do about it. I do see that gdalinfo does display 0 for latitude, but also has other information. Does this mean that the file is defective? Or that there is a problem with gdalwarp? Is there some way, based on the information that gdalinfo is displaying that I can correct this? Thanks, --Adam ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MSVC warnings changes
Folks, I have spent several hours today cleaning up warnings when building with Microsoft Visual C++. The first step was to move warning suppression out of gdal/port/cpl_port.h and instead passing warning suppression via the compiler commandline line. This is accomplished by setting of the WARNFLAGS macro in nmake.opt with a warning level (/W4 now) and a set of specific warnings to be disabled (using /wd4127, etc). Moving the disabling out of cpl_port.h is important because it means GDAL policy of disabling some warnings will not impact applications including gdal.h. The warning I have disabled are things I feel are reasonable practice and not worth seeing as warnings. Mostly this is the same as the warnings disabled in cpl_port.h, but I have add a few including warnings related to signed/unsigned comparison mismatches. These drive me nuts and have not (for me) yet lead to identifying a real error. I have also introduced the SOFTWARNFLAGS macro. This disables a bunch more warnings, and is used in some of the submakefiles building code from external sources that we can't practically alter. This includes stuff like zlib, and libjpeg. I have made a variety substantial pass over the GDAL source tree building with MS Visual Studio 2008 Express Edition and trying to adjust the code to clean away warnings and in a few cases adding extra local warning disablers either in makefiles or using the pragma in the code. These changes can mostly be seen in these commits: http://trac.osgeo.org/gdal/changeset/21684 http://trac.osgeo.org/gdal/changeset/21680 The main warnings I'm still aware of are related to the MITAB and AVCE00 libraries. These changes need to be upstreamed and were sufficiently involved that I put them off. Beyond that I was able to get a pretty much warning free build on /W4. Going forward I am hoping we can balance appropriate choice of warnings to suppress globally and adjustments to the code to keep our windows build warning-clean. Hopefully this will help us be more vigilant in addressing new warnings that do pop up. 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
[gdal-dev] nmake.local on windows builds
Folks, Some time ago Tamas added a mechanism to nmake.opt (the central include file for windows MSVC nmake based makefiles) so that you could provide an extra definition file on the commandline. eg. nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt While this is useful, expecially in cases where it is desirable to have several build configurations out of one tree, I never used it. I always just adding !INCLUDE nmake.osgeo4w or !INCLUDE nmake.frank at the beginning of nmake.opt and put my definitions in that new file. With Kirk's recent introduction of a complicated nmake.opt file for the MrSID driver, I've learned that you can check for the existance of a file in an nmake !IF EXISTS directive, and I have incorporated use of this in nmake.opt to pull in nmake.local if it exists. So going forward, I'm hoping the default way of tailoring windows builds will be to create an nmake.local file overriding definitions from nmake.opt. 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
[gdal-dev] Re: gdapwarp problem
On Feb 11, 2011, at 10:20 AM, Adam Dershowitz, Ph.D., P.E. wrote: I am having a problem trying to use gdalwarp. Perhaps I am just missing something, but I figured I would see if someone can help. I downloaded some aerial imagery from here: http://www.michigan.gov/dnr/0,1607,7-153-10371_14546-30211--,00.html I want to import it into a UTM zone 17 project. So I did the following: gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' input.sid output_utm.sid gdapwarp responds with an error, but then continues with the conversion: ERROR 6: Failed to initialize PROJ.4 with `+proj=omerc +lat_0=0 +lonc=0 +alpha=0 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs '. lat_0 = 0 or 90 or alpha = 90 0...10...20...30...40...50...60...70...80...90...100 - done. It does complete, but the area of interest is in the range of UTM (254500,4734000) and the output of gdalwarp is around 663144,240035. Any suggestions for what I might be doing wrong? If I do gdalinfo on the original file here is what I get: I googled around some and it looks like this is actually an issue with the Michigan projection in Proj4. I found this link: http://www.osgeo.org/pipermail/mapserver-users/2006-July/018292.html And this seems to give reasonable results, based on the above: gdalwarp -t_srs '+proj=utm +zone=17 +datum=WGS84' -s_srs '+proj=omerc +lat_0=45.30917 +lonc=-86.0 +alpha=337.25556 +k=0.9996 +x_0=499839.8337 +y_0=528600.2398 +ellps=GRS80 +datum=NAD83 +units=m' oakgrove_sw.sid oakgrove_sw_utm.tifg So, I am not really sure about the source of these numbers, but it does look pretty close. --Adam___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gdal-dev Digest, Vol 81, Issue 27
Hi Joris, You're ahead of me already, as I don't have any real experience with C/C++. However, I would be interested to see specifically how you're getting the SpatialReference objects to work...since I'm at least able to compile and load that particular module. Do you have a bit of sample code that can demonstrate this? As I noted in a previous post to this list, I seem to get zeros returned by the relevant functions...so either the compiled module I have isn't working right, or I'm not using it right. It would be helpful if I could compare my tests with the way you've done it. Best regards, Mike On Friday, February 11, 2011 12:00:11 Joris van de Sande wrote: Date: Fri, 11 Feb 2011 12:50:41 +0100 From: Joris van de Sande joris.devpl...@gmail.com Subject: [gdal-dev] Reviving the PHP Bindings To: gdal-dev@lists.osgeo.org Message-ID: AANLkTin4SjA8uqswvFY9E0ZKV86esfYdgrB=uaaxh...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hello, This is a reply to the PHP Bindings thread that has been started by Mike Leahy.I have just registered with the list, so I was not able to reply to the thread. I am also interested in getting the PHP bindings for GDAL up to date. Right now we're using the gdal command line utilities a lot from within PHP. We're relying on regular expressions to parse the output at the moment. So it would make development a lot easier if we could use the internal GDAL classes and functions from within PHP. A few months ago I have created a little PHP module that converts projection strings from wkt to proj format (and vice versa) using the SpatialReference class. But it would be great if more functionality could be used from inside PHP. What can be done to revive the PHP bindings? Are more people interested I am a PHP developer with some knowledge of C/C++. My main interest at the moment are: 1. Using the SpatialReference class from within PHP 2. Retrieving map(meta)data like gdalinfo does from within PHP Regards, Joris van de Sande ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] nmake.local on windows builds
Frank, While I'm not sure about what changes you intend to do here, I would emphatically disagree removing the current approach with the ability of setting the full path to the external configuration file from the nmake command line. My build system is higly depend on this setting and if we don't have any compelling reason I would like to avoid relocating this custom file (which is anyway generated dynamically) into the gdal source tree. Best regards, Tamas 2011/2/11 Frank Warmerdam warmer...@pobox.com Folks, Some time ago Tamas added a mechanism to nmake.opt (the central include file for windows MSVC nmake based makefiles) so that you could provide an extra definition file on the commandline. eg. nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt While this is useful, expecially in cases where it is desirable to have several build configurations out of one tree, I never used it. I always just adding !INCLUDE nmake.osgeo4w or !INCLUDE nmake.frank at the beginning of nmake.opt and put my definitions in that new file. With Kirk's recent introduction of a complicated nmake.opt file for the MrSID driver, I've learned that you can check for the existance of a file in an nmake !IF EXISTS directive, and I have incorporated use of this in nmake.opt to pull in nmake.local if it exists. So going forward, I'm hoping the default way of tailoring windows builds will be to create an nmake.local file overriding definitions from nmake.opt. 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] nmake.local on windows builds
On 11-02-11 06:56 PM, Tamas Szekeres wrote: Frank, While I'm not sure about what changes you intend to do here, I would emphatically disagree removing the current approach with the ability of setting the full path to the external configuration file from the nmake command line. My build system is higly depend on this setting and if we don't have any compelling reason I would like to avoid relocating this custom file (which is anyway generated dynamically) into the gdal source tree. Tamas, I did not remove the support for EXT_NMAKE_OPT - the first stuff in nmake.opt now looks like: ### # For convenience, user may put custom settings in a local settings file # named nmake.local, or a name defined by the EXT_NMAKE_OPT option. !IF EXIST($(GDAL_ROOT)\nmake.local) !INCLUDE $(GDAL_ROOT)\nmake.local !ENDIF # nmake -f makefile.vc EXT_NMAKE_OPT=mynmake.opt !IFDEF EXT_NMAKE_OPT !INCLUDE $(EXT_NMAKE_OPT) !ENDIF I believe this will serve both needs smoothly, albeit with a little extra complication in the nmake.opt. 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
