Re: [gdal-dev] gdal_merge.py on large Tiff's. gdalwarp not working properly.
Aaron, This could be solved by using the nodata attribute. You can set the nodata value in the source in the vrt file[1]. The vrt driver will ignore the nodata areas. If you have problem with that, rerun the gdalwarp operation and make sure you get the nodata values. Use the -srcnodata and -dstnodata options in gdalwarp. [1]: http://www.gdal.org/gdal_vrttut.html On Mon, Jul 9, 2012 at 7:49 AM, aphunter wrote: > Hi Jean-Claude. Thanks for the idea. Unfortunately it made the split a > little > larger. Is it possible to make the borders transparent, or remove them so > the blending works properly as it does in gdal_merge.py? > > Thanks, > Aaron > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/gdal-merge-py-on-large-Tiff-s-gdalwarp-not-working-properly-tp4986729p4986806.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 > -- Best regards, Chaitanya kumar CH. +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] gdal_merge.py on large Tiff's. gdalwarp not working properly.
Hi Jean-Claude. Thanks for the idea. Unfortunately it made the split a little larger. Is it possible to make the borders transparent, or remove them so the blending works properly as it does in gdal_merge.py? Thanks, Aaron -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdal-merge-py-on-large-Tiff-s-gdalwarp-not-working-properly-tp4986729p4986806.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] GDAL and Kakadu v7 SDK
Does anyone happen to know how to get Kakadu v7 SDK to compile successfully into GDAL under 64bit Debian Linux please ? (eventually it would be great to get the GeoServer jp2k ImageIO stuff working as well, but that's another matter) The v7 SDK of Kakadu (by itself) compiles successfully. I've followed the instructions in http://trac.osgeo.org/gdal/wiki/JP2KAK But get the following errors - jp2kakdataset.cpp: In function 'int JP2KAKCreateCopy_WriteTile(GDALDataset*, kdu_tile&, kdu_roi_image*, int, int, int, int, int, int, GDALDataType, kdu_codestream&, int, kdu_long*, int, int (*)(double, const char*, void*), void*, bool)': jp2kakdataset.cpp:1977: error: no matching function for call to 'kdu_line_buf::pre_create(kdu_sample_allocator*, int&, int&, int&)' /home/kakadu/v7_1-01334E/coresys/common/kdu_sample_processing.h:423: note: candidates are: void kdu_line_buf::pre_create(kdu_sample_allocator*, int, bool, bool, int, int) jp2kakdataset.cpp:2090: error: no matching function for call to 'kdu_push_ifc::push(kdu_line_buf&, bool)' /home/kakadu/v7_1-01334E/coresys/common/kdu_sample_processing.h:917: note: candidates are: void kdu_push_ifc::push(kdu_line_buf&, kdu_thread_env*) /home/kakadu/v7_1-01334E/apps/jp2/jp2_shared.h: At global scope: /home/kakadu/v7_1-01334E/apps/jp2/jp2_shared.h:825: warning: 'jp2_brand' defined but not used /home/kakadu/v7_1-01334E/apps/jp2/jp2_shared.h:826: warning: 'jpx_brand' defined but not used /home/kakadu/v7_1-01334E/apps/jp2/jp2_shared.h:827: warning: 'jpx_baseline_brand' defined but not used /home/kakadu/v7_1-01334E/apps/jp2/jp2_shared.h:828: warning: 'mj2_brand' defined but not used make[2]: *** [../o/jp2kakdataset.lo] Error 1 make[2]: Leaving directory `/home/geoserver/gdal-1.8.0/frmts/jp2kak' make[1]: *** [jp2kak-install-obj] Error 2 make[1]: Leaving directory `/home/geoserver/gdal-1.8.0/frmts' make: *** [frmts-target] Error 2 Is it worth even pursuing this ? Many thanks, Shaun -- The information in this email together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. There is no waiver of any confidentiality/privilege by your inadvertent receipt of this material. Any form of review, disclosure, modification, distribution and/or publication of this email message is prohibited, unless as a necessary part of Departmental business. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network. -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_merge.py on large Tiff's. gdalwarp not working properly.
On 07/08/2012 07:48 PM, aphunter wrote: > Definitely, thanks for the help. I am sort of new to this stuff. Below is the > imagery from the small images I'm testing with. Hi, Since you have reprojected one of the images, it has a black border. Try to change the images order in the gdalwarp command. Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem with gdalwarp
Jeff, The coordinates you are using with -te are not in the coordinate system of the image. >From the docs -te xmin ymin xmax ymax:set georeferenced extents of output file to be created (in target SRS). Convert the lat/lon coordinates you are using to the srs of the image and then try it. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center On 7/8/12 4:01 PM, "Jeff Lake" wrote: >I am attempting to crop a geo tiff that I reprojected .. >But I keep getting the error I cannot make an image that is 0x0 > >gdalinfo of the geotif > >Driver: GTiff/GeoTIFF >Files: na_regionals.tif >Size is 13738, 9740 >Coordinate System is: >PROJCS["unnamed", > GEOGCS["WGS 84", > DATUM["unknown", > SPHEROID["WGS84",6378137,298.257223563]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433]], > PROJECTION["Lambert_Conformal_Conic_2SP"], > PARAMETER["standard_parallel_1",25], > PARAMETER["standard_parallel_2",25], > PARAMETER["latitude_of_origin",36.5], > PARAMETER["central_meridian",-95], > PARAMETER["false_easting",0], > PARAMETER["false_northing",0], > UNIT["metre",1, > AUTHORITY["EPSG","9001"]]] >Origin = (-8824126.437603076919913,8459741.486810354515910) >Pixel Size = (1109.003596911612931,-1109.003596911612931) >Metadata: > AREA_OR_POINT=Area >Image Structure Metadata: > INTERLEAVE=PIXEL >Corner Coordinates: >Upper Left (-8824126.438, 8459741.487) (109d 0'29.50"E, 58d50' 2.53"N) >Lower Left (-8824126.438,-2341953.547) (168d 6'52.48"W, 5d12'19.39"S) >Upper Right ( 6411364.977, 8459741.487) ( 43d12'43.71"E, 72d27'51.59"N) >Lower Right ( 6411364.977,-2341953.547) ( 39d23'29.30"W, 3d51'28.79"N) >Center (-1206380.730, 3058893.970) (112d24'29.73"W, 60d35' 2.20"N) >Band 1 Block=13738x1 Type=Byte, ColorInterp=Red >Band 2 Block=13738x1 Type=Byte, ColorInterp=Green >Band 3 Block=13738x1 Type=Byte, ColorInterp=Blue > > >my gdalwarp command to crop > gdalwarp -te -119.045 57.455 -73.818 10.284 na_regionals.tif >conus_lcc.tif > >and the error >Creating output file that is 0P x 0L. >ERROR 1: Attempt to create 0x0 dataset is illegal,sizes must be larger >than zero. > >what am I doing wrong >version info >GDAL 1.8.0, released 2011/01/12 > >-Jeff Lake >MichiganWxSystem.com >WeatherMichigan.net >TheWeatherCenter.net >GRLevelXStuff.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] Problem with gdalwarp
I am attempting to crop a geo tiff that I reprojected .. But I keep getting the error I cannot make an image that is 0x0 gdalinfo of the geotif Driver: GTiff/GeoTIFF Files: na_regionals.tif Size is 13738, 9740 Coordinate System is: PROJCS["unnamed", GEOGCS["WGS 84", DATUM["unknown", SPHEROID["WGS84",6378137,298.257223563]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Lambert_Conformal_Conic_2SP"], PARAMETER["standard_parallel_1",25], PARAMETER["standard_parallel_2",25], PARAMETER["latitude_of_origin",36.5], PARAMETER["central_meridian",-95], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (-8824126.437603076919913,8459741.486810354515910) Pixel Size = (1109.003596911612931,-1109.003596911612931) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-8824126.438, 8459741.487) (109d 0'29.50"E, 58d50' 2.53"N) Lower Left (-8824126.438,-2341953.547) (168d 6'52.48"W, 5d12'19.39"S) Upper Right ( 6411364.977, 8459741.487) ( 43d12'43.71"E, 72d27'51.59"N) Lower Right ( 6411364.977,-2341953.547) ( 39d23'29.30"W, 3d51'28.79"N) Center (-1206380.730, 3058893.970) (112d24'29.73"W, 60d35' 2.20"N) Band 1 Block=13738x1 Type=Byte, ColorInterp=Red Band 2 Block=13738x1 Type=Byte, ColorInterp=Green Band 3 Block=13738x1 Type=Byte, ColorInterp=Blue my gdalwarp command to crop gdalwarp -te -119.045 57.455 -73.818 10.284 na_regionals.tif conus_lcc.tif and the error Creating output file that is 0P x 0L. ERROR 1: Attempt to create 0x0 dataset is illegal,sizes must be larger than zero. what am I doing wrong version info GDAL 1.8.0, released 2011/01/12 -Jeff Lake MichiganWxSystem.com WeatherMichigan.net TheWeatherCenter.net GRLevelXStuff.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_merge.py on large Tiff's. gdalwarp not working properly.
Definitely, thanks for the help. I am sort of new to this stuff. Below is the imagery from the small images I'm testing with. Here is the info for the reprojected image (EPSG26910 -> EPSG26911) Driver: GTiff/GeoTIFF Files: 26910_rs.tif Size is 4577, 11883 Coordinate System is: PROJCS["NAD83 / UTM zone 11N", GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, AUTHORITY["EPSG","7019"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6269"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4269"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-117], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","26911"]] Origin = (-177789.631458136136644,4942643.042761978693306) Pixel Size = (100.253523439120713,-100.236459348383733) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -177789.631, 4942643.043) (125d29'56.62"W, 44d19'11.15"N) Lower Left ( -177789.631, 3751533.196) (124d18'18.68"W, 33d41'14.38"N) Upper Right ( 281070.745, 4942643.043) (119d45'31.64"W, 44d36'13.72"N) Lower Right ( 281070.745, 3751533.196) (119d22' 1.78"W, 33d52'53.21"N) Center ( 51640.557, 4347088.120) (122d11'16.55"W, 39d 9'26.88"N) Band 1 Block=4577x1 Type=Byte, ColorInterp=Red Band 2 Block=4577x1 Type=Byte, ColorInterp=Green Band 3 Block=4577x1 Type=Byte, ColorInterp=Blue Here is the info for the native EPSG26911 image. PROJCS["NAD83 / UTM zone 11N", 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["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-117], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","26911"]] Origin = (222400.000,4654450.000) Pixel Size = (100.012896094325725,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 222400.000, 4654450.000) (120d21' 4.97"W, 41d59'35.32"N) Lower Left ( 222400.000, 3595550.000) (119d57'11.96"W, 32d27'45.18"N) Upper Right ( 765270.000, 4654450.000) (113d47'50.08"W, 41d59'50.61"N) Lower Right ( 765270.000, 3595550.000) (114d10'39.77"W, 32d27'56.01"N) Center ( 493835.000, 4125000.000) (117d 4'10.33"W, 37d16'17.60"N) Band 1 Block=5428x1 Type=Byte, ColorInterp=Red Band 2 Block=5428x1 Type=Byte, ColorInterp=Green Band 3 Block=5428x1 Type=Byte, ColorInterp=Blue -- View this message in context: http://osgeo-org.1560.n6.nabble.com/gdal-merge-py-on-large-Tiff-s-gdalwarp-not-working-properly-tp4986729p4986770.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
Re: [gdal-dev] Dxf output wrong in gdal 1.9 and correct in gdal 1.8
08.07.2012 17:58, Lorenzo Moretti пишет: Hi There are some problems in gdal 1.9.1. There are errors in dxf output when I use ogr2ogr. I have a simple shape file with some polylines. I want to convert it in dxf file. The same command GDAL 1.8 ogr2ogr -f "DXF" -t_srs EPSG:3004 "/Volumes/myhd/ustgdal18.dxf" -s_srs EPSG:32633 "/Volumes/myhd/ust.shp" GDAL 1.9.1 ogr2ogr -f "DXF" -t_srs EPSG:3004 "/Volumes/myhd/ustgdal19.dxf" -s_srs EPSG:32633 "/Volumes/myhd/ust.shp" creates two different DXF files The first one, in gdal 1.8, is correct. It create a perfect DXF file. The size is 59kB. The second one, in gdal 1.9, is wrong: it lost many polylines and the size is 62kB. I have analyzed the two dxf file. The correct file in gdal 1.8 has the perfect attribute for polylines: 100 AcDbEntity 100 AcDbPolyline 70 1 90 5 10 2420094.24101526 20 . The wrong DXF file in gdal 1.9 changes the attribute for polyline with hatch attribute: 100 AcDbEntity 100 AcDbHatch 2 SOLID 70 1 71 0 91 1 92 2 72 0 73 1 93 7 10 2420032.16360568 20 . This is an error. Is this a bug in gdal 1.9.1 ? Lorenzo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev I have also reported this bug: http://trac.osgeo.org/gdal/ticket/4680 You can add your investigations to this ticket Best regards, Dmitry ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Dxf output wrong in gdal 1.9 and correct in gdal 1.8
Hi There are some problems in gdal 1.9.1. There are errors in dxf output when I use ogr2ogr. I have a simple shape file with some polylines. I want to convert it in dxf file. The same command GDAL 1.8 ogr2ogr -f "DXF" -t_srs EPSG:3004 "/Volumes/myhd/ustgdal18.dxf" -s_srs EPSG:32633 "/Volumes/myhd/ust.shp" GDAL 1.9.1 ogr2ogr -f "DXF" -t_srs EPSG:3004 "/Volumes/myhd/ustgdal19.dxf" -s_srs EPSG:32633 "/Volumes/myhd/ust.shp" creates two different DXF files The first one, in gdal 1.8, is correct. It create a perfect DXF file. The size is 59kB. The second one, in gdal 1.9, is wrong: it lost many polylines and the size is 62kB. I have analyzed the two dxf file. The correct file in gdal 1.8 has the perfect attribute for polylines: 100 AcDbEntity 100 AcDbPolyline 70 1 90 5 10 2420094.24101526 20 . The wrong DXF file in gdal 1.9 changes the attribute for polyline with hatch attribute: 100 AcDbEntity 100 AcDbHatch 2 SOLID 70 1 71 0 91 1 92 2 72 0 73 1 93 7 10 2420032.16360568 20 . This is an error. Is this a bug in gdal 1.9.1 ? Lorenzo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_merge.py on large Tiff's. gdalwarp not working properly.
Aaron, Can you provide some info about the images? The gdalinfo output of each dataset and, if possible, the small images. On Sun, Jul 8, 2012 at 12:08 PM, aphunter wrote: > Thanks for the suggestion. Unfortunately building the .vrt file as you > suggested, and using gdal_translate, gives me the same fractured image that > gdal_warp does. I am not sure why gdal_merge.py works properly while the > others don't. > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/gdal-merge-py-on-large-Tiff-s-gdalwarp-not-working-properly-tp4986729p4986741.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 > -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
