[gdal-dev] Converting from Lambert (LCC) to latlong/mercator

Brian Murray idlegod at gmail.com
Sun Feb 22 15:31:19 EST 2009


Yep. Its a tad bit off (less then 5% for sure), but I also have the
lat/long values about 5% off, since I picked a lat/long that wasn't at
the edges. Once I adjust those, it will be OK now. I did remove the
legend, which will help. I just left it on there while it wasn't
scaling at all.

On Sun, Feb 22, 2009 at 1:24 PM, Joaquim Luis <jluis at ualg.pt> wrote:
> 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 <jluis at 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.000000000000000,56.000000000000000)
>>>> 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.0000000,  56.0000000) (115d 0'6.32"W, 54d 0'1.81"N)
>>>> Lower Left  (-115.0000000,  54.0000000) (115d 0'6.32"W, 54d 0'1.75"N)
>>>> Upper Right (-105.0000000,  56.0000000) (115d 0'5.77"W, 54d 0'1.81"N)
>>>> Lower Right (-105.0000000,  54.0000000) (115d 0'5.77"W, 54d 0'1.75"N)
>>>> Center      (-110.0000000,  55.0000000) (115d 0'6.04"W, 54d 0'1.78"N)
>>>> 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 <idlegod at 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
>>>>> <stevensw at 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 at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>>>
>>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>
>


More information about the gdal-dev mailing list