Raster export bounding box is incorrect when DD or DMS are used to define extent

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Launch MORIS and switch to a Custom basemap. Add the Impervious Surface (IS) 
layer to your map and zoom in to Logan Airport. Launch the Data Export Wizard. 
At Step 2, remove all layers of interest except for the IS layer. Open the 
Advanced section, select "Decimal degrees" and click the "Import active map's 
bounding box" button. At Step 4, leave the default settings of MA State 
Plane...meters, and GeoTiff. Export to a zip file and open the GeoTiff in an 
image viewer. The output is a "blank" GeoTiff, instead of the expected IS layer 
for the Logan Airport area.   

This bug was present in an earlier version of MORIS. It was addressed by 
forcing the final export URL to use the translated MA State Plane coordinates 
(EPSG 26986), while allowing the user to enter geographic lat/long coordinates 
at Step 2 of the wizard. It appears that this fix applies to vector data 
exports only. It needs to be applied to raster data exports as well.

Original issue reported on code.google.com by marc.car...@state.ma.us on 31 Mar 2011 at 3:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The final WMS is only in 26986 for rasters.  (For all layers, for that matter.)

Committed revision 66.

Original comment by cpl...@gmail.com on 22 Aug 2011 at 6:46

• Changed state: Fixed

[GoogleCodeExporter]

Tested in FF 6 - works great.

Original comment by Aleda.Fr...@state.ma.us on 24 Aug 2011 at 6:06

[GoogleCodeExporter]

My downloaded chunk of Impervious Surface data from Logan falls into the right 
place but does not have a defined projection.

This problem is bigger- no combo of download options yields a tiff with a 
defined projection.

Original comment by daniel.s...@state.ma.us on 26 Aug 2011 at 3:27

[GoogleCodeExporter]

After I upgraded the code today this is no longer working for me.  I went back 
to the two previous version and it's not working their either.  I get a .tif 
that's 1KB.  I tried 2 different GeoServer instances.  Did it break recently? 
Charlton, can you double check this on your side? I'm coming down with a cold 
and that makes me stupid... 

Original comment by Aleda.Fr...@state.ma.us on 8 Sep 2011 at 8:06

[GoogleCodeExporter]

Let me add the comments into here.
Something is going on with the calculation to determine if the output image is 
going to be > 15MB or not.  (We don't want to give the user more than 15MB at a 
time).

The Impervious Surface is exhibiting the "too generous" behavior of offering a 
green check then not downloading (correctly) in the current production version 
of OLIVER and MORIS.  The projection does not matter.

