You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like a recent change altered the margins for KML plotting (frametools.py) so that now, plots created as Google Earth overlays no longer line up with topography.
In this plot, the overlay matches the topography
but here, the margins shrink the PNG file so that the plot no longer fits the topography.
Commit f0d1bf5 seems to be where the margins were changed. Restoring the previous command fixes this issue.
The text was updated successfully, but these errors were encountered:
donnaaboise
changed the title
KML (Google Earth) : Plot margins were changed so GE overlays do not match topography
KML (Google Earth) : GE overlays do not match topography
Aug 15, 2020
Thanks for pointing this out @donnaaboise, I'll take a look. I made the change to be consistent with what I found worked well in geoclaw.kmltools.pcolorcells_for_kml, which I have been using to make kml overlays to display topofiles and fgmax results. This seemed to be the approach recommended in things I found online (e.g. stackoverflow)when I was struggling to get things to line up properly at the 1/3 arcsecond resolution level (10 meters) whereas the version in frametools.py wasn't working for me.
But I didn't test it well enough in frametools.py apparently. I'll look at this again. Have you tried the original approach in a case where you have results at a much finer resolution than shown in your figures here? (E.g. in Kahului Harbor in clawpack/tsunami-examples#2?) Do things line up properly at that scale?
It looks like a recent change altered the margins for KML plotting (frametools.py) so that now, plots created as Google Earth overlays no longer line up with topography.
In this plot, the overlay matches the topography
but here, the margins shrink the PNG file so that the plot no longer fits the topography.
Commit f0d1bf5 seems to be where the margins were changed. Restoring the previous command fixes this issue.
The text was updated successfully, but these errors were encountered: