Topics

I've been creating routable Garmin maps since 2012, first generating a .mp file and then using mkgmap to produce a Garmin IMG file.  Last year I noticed that the routing had changed, directing me along short-cut paths which were supposed to be blocked for the chosen "Activity".  This week I delved into that problem and found that setting the the .mp "RouteParam" "denied_bicycle" flag to 1 now does not have that effect - bicycles are always routed just as automobiles are. FYI I tested all the "RouteParam" "denied" flags and could not find any which could deny bikes but not deny autos, or vice versa.

I could not find any mention of this change on the forums except for popj noting that "GPSMAP 66, Edge: Bicycle routing uses highways"  in the recent topic "Garmin .img maps" (I know that most people do not make routable maps.) So I wanted to note here that this routing change seems general since it occurs on my GPSMAP 64 as well as my 66.  Hopefully it is a bug that Garmin will later correct.

Any additional info that others have would be appreciated.  The loss of the additional "Cycling" routing option, leaving only "Automobile" and "Pedestrian" options, has affected both how I make and how I use my maps. [Background: my maps are hiking maps and previously I could control routing over roads, official trails, and use trails - but now in order to preserve ability to route or not-route along use trails I cannot discriminate between roads or trails in the routing.]

Jack

PS: forgot to mention that the "denied_pedestrian" RouteParam now does not block the "Pedestrian" activity!

PPS: later found that the expected behavior works for my 66 only when I also select the "Minimize Time" option - for "Minimize Distance" it routes along "denied" paths.  A still trying to figure out how the "Minimize Time" and "Minimize Distance" choices affects things.

I've noticed on my GPS64 load of my custom map that POIs with some types (eg: 0x5201, 0x6619) are found by a "FIND" of both "All POIs" & "Geographic Points (All Categories)" but other types (eg: 0x641c,0x6701) are found only in "Geographic Points (All Categories)" - not by "All POIs". (All types are displayed on the map.) Could not find anything in cGPSmapper User Manual addressing this. 

Anyone know what determines what Type is NOT found by  "All POIs" ??  My guess is that Garmin has some list of "known" POIs (eg those listed in cGPSmapper User Manual, but with others subsequently added by Garmin) and only those will be included in "All POIs" - but that's just a guess. (In my custom map I've purposely tried _not_ to use a "known" type since none of the Garmin descriptions match what the icon is supposed to represent - but I may now need to change that.)

I've been using version r2314 of mkgmap (which uses Java6) for my MP compiles.  But I'd been having some problems, so installed the latest mkgmap version, r3759 (which uses Java8), thinking there might be a bug in the older version which had been corrected.

I was surprised to note that img files produced from a contour-line MP were 20% smaller than their r2314-produced counterparts, but could see no difference between their IMG maps  when loaded to my GPS.  But then when I tried to install the EXE version into BaseCamp, BaseCamp rejected it and asked that it be "re-installed" - which I tried again but with the same failure.  Going back to r2314 solved that problem

I should note that I'd previously incorporated some r3759 compiles (for streams) without any difficulty. It was only when I tried using it for contour line files that the problem occurred. But since I can't have confidence in r3759, I've have gone back to using r2314 for all my MP compiles.

I've produced a map which renders differently on my GPSMAP64 and etrex30. Specifially, I've produced an .IMG file which when placed in the "Garmin" directory of the GPSMAP64 renders "correctly", with contour lines displaying above a polygon.  But when loaded onto the etrex30 the polygon is rendered _above_ the contour lines, so they cannot be seen.

That map was created by combining separate IMG files for the contours, polygon, and etc. I also used those to produce a Windows .EXE file which when in installed into the Windows registry displays correctly in BaseCamp.  But when BaseCamp then installs the file to the GPS, again on the etrex30 the polygon is rendered above the contour lines.

I couldn't find any reference in previous postings to such behavior.  Has anyone else seen disparities between the two platforms ?

After hearing from a user of my Garmin map that BaseCamp had failed to load it into her etrex, I tried the same using my Windows BaseCamp and got "There is a problem with your Big Sur Trailmap installation.  Re-install the product and try again."  Of course, re-installation gave the same result.  My map is complex, with cgsmapper compiles (of contours and streams), with mkgmap compiles (of trails, boundaries, and other data), and with TYP files - and it routable.  I use  NSI to produce an installation file which does install and display correctly in my BaseCamp (and is routable there).  Many years ago, when first creating the map, I was able to successfully install the map to my GPS using BaseCamp.  But since then my usual procedure has been to install the map by simply writing the corresponding IMG file to the GPS Garmin directory, not installing via MapSource (since updating MapSource is a slow procedure).

