›

Visible "seams" at edges of source tiles on export of hillshade images

tjhbtjhb Global Mapper UserPosts: 454Trusted User
edited September 2012 in Bug Report
Mike,

Here is a issue which has affected us over a few months. I apologise for not having reported it sooner. We have managed to work around it with extra work; but it was a false economy not to make time to file a report earlier.

Since you are on the point of releasing a new version, it seems high time I submitted a report, and some data.

The issue affects all recent builds of GM 13.2. I believe it also affected 13.1 (perhaps not all builds), though not 13.0 (or earlier versions). I can re-test this.

I tried to test version 14 beta 2 too, before posting, but unfortnately even one export tile (9216 x 9216 pixels) is over the limit for a trial licence, and ideally I would want to export at least four tiles. Perhaps there a beta licence code that allows full testing?

For now, can I please send you some test data to reproduce the issue? I'll need to send an AOI shapefile and four DEM source tiles (8192 x 8192) currently in ESRI FLT format. What is the best way to do that?

(BTW Is there any chance you could add FLT to the list of commonly used formats? I know you have to draw the line somewhere, and FLT is already on the list of commonly supported elevation types. This is a format we use almost every time we use Global Mapper.)

I'll describe the issue.

(Background.) Our AOI tiling scheme has two variants: overlapped and cropped. We produce our DEM and imagery with overlaps between tiles, then crop and discard the overlap. (This is to ensure data continuity across tile boundaries.)

Our DEM goes into the creation of our landcover textures, in the form of hillshade and height maps. Preparation is in GM. It includes loading the set of cropped DEM tiles, then to the overlapped tiling scheme. (So each output image tile uses elevation data from between 2 and 9 DEM input tiles.)

When we export the hillshade imagery (at source resolution; and with nearest neighbour resampling selected), we see "seams" or "grooves", 2 pixels wide, along the edge of each source DEM tile. (Which is half of the width of the overlap from the edge of each output tile.) Where the terrain is perfectly flat the seams are almost invisible; they are noticeable even in low relief.

Perhaps shading is not calculated continuously across source tile boundaries, even though the tiles form a seamless mosaic?

We see this result when we export from the GUI, either with the Gridding option "Use selected area feature(s) for grid cells", or (for just one tile) using the Export Bounds tab and selecting "Crop to selected area feature(s)".

The way we have worked around the issue is to export the (cropped) source DEM tiles to overlapped DEM tiles, then load the result, and finally export hillshade from the overlapped source. This does not produce seams in output.

Can I please send you some data to test?

Tim Baigent
Wellington

Comments

  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited September 2012
    Tim,

    No need for sample data, I am quite familiar with what you are describing. The issue is indeed due to the hill shading/interpolation not going across tile boundaries, so you see a visible edge at the seams whenever the elevation slope angle or aspect changes. If you add all of your maps to a map catalog they should be seen as siblings and not just independent layers, so the hill shading and interpolation should then cross the layer boundaries and get rid of the seam. There isn't any way to get rid of it for independent layers. The suggested workaround is what you are doing already (i.e. export to a single large image, then render from that). As a tip you might use the Global Mapper Grid (GMG) format for the large combined format as you can put pretty much an unlimited amount of data into a single GMG file and not have any performance issues.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited September 2012
    Great! Thanks Mike. Very happy to know that there is nothing actually wrong, and that a map catalog will give us exactly the result we want. I haven't been making as much use of map catalogs as I should (though my colleagues use them all the time), so I think now is the time for me to change my habits.

    Good luck for the new release. I look forward to spending the money.

    Not the most substantial feature, but a real improvement: the clean Digitizer menu, and the Terrain Analysis menu, are beautiful to see.

    I'm just trying out the creation of ridgelines now. The options seem really well thought-out (and the dialog is again very clean). I'm already thinking of "misusing" this tool though: if I pre-prepare the terrain, by subtracting all elevations from a constant value, then perhaps I can use it to delineate valleys as well.

    Best regards,
    Tim
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited September 2012
    Tim,

    Actually the "valleys" would be the streams that a watershed creates. Actually the ridge finding tool is just the watershed stream finder with the elevations inverted, so where a stream flows on the inverted terrain is actually a ridge line on the original terrain.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited September 2012
    Oh thought I'd mention about FLT files, the limit on what can be added to 'Commonly Supported Types' is actually due to a limit on the length of the filename filter entry in Windows. It can't be more than 255 characters in total, so the Commonly Supported Types entry has a fixed set of the most important types added. We can't add more without removing something else.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
  • tjhbtjhb Global Mapper User Posts: 454Trusted User
    edited September 2012
    (1)
    Oh boy! There was I assuming that watersheds in GM were areas. (I had never used them.) So that's a useful bit of ignorance removed. The ridges do look very good. Almost all ridgelines found and smoothly delineated. Some slightly off the ridge, but once I've figured out how to tune the settings I expect they can all be right on. (I might try applying some non-linear exaggeration to make the algorithm's job easier. I.e. multiplying by a large constant and applying a power < 1, to exaggerate low elevations disproportionately more than high. Very easy to do non-destructively in GM.)

    (2)
    Thanks for the note about FLT. 255 filenames doesn't seem much nowadays does it. Hence also your handy warning dialogs suggesting the use of folders instead, when loading large numbers of files.

    Thanks again Mike.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited September 2012
    Actually the limit is that a single mask entry can only be 255 characters (i.e. "*.dem;*grd;*.tif;*.jpg;*.png;....). No more file masks can be added past 255 characters or they get truncated. There is also a limit on how many files you can select at once in terms of the combined length of the filenames. That is about 16K characters of filename I believe. They are silly limits especially with Global Mapper providing the buffer to store values in, but there isn't an easy way around them.

    Thanks,

    Mike
    Global Mapper Guru
    gmsupport@bluemarblegeo.com
    http://www.globalmapper.com
Sign In or Register to comment.