Welcome to GPSFileDepot!

Main Menu

Experiments with LIDAR

Started by Boyd, December 27, 2011, 09:15:55 PM

Previous topic - Next topic


Quote from: Boyd on December 28, 2011, 01:00:23 PM
Seldom: yeah, that math always confuses me but what you say makes sense. I thought the error was +/- 2.5 meters, which means any two points could be 5 meters apart. Remember this thread? it is pretty graphic evidence that some rounding or truncation is taking place:,1335.msg8387.html#msg8387

Getting off topic again, but what would be really instructive would be to see a graphic scale on your pink and cyan illustration.


No problem, just quickly threw this together from the old files. But I tried a new test and didn't see this happen, so maybe something was wrong with my earlier method? Weird. IIRC, I also needed to check the option for saving data in double precision when writing the .gmp file, so maybe it's related to that.

Then I realized I was getting sucked back into this old project, so that will have to wait.  ;)

Try for yourself.... draw something curvy at close zoom, export as .mp and reimport. Here's a screenshot with a scale using the same files from the original thread.


Thanks, I'll start a new thread when I have something to show.


Boyd - very interesting.

FYI - my West Virginia 10' Contour Overlay mapset, uploaded in Aug, 2009, used a 10' contour interval created from USGS 3 meter NED data derived from mass points/breaklines.
My North Carolina 10/5 ft Contour Overlay mapset, uploaded in Sept, 2009, used a 10' ci in western' NC and 5' in the central areas and was created from USGS 3 meter NED data derived from LIDAR.


Well this is certainly a learning experience. The main lesson so far is: Mapsource is a lot more powerful than I ever expected. I re-did my prototype map using the match distance of 32 and full 3m resolution. This reduced the polygon count to about 1/4 of the previous test and compiled .img tile are only around 500KB.

In Mapsource, this works really well. Response is snappy zooming and scrolling and it looks great.

Much to my surprise, Basecamp looks really bad, even at the max detail setting. To be fair, I am breaking all the rules for Garmin vector maps, so I can't really blame Garmin. But it's strange to see such a big difference from Mapsource. I guess Basecamp has been tweaked for other things, like Birdseye imagery?

Now, on my Montana this map is more responsive than the previous version although still sluggish to zoom and pan. But the same problem remains - the rendering quality is much worse. It almost looks like it's smoothing the rectangular pixels. The two screenshots below show the exact same area as the two Mapsource screenshots above. If you compare, you'll see they are completely different. This map just isn't usable on the GPS.

Oh well, time to try some more things and see what happens. I am just blown away by how good this works in Mapsource though. Maybe it's useful for that by itself. I tried it with nRoute, and this new map works ok there now as long as you don't zoom out too far. So at least that provides one way to navigate using the map.


Have tried a lot of different things, and the best result so far involved using the Photoshop pixellate filter to process the TIFF before vectorizing in Globalmapper. Still needs more work, but it has improved. Clearly, it will never approach the quality that I can get in Mapsource however. I think the next step will be to come up with a color table more similar to the Atlas Shader in Globalmapper. At least that would give more visual cues to the elevations than greyscale.


I am not sure about everything, but to me it is looking more and more like you did not do what you think you did.

When GM displays a DEM, it displays a combination of the elevation data and slope shading it creates from the adjacent elevation values.  Turn off hill shading in configure/vector options to see just the elevation data.  For me the Daylight shaded gives various shades of cyan; the slope shaded gives shades of grey.

When you exported the file in 8 bit grey scale, you were exporting the slope shading not the elevation values.  For elevation you would need to use the elevation - 16 bit or elevation -32 bit format. 

When I open a file saved as 8-bit greyscale, the RGB values are representing the shading, lightest for flat to deepest for steepest.  The three values I see are the same for the various shades of grey, or 000,xxx,xxx for the various shades of cyan.

You are making 72 ranges of slopes, not elevations.  Elevations would be in bands of similiar shades on opposite sides of streams/valleys.

I do not understand why MapSource, BaseCamp and the GPSr display the data so differently.

The number of significant digits exported in the .mp format is often less than the what was in the source data.  The 4-way intersection being converted to 2 3-ways is weird; however, I have seen a lot of things GM kinda does right, but not exactly correct.