There have been considerable changes from the initial map (e.g. inclusion of a wildfire polygon) and I don't know at what point the BaseCamp problem developed.  The error message is obviously not helpful.  The only way I can think of trying to solve this is by successively removing elements from the map (e.g. first the wildfire polygon, then the trails, then the contours, ...) until it works. That would be very time consuming and I'm don't think I can devote that time.  Still, I want to make a quick attempt at finding a solution.  So my question is: is there some method (e.g. a software package) of testing the installation executable, one which would provide more useful error messages?

And if anyone has advice on how to best proceed in ferreting out the problem, I would love to hear it!

Jack

I noticed that some of my .mp files have
  Levels=4
  ...
  Zoom0=1
  Zoom1=2
  Zoom2=3
  Zoom3=4
whereas some others have
  Levels=5
  ...
  Zoom0=0
  Zoom1=1
  Zoom2=2
  Zoom3=3
  Zoom4=4
The history of those is lost to me so I was trying to understand what the "Zoom#="
parameter does.

Reading the cgpsmapper manual, "Level#=" and the difference between "Hardware" and "Map" zoom levels are thoroughly explained. But all I can find for "Zoom#=" is "Refer to Section 4.4" - yet that section discusses "Level#=" but nowhere mentions "Zoom#="!  There is a later use of
  Zoom0=0
  Zoom1=1
  ..
  Zoom4=4
in an example - but that it all I can find!

I'm surprised that this seems an omission from the otherwise remarkably detailed descriptions in the manual.  Does anyone know what "Zoom#=" is supposed to do? Might this be an obsoleted parameter?

Jack

The cGpsMapper manual is an invaluable resource for those constructing or editing .mp ("Polish format") mapping files but the links I found all pointed to the cgpsmapper.com server which seems no longer available.   Finally I found an archived version which greatly helped me, so for others having problems accessing the manual a "wayback machine" link is

https://web.archive.org/web/20160729043418/http://cgpsmapper.com/manual.htm

Jack

