Jump to content
Sign in to follow this  
Followers 6
Cheminer Will

GPSMAP Proximity Alerts/Alarms

Recommended Posts

Posted (edited)
10 hours ago, Cheminer Will said:

there is a very well done explanation

Actually there is a fault in the description. He confuses Latitude and Longitude in his examples. Column A | B should be Longitude | Latitude (that's right). But his example screenshots show it just the other way around. If one is working based on the screenshots - then it will not work.

His example GSAK view is also wrong:

2. Create + Enable a 'View' in GSAK that displays only the data specified here.

Should be: Longitude, Latitude, Code, Description

 

Hans

Edited by HHL

Share this post


Link to post
4 hours ago, HHL said:

Actually there is a fault in the description. He confuses Latitude and Longitude in his examples. Column A | B should be Longitude | Latitude (that's right). But his example screenshots show it just the other way around. If one is working based on the screenshots - then it will not work.

His example GSAK view is also wrong:

2. Create + Enable a 'View' in GSAK that displays only the data specified here.

Should be: Longitude, Latitude, Code, Description

 

Hans

 

Doh!

 

Corrected!

 

Thank You.

Share this post


Link to post
Posted (edited)
On 4/7/2019 at 7:48 PM, Cheminer Will said:

Here is a different snip showing 3 of the caches I went to today without alerts:  #6, #32, #34 

 

780255480_Prox2CSV.PNG.efc42711aa5d42baf67951f41d434497.PNG

 

 

My bad for not catching this before.

 

The first two columns are reversed. GC.com and every GPSr I know always show coordinates in that order (LAT/LON), but for some unknown reason, Garmin wants them in the reverse order (LON/LAT) for POI loader.

 

I am so used to seeing coordinates displayed in (LAT/LON) that it didn't appear incorrect the first time!

 

 

Edited by Atlas Cached

Share this post


Link to post
2 hours ago, Atlas Cached said:

My bad for not catching this before.

See this post in this thread from Feb 25:

 

Share this post


Link to post
Posted (edited)
8 hours ago, HHL said:

Should be: Longitude, Latitude, Code, Description

 

Well I see this now. Pretty sure I followed HHL advice earlier when I had other things incorrect, but may have swapped the columns once I started following GPSrChive.  I am trying a new file today and will see if it works.  

Edited by Cheminer Will

Share this post


Link to post

Just went through the process again making sure the columns were correct.  Still no alert.  I then did it with only one POI instead of the several hundred.  Still no alert when I walked up to that point.

Share this post


Link to post

I (mostly) followed the instructions. I've been using downloaded GPX and csv files for years from poifactory.com as well as creating my own for use with a Nuvi on road trips. Setting a 10,000 ft notification for Rest Areas and 500 ft for red light cameras, for example. First time using poiloader with the GPSMAP 64st, though.

 

I did not bother with a custom icon, I just created the csv. Set a distance of 1000 feet and drove around in the car. I got notifications, but not for ALL of them. Presumably because quite a few overlapped. Where there were clusters where several were within 528 feet of each other, I'd get the notification for the first, but not the others. At any rate, notifications worked (mostly) as expected on the GPSMAP 64st.

 

I do know that poiloader is very fussy about filenames as well as poi names within the file. This allows it to automatically assign distances or speeds when you have multiple csv/gpx poi files in the folder to upload at once. There are quite a few examples in the poiloader help file.

 

I can only think of 2 suggestions... 

Eliminate the custom icon to see if that is causing a problem somehow.

Check the "creating a custom poi file" section in the poiloader help section to see if you are accidentally triggering an auto function in poiloader.

 

Oh, one more thing. I'm using a different version of poiloader than what is shown in the instructions. My version does not have the option of setting the POI output filename. It always creates poi.gpi on the device. I have no idea if that is significant or not. 

 

Share this post


Link to post
Posted (edited)
3 hours ago, JohnCNA said:

At any rate, notifications worked (mostly) as expected on the GPSMAP 64st.

Well darn.  Thanks for doing that.  It seems it does work for you on your GPSMAP 64.  

 

3 hours ago, JohnCNA said:

I do know that poiloader is very fussy about filenames as well as poi names within the file.

I believe I am using the same file names as @Atlas Cached and it works for him.

 

3 hours ago, JohnCNA said:

Eliminate the custom icon to see if that is causing a problem somehow.

Same icon also, but I did use a different icon a couple of times and that did not make a difference. I will try it with no icon in the file directory and see if that makes a difference.

 

3 hours ago, JohnCNA said:

Check the "creating a custom poi file" section in the poiloader help section to see if you are accidentally triggering an auto function in poiloader.

I don't think I am but do believe I am using the same process as Atlas Cached and it works for him.

 

3 hours ago, JohnCNA said:

I'm using a different version of poiloader than what is shown in the instructions.  My version does not have the option of setting the POI output filename

I will try letting POI Loader choose its own file name as at this point I am willing to try anything!

 

Thanks for verifying that it works for you.  Did you use GSAK to create the .csv file?

Edited by Cheminer Will

Share this post


Link to post

As a sanity check, use GPSBabel to read the gpi files and let it write unicsv files which are easy to hand inspect for correctness. GPX and others are easy to drop into your favorite mapping apps. Remember that GSAKs POI handler is actually ours, I'm pretty sure.

 

As consolation to all the programmer types, in GPSBabel , I think we've mixed up late/long order and hemisphere sign probably at least a dozen times in our history. The KML guys, with their root in graphics (x,y) instead of cartography think their order is obvious. (Then they go off and named the official blog "latlong" to keep everyone in their toes...) Mapping wonks go the other way. Someone will reverse engineer a file from someone in a different hemisphere and not notice that their interpretation seems legit, but is in an ocean because reverse order seemed to basically work. Someone will make a local map program and treat all values as positive because it the obvious thing to do. Weve bozoed this several different ways in our history.

 

Correctly interpreting horizontal times vertical is a messy area. (Cartography jokes play to a pretty small audience...)

Share this post


Link to post
Posted (edited)
16 hours ago, robertlipe said:

As a sanity check, use GPSBabel to read the gpi files and let it write unicsv files which are easy to hand inspect for correctness. GPX and others are easy to drop into your favorite mapping apps. Remember that GSAKs POI handler is actually ours, I'm pretty sure.

 

GPSBabel (1.5.4) always returns a *.csv file that lists Lat in the first column, then Lon in the next column, regardless of actual *.gpi file structure.

 

Can GPSBabel be updated to return *.csv files that actually represent the input file structure?

 

 

Edited by Atlas Cached

Share this post


Link to post

Our (badly named) CSV format is documented to use lat, lon, name at https://www.gpsbabel.org/htmldoc-development/fmt_csv.html and that's the definition of that format to us. The order we see something on input really has no correlation (indeed, couldn't if we tried...) to the order they appear in output. We read and write map formats, not text streams of columns. It's actually defined at https://github.com/gpsbabel/gpsbabel/blob/master/style/csv.style and if you want to swap those, you can use our swap filter or if you want to add others, you can make your own formats with style files described at https://www.gpsbabel.org/htmldoc-development/Styles.html  If you don't actually care about the order of the files and you just want "everything", go with "unicsv" instead of "csv" - that gets you a more wordy file with pretty much everything we know about a point like temperature and speed and whatever else.

So whatever you see in the first column of that output is what GPSBabel associates with the lat of that point, no matter what format, device, or options were used to read it. That happens to be the first dword of that pair in the GPI format of that tuple, but it's immaterial. I'm trying to help you guys figure out what's *really* in your GPI files as opposed to what you think you put into POILoader; GPSBabel (unlike POILoader, when I last looked) can both read and write the GPI files so you can see what the device sees - which may or may not be what you put into POILOader.

Edited: oh, wait, you're looking for the format that was used by POI Loader before it learned how to read GPX. I'd forgotten that even was still in circulation. We call that "garmin_poi" and it's documented at https://www.gpsbabel.org/htmldoc-development/fmt_garmin_poi.html and you can see the implementation at https://github.com/gpsbabel/gpsbabel/blob/master/style/garmin_poi.style where you can see the first two fields swapped. Somewhat ironically, it links back to this forum with an ambiguous post from 14 years ago that (taa daaa) swapped the lat/lon :-) So I think you should probably be able to do a roundtrip to let GPSBabel read the GPI's generated from the Garmin POI by POILoader and see if the data matches what you put in. Or you could just try GPSBabel instead of POILoader...but I'll be honest that if alerts don't work, there's not a whole lot we can do about it other than by comparing as best we can what POILoader does (assuming it works right...) and try to mock that. But it's possible we'll at least have a _different_ set of problems for you :-)

Share this post


Link to post
9 hours ago, robertlipe said:

GPSBabel (unlike POILoader, when I last looked) can both read and write the GPI files so you can see what the device sees - which may or may not be what you put into POILOader.
 

 

No, I can not see what the device sees, because GPSBABEL does not properly report the data in the *.gpi (POI) file as it actually exists.

 

9 hours ago, robertlipe said:

So I think you should probably be able to do a roundtrip to let GPSBabel read the GPI's generated from the Garmin POI by POILoader and see if the data matches what you put in. 

 

I have read several *.gpi (POI) files with GPSBABEL, and while the data in each *.gpi (POI) file is different (one has Lat/Lon, the other Lon/Lat, for example), GPSBABEL always reorts the data as Lat/Lon, which is not correct, and does not allow us to 'see' what the device sees.....

 

BTW, POI alarms do work properly when the *.gpi (POI) file is generated properly. I added 'Lat-Lon' and 'Lon-Lat' to the name of each POI file I created so I could ID them properly since GPSBABEL fails so miserably at reporting the actual data in those files.

Share this post


Link to post

We have zero reports of "failing miserably",  (Zero reports of a problem does not, of course, mean zero problems. :-)  Please send us a report, either on github or on the mailing list, with example files and enough context to investigate, including where you think any points are. (I may or may not be the one that sees it first...) and we'll look at it. Mailing lists can be grumpy about large files as attachments.

I suspect we're just having a parlance breakdown. When dealing with multiple formats and independent readers and writers, it's easy to get them mixed.

The GPI format itself has exactly one order for that pair of numbers. Since it's a binary format, it's hard to demonstrate that here. It doesn't matter what format those numbers ultimately come from or go to.
I do now see a potential ambiguity when reading the garmin_poi format. We always use lon, lat regardless of what's in the first line of the file. On write, it's always lon, lat, as described in the garmin_poi style file above.
Our unicsv format obeys that first line on a read. On a write, we always write lat first, but the header we write always matches that.  https://www.gpsbabel.org/htmldoc-development/fmt_unicsv.html

Share this post


Link to post

This issue has been resolved with the release of Firmware v3.10 for the GPSMAP 66 on 03JUL19.

Share this post


Link to post
Posted (edited)

A couple people already know but since I started this thread, I thought should post my results with Firmware v3.10 for others that may try this in the future.  I have tried with several different files loaded with POI Loader and this new release and it still does not alert for me.  I even tried with a single file from another person and even that one does not alert when I approach.  I then did a factory reset and still no joy. So, for me at least, this is not working yet.  As always, if I am navigating a Go To for a specific point, all alerts work as expected for that point, 100% of the time.  It may be that this process is just not going to work on all units.  I would still be interested if there is anyone that has followed the instructions on GPSrChive and has this work 100% of the time. 

 

The one caveat is that GPS software 2.70 is not available for my 66 at this point.  My unit has updated to 2.60 but not 2.70.  Perhaps both Firmware 3.10 and Software 2.70 are needed for this to resolve for me?

Edited by Cheminer Will

Share this post


Link to post

Hello Everyone,

I have been following this thread for about 6 months now as I have been trying to figure out how to get POI Proximity alerts working on my GPSMAP 64S.  While I have not spent any significant amount of time Geocaching, I do spend a lot of time working with GPS units to keep our Search and Rescue teams' units working as required.

 

In the SAR community we have requirement similar to your Geocache Proximity Alerting challenge. We have many locations around the province for which we want to receive automatic alerts indicating that we are operating in close proximity to ANY of these locations without specifically having to know we are close to one of them.  Example are hazard locations, abandoned mine shafts, sink holes, emergency assembly points etc. which are not always captured on maps.

 

Our thought was to have a custom POI database(s) containing the various locations with custom symbols and proximity alert ranges - hence my close following of this Geocaching thread.  Thanks for all your efforts, this was very helpful.

 

Until last week, my experience and results (setting up POIs and walking through them trying to generate alerts) were very similar to those described by Cheminer Will throughout the thread.  Last week, I setup a new POI database containing 10 POI locations around my neighborhood.  I was able to get the alerting function to work after a couple of test runs.

 

Bit of disclosure first:  I use a MAC computer and my GPSMAP 64S has V5.30 of the firmware loaded.  POI Loader version used to generate the .gpi file was 2.3.0.  I generated a GPX file containing the POI locations and the proximity ranges using Basecamp.  I have yet to try using a CSV file but will do that in the next day or so and report those results.

 

Here are the steps and parameters that I used and how I got it to finally work...

1. Generated a GPX file with the 10 POI locations using Basecamp each with a proximity range of 15m.   POI locations are all vary between 60 to about 200m apart
2. Created a POI directory which contained: Test_POI.gpx and Test_POI.bmp (custom POI symbol)
3. Ran the POI Loader (in Express Mode) on the POI directory and selected filename as GPX_MAC_2p3p0
4. GPX_MAC_2p3p0.gpi was confirmed to be present in the Garmin/POI directory on the 64s

 

Outside to run tests...
On the first test run, I simply walked the route between the POI symbols on the GPSMAP 64 display.  I was walking at normal walking speed - between 4-7km/hour.  At no point during this test, was a proximity alert generated.  I went back home frustrated.

 

Later that same day I had to go out in the car, and having recalled one of the posts by JohnCNA (indicating he was driving) and some posts by Hans (with images showing speeds of 50km/hr).  I took the GPS out (with the same POI file) and did the same route DRIVING in the car (15-30km/hr).  

Low and behold - ALERT after ALERT - each POI in turn alerted in the car. I was amazed that it worked - See attached image.

 

002.png.1747bb0fe155896aa135a9eaa6dc7430.png

 

Later that day, I again tried the route walking - slowly at first without any alerts being generated.  On my second loop around the POIs - I took off running about ~12 km/hr and again ALERT after ALERT.  Even after I slowed down to below 7km an hour the ALERTs still were being generated.

 

Sorry for the long story ... but based on what I saw with these tests - after many attempts walking around/through POIs on a map with no success with alerts, it appears that there may be some limitation as to a minimum speed required to get the alerts to trigger.

 

Again, while this gpi file was generated using a GPX file, I believe that the CSV version will likely work the same - I just haven't tested it yet.  I just wanted to let you know what I found so that you could see if this solves your problems with your 66 as well.  Try a simple route in your car and see if that works.  If so, take a gentle run over the same path and see if that works.  

 

Just for clarity when I say route - I don't mean a GARMIN route but just the path between the POI symbols on the display.  I didn't have any GARMIN route, steering or guidance between my position and any of the POI symbols while I was testing.  The POI symbols were simply displayed on the GPS display while I was walking, driving or jogging between them.

 

For my purposes (and likely yours as well), having some minimum speed to get the alerting to work is really not desirable/acceptable for situations were you are walking around (ie geocaching or searching for someone).  If further testing shows this common issue with minimum speed - we will need Garmin's help to fix.

 

Good luck with your testing.

  • Helpful 2

Share this post


Link to post

NAVG8OR,

 

Were all of your POI alerts near roadways? Have you tested any that are not near routable roads? Have you tested without routable maps enabled?

 

Thank You!

Share this post


Link to post

Atlas Cached,

 

 Good questions.  I checked the GPS unit and I have both routable and non-routable maps on the unit.  I believe, based on the current settings on the unit, I likely had a routable map enabled during the previous testing session.  All the POIs in that testcase were located near roadways.

 

 I will perform some additional testing this weekend in a wilderness area away from routable roads with testcases where either a routable or a non-routable map are enabled on the unit.  As well, I want to re-run my original testcase based on a CSV file instead of the GPX based file - to determine if the results differ.  

 

 Will report back with results.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 6

×
×
  • Create New...