Subscribe to this thread
Home - General / All posts - Slope Analysis different in M8 and M9
lflee5 post(s)
#02-Jan-19 01:10

text

Attachments:
Layout Florida slope in M9.pdf
Layout M8 Slope Image.pdf

tjhb

8,474 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?

lflee5 post(s)
#04-Jan-19 03:12

Oh dear, it looks like all the text were dropped when I attached the two files and hit POST.

1. Source of data:

I downloaded the example file Florida_palette_hill_shading.map from Manifold Release 9 downloads and examples files. I exported the Florida image as GeoTIFF for Manifold 8 (Build 8.0.30.0).

2. Creating slope surface in M8:

I imported the Florida GeoTIFF,

EDIT>SAVE MASK/CHANNEL (Save: Surface: slope) To: Slope Image

I then opened the Slope Image and VIEW>DISPLAY OPTIONS and selected CB RdYGn 7 (reversed) palette, and set the "Height" values at 0, 2, 6, 12, 20, 25, 45 degrees (to correspond the the local slope classifications for Flat, Undulating, Rolling, Hilly, Steep, and Very Steep respectively). The image was exported in the layout with explanatory captions.

3. Creating slope surface with M9 (Build 9.0.168.7)

With Florida image open, TRANSFORM>SLOPE (radius 1)>Add Component to create Florida Table Slope Image

Open Florida Table Slope Image, STYLE>Channel 0>7 Breaks and chose breaks at 0, 2, 6, 12, 20, 25, 45 degrees and palette Green-Orange (the closest I can find and which is reproducible) to correspond to the M8 display style, and exported as a Layout.

The point I'm making is in M8 the slope classes are mostly in the greens and yellow (0-12 degree), while in M9 there is a significant level of orange (>12 degrees). I have tried transforming the slope images to contour areas and in M8 the 0-20 degree range totaled 99.9% of the total area while in M9 it was only 44.5%. I have also tried out the slope transformation with the raster in other example files from the same source, and they all show a higher reading for slopes in M9 compared to M8.

Another interesting observation I made was that the slope image from M9 appears to show edge artifacts - there is a distinct appearance of 6 tiles in the image while the slope image from M8 was smooth.

I hope there is now sufficient information for others to test and advise if I made a mistake somewhere.

Cheers,

LF Lee

tjhb

8,474 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.

tjhb

8,474 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?

tjhb

8,474 post(s)
online
#12-Jan-19 21:26

I have reported it to Tech.

Dimitri


5,174 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

adamw


8,289 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

adamw


8,289 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:

--SQL9

VALUE @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

Dimitri


5,174 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.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.