Welcome, Guest. Please login or register.

Login with username, password and session length
Forums Search:  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - glendeni

Pages: [1] 2 3 ... 6
Want to thank you for all the time you put into creating this updated tutorial.  Seeing it motivated me to try comparing contours form the latest one-third arcsec data to the ones I've been using from the old CATOPO datafile for my area which has very complex topography (Big Sur, CA).  Following your directions, it was quite painless, using QGIS 2.18 (admittedly I already had some familiarity with that software).

So I only went through the "Part 2 - Elevation Data - Option 2" section.  For that, my only suggestions would be:

Using The National Map Viewer to Download the Data
() instead of "state" should use "area of interest, e.g. a state"

Processing the data - QGIS
() would help understanding at each step to give a description of what will be created following a "click OK'
 eg 12. "Click "OK" -> Click "OK to create a contour .shp shapefile
() after 8. need to insert: Click "OK"

Also, in QGIS I found that the specified filenames sometimes did not appear in the directory I expected, so had to hunt them down.  That may have been due to directories used in my last project being used instead of the the ones I expected.  Anyway, I think its good practice to click on the  "Select" button to make sure the file will be written to the directory you want.

Thanks again.


Map Making Support / Re: POI type affects GPS "Find"
« on: January 05, 2018, 03:43:45 PM »
Thanks for that link.  Seems like this must be empirically found. I'll just have to use trial and error.


Map Making Support / POI type affects GPS "Find"
« on: January 05, 2018, 11:59:33 AM »
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.

Thanks to your help, I now have the map displaying correctly with contours+streams displayed only at higher map zoom levels and a polygon being displayed at all levels but always below the contour+stream lines.

Probably last layer of your contour map is always visible. You could create transparent map with more layers, so last one should be empty.

My interpretation of what you are saying is that in the MP file if one has polylines all defined for "Data0" then if "Levels=1" (which is a mistake since there should always bean empty level)  the lines will be visible at the Data0 level and also all levels above, but if "Levels=2" and "Level1" is set then the lines will not be visible for levels at and above that value

Sorry, but reading the responses has definitely confused me.  For thing, I think in terms of layers being above or below  - and "last" confuses me.  To me a "last" layer would be the "bottom most" layer, i.e. the last one an eye would see when looking down on the map - but the context seemingly implies it here means the "top most" layer.

I must correct what I said.  I later discovered that a map I'd previously downloaded to the etrex via BaseCamp in previous testing was still on it when I loaded my new IMG file (the IMG files  have slightly different names) and the former apparently took precedence - so that was what I was seeing and reporting on.  When I removed that, the contour and stream lines were ABOVE the polygon.  So your suspicion was correct.

But that also triggered a memory of why years ago I had decided to change to make them non-transparent.  For some strange reason when compiled with mkgmap with --transparent (even with the latest compiler) the MP "Level" command is apparently not respected, at least to my understanding, since even with
the lines are being displayed at ALL zoom levels, which is rather ugly at the lower zooms when everything blends together.  I don't think I can live with that.  So i will go back to not using --transparent and simply stop trying to produce a polygon, since it is less important than the contour and stream lines.

Those were compiled so long ago that I can't be sure - I have notes made back then, but could not be certain that I had not later made some change.  So I recompiled those, with the mkgmap compiler with --transparent flag (which seems to override whatever "Transparent" is set to in the .mp file, but that was already "Y").  FWIW I've now upgraded the mkgmap compiler to the most recent version,  vice what was used back in the original compilation.

Combining all IMGs, I get the same result as before.  Interestingly, the etrex is so slow that the map-drawing occurs in visible stages and I can see the contours being drawn but then afterward being overlaid by the polygon.

Map Making Support / Re: universal Garmin gmapi map creation on Linux box
« on: January 18, 2017, 09:51:36 PM »
Just wanted to reinforce the fact that this will NOT work for img files produced by cgpsmapper.  I'd forgotten this myself and just spent a lot of time compiling with different cgpsmapper options to see if I could get one to work - but all failed.  FYI the version that I am using is dated Feb 2011.  I could not find a later/updated version.

Map Making Support / Polygon renders differently on GPSMAP64 and etrex30
« on: January 18, 2017, 07:41:19 PM »
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 ?

Map Making Support / Re: Loading via BaseCamp fails
« on: January 18, 2017, 07:39:26 PM »
Gave up on trying to get MapsetToolkit to work and as a quick thing to try removed the last addition to my map, a polygon showing a wildfire forest closure area.  Lo and behold, the problem went away - specifically,  I could download the map to a GPS after installing it on BaseCamp.  Given that, I traced things back and discovered that although I'd included a link to the polygon IMG file for the full map IMG build, both the .EXE and Gmap versions required a link to it from another location, which I'd failed to do.  So now have an explanation.  (And in retrospect, I should have noticed that the polygon was not being displayed in BaseCamp, as a clue that something was missing.)

I thought success was in sight but it turned out to be only partial.  Adding that link then produced a failure of the Gmap build!  Further investigation found that it fails when using an IMG produced by a cgpsmapper compile while succeeding using one compiled by mkgmap (for the same .mp file).  Do not understand that!

But also obtained another strange result. I'll put up a separate thread to not obfuscate this one.  Briefely I found the same IMG file renders differently on etrex30 and GPSMAP64 GPSs (and the one on the etrex30 is unacceptable).

Map Making Support / Re: Loading via BaseCamp fails
« on: January 17, 2017, 05:25:33 PM »
When it rains it pours.  MapsetToolkit seems broken on my PC - for example many of the menu labels are missing, see the attached screenshot.  I tried restarting my Windows 7, tried a new download and re-install of MapsetToolkit, tried changing compatability setting to Windows XP.  But none of those produced anything different.  Will have to think about how to proceed.

Map Making Support / Re: Loading via BaseCamp fails
« on: January 17, 2017, 12:47:35 PM »
Thanks for your reply.  I will have to dig a bit to re-remember the creation details.  But before working on that I tried using MapsetToolkit, since I already had that installed.  Clicking on my map in the "Mapset Installed" pane highlights it in dark brown, then clicking "Check Registry" changes the highlight to gray with no messages appearing - does that mean that no problem was found or does that mean that MapsetToolkit failed to function?

Map Making Support / Loading via BaseCamp fails
« on: January 17, 2017, 11:43:05 AM »
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!


Pages: [1] 2 3 ... 6