new feature request: TomTom POI / per state [Implemented]

[mtrax]

I was just mulling over this one myself, when I thought perhaps GCA could do it better.

Could you produce a file for Tomtom or I guess Garmin devices a POI file for the whole state preferably with and without GC caches and for bonus points separated by cache-type (optional), as the data normally just has name & location I assume GC data should be allowed.
This way I could store all the states Geocaches without having to download via PQ .
ie I could see on Tomtom and then look up on my phone etc..
Assuming the generation of this data is not a drama the only real issue I see is the format of the data ie with the .OV2 file format.

To add some ideas to the mix, you could either have one file and prefix each with the cache type eg T-my cache name and then put the rest of the detail in the description eg GC code, D/T, Find/DNF log summary
NB I don't know if description is supporting in the file format , just POI name.

Anyway let us know what you think..

[caughtatwork]

We have GPSBabel running "under the hood" for various activities so I believe we should be in a position to generate a GPX file, pass it through GPSBabel to create the OV2 file and then hand that out to you.

With GPSBabel we could theoretically chance anything to anything. The reason we don't is I don't have the applicable devices to test against.

I am entirely uncertain about providing GC data, whether that just be a waypoint and co-ords. We've discussed this before for the .loc file concept.

So for the immediate deployment, let me play with a "my query" being available as output in .ov2 format. This might take a day or two depending on life requirements, but I'll keep you updated as I progress.

[mtrax]

that would be great as it could email the file too, thanks

[caughtatwork]

That would be the idea

[Zalgariath]

I use this GSAK Macro for my TomTom... even imports hints You still need the PQ's though obviously, but for one state that's not really a huge issue.

[mtrax]

I think its a huge issue to keep the whole state updated on a regular basis given it needs between 6-12 PQ for the data, doable but not quickly or simply.
Note I also use that GSAK macro.
note there is also some doco or assistance in the macro about the description format which might be useful eg using the telephone# to store more details on the cache.

[caughtatwork]

I think its a huge issue to keep the whole state updated on a regular basis given it needs between 6-12 PQ for the data, doable but not quickly or simply.
Note I also use that GSAK macro.
note there is also some doco or assistance in the macro about the description format which might be useful eg using the telephone# to store more details on the cache.

Please give me as much help and info as you can.
I didn't get anything done last night, suffering from an annoying illness.

[Zalgariath]

I think its a huge issue to keep the whole state updated on a regular basis given it needs between 6-12 PQ for the data, doable but not quickly or simply.

A great hint Lucy and Roo gave me was to set the PQ's organised day date placed to run once a week as you probably already do... but then and make sure in the PQ to tick the "updated in the last 7 days" button. This means any caches that have been dormant are excluded, and you will cut down the number of PQ's required per state by half or better

[mtrax]

I think its a huge issue to keep the whole state updated on a regular basis given it needs between 6-12 PQ for the data, doable but not quickly or simply.
Note I also use that GSAK macro.
note there is also some doco or assistance in the macro about the description format which might be useful eg using the telephone# to store more details on the cache.

Please give me as much help and info as you can.

sure, hope you get better quickly.

here is a extract from the macro help file:

One thing you may have noticed that the POI's that come pre-loaded on your TomTom may also display a phone number for each waypoint in the POI file. This field on your decice can also be written to and made to display data from within GSAK.

How this works is that when your TomTom reads the POI description data it looks to see if there is greater than symbol ' > ' in it and anything after this is treated as the data for the phone number field. In effect all you need to do is add a '>' into the description data and anything after that will be added to the phone number field on the TomTom.

One thing to watch though is that the TomTom appears to remove spaces from the text and depending on the device, it also changes the text size on the display depending on the length of the data submitted. The other 'feature' of this field is that the TomTom sometimes adds '-' at the end of each line to split it up.

As with other tags you will need to add the '>' to both the cache and child parts of the description. As an example you could use:

%Name %Code>%lat=M_%lon=M_D%dif/T%ter_Gr:%con1%Children %c_Name %name >%lat=M_%lon=M

To add in the Lattitude, Longitude, Difficulty, Terrain and the container type into the phone number part of the display.

@Zalgariath yes filtering out by updates can reduce the amount alot but there are alot of good caches which don't get found often ie after the initial rush of finders (locally) then may not get found for a few weeks.

[caughtatwork]

mtrax: You will have a PM in a few moments

[caughtatwork]

This function is coming along nicely at the moment.

Beta 1.0 worked well.
Refined requirements and Beta 1.1 is now executing for mtrax.

I'm still arguing with myself over whether we can include all caches (GCA and 3rd parties) as the name and co-ords aren't copyright, but that's a different discussion.

[caughtatwork]

http://forum.geocaching.com.au/viewtopi ... 90#p179290

[mtrax]

thanks
BTW what is the contentious data for GC caches?
ie what would need to be removed to give it the go-ahead?

[caughtatwork]

Data such as name, lat / lon, difficulty, terrain, etc is not copyrightable.

However, GC restrict access to the data on their site. i.e. You need to be a member to see all of that information, even if membership is free. They also go to lengths to fuzz the lat / lon on the Google Earth kml feed to ensure you can't get the lat / lon information without being a member.

It just seems wrong (not legally, but morally) to provide specific information from a website that goes to lengths to restrict it.

Yes, I know there are ways around that (and we leak a bit, by the way, but if you know, please don't document the how), but the intent of that site is to restrict the data and I feel morally uncomfortable in providing it willy nilly.

[Mr Router]

t (and we leak a bit, by the way, but if you know, please don't document the how).

i have known this secret for quiet awhile, i love it ! the secret is in safe hands but may i say thankyou