No, I fully understood what I was doing. I converted to a TIFF image and discarded the elevation data because I wanted the map to look like the results of the shader on the original DEM data. I also tried a number of different ways of making polygons from the actual elevation data. When you vectorize that, you get just one value, ELEVATION. When you vectorize a TIFF you RGB(XX XX XX) in the file.

I may in fact make a different kind of map using DEM shading too, but that looks very different, which much smoother gradients that don't reveal the terrain detail as well. Believe me, I have tried lots of different things, and will try many more before I'm through no doubt!  ;)

It's just frustrating that I can make exactly the map I want in Mapsource, but the GPS renders it so differently. Probably has something to do with compromises they made because of the small CPU and limited RAM.

But now I've got to put this to rest for a few days while I clean up my disaster area of a house so I can party with my kids on New Years Eve. Happy New Years everyone!


Wow. Not all GPS'es are created equal. I almost didn't bother, but figured "what the heck"... Here's the same map on my Nuvi 3790. Rendering is virtually identical to Mapsource. Totally blown away by this... why can't my expensive Montana do the same thing?  ;D

And this effect is being enhanced by the North America DEM map on the device (gmapdem.img). But the fun really begins when you switch to 3d mode. Now I feel just a little better about this. :)


I've been lurking on this thread... and I have to ask now, are you going to send this information to Garmin and ask why the Montana performs so poorly?

I know I want to know :)
Garmin GPSMap 60cs, Dakota 20, Colorado 400t, Oregon 300/400t/450/550t/650/650t, Montana 650, Lowrance Endura Sierra, nuvi 3790, iPhone 3G/4/4s
Geocaching ID: Atlas Cached Ambassador

Indrid Cold

Quote from: Boyd on December 29, 2011, 11:29:18 PM
Wow. Not all GPS'es are created equal. I almost didn't bother, but figured "what the heck"... Here's the same map on my Nuvi 3790. Rendering is virtually identical to Mapsource. Totally blown away by this... why can't my expensive Montana do the same thing?  ;D
Does your Montana do 3D buildings?


Well clearly there were different design goals for these devices. My tongue was implanted in my cheek when I made the Montana comment.  ;)  All along I've been impressed by the 3d capabilities of the 3790 (the 3490 is the new version, but I haven't seen one myself). The Montana doesn't do 3d buildings and doesn't do "real" 3d like the 3790. However it does a nice job with *real* raster imagery, and I am "faking" it here with this project. I am breaking all of Garmin's rules here and pushing their format to the breaking point.

Also remember that the 3790 screen is 800x480 pixels - almost 3x the pixel count of the Montana, but not transreflective. Each unit has its own strengths, and the Montana is still my choice "real" navigation.

Pondering this, I assume that Garmin made some compromises when rendering vector maps on screens with low pixel counts. I'm sure they never thought people would use maps with so many tiny polygons.

FWIW, my first attempt at this resulted in ~3 million polygons in one 24k quad. This most recent map cuts that down to around 60,000.


I did not realize you statement about the 72 elevation ranges was refering to a diferent method than all the 3D slope type illustrations you were describing and providing.

Hope Garmin will provide some info on why the same data displays so differently.  I have noticed some differences with Garmin's default types between my 76 and OR300. 


I used the daylight shader in GlobalMapper to create the source TIFF. The slope direction shader also works very well with this sort of flat terrain. Remember, it is very flat around here. In my earlier examples, the full range of elevations is only about 20 meters.

To make shaded terrain in a mountainous area, I'm sure I would approach it differently. But the original goal was to make a map that shows the subtle variations in a flat coastal area. Using an 8 bit grayscale TIFF, there are 256 steps that should correspond to the full range of elevations. I map these to 72 steps because that was the most custom types I could re-purpose without getting into marine colors, etc. It's an approximation, but these steps each represent a range of elevations. That should be relatively accurate in a flat area, but not so much if you are mapping the Rockies.  ;)

Clearly this doesn't solve the problem of making *real* DEM for Garmin. But we just don't know how to do that....


Wow, the nuvi does look really good.

I laugh at the Rockies comment; the grand canyon is a nightmare of topography.

It would be nice to make our own dem for the units but the good news is many of the newer ones include it so our maps can just lay on top.
Dan Blomberg
Administrator - GPSFileDepot
GPS Units: Garmin Dakota 20, Garmin GPSMap 60csx, Nuvi 255W, Nuvi 250W, ForeRunner 110, Fenix 2, Tactix Bravo, Foretrex 401
See/Download My Maps!