GPSFileDepot.com
 

News:

Welcome to GPSFileDepot!

Main Menu
Menu

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.

Show posts Menu

Messages - glendeni

#1
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.


#2
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.

Jack
#3
Map Making Support / Re: POI type affects GPS "Find"
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.

Jack
#4
Map Making Support / POI type affects GPS "Find"
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.)
#5
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.
#6
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.
#7
Quote from: popej on January 20, 2017, 02:08:28 AM
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
#8
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.

#9
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
  Levels=2
  Level0=24
  Level1=23
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.
#10
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.
#11
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.
#12
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 ?
#13
Map Making Support / Re: Loading via BaseCamp fails
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).
#14
Map Making Support / Re: Loading via BaseCamp fails
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.
#15
Map Making Support / Re: Loading via BaseCamp fails
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?