Home - General / All posts - Slope Analysis different in M8 and M9
 lflee5 post(s) #02-Jan-19 01:10 text
 tjhb8,578 post(s)online #02-Jan-19 02:22 You'll need to expand on the text part of that!Most important: how did you creat the slope surfaces/images in Manifold 8 and 9? Exact method, exact parameters, possibly with screenshots.Next: exactly how have you styled the results, in Manifold 8 and 9? Again screenshots would be good. Is there a reason why the styles have to be so different?Lastly: where is the data from, what is the pixel resolution, and can you supply it (or a subset) for others to test with?
 tjhb8,578 post(s)online #04-Jan-19 05:03 Perfect! More than thorough, thanks.I'll do the same in both 8 and 9 and let you know if I see some small misstep, or an anomaly, or none. Others might too.
 tjhb8,578 post(s)online #09-Jan-19 22:17 Sorry to have taken so long here to get back to this.I think you have found a bug in the TileSlope algorithm in Manifold 9.It seems that the slope calculation "forgets" to allow for pixel resolution, treating every pixel as if it measured 1 unit x 1 unit. It should be discounting pixel height differences by the radius between pixel centres, but it seems it is not.This shows up strongly with the Florida example, where the pixels measure 65.60000000000001 x 65.60000000000001 metres. If we compensate (that is, tell a big fat lie) by dividing all heights in the image by 65.60000000000001, then the slope result in Manifold 9 closely matches the result in Manifold 8.The same might affect other Tile* functions as well? The other functions that operate over a window are TileAspect, TileBlur, TileBlurDirection, TileBlurGaussian, TileEdges, TileEdgesDirection and TileSharpen.(There seems to be a somewhat similar issue with the interpolation functions, noted here and already reported.)It is a good thing that you took the trouble to be puzzled!Can I report this as a bug, and reference the thread?
 tjhb8,578 post(s)online #12-Jan-19 21:26 I have reported it to Tech.
 Dimitri5,291 post(s) #13-Jan-19 13:35 Thanks, Tim! It's a lucky coincidence this came up now since these functions are all in play right now with much work being done in GPGPU and rasters, integration of the latest CUDA, etc. It's a good time to deal with issues.
 lflee5 post(s) #17-Jan-19 00:50 Thanks for checking and verifying it's indeed a bug, and for reporting it. Sorry for the late response.Regards,LF Lee
 adamw8,401 post(s) #17-Jan-19 06:45 Confirming that the issue is exactly the Tile... functions not using the scale factors for X, Y and Z, unlike in Manifold 8, and that we will fix it.Thanks a lot for the detailed notes.
 lflee5 post(s) #18-Jan-19 07:49 I don't know if this is related to the same issue, but I'm getting different area computations using M8 and M9, with the same Florida example.When I transformed the Florida image in M9 (Build 9.0.168.0) into contour area (min=0, max=100, step=50, no decompose to shapes) to obtain 2 areas (0-50m and 50-100m), the areas (GeomArea([Geom], 0)) were reported as 3,179,242 and 68,816 respectively, with a total of 3,248,058.I did the same exercise in M8 (Build 8.0.30.0) the Area(i) were reported as 13,666,005,091 and 296,022,654 respectively for 0-50m and 50-100m contours (total 13,962,027,745).The projection metadata stated the unit was in metres, so the M8 figures are closer to the computed areas as indicated by the tracker lengths and heights. I’m not sure what units the M9 areas are in.Regards,LF Lee
 adamw8,401 post(s) #18-Jan-19 08:36 Probably related - GeomArea in 9 reports area in units of the passed geom, not in units of the coordinate system associated with that geom.If the coordinate system units are different from 1 (m / deg), as seen in the Coordinate System Metrics dialog (invoked from the Coordinate System dialog, which in turn can be accessed from the Component pane - click on the button next to the coordinate system readout, then select Assign Initial Coordinate System - Edit Coordinate System), the result of GeomArea has to be multiplied to the square of local scales (local scale X in desired unit * local scale Y in desired unit). (You say that the coordinate system of your component is in meters, but there are also local scales. As in, the coordinate system might be set up so that 1 unit is, say, 5 meters by X and 5 meters by Y. The result of GeomArea on a geom in such a coordinate system is square meters divided by 25, it has to be multiplied back by 25 to become square meters.)We are planning to alter the Area and similar templates in the Transform pane to do this automatically.If you are writing queries, you can get the values of local scale X / Y using something like:--SQL9? StringJsonNumber(CoordSystemParse(ComponentCoordSystem([co100a])),    'LocalScaleX', false)...or, a fuller version:--SQL9VALUE @cs NVARCHAR = CoordSystemParse(ComponentCoordSystem([co100a]));VALUE @sx FLOAT64 = COALESCE(StringJsonNumber(@cs, 'LocalScaleX', false), 1);VALUE @sy FLOAT64 = COALESCE(StringJsonNumber(@cs, 'LocalScaleY', false), 1);-- using COALESCE to translate possible NULL to default value of 1-- can now use: ... GeomArea(...)*(sx*sy) ...Hope this helps.
 lflee5 post(s) #19-Jan-19 07:03 Multiplying the 3,179,242 and 68,816 from M9 by the square of the local scales (65.6) gave area figures very close to those from M8.How I look back on the good old days of just checking the Area(i) in M8! Regards,LF Lee
 Dimitri5,291 post(s) #19-Jan-19 09:26 How I look back on the good old days of just checking the Area(i) in M8!You can do that in 9 as well, and better. Been discussed in a thread in the forum.
 adamw8,401 post(s) #31-Jan-19 10:08 We hear you.The problem of "Area (I)" being simple to understand because it does a single fixed thing is exactly that it does a single fixed thing which suffices for some uses but not others. People frequently want to do similar things, but since there are many different things people want to do here, it is infeasible to create a new "Xxx (I)" field for each. We are solving this in 9 by having no intrinsic fields by default, and instead allowing to create an arbitrary number of new ones which work similarly (computed fields). Currently, the process is more involved than it was in 8, but we are adding UI tools that help tackle the complexity all the time, so we might absolutely add a tool where you would basically just check a box near "Area (I), Manifold 8 style" and the tool would add it.So, if you find yourself missing something from 8, please send a suggestion to sales. Because we can and do add things like that constantly.
 Dimitri5,291 post(s) #31-Jan-19 10:48 just check a box near "Area (I), Manifold 8 style"Ugh.. I think it would be better to have a Favorites dropdown preloaded with things like Area, Length, etc...
 adamw8,401 post(s) #31-Jan-19 10:12 A follow-up - issues with scale in Slope and other raster transforms are fixed in 9.0.168.8.