Messages

For my Nuvi, I used to just rename the existing POI file as something else e.g. poi.gpi -> FirstSet.gpi. Nuvi would then all you to have multiple categories. The name of the categories would be FirstSet or whatever file name I picked.

Right, I do the same myself... but I'm trying to make it idiot proof for people to whom file renaming and folders is a big mystery.

Thanks, some good information there.  Doesn't mention POI's at all, though.  I don't know that Mapsource or POI loader put the GPS into mass storage mode; the device just says "transferring data" or something like that, but it does seem to send a single file (poi.gpi) to the card rather than sending individual waypoints to the internal memory... which is what I want to do, except that I want to use a different filename (which the device will accept) rather than overwriting any poi file that already exists on the device.

Does anybody know of a way to put a Garmin handgeld GPS into mass storage mode remotely?  I'm working on a program to manage POI's for aeronautical data and I want to be able to send it to the unit without having to manually put it into mass storage mode via the GPS menus.  Mapsource and POILoader can cause the unit to automatically receive data without any intervention at the GPS end, of course, but I need a simple command line utility or even maybe just a dll I can call to let me see it as a drive.

I think I already know the answer (no), but is there a way to have points display differently at different zoom levels?  I'd like to switch to a smaller icon, and perhaps lose the label, as I zoom out, without the point disappearing completely.  I know I could have multiple entries using different types, but then there would be multiple entries in the find function.

-Dana

Ah, it's getting more coherent now.  Seems I had the detail level set to "most"... with it set to "normal" the levels where the basemap takes over do in fact correspond with the cgpsmapper manual:

Detail   Level1=19   Level1=18   Level1=17   Level1=16   Level1=15
Normal         5      8      20      30 (map@20 only)
More         8      20      30
Most   8      20      30      50

So, I use 16, and accept the fact that I can't get the basemap to appear at 12miles, only 20.

-Dana

Curioser and curioser.
At Level0=18 & Level1=17, it shifts to basemap at 30 miles
At Level0=19 & Level1=18, it shifts to basemap at 20 miles
At Level0=20 & Level1=19, the custom map never appears  (at TreSize=50)
At Level0=20 & Level1=19, it shifts to basemap at 8 miles (but only at TreSize>= 100)
At Level0=21 & Level1=20, it shifts to basemap at 5 miles
All the above are TreSize=50 except as noted, and DraPriority=3
DrawPriority has no effect, from 3 to 31, no difference.

I guess I never saw it switch when I had it set at 20 since the raster map resolution breaks up below 5 miles.

Of course I woud really like it to switch to the base map at 12 miles, but of course that's the one I can't get... I guess I'll settle for 20.

-Dana

Nope, 20 made no difference...

I'm already using TreSize=50 (yes 50) as it makes a dramatic improvement in the map draw speed.  I just ignore the warning about it being below 100.  If I set it to less than 50 the map doesn't display at all on the GPS (just shows "no map").

TreSize seems to be related to the size of the patches that show up as the map is drawn on the GPS.

-Dana

For the last build, I didn't have a draw priority specified (I believe the default is 25?).  This time I used 31... doesn't the higher number give the map a higher draw priority?  I'll try 20, anyway.

Without turning on the basemap, even with Level1=18 I'm still seeing my map out to 20mi zoom (I want it to disappear at 12).

I'd also like if it disappeared closer than, say 3mi zoom to have the Garmin 100k topo take over from there.

-Dana

According to the cgpsmapper documentation, the levels specified in the header section of the mp file control where the base map takes over from the map on the card:

The highest numbered map zoom level that you define dictates the zoom level at which
your map replaces the GPS unit's base map. In our example, the highest numbered map
zoom level is 3 and this corresponds to hardware zoom level 17. What this means is that if
the GPS device user zooms in to level 17 or higher it will see your uploaded map. At
hardware zoom levels 16 and below it will see the base map.

My levels look like this:
Levels=2
Level0=20
Level1=17

Zoom0=0
Zoom1=1

All the points in the .mp file are defined at level zero.  My map does disappear at the farther out zoom levels (though farther out than I expected; I guess need to adjust Level1).  However, if I unhide the base map, it displays over my own map regardless of the zoom level.

-Dana

-Dana

Well, the four 2° tiles are unacceptably slow on the GPS, so I moved on to sixteen 1° tiles.  At about a half hour per tile for cgpsmapper to process (not counting the time to create the mp files from the raster image), I finished half of them and dumped them into the GPS.  Much better, but still not ideal.  Tomorrow I guess I'll try 64 1/2° tiles (times a half dozen or so raster images covering 4°).

-Dana

Is there a limit, or a point of diminishing returns, though?

Any insight on the TreSize?

-Dana

I'm trying to understand tiling and cgpsmapper.

I've got my raster conversion program (similar in principle to MOAGU in that each pixel on the input map is converted to a custom point, but optimized for larger areas, with some other differences) working pretty well now. and I'm trying to optimize the map performance on the GPS.

Working with a smaller test area, 1° X 1° and roughly 200,000 points, I found that performance improved significantly by lowering the TreSize down to 50 (below 100 generates a warning; below 50 and the map doesn't display on the GPS at all).  However, it's not clear exactly what it refers to, "maximum allowed region size".  I'm not clear what a "region" is as cgpsmapper defines it.

Moving on to the actual size images I intend to use (2400X2400, from which I'm extracting an area 4° X 4°), I find that cgpsmapper will process an area of up to about 2° square before choking, so I'm creating four .mp files of 2° square each.  However, the performance on the GPS drops dramatically.  My fast coputer at work is processing the four 2° tiles overnight right now [I hope!].

If I break it up into more smaller ,mp (e.g. sixteen 1°sq tiles instead of four 2° square tiles), will that improve the performance on the GPS?  Or is there a way to use one large .mp file and cause cgpsmapper to break it up?  It seems that I'm waiting for the GPS to display points that even aren't on the screen if I'm zoomed in closer than the entire area.

-Dana

[HA!]

Ah HA!

Such a simple thing... isn't it always?  I was missing the quotation marks on the XPM definition.

Xpm=1 1 1 1
should have been
Xpm="1 1 1 1"

I'm also using types 0x77 through 0xFF with subtypes 0x11-13 because that's the last thing I tried before noticing the missing quotes.

I still have a ways to go, but the map is on the screen, readable at at least one zoom level, and in the right place!  Yee Hah!

-Dana

Hmmm, yes, well maybe that one was a bad example... I've tried so many different hex types that I'm losing track.  But mostly I've used types that I know to be point types... and still no joy... I either get standard icons or nothing (blank screen, just a background showing where the map supposedly is).

I thought extracting the color information from the bitmap file, converting from a conic projection, and establishing a precise lat/long for each pixel would be the hard part, but it's the custom point thing that has me stumped.

-Dana