Skip to main content
Geographic Information Systems

Return to Answer

Discovered the proper steps to take in order to correctly answer the question
Source Link
teknocreator
teknocreator
  • 673
  • 5
  • 14

After playing2nd UPDATE: Played around some more and got the radar overlay to work with this forOpenLayers. What I and a whilefew others have referred to holds true here. The Ridge Radar gifs are really meant to go into Google Earth (though they might also play nice in Google Maps too). However, in OpenLayers, one does have to ensure that raster images are transformed to spherical mercator in order to display in Google Maps and Open Street Maps via OpenLayers. In order to do that, you have to geo-reference the raster to ESPG 4326 and then transform it to spherical mercator. Now I thinkused GDAL to do the problem lies with howgeo-referencing and also warping to spherical mercator. Here are the gif image iscommands I used:

gdal_translate -of PNG -a_srs EPSG:4326 -a_ullr -127.62 50.41 -66.42 21.61 radar.gif radartemp1.png

gdalwarp -t_srs '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs' radartemp1.png radartemp2.png

gdal_translate -of PNG -outsize 80% 80% radartemp2.png radartemp3.png

The first line geo-referenced/createdreferences the image to EPSG 4326 and also converts to a PNG. Just used to doing that but you should be able to keep GIFs (-of GIF).

The second line converts the image to EPSG 900913 via the proj.4 commands in single quotes. I had tried using 900913 and also 3785/3857 in gdalwarp but my version of GDAL didn't like those. Found the proj.4 commands worked. Key to this was the +nadgrids=@null option. I found that in our geo-referencing that things worked fine with the transformation that we were using for our initial GM prototype. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this as the gif images appear to be designed to work with Google Earth. We're using GDAL along with proj.4 transformation parameters Discovered after a search and one optionalso in the proj.4 linereference that we had to add from our original ones was this:

+nadgrids=@null

Butsnapwire_org indicated that was after geo-referencing our images first on a lambert conformal grid and then transforming themthis is critical to getting the grid transformed into spherical mercator. After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself.

I'm going to keep whatNow I originally said below just as listing another way of building the app. I think I'll also look at the kml and see what projection information is being used, try the transformation routinesfound that in GDAL to get a correct image if possible. I'll post back if I actually get something.

HOWEVER, I attemptedorder to do what I said below and got the same result you didwork with EPSG 900913 in that the overlay image was displaced northward. SoOL, that led meI had to my conclusion above.

Now, you might consider working withuse meters for the projection instead of the lat lon bounds and just transform everything between the two:

NOW I've entered the correct numbers here after the 3rd GDAL transformation step above for your use in the new OpenLayers.Bounds line below

GMoverlay= new OpenLayers.Layer.Image("Overlay"Radar Title"Overlay","relative directory string holding image name""radartemp3.png",
     new OpenLayers.Bounds(-1448304814206593.340415, 22916742465071.487940,-67754207394741.041764, 69473936517585.399728),   
     new OpenLayers.Size(742847,448484),
     {isBaseLayer: false, opacity: opacty0.4,
      projection: new OpenLayers.Projection("EPSG:900913")});

new OpenLayers.Bounds(-1448304814206593.340415, 22916742465071.487940,-67754207394741.041764, 69473936517585.399728)

WeYou would get that info using GDALby running

gdalinfo radartemp3. You may be able to transformpng

The lower left and upper right coordinates of the bounds thattransformed image are specified in the KMLdisplayed in OL code and use here instead. I just hardcoded it as ours aren't going to change. Note that I did initially try to use a bounds variablethis command's output and transform, but that didn't seem to work. But, our bounds might not have been correct eitherthen entered in the part above when doingdeclaring the transformation. I haven't revisited since then as this works for us presentlynew OL Image.

The referenced link that snapwire_org mentioned has a good deal of what I refer to here.

Hope this helpsAlso note that the size of the image is about a quarter the size of radartemp3.png. That's because you have to reduce the size number the farther out you zoom. So, you can't use 3700 x 1600 of the original image.

This really should be the answer you're looking for. I checked it myself in some waya test OL app with much of the pieces above and it projected spot on to what was being displayed at weather. Tookgov. You still will have to do the geo-referencing and transformations. But GDAL is also open source and easy to install.

Tell you, it took a while to find that proj.4 option for our transformations. Then I pieced together several references which set up the map and image overlay in meters (including the one from snapwire_org) and then did transformations for points between 4326 and 900913. Worked like a charm then.

Good luck!

Good luck!

After playing around with this for a while, I think the problem lies with how the gif image is geo-referenced/created. I found that in our geo-referencing that things worked fine with the transformation that we were using for GM. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this as the gif images appear to be designed to work with Google Earth. We're using GDAL along with proj.4 transformation parameters and one option in the proj.4 line that we had to add from our original ones was this:

+nadgrids=@null

But that was after geo-referencing our images first on a lambert conformal grid and then transforming them to the spherical mercator. After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself.

I'm going to keep what I originally said below just as listing another way of building the app. I think I'll also look at the kml and see what projection information is being used, try the transformation routines in GDAL to get a correct image if possible. I'll post back if I actually get something.

