sample_raster_points() in mapping.py seems to not be performing as desired

[mike-krasowski]

As part of QA/QC efforts, I ran _w4h.getresources() with the defaults (local) and w4h.run() with the defaults from the example. I exported the by-point results of the w4h.run() function to shapefile for inspection in ArcGIS Pro where I noticed a few things:

1. the projected lat long fields are populated oddly, I think.
2. somewhere in the translation from python to ArcGIS Pro the API values get truncated/rounded and lose many of their digits (i.e., 123456789 becomes 123450000). I think we talked about this before, but is it possible the unique call in this function struggles to match large integers/floats?
3. the surface_elev for the majority of the points are unrealistic for the study area
4. I popped a print statement into _sample_rasterpoints() to get a better understanding of the functioning of a portion of the function and got the results below:

code:

results:

I'm not 100% sure how to interpret/troubleshoot these things. It seems that the original lat-long values are correct (when brought into ArcGIS Pro, they mapped in the study area and when cross checked with ILWATER, the locations look identical), but the projected coordinates look suspicious. The surface and bedrock elevations in the screenshots above look correct, but many of the surface elevations (and values derived from them) for other points are incorrect for the study area. Many have values outside the range of the original surface elevation raster provided with the package download.

[RJbalikian]

Fixed issue, was an issue with truncated API number of sample data