Latest Contributions by EricKrause

@David_Brooks Yes, it is possible to configure EBK3D to be a nearest neighbor classifier where every prediction just takes the value of the closest input point.   Please see A Workflow for Creating Discrete Voxels blog for instructions. ... View more

Hi Paul, I noticed in the geoprocessing pane that you have some pending edits on the input points.  Can you close the edit session and see if this still happens? ... View more

Hi again, thank you for the kind words! To kind of rephrase, the issue is more that GWR provides a single answer, so it makes sense to present that answer.  EBKRP, on the other hand, provides many answers, and while the final predictions are comparable, the components of the different models can vary significantly and appear to contradict each other.  Simply asking, "How does this explanatory variable affect the dependent variable at this location," it is very possible that EBKRP could say "positively, negatively, and no effect."  Personally, I see no contradiction in using GWR to explain relationships, then using EBKRP to actually make predictions.  I do it frequently myself. And, yes, EBK in 3D does not support explanatory variables (aside from vertical detrending).  If this is a feature you think would help solve your problems, posting it in ArcGIS Ideas is the best course of action. -Eric ... View more

Hi Elijah, This is a deceptively complicated question.  The general idea is that when predicting to a new location, GWR uses a single model, thus creating a single set of coefficients for the location. EBKRP, however, uses many (potentially very different) models when predicting to a new location, and it isn't reliable or meaningful to try to disentangle how each explanatory variable contributed to the final prediction. In EBKRP, predictions are performed using weighted combination of regression-kriging results from defined subsets of points, each using principle components of the original variables within each subset.  This is where the problem comes in.  While it is fine to use weighted combinations of PCA-regression for prediction, the individual coefficient values could be very misleading when expressed in terms of the original variables.  EBKRP, in essence, averages only the predicted value of various local models, and while it is safe to average the final prediction, it doesn't follow that it is safe to average the individual components of each model, which you would have to do in order to give a single estimate of the coefficients at the prediction location.   Hope that made some sense. -Eric ... View more

Hi again, You're correct that in ArcMap, the Measured value appears on the x-axis, but this was changed for ArcGIS Pro, based on new research in 2008.  You can read the full details of why the Measured value should be on the y-axis in this paper.  Long story short, the axes don't matter for the R^2 value and for testing whether the slope is equal to 0.  However, to test that the line has slope=1 and y-intercept=0, the predicted values need to be on the x-axis and measured values on the y-axis.  This is only relevant for Measured vs Predicted, so we kept the Measured value on the x-axis for all other graphs. I'm still interested to hear whether the Error plot also has a negative slope.  These are the raw errors that are not standardized by the kriging variance, so that graph may still have a positive slope even if the standardized errors have a negative slope. -Eric ... View more

Hi Christian, I think the slopes of the blue trend lines is causing the confusion.  If you ignore the blue lines for a minute, notice in the first graph that most of the largest measured values (the points highest on the y-axis) generally fall above the 1:1 gray line, indicating that they are underpredicted (ie, the prediction is less than the measured value).  The corresponding points on the Standardized Error graph (the points furthest on the right) generally do have negative standardized errors, indicating that they were underpredicted. Ignoring the trend lines, I hope you can see that the scatterplots and their values do not contradict each other. The blue trend lines, however, add some confusion.  It does seem contradictory that the blue line in the first graph would be flatter than the 1:1 gray line while the trend line of the second graph has a negative slope.  The latter seems to indicate smoothing, and the former seems to indicate the opposite.   There are a couple things that come to mind for how this could happen. First, standardized errors are scaled by the inverse of the standard deviation, so the relative impact on the trend line for each point is different between each graph, which could be enough to change the slope of the Standardized Error trend line from positive to negative.  Please look to Error graph, which shows the equivalent scatterplot and trend line for the unstandardized errors, and see if its trend line is positive or negative. Second, the blue trend lines use a robust estimation technique and are not just simple linear regressions.  The documentation describes this process as: "This procedure first fits a standard linear regression line to the scatterplot. Next, any points that are more than two standard deviations above or below the regression line are removed, and a new regression equation is calculated."  This removal of values could be subtle enough to switch the sign of the slope. -Eric ... View more

Hi Nooch, All of the interpolation methods in Geostatistical Analyst assume a continuous variable and will not produce meaningful results for categorical data.  However, it is possible to configure Empirical Bayesian Kriging 3D to be a nearest neighbor interpolation method, where every location is given the value of its closest neighbor in 3D.  This is the 3D equivalent of Create Thiessen Polygons, as @DanPatterson suggested.  Calling this an "interpolation method" is a bit of a stretch, but it will produce a full 3D voxel of classified soil types, if that is what you are hoping to achieve.   A colleague recently wrote a blog outlining this workflow: https://www.esri.com/arcgis-blog/products/arcgis-pro/3d-gis/a-workflow-for-creating-discrete-voxels/   Good luck! -Eric ... View more