HOWEVER, I attempted to do what I said below and got the same result you did in that the overlay image was displaced northward. So, that led me to my conclusion above.

Now, you might consider working with meters for the projection instead of the lat lon bounds and just transform everything between the two:

GMoverlay= new OpenLayers.Layer.Image("Overlay Title","relative directory string holding image name",
     new OpenLayers.Bounds(-14483048.340, 2291674.487,-6775420.041, 6947393.399),   
     new OpenLayers.Size(742,448),
     {isBaseLayer: false, opacity: opacty,
      projection: new OpenLayers.Projection("EPSG:900913")});

new OpenLayers.Bounds(-14483048.340, 2291674.487,-6775420.041, 6947393.399)

We get that info using GDAL. You may be able to transform the bounds that are specified in the KML in OL code and use here instead. I just hardcoded it as ours aren't going to change. Note that I did initially try to use a bounds variable and transform, but that didn't seem to work. But, our bounds might not have been correct either when doing the transformation. I haven't revisited since then as this works for us presently.

The referenced link that snapwire_org has a good deal of what I refer to here.

Hope this helps in some way. Took a while to find that proj.4 option for our transformations. Then I pieced together several references which set up the map and image overlay in meters (including the one from snapwire_org) and then did transformations for points between 4326 and 900913. Worked like a charm then.

Good luck!

2nd UPDATE: Played around some more and got the radar overlay to work with OpenLayers. What I and a few others have referred to holds true here. The Ridge Radar gifs are really meant to go into Google Earth (though they might also play nice in Google Maps too). However, in OpenLayers, one does have to ensure that raster images are transformed to spherical mercator in order to display in Google Maps and Open Street Maps via OpenLayers. In order to do that, you have to geo-reference the raster to ESPG 4326 and then transform it to spherical mercator. Now I used GDAL to do the geo-referencing and also warping to spherical mercator. Here are the commands I used:

gdal_translate -of PNG -a_srs EPSG:4326 -a_ullr -127.62 50.41 -66.42 21.61 radar.gif radartemp1.png

gdalwarp -t_srs '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs' radartemp1.png radartemp2.png

gdal_translate -of PNG -outsize 80% 80% radartemp2.png radartemp3.png

The first line geo-references the image to EPSG 4326 and also converts to a PNG. Just used to doing that but you should be able to keep GIFs (-of GIF).

The second line converts the image to EPSG 900913 via the proj.4 commands in single quotes. I had tried using 900913 and also 3785/3857 in gdalwarp but my version of GDAL didn't like those. Found the proj.4 commands worked. Key to this was the +nadgrids=@null option. I found that in our geo-referencing things worked fine with the transformation that we were using for our initial GM prototype. However, our images were "squished" when we tried to use them for OL. Discovered after a search and also in the reference that snapwire_org indicated that this is critical to getting the grid transformed into spherical mercator.

Now I found that in order to work with EPSG 900913 in OL, I had to use meters for the projection instead of the lat lon bounds and just transform everything between the two:

NOW I've entered the correct numbers here after the 3rd GDAL transformation step above for your use in the new OpenLayers.Bounds line below

GMoverlay= new OpenLayers.Layer.Image("Radar Overlay","radartemp3.png",
     new OpenLayers.Bounds(-14206593.415,2465071.940,-7394741.764,6517585.728),   
     new OpenLayers.Size(847,484),
     {isBaseLayer: false, opacity: 0.4,
      projection: new OpenLayers.Projection("EPSG:900913")});

new OpenLayers.Bounds(-14206593.415,2465071.940,-7394741.764,6517585.728)

You would get that info by running

gdalinfo radartemp3.png

The lower left and upper right coordinates of the transformed image are displayed in this command's output and then entered in the part above when declaring the new OL Image.

The referenced link that snapwire_org mentioned has a good deal of what I refer to here.

Also note that the size of the image is about a quarter the size of radartemp3.png. That's because you have to reduce the size number the farther out you zoom. So, you can't use 3700 x 1600 of the original image.

This really should be the answer you're looking for. I checked it myself in a test OL app with much of the pieces above and it projected spot on to what was being displayed at weather.gov. You still will have to do the geo-referencing and transformations. But GDAL is also open source and easy to install.

Tell you, it took a while to find that proj.4 option for our transformations. Then I pieced together several references which set up the map and image overlay in meters (including the one from snapwire_org) and then did transformations for points between 4326 and 900913. Worked like a charm then.

Good luck!

I discovered what I wrote didn't solve the issue and wanted to update my post with those findings with what I thought might solve the issue
Source Link
teknocreator
teknocreator
  • 673
  • 5
  • 14

FirstAfter playing around with this for a while, there may be an issueI think the problem lies with how the gif image is geo-referenced/created. I found that in our geo-referencing that things worked fine with the transformation ifthat we were using for GM. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this for OL folksas the gif images appear to be designed to work with Google Earth. We're using GDAL along with proj.4 transformation parameters and one option in the proj.4 line that we had to add from our original ones was this:

AfterBut that was after geo-referencing our images first on a lambert conformal grid and then transforming them to the spherical mercator. After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself.

