Jump to content
Sign in to follow this  
Followers 4
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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 4

×