Geographic Coordinate Systems Warning when using BAGIS Reference Maps web service

[lbross]

The good news is that if I save an .lyr file pointed to the web service, this path can be saved to the BAGIS settings file. BAGIS can also open and load this .lyr with no code changes. However, when I load an AOI boundary, I get the attached warning about different GCS's. Is this a problem? Can we make the web service projection match the BAGIS standard?

[jdduh]

The AWDB uses the "USA_Contiguous_Albers_Equal_Area_Conic_USGS_version" projection, which is the NWCC standard. DEM and PRISM raster services are on NAD_1983_Albers, which is a comparable projection as the standard projection. BAGIS V2 clip routine can handle them without any issue. One issue that needs some research is the "snap" raster option. BAGIS V2 uses a local raster to set the snap raster in raster processing environment. It seems that you need to use the lyr file to set the snap raster parameter.

[lbross]

From Geoffrey: May need to create a layer first with web service as data source and then set snap raster from there.

[lbross]

Can you point me at the code in BAGIS V2 where the snap raster is set in the raster processing environment? When I look at CmdSelectBasin_Click, I see Message Boxes indicating that the extent boundaries will be snapped to the raster cells but the only thing called is BA_GetRasterDimension which just populates values in a BA_DEMInfo structure.

[jdduh]

Obviously I implemented the "snap" function with a hack. The BA_GetRasterDimension sub set the values of BA_DEMDimension (which has a BA_DEMInfo data type). Then the BA_SnapGCElementtoRaster sub does the snapping when the BASIN boundary is selected with the setDEMExtenttool.

[jdduh]

If you can query the webservice and set all the required values of BA_DEMDimension, then you don't need to worry about the snap function.

The values needed are:
DEM x and y cell sizes
DEM minimum x and y map coordinates

[lbross]

I stepped through the BA_SnapGCElementtoRaster sub and all the values are as they should be. The graphical element that the user has drawn is snapped to the raster and a vector is created from it.

As we discussed, I have to convert this vector to a raster to get the row/column counts for clipping from the image service. Unfortunately, I've been unable to find a way to use the image service layer as snap raster input for the GP environment for the FeatureToRaster tool. Can we assume the alignment will be good because the original vector was snapped to the raster? I've visually examined the output and the cells seem to line up.

If not, are there other properties we can set in the GP environment that would be the equivalent of snap raster? Like you did in BA_SnapGCElementtoRaster ?

[jdduh]

If the BA_SnapGCElementtoRaster works correctly, then you can just rasterize the snapped vector. But, now that we know the x, y extends and x, y cellsize of the vector, we should be able to calculate the row/column. You can modify the BA_SnapGCElementtoRaster (or use it as an example to create a new sub) so that it returns the row/column numbers.

The create AOI from shapefile tool does need to set the snap raster using the web service. The code is in the BA_ShapeFile2RasterGDB sub. It involves using the IRasterAnalysisEnvironment.SetExtend method. I'm not sure if we can directly feed the webservice to the method. Maybe by converting the webservice to a layer first?

[lbross]

Running some tests to calculate the row/column values from a vector. I get the Envelope of the vector and then divide the height/width by the cell size. Clearly this will most likely be a float value. What is the best way to handle this? Always round up?

I tested using the aoi layers from teton_aoi which was created using original BAGIS code. In this test, I used the Fix function from BA_SnapGCElementtoRaster so the cell counts are always rounded down which I don't think is right. Still, for the largest vector: p_aoi, I am off by 2 and 3 cells.

aoi_v 1761 x 1811
aoibagis 1761 x 1811

aoib_v 1770 x 1820
aoib 1771 x 1821

p_aoi_v 1851 x 1901
p_aoi 1853 x 1904
The cell counts for each vector are what my subroutine returned

I will explore updating the BA_ShapeFile2RasterGDB sub to see if we can set the snap raster from an image service in the setExtent() method.

[jdduh]

Please make it always round up. At the BASIN delineation stage, the size of the "AOI" boundary doesn't have to be precise. Users tend to select a rectangle that is much larger than the actual AOI(s) to be delineated.

[lbross]

Updated BA_ShapeFile2RasterGDB sub with option of using an IRasterLayer as snapraster; Appears to work with preliminary testing. If you have thoughts on specific ways to test, let me know. It's hard to visually compare the clip to the image service because the symbology on the image service makes it difficult to see the cell borders.

[lbross]

To test:

1. Create 2 separate basins covering same area
2. Use same gauge station to create aoi from each basin and make sure boundaries match

[lbross]

I have tested creating an AOI both from a pourpoint and from a shapefile and they are both slightly offset from the original AOI. However, I'm not convinced that the westus_bc_30m DEM is lined up precisely with the web service DEM (http://atlas.geog.pdx.edu/arcgis/services/30_Meters_DEM/westus_30m/ImageServer). When I view them both in ArcMap the corners don't line-up exactly.

Suggestions?