I'm going to keep what I originally said below just as listing another way of building the app. I think I'll also look at the kml and see what projection information is being used, try the transformation routines in GDAL to get a correct image if possible. I'll post back if I actually get something.

HOWEVER, I attempted to do what I say next doesn't worksaid below and got the same result you did in that the overlay image was displaced northward. So, that led me to my conclusion above.

 

Good luck!

Good luck!

First, there may be an issue with how the gif image is geo-referenced. I found that in our geo-referencing that things worked fine with the transformation if we were using for GM. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this for OL folks. We're using GDAL along with proj.4 transformation parameters and one option in the proj.4 line that we had to add from our original ones was this:

After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself if what I say next doesn't work.

Good luck!

After playing around with this for a while, I think the problem lies with how the gif image is geo-referenced/created. I found that in our geo-referencing that things worked fine with the transformation that we were using for GM. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this as the gif images appear to be designed to work with Google Earth. We're using GDAL along with proj.4 transformation parameters and one option in the proj.4 line that we had to add from our original ones was this:

But that was after geo-referencing our images first on a lambert conformal grid and then transforming them to the spherical mercator. After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself.

I'm going to keep what I originally said below just as listing another way of building the app. I think I'll also look at the kml and see what projection information is being used, try the transformation routines in GDAL to get a correct image if possible. I'll post back if I actually get something.

HOWEVER, I attempted to do what I said below and got the same result you did in that the overlay image was displaced northward. So, that led me to my conclusion above.

 

Good luck!

Source Link
teknocreator
teknocreator
  • 673
  • 5
  • 14

Hayley,

First, there may be an issue with how the gif image is geo-referenced. I found that in our geo-referencing that things worked fine with the transformation if we were using for GM. However, our images were "squished" when we tried to use them for OL. The Ridge Radar folks may not realize this for OL folks. We're using GDAL along with proj.4 transformation parameters and one option in the proj.4 line that we had to add from our original ones was this:

+nadgrids=@null

After that and what I describe next below, the overlays lined up correctly. Not sure how to solve that other than providing feedback to the Ridge Radar folks or geo-referencing the gif image yourself if what I say next doesn't work.

Now, you might consider working with meters for the projection instead of the lat lon bounds and just transform everything between the two:

Declaring the map:

map = new OpenLayers.Map("map", {

    projection: new OpenLayers.Projection("EPSG:900913"),
    units: "m",
    maxResolution: 156543.0339,
    maxExtent: new OpenLayers.Bounds(
        -20037508, -20037508, 20037508, 20037508.34),
    displayProjection: new OpenLayers.Projection("EPSG:4326"),
    controls: [
        new OpenLayers.Control.Navigation(),
        new OpenLayers.Control.KeyboardDefaults(),
        new OpenLayers.Control.PanZoomBar(),
        new OpenLayers.Control.Scale(),
        new OpenLayers.Control.Attribution()
    ]

});

Now for the image overlay:

// create spherical mercator base layers

var googleLayer = new OpenLayers.Layer.Google("Google Physical", {type: google.maps.MapTypeId.TERRAIN, visibility: true});
var gstr = new OpenLayers.Layer.Google("Google Streets", {type: google.maps.MapTypeId.ROAD, visibility: true});
var osmLayer = new OpenLayers.Layer.OSM("OpenStreetMap");

// create overlay with first image (GMoverlay is a global);

GMoverlay= new OpenLayers.Layer.Image("Overlay Title","relative directory string holding image name",
     new OpenLayers.Bounds(-14483048.340, 2291674.487,-6775420.041, 6947393.399),   
     new OpenLayers.Size(742,448),
     {isBaseLayer: false, opacity: opacty,
      projection: new OpenLayers.Projection("EPSG:900913")});

//add layers to map

map.addLayers([googleLayer, gstr,osmLayer, GMoverlay]);

Again, you can see in the Bounds, we're using meters:

new OpenLayers.Bounds(-14483048.340, 2291674.487,-6775420.041, 6947393.399)

We get that info using GDAL. You may be able to transform the bounds that are specified in the KML in OL code and use here instead. I just hardcoded it as ours aren't going to change. Note that I did initially try to use a bounds variable and transform, but that didn't seem to work. But, our bounds might not have been correct either when doing the transformation. I haven't revisited since then as this works for us presently.

In going back and forth between meters and standard Lat/Lon, you have to use OL transforms like this one for setting the initial center:

map.setCenter(new OpenLayers.LonLat(-80, 40).transform(
        new OpenLayers.Projection("EPSG:4326"),
        map.getProjectionObject()),5);

You need to be careful here using transform on geometries as I discovered when grabbing a point on the map. This is also discussed in that link on spherical mercator and here's the relevant statement:

"Because all transforms are in place, once you have added a geometry to a layer, you should not call transform on the geometry directly: instead, you should transform a clone of the geometry:"

The referenced link that snapwire_org has a good deal of what I refer to here.

Hope this helps in some way. Took a while to find that proj.4 option for our transformations. Then I pieced together several references which set up the map and image overlay in meters (including the one from snapwire_org) and then did transformations for points between 4326 and 900913. Worked like a charm then.

Good luck!