Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ 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] Converting from Lambert (LCC) to latlong/mercator
Brian Murray wrote: I know. I left that on there in the mean time while I figured out the translations. It wasn't even bending the map at all before. The software just sees the image as a blob of data, that you have to tell it how to transform, so it really didn't care that the map had a legend left on it. In my last post, I describe how I finally got it to work. :) Good for you, ... but are you sure it worked? I mean, are you sure that it is correctly referenced? At half way of the description I just quit following it (sorry, too complicated for me). Joaquim Luis On Sun, Feb 22, 2009 at 12:59 PM, Joaquim Luis jl...@ualg.pt wrote: Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
From the gdal_translate line, the images are identical, but with added information to the tif, in a geotif style. Once I warp it, the image is squished (as I would expect), but the width is the same. I have also tried embedding all of the geotiff data within the intermediate image, but for some reason, I just cannot seem to set the pixel size. If I create a wld or a tfw file, it just seems to ignore it. gdal_translate -of gtiff -CO TFW=YES -a_ullr -115 56 -105 54 -a_srs +proj=lcc +lat_0=56 +lon_0=-115 +lat_2=49.33 +lat_1=54.66 +x_0=0 +y_0=0 +datum=NAD27 n.tif nn.tif I am wondering if perhaps its because photoshop added a bunch of incorrect meta data: Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=72 TIFFTAG_YRESOLUTION=72 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) To my eyes, that looks like 72pixels per inch, which is about right for the scanner it came in from, but wrong for the actual map scale. I cannot find a way in photoshop to change that, and it definitely doesn't like scaling to sizes below 1.0 On Sat, Feb 21, 2009 at 8:45 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Hi Have you not got a world file for your image? I would agree that the pixel size does not seem right. I would try writing my own world file with reasonable values - just to see if the image come out looking better. Make sure you call it the same name as your original tiff file (with .wld or .twf extention) and gdal will automatically pick it up. What results do you get if you run gdalinfo on the new file? Does it have more or less the same number of pixels? I know you can set the resolution with gdalwarp but I haven't tried that. About the false eastings and northings, it would very much depend on the projection of the original image. If they do not specify I would assume they are 0. Wendy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
Hm, so maybe that value is correct. 1/0.000854993160055 is 1169.56163712, which would mean its about 1px per km. I think I found an issue even before I warp: gdal_translate -of gtiff -CO TFW=YES -a_ullr -115 56 -105 54 -a_srs +proj=lcc +lat_0=56 +lon_0=-115 +lat_2=49.33 +lat_1=54.66 +x_0=0 +y_0=0 +datum=NAD27 n.tif nn.tif Upper Left (-115.000, 56.000) (115d 0'6.63W, 56d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.63W, 56d 0'1.74N) Upper Right (-105.000, 56.000) (115d 0'6.05W, 56d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'6.05W, 56d 0'1.74N) Center (-110.000, 55.000) (115d 0'6.34W, 56d 0'1.78N) Apparently a_ullr isn't setting it correctly... On Sat, Feb 21, 2009 at 9:17 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Hi Why not save it as a GIF or JPG and then give it to gdalwarp (with a world file)? I think that if you specify a geotiff file gdalwarp would use the information inside the file. So photoshop adding those tags could very well cause a problem. Remember, the pixel size is in the units of the projection, in this case meters. Wendy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