I then looked at another layer - COQ2005 (color orthos 2005).  It is behaving 
better - although there is a section of scale between where it gives a good 
image (up to say 9MB and where it gives the "too big to download" message that 
it downloads a white image.  I'm not sure what that's about! 

So, this is not a new problem.. although I'm pretty sure we had tested this 
before. But regardless, it's not just in the dev version.  Let me keep 
checking.  

Does the calculation happen twice?  Once on the page that gives either the 
green check or red x and once when the extract is ready to happen?  I'm not 
sure why the 1KB is sometime produced.  I didn't think that GeoServer restricts 
the size, I thought it was all on the client side.  (GeoServer can restrict WFS 
feature counts, but that's different).  I would like to look this one up in the 
old Bugzilla database.  Is that still possible.  I'm looking at 
http://issuetracker.coastmap.com:8888 but I don't see any bugs. 

Original comment by Aleda.Fr...@state.ma.us on 9 Sep 2011 at 2:10

[GoogleCodeExporter]

It looks like bugzilla has been wiped clean.  I'll ask.

Original comment by cpl...@gmail.com on 9 Sep 2011 at 3:20

[GoogleCodeExporter]

It does get run 2x.  Could you provide a list of steps so that I can debug?

Original comment by cpl...@gmail.com on 9 Sep 2011 at 4:20

• Changed state: Accepted

[GoogleCodeExporter]

I'm not sure if this helps, but I added a check to make sure at least 1 layer 
made the cut for export.  If not, you get a notice.  Before this check was in 
place, I think it tried to zip up garbage for a layer that failed because of 
size or #.

See if this helps w/ at least part of the problem.

Committed revision 89.

Original comment by cpl...@gmail.com on 9 Sep 2011 at 4:34

[GoogleCodeExporter]

I don't perceive a change, but probably a good change anyway.  

Original comment by Aleda.Fr...@state.ma.us on 9 Sep 2011 at 6:11

[GoogleCodeExporter]

I'm your agent of change.  Just a reminder that I'm hoping to get an example in 
my hot little hands of how to reproduce this bug before I hunker down to fix it.

Original comment by cpl...@gmail.com on 9 Sep 2011 at 6:37

[GoogleCodeExporter]

I'm still trying to narrow it down.  I wish I had the Bugzilla content, because 
I described it completely there.  I do have some math in my email though, I can 
provide that... Note, we are now talking about a different bug than the one 
described at the beginning of the Issue.  The original bug has been fixed.  We 
just stumbled on this "too generous when allowed export" bug.  Should I create 
a new issue to separate it out or do you want me to continue on here?

Original comment by Aleda.Fr...@state.ma.us on 9 Sep 2011 at 6:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Charlton, I am attacking this problem today, in a last attempt to get a good 
explanation for you of what needs to be done.

One problem there must be with the formula that I see already is that for the 
wind layer "Modeled Wind Speed at 100m", I am getting a red X saying "no 
download allowed" for cases where it should not apply.  We are setting our cut 
off for download at a 15MB file.  

Consider this: (which I see on both old MORIS and new MORIS). 

At 24,000 scale a download of the layer "Modeled Wind Speed at 100m" results in 
a 6KB tif.  At 50,000 scale it results in a 22KB tif.  At 100,000 scale I'm 
told that it "> max file size" on step 3 of the export wizard.  I don't think 
that the file at that scale was going to be > 15MB at that point.

Now, looking at the slice_getcaps.pl output 
massgis_GISDATA.IMG_WIND_SPD100M.GISDATA.IMG_WIND_SPD100M__Default.xml for this 
layer:

   <Keyword>IS-IMAGERY</Keyword>
   <Keyword>UnitsPerPixel=200</Keyword>
   <Keyword>BytesPerPixel=4</Keyword>

I can make the math work for the 50,000 case:

If I start to export and look at the minx, miny and maxx, maxy in 26986 meters 
I get this:
                                maxx  , maxy
                206405, 874691

minx    miny
183795, 861853

I can subtract 206405-183795 to get 22610 meters wide.
I can subtract 874691-861853 to get 12838 meters high.

<Keyword>UnitsPerPixel=200</Keyword> tells us that pixels are 200x200 meters in 
this layer.

22610 / 200 = 113 pixels wide 
25676 / 200 = 64 pixels high

That's 113 x 64 = 7232 pixels for what we're trying to download. 

<Keyword>BytesPerPixel=4</Keyword> tells us that pixels are 4 bytes each.

So 7232 x 4 = 28928 bytes.

Using a converter: 
http://www.matisse.net/bitcalc/?input_amount=28928&input_units=bytes¬ation=lega
cy

= 22 KB

Following the same math for 100,000 scale by the way yields 113 KB.

I believe somehow the math is going wrong to appear > 15MB so that the "no 
download allowed" is being shown.

The other issue I was seeing may be somehow related to this one - I think if we 
can fix this one first perhaps the other will resolve. 

Now, I looked in the code and I think in the map.js where you have 
    return (2 * dx * dy * lyrMetadata[name].imgBytesPerPixel) / (lyrMetadata[name].imgUnitsPerPixel * 1048576) < 15; 

the value is much too high.  

I know there are probably different ways to calc this, but since the one above 
is in my mind I rewrote it as:

    var pixelsWide = dx/lyrMetadata[name].imgUnitsPerPixel;
    var pixelsHigh = dy/lyrMetadata[name].imgUnitsPerPixel;
    var sqPixels = pixelsWide * pixelsHigh;
    var totBytes = sqPixels * lyrMetadata[name].imgBytesPerPixel;
    var totMB = totBytes / 1024 / 1024;
    return (totMB < 15);

and with alerts I was able to verify the the values are good.
However you say this formula is also run elsewhere? (I noticed this was stepped 
through twice).  If this is the only place to change I can commit this if you 
like. 

Original comment by Aleda.Fr...@state.ma.us on 2 Dec 2011 at 4:53

[GoogleCodeExporter]

By all means commit your changes if it does the trick!!!

The rasterOK() function is called from two different places, yes.  It might be 
a bit redundant to do it 2x (once to draw the icons / text and a second before 
any feature counting is done), but I think I did it to match the flow in use 
for vector data.

Original comment by cpl...@gmail.com on 2 Dec 2011 at 6:05

[GoogleCodeExporter]

Original comment by Aleda.Fr...@state.ma.us on 2 Dec 2011 at 6:43

• Changed state: Fixed