I provide trail maps for Big Sur hikers (http://bigsurtrailmap.net), since many printed maps have errors and most don't include "unofficial" trails known to local hikers.  Besides on-line and printable maps, I provide a routable Garmin map for GPS users.

I originally setup the Garmin map in 2012 and created scripts such that later trail changes were automatically replicated in an weekly-updated Garmin map - so much of that 2012 knowledge is now lost to my aging (71yo) memory.  But a recent wildfire (you may have heard about it, the most costly one in US history so far) has greatly impacted many trails - so displaying the burnt area has become important. I've now done that for the on-line and printable maps but am having difficulty doing so for the Garmin map.

I am trying to add a single polygon of the burnt area as _simply_ as possible since it will only be temporary, likely removed in about 2 years when the land has recovered somewhat and trail crews (almost all volunteer - I'm also a trailworker) have had a chance to do some work.  I've _almost_ got this to work, but my current knowledge seems insufficient despite trying to refresh it via on-line searchs. A particular problem is being unable to find any manual giving the MP format specifications, since website cgpsmapper.com is no longer on-line.

By "almost" working I mean that I have created a new TYP file and IMG file (compiled from a MP file using OSM mkgmap) which I can display in GPSMapEdit with a pink polygon displayed below the existing trails+contour+stream lines and camp+poi icons.  But two problems are:
(1) the polygon is only displayed at "Level 0", not at higher levels and I would like it displayed to level 2
(2) when the IMG file is transferred to my GPSMAP64 the polygon does not appear at _any_ zoom level.

Things which may be applicable:
() the TYP polygon is created with _no_ draw order
   (but trying a draw order of 9 gave no change)
() the "polygon" MP file contains:
     [IMG ID]
     CodePage=1252
     ID=...
     Name=SoberanesWildfire
     Preprocess=F
     TreSize=396
     TreMargin=0.00000
     RgnLimit=1024
     Transparent=Y
     Copyright=
     Levels=5
     Level0=24
     Level1=21
     Level2=18
     Level3=17
     Level4=16
     Zoom0=0
     Zoom1=1
     Zoom2=2
     Zoom3=3
     Zoom4=4
     [END-IMG ID]
     [POLYGON]
     Type=0x71
     EndLevel=2
     Data0=(36.501664,-121.896562),...
     [END]
() a "polygon" IMG is created from the "polygon" MP file using mkgmap with "--transparent"
() the "trailmap" IMG is created by adding the "polygon" IMG to the other (trail,contour,stream) IMG files in a mkgmap run

Any insight would be appreciated.  I assume something needs to be changed in my "polygon" MP file but my testing some alternative MP versions has not produced anything better.

Jack

I'm now creating "universal" Garmin "gmapi" map files which can be used to install maps on both Windows and Mac machines.  My current plan is to offer both a "registry" installation version of my maps for Windows users and the "gmapi" files for Mac users or others who might have a problem with the "registry" installation.   I'm going to assume that any gmapi users will have enough knowledge to do basic computer operations such as a "copy" (and possibly "unzip"), so will not need an installation script - but don't know what would be the most "convenient" form for them to use.

I've tested gmapi use on a Windows PC but am unsure how they should be used (and hence packaged) for a Mac.  Since I don't have one and can't test that, I'm looking for some guidance here.

"gmapi" creation produces a gmapi directory with a gmap subdirectory which contains the map files actually used.  On a Windows machine, the "gmap" subdirectory is utilized, not the "gmapi" one, being placed under an OS-dependent folder such as C:\ProgramData\Garmin\Maps.

Based on the thread http://forums.gpsfiledepot.com/index.php?topic=2383 I believe that for a Mac I should provide the "gmapi" directory (not its "gmap" subdirectory) as either a .zip or .tgz file.  Can someone who uses a Mac enlighten me on this?

Jack

I've now successfully created "universal" Garmin "gmapi" map files on a Linux box and wanted to document the procedure here for others as there were a few glitches I had to solve. Most people here use Windows based proceures,  so I wanted to document a successful Linux process.

Background: this will only work for .img files produced by the OSM mkgmap compiler, not for .img files produced by cgpsmapper (which I did test).  I'm assuming here that someone is already familiar with the mkgmap compiler and has already used it to create .img and .tdb files (and routing .mdx/mdr.img  files if desired).

() On Linux box, you can produce a "gmapi" directory containing a "gmap" subdirectory which contains map data usable with BaseCamp on Windows PC (7-64bit tested) and OS-X Mac (untested) by  using the OSM program gmapi-builder.py . A link to an older version with instructions is   http://wiki.openstreetmap.org/wiki/Gmapibuilder  - but there is a newer version can also utilize styling .TYP and/or routing .mdx/mdr.img files and it is hard to find so I've uploaded it as an attachment below.

() Put all the files in subdirectory, say "tiles", then run command
   

Code Select Expand

gmapi-builder.py -v -t tiles/MyMap.tdb -b tiles/MyMap.img -s tiles/STYLES.TYP -i tiles/MyMap.mdx -m tiles/MyMap_mdr.img tiles/*img
       where "MyMap.img" is "background" map name or number
       and the last argument can be multiple, such that all needed .img files (i.e. basemap, routing, etc) are included
       Optional arguments -s/-i/-m are only needed as appropriate for processing .TYP and .mdx/mdr.img files
       and I've included optional "-v" flag for more verbose output

() This creates directory MyMap.gmapi which has a subdirectory MyMap.gmap.  The latter should be installed on PC under a folder which varies with the OS.  The following should work
         for Windows XP: "C:\Documents and Settings\All Users\Application Data" folder (untested)
         for Vista and Windows 7: "C:\ProgramData\Garmin\Maps" folder (tested)
         for a Mac - am unsure as to how the files should be provided, but I think one can create a .zip or .tgz file of the gmapi directory and a Mac can open those for automatic installation

() The script does give a worrisome "Unknown Block: ..." message.  This has also been reported by others.  But no one has yet reported finding any resulting problem (and neither can I). Note: one message which does indicate an error is "Missing part:  ... in IMG-file", which occurs when a .img file is not readable (likely not created by mkgmap)

() I've tested WITH a styling TYP file and WITH routing files and WITH contour+stream .img files overlaid on a background map.  Everything (including routing) worked for me on a Windows 7 64-bit BaseCamp.  So all seems good

Jack

I'm looking for guidance on how to proceed after failing to resolve a problem encountered by a user of my maps.  Hopefully I'll get some wisdom from those better versed than I in the installation of a map into a PC for BaseCamp use.

The story so far:

() User with a new PC with Windows 7 64-bit first installed BaseCamp, then tried to install one of my maps.  He successfully followed the nsis installer procedure, with no apparent error, but the map did _not_ appear in BaseCamp.  It _did_ appear in the ControlPanel "Programs and Features" display.

() He was able to fix this by following the procedure described in thread http://forums.gpsfiledepot.com/index.php?topic=3794.0 - namely, downloading and installing the "MyTrails" map, then installing my map, then uninstalling the "MyTrails" map.

() That might seem to point to a problem created by use of a "older" installation script, as mentioned in that forum post. "Older" seems to mean prior to Dec 2011, namely the changes I found discussed in the Feb-Mar 2010 forum thread  http://forums.gpsfiledepot.com/index.php?topic=1022.0

() However, all my development work was done between Sept-Dec 2012.  As such, I used the then current NSIS version (2.46, currently still the latest v2) and the "new" installation script template available at that time.

() Comparing my current .nsi script to the current template .nsi file I can see no notable differences, only differences relevant to my specific maps.  (And there is NOT any reference to a Registry.nsh file anywhere, which was apparently one source of difficulty in the 2010 thread).  Looking at the "Write the MapSource configuration into the registry" section, the only difference is that in my version the following lines are used, not "commented-out" as in the template

Code Select Expand


WriteRegStr   HKLM "SOFTWARE\$OS_EXTRAGarmin\MapSource\Families\${MAP_SHORT_NAME}"   "IDX"   "$INSTDIR\${MAP_SHORT_NAME}.mdx"
WriteRegStr   HKLM "SOFTWARE\$OS_EXTRAGarmin\MapSource\Families\${MAP_SHORT_NAME}"   "TYP"   "$INSTDIR\${MAP_TYPE}.typ"     ; only if using custom type

These lines were uncommented since I  do use TYP and MDX files.

() At the risk of introducing a red herring, I should mention that I'm creating the installation executable (and the .IMG files to be loaded into the GPS) and so running the NSIS creation script on a Linux box, not a Windows PC.  But prior to this there has been no reported problem.  (I myself also use a Windows 7 64-bit PC and have been able to install, uninstall, and re-install my map on my PC without difficulty - but have not tried a clean install of BaseCamp, since I have multiple installed maps which I would not want to recreate).  I run on a Linux box because I have a batch script which is run automatically each week to update the map with any current changes to the trail system - and has been doing so since Jan 2013.

() So next, I should ...

Jack

My current installation executable:
http://bigsurtrailmap.net/TRAILMAP/GARMIN/ROUTABLE/MEDIUM/BigSurTrailmapWithTopo_install.exe

I've added an attachment with my .nsi file

I'm trying to eliminate the green background (indicating Park/NationalForest/etc) from my Garmin Topo24K maps, so the contour lines will be more easily visible.  I don't need to be told that I'm in a Park/NF/etc when I hike - ALL the places I hike have a green background!  I know that TYP files can be used to alter the treatment of polygons, which I believe are used to generate the background, so I want to make those transparent.  I'm used to editing TYP files, as I've done that in creating my own (routable) maps.

But I can't see where any TYP file is being used with Topo24K.  30 minutes of googling has not producing anything useful.  So I'm hoping someone here has some info on how to do this.

A specific question: I can use GPSmapedit to determine the hextypes of the polygons on the maps.  Is it possible to simply create a TYP file with all those polygon types set to transparent and then load that onto my GPSMAP 62 (assuming I can figure out the family ID of the Topo24K files) ??

I want to note that I've found that it possible to automate the process of creating routable Garmin-format map files (both an .img file for direct GPS installation and a Windows-executable for MapSource installation) by using the OSM compiler.  And in particular it is possible to do this on a Linux box.  This may encourage others to do likewise.

Previously I'd been producing the Garmin-format files by having to manually run several different programs on a Windows box (namely cGPSmapper, GMapTool, MapSetToolkit, and NSIS) and since several of those are GUI based automation was not possible.  I actually got started using the OSM compiler because for some reason my latest .mp file produces a Windows "Access Violation" error with cGPSmapper (it was working fine until a month ago), but runs ok with the OSM compiler.  I then discovered that both the OSM compiler and NSIS will work on a Linux box, and with a little more (OK, actually a lot more) work I could automate the complete process.  Since I produce 9 different Garmin-format map files (I have variants which provide 3 different icon/line size options for the user, and "with topo" and "sans topo" versions), doing this manually was a pain in the butt so I found myself doing the updating only every 3-4 months.

For my "Big Sur Trail Map" (http://bigsurtrailmap.net) I use GPX data to create multiple map formats: an on-line browser-displayable map, a Google-Earth-format file for downloading, printable PDF maps, and the aforementioned Garmin-format files.  Now I simply have to make a change in the GPX line or point file and the result is propagated into all the maps (nightly for the on-line and Google-Earth maps, weekly for the PDF and Garmin maps).  Changes are needed surprisingly often, since I continue to find unofficial "use trails", the official trails get created and/or re-routed, etc..

I've spent a frustrating day trying to make some icon labels invisible using a TYP file before finally stumbling on a solution, so am posting my result here so that others will hopefully not have to go through the same experience (googling "TYP hidden labels" did not produce anything helpful to me).

Why did it take so long?  I went through many, many tests, all needing to going through creation of a MapSource installtion, including

() using the "on line" TYP editor - after checking "extended labels", changing the icon and font color DID work, but changing the "Font Style" was NOT having any effect

() using TypWiz3
I input
  ExtendedLabels=Y
  FontStyle=NoLabel (invisible)
but later tried re-inputting the TYP file created and found that TypWix had substituted "Default" for its FontStyle without any notice to me!  It took quite awhile for me to discover that the value I thought I was specifying was not actually being used!
(I also tried variants such as just "Nolabel" with the same results.)

() altering the .mp file's  "Lblcoding" values

The solution?  Like the proverbial millions of monkeys typing to accidentally create a line of Shakespeare, I found that when using the on-line TYP editor if, with "extended labels" checked, I changed "Custom Colors" from its default "no custom colors" to "custom day color" then the text DID become invisible. (The custom day color actually specified could apparently have any value.)

I'd previously reported getting "cpreview.exe has stopped executing" messages on my Windows 7 PC, with abnormal cpreview termination so, most notably, a _MDR.IMG file was not being created.  I finally tracked down the cause so am reporting it here in case anyone else encounters the same problem, which was certainly mysterious to me.

I'd been running MapSetToolKit to create MapSource installation files from 13 .IMG files in 3 different subdirectories.  After that process, IMG files with the same names appeared in the MapSource installation directory.  I assumed that they were simply copies of the original files (the file sizes were the same, to the precision reported by Windows Explorer) used in the MS installation process.  I now realize the abnormal terminations must have been on those runs when I had, for whatever reason, closed MapSetToolKit and since it does not remember the last parameters input to it, "for convenience" I was simply selected those files since they were all in a single directory.  But there must actually be some difference between those files and the original IMG files of the same name, because testing now shows that cpreview abnormal termination always occurs if I use those files but not if I use the original files.

FWIW I tried to look into this in more detail by using a script to run cpreview.exe and pipe stdout and stderr into files - but that gave no insight since cpreview indeed stops executing, as Windows 7 reports, so no stdout or stderr is generated. But at least I now know the reason for the problem.  For me it had been confusing since it was seemingly occurring with files which I had previously run without a problem.

I have 10 .img files containing topo data for different regions, 2 .img files containing steam data, and 1 .img file containing trail data.  I expect to be frequently updating the trail data whereas the topo and stream data will be static.  Currently I create an overall IMG file for MapSouce using all 13 files as input to MapsetToolkit but it would be more convenient to combine the static topo and stream data into a single .img file so that I only have to worry about two .img files when using MapsetToolkit.

I can combine the topo, for example, by generating a .mp file from each of the regional .img files, combining these into a single .mp file and generating a single .img topo file. I've already tried this - the compilation took 3 hours on my i5 processor but it did work.  But I've started wondering about the useage efficiency of using such a large single .img file instead of 10 smaller files.  Does anyone know whether using such a .img file will result in less efficient use either in MapSource or the GPS?

(As an alternative I've considered using the "Join" functionality of GmapTool to combine the 10 regional topo file, but I don't know exactly what that does.  Perhaps using GmapTool's "Join" would create a single .img file but within that file the 10 regional files would still be separate??)

I have two .img files (stream data for different regions) which I can individually install as a mapset in MapSource using MapsetToolkit.  I want to make a single mapset from them to cover both regions, so used Gmaptool to "join" the .img files into a single .img file. MapsetToolkit installs that file into MS without any apparent problem (though the cpreview and cgpsmapper output lines stream by so quickly that I cannot know for certain whether a warning or error message is there), but when I try to start MapSource I get a popup window with error message "There is a problem with the BigSurTrailmap installation.  Please re-install BigSurTrailmap and start MapSource again".  This occurs both when I do and do not specify a FID during the Gmaptool join process.

I'm at a loss to see what I can do differently - the MapsetToolkit parameters I'm using are the same ones which worked for each of the individual .img files.  The joined .img file does work without problems when loaded into a GPS - so the MapSource installation is the problem.  So am hoping to find some help here.

Jack

PS: anyone know of a way to capture the cpreview and cgpsmapper output streams produced during MapsetToolkit into a file so I can examine them for any warning/error messages?

I've created a routable map and as an alternative to a direct file install to the GPS I'm providing a BaseCamp/MapSource installation file (created by NSIS).  After executing the installation file, the map displays fine in BaseCamp/MapSource and using it to transfer the map to the GPS allows one to route via trails/roads on the GPS just as the directly installed file does.

But I find that I cannot create a non-direct route in BaseCamp/MapSource.  I don't have previous experience trying to create an "on road" route using the software so don't know exactly what to expect, but I believe I am invoking it correctly.  I create two waypoints at two "camp" icons along a trail, then click the "Route" tool and drag them to the "Start Point" and "Destination" boxes of the popup window - and end up with a straight magenta line between the two.  [FWIW I note that I cannot drag the icon directly to the popup window box - I can only drag a waypoint I've created at that position.]

I'd appreciate any feedback from someone who has created a routable map as to whether non-direct routing works in BaseCamp/MapSource for your map.

Jack

In creating a routable trail map, I wanted to distinguish between official trails and "use trails" in the routings (they already appear differently on the map).  "Use trails" can be of questionable hikeability (actually in the Ventana Wilderness the official trails can also be of questionable hikeability!), so some people may simply not want to attempt using them.  Those people would not want to have a route which includes a use trail, so my idea was to use the "Denied_car" capability of the cGPSmapper to exclude use trails from routings.  Since this map is intended primarily for hikers, with roads being shown only for trailhead access, my idea was that people could set the "Activity Mode" to "Automobile" if wanting to use only official trails but "Pedestrian" mode if wanting to also use "use trails".

So I created such a trailmap, but am finding that when in "Automobile" mode my Oregon GPS will not route along the official trails (for which I am using type 0x0f).  I was so disbelieving of this that I redid the file creation process, carefully monitoring it from the .mp file (checking to ensure that it used "RouteParam=0,4,0,0,0,0,1" only for the use trails) through transfer to the GPS.  So the "Denied_car" digit of RouteParam  does not seem to be controlling the automobile-vs-pedestrian difference - I can only guess that it is being controlled by the fact that I am using "road" types for my actual roads and other types (0x0e and 0x0f) for trails and use trails.

But I am still somewhat unbelieving of this - it would seem that if the "Denied_car" parameter of cGPSmapper has no effect that others would have noticed it!  So I'm posting here to see if anyone with experience in creating a routable map has some relevant knowledge to pass on. Perhaps I am missing something.

I just finished improving the trail map I'd made for the Ventana and Silver Peak Wilderness areas in Big Sur California by adding routing and additional icons.  The routing is working (based on demo mode tests) but the icon addition produced some questions so I decided to turn to some other map-makers for help.

I want to identify 3 different kinds of camping sites so chose 3 different icons and gave them hex ID types of 4801, 4802, and 4803 since 48xx is supposed to be for "Camping".  The icons displayed ok, with their correct label, but none of the campsites appeared in a POI search, although I had compiled with POI indexing, so I can not search on their names.  Icons I used with the 64xx, 65xx, and 66xx types (Manmade features, Water features, and Land features) all were listed as POIs and could be searched for. [This is the case for a GPSMAP60csx, an Oregon, and a GPSMAP62.] I understand why the 48xx types would not be listed as "Geographic Features" but do not understand why they would not appear as a POI.  To me it does not make much sense to use icons types for which no search can be made.

Do I misunderstand what a POI is supposed to be?  Could I have done something incorrect when creating 48xx icons (the cGPSMapper compiler input code was essentially the same as for 64xxx etc types, differing only in the type number)?