Hi Suzanne, You're pretty much correct in your first three questions.  I'll add a few notes:    1. The values I see in the voxel layer do come from the EBK3D analysis. That the EBK3D didn't show them to me before is because it has made its (and our) life a bit easier (runs quick) by visualising a triangular grid and 'spreading' the range of values of the original data set over it? Yes.  To build a representative histogram of the output surface, the geostatistical layer would have to make many calculations. By borrowing the histogram of the input points, it can process much more quickly.  However, it is just a rough visualization of what the surface actually looks like.      2. That means that whatever export format I choose for the statistical layer (for example 'to points') I will obtain the values that I now see in my voxel layer?     Yes, all the geostatistical layer does is call a function that returns a prediction (and possibly standard errors) at a coordinate and then writes the value(s) to an output format.  As far as the geostatistical layer is aware, exporting to points, voxels, rasters, etc are all just sets of coordinates used to call this function. After exporting to whatever format, the renderer of the output is always built on the predicted values stored in that format.  So, for example, exporting to a raster will build the render using the entire histogram of the raster.  Similarly with a voxel, the renderer is built on the range of the entire 3D volume (with extremes excluded, as Andrew noted). 3. Some of the values I obtain are nonphysical (i.e. the negative values), does this not mean something is fundamentally wrong about the statistical analysis? Especially if the values are really quite different from the original data set (for example if my data ranges from 0.1 to 80 and the voxel layer shows results between -20 and 60)? Most likely, this behavior indicates that the EBK3D model doesn't fit the data well.  Kriging of all types has a tendency to smooth the input data, where the range of the predictions is narrower than the range of the input data. However, it can also make predictions outside of the range of the input points.  You're actually seeing both at the same time, where both the min and max of the predictions were lower than the min/max of the original data points; it smoothed off the top but extend the bottom of the distribution. I suspect this is due to the shape of the histogram of the original points, which was heavily right-skewed and had constant values.  You should try to identify where the largest deviations are in the 3D volume.  It's possible that you'll find them far off in a corner away from the points, but the still model fits well in the areas where you have data.  If that doesn't work out, I don't have very many recommendations aside from what I already suggested: trying different subset sizes, overlap factors, and transformations.  4. Wouldn't adjusting the min/max range in the above mentioned case from -20 and 60 to 0.1 and 80 be cheating? It seems I would then be ignoring what the geostatistical analyst has told me.. I wouldn't call it cheating as long as you disclose what you're doing.  It's well understood that kriging doesn't understand what the data means (so it won't respect physical impossibilities), and the predictions become unstable when extrapolating.  Simply removing these areas or setting them transparent is very common, but should of course be disclosed. You're not actually changing any data when you do this, just choosing to not display results that you know to be misleading or impossible.  Ideally, you'll just find a perfect EBK3D model that doesn't require this, but assuming this doesn't happen, in my opinion, it's better to not display results you know to be wrong. -Eric ... View more

Hi Suzanne, In addition to the differences in the min/max renderer of the voxel versus the classified renderer of the geostatistical layer, there are also even more fundamental differences. The geostatistical layer actually builds its histogram (used to create the class breaks) on the values of the original points you interpolated.  The voxel layer instead classifies using the values of the netCDF file.  In general, the voxel layer will be a much better representation of what the 3D volume actually looks like.  There is an exactly analogous concept with exporting 2D geostatistical layers to 2D rasters, where the exported raster often looks very different and has different ranges than the geostatistical layer. This is also why the minimum value of the voxel symbology is less than the minimum value of the geostatistical layer symbology.  Some areas of the voxel had predicted values less than the minimum of the original points you interpolated.  This can happen for lots of different reasons, but it's likely related to transformations and trends in the EBK3D model. As for why the geostatistical layer operates like this, it's best to think of the geostatistical layer as a function that does rendering on the fly.  It takes an (x,y) or (x,y,z) coordinate as input and computes the value using references to the interpolation parameters and input points.  Unlike a raster of a voxel layer, it does not have output data written anywhere to disk.  In a sense, the geostatistical layer doesn't know its own values until you do something that requires the calculation.  The filled contours you actually see in the map are just generated by contouring a coarse triangular grid behind the scenes. The benefits of this are that the geostatistical layer calculates and renders very quickly, and it can be used as a model source to easily export to numerous other data formats: rasters, points, contours, voxels, multidimensional rasters, etc.  Hope that made sense, -Eric ... View more

Glad to hear you got the voxel to render!  For your next step, look into the GA Layer To Points tool.  It can be used to export the values of the EBK3D layer directly to 3D point features. ... View more

I suspect the problem is that the coordinate system (both horizonal and vertical) of the scene have to be the same as the Voxel layer, and the coordinate systems of the Voxel layer are driven by the EBK3D layer. Please try adding a brand new Local Scene and immediately try to add the netCDF file as a voxel layer before doing anything else with the scene (specifically, do not add any data to it).  My bet is that it will render correctly.  When you add data to a new map/scene, it will set the coordinate systems to match that data, so the voxel layer and the scene should automatically be put into the same coordinate systems. If this ends up being the issue, you can change the coordinate systems of your other scene to match the coordinate systems of the EBK3D layer, and then you should be able to add the voxel layer. [Edit: I see Andrew beat me to it] ... View more

I also want to clarify that, yes, it's not usually standard practice to create confidence intervals for the Moran's I Index.  There's nothing incorrect about doing it, but it just isn't very meaningful.  Confidence intervals are most effective when they are in meaningful units.  For example, some political position has 56% support, plus or minus 3%.  Similarly with dollars, you could project a cost of $5000 dollars, plus or minus $400.  But since the Moran's I Index isn't really in a meaningful unit, it's hard to interpret what the confidence interval actually means.  That's why usually just z-scores and p-values are calculated for it, but again, there's nothing incorrect about creating confidence intervals for it. ... View more

Hi Suzanne, The isosurface is a 3D contour, so you have to specify which value you want to contour.  My guess is that the default value is producing a very small (or even empty) isosurface.  You can change the isosurface value in the Voxel Exploration pane. I recently wrote a LearnGIS lesson that performs EBK3D and ends with voxel visualization and exploration.  You might find the entire thing useful, but here's the section specifically about creating isosurfaces: Interpolate 3D oxygen measurements in Monterey Bay | Learn ArcGIS  -Eric ... View more