Cachemate 3.2

[+Hi-Tek]

We have discovered a anomaly (bug?) with cachemate.

It's neither... it's doing that because it was designed to. If those coordinates are in the description as they appear in your post, and I'm assuming there are numbers in place of the *'s, then it looks like you should have filled in something before exporting the waypoint to the iQue mapping software. The main cache coordinates, which would show up in the coordinates field of an imported cache record, would never be formatted that way.

 

What the coordinate parser does is look for characters matching N/W/E/S (case insensitive) and groups of characters representing unsigned floating point numbers, and ignores everything else. Anything else it treats as whitespace delimiting those groups of numeric characters. It happens to accept what you entered because the syntax pattern of what it found, as far as its parsing is concerned, matches "hddd dd.ddd" (latitude and longitude each being a heading character, followed by 2 numbers).

 

The accepted coordinate syntax patterns are in the documentation and help text (for the nearest cache search, anyway). The actual parsing algorithm isn't, because in most cases it's a little more information than is needed.

I dont think I made it clear what the problem we had was. I had in fact removed the numbers as I thought it made the problem clearer - I've re-instated the numbers here.

 

This is the cache page (GCH0YK)

 

Chess themed Geocache No.6

 

We were 'paperless' using the iQues in the field.

 

On reading the description on the iQue (as produced by cachemate) the superscript 3's were missing (see below). We had found the clues that solved the (ii) & (iii)

 

Cachemate :

Your final target, the Cache, is located at:

N51° 52.(iii)(ii+C)(ii) / W00° 51.(iii)F(iii).

 

which should have read ....

 

From Web page:

Your final target, the Cache, is located at:

N51° 52.(iii³)(ii+C)(ii) / W00° 51.(iii³)F(iii³).

 

From the cachemate 'description' page we had no indication that the numbers (ii) & (iii) should be 'cubed' and hence we were way off the cache location.

 

It seems cachemate has ignored the superscript 3 which made a lot of difference distance wise to the cache final location.

[+Maeglin]

Ah, ok... well, I've got a pocket query set up with that cache in the center, so when it arrives I'll check it out myself and see what's going on. Thanks.

[+Hi-Tek]

Ah, ok... well, I've got a pocket query set up with that cache in the center, so when it arrives I'll check it out myself and see what's going on.  Thanks.

Thanks for looking into it.

[+Maeglin]

Thanks for looking into it.

Not a problem. Didn't take long to find either, thanks to the pocket query being rather quick to send (for once)... it's in CMConvert, not CacheMate. I've found and fixed the problem in the Unix version, and will be patching the Windows version later today. I should be able to get a patch release out before going to bed.

Edited December 22, 2003 by Maeglin

[+Hi-Tek]

Thanks for looking into it.

Not a problem. Didn't take long to find either, thanks to the pocket query being rather quick to send (for once)... it's in CMConvert, not CacheMate. I've found and fixed the problem in the Unix version, and will be patching the Windows version later today. I should be able to get a patch release out before going to bed.

Glad you found the quirk - thanks for such a speedy response (as always ).

[+Maeglin]

No sweat

 

CMConvert 1.61 is now on the site, with the fix for that problem of yours. Most of the work was in writing a UTF-8 decoder, which is apparently something the XML parser doesn't do for me.

[+JeremyA]

CMConvert 1.61 is now on the site, with the fix for that problem of yours.

CMConvert 1.61 is now in MacCMConvert too. Version 1.3.1 also has a couple of other new features from CMConvert in it.

 

JeremyA

[+robert]

Thanks for sending it to me, JeremyA. Haven't had a chance to try it out yet, though.

[+Learned Gerbil]

Well done - if only everyone supported their software this well!

[+Hi-Tek]

No sweat

 

CMConvert 1.61 is now on the site, with the fix for that problem of yours. Most of the work was in writing a UTF-8 decoder, which is apparently something the XML parser doesn't do for me.

Cheers - it works a treat. Fantastic support - many thanks.

[+paul.blitz]

I'd like to say is this program adds so much value to my iQue 3600 - thanks - your efforts are very much appreciated here in the UK.

When I got my iQue, and someone pointed me to Cachemate, it took less than 24 hrs to choose to register it! It's excellent value for the price.

 

Last week I bought a palm universal serial cable, cut off the d-type, added a pfranc plug, and can now send coords from my iQue to my eTrex.

 

As a result of all this, the amount of paper needed to print out the cache pages had dramatically reduced (amazingly close to zero printouts now!).... won't be long before the saved paper actually pays for cachemate!!!!!

 

I'm off to get the latest versions.... I dunno, I blink, and suddenly find ANOTHER version out......

 

Keep up the great work... and have a fun Xmas!

 

paul blitz

[+Maeglin]

A few things:

 

- Version 3.22 was just released and is now on the site. I replaced the waypoint projection formula with Vincenty's formula (what Garmin units seem to use)... the old one was an improvised thing that proved to be way off in certain situations.

 

- Both the Garmin and Magellan upload plugins have been updated to allow some selection of waypoint symbols. Apologies in advance for the scarcity of selections for Magellan units, but between the various models there didn't seem to be a lot in common in that department.

 

- Happy Holidays!

[+Learned Gerbil]

Thanks again for the updates - and especially the effort you have gone to to produce the symbol selection I asked for.

 

I appreciate the problems of handling symbols from various models, however, most of the options appear to give me the default symbol (crosshairs) which whilst better than the strange (and unrecognised) symbol the previous version of the plugin gave me, is not much use as I still have to change it to what I would like to see on my screen. The whole point of wanting this option was so caches would be easy to spot amongst the host of other waypoints on my device - most of whch are of course created with the default crosshairs symbol. Indeed, the old version of the plugin at least gave a strange symbol making new caches easy to identify so they could be edited.

 

My prefered symbol for caches is the Flag - but this is one of the options that gives me the unhelpful default crosshairs symbol.

 

For the record I am using a GPS 320 and a PalmIIIxe

 

BTW, another item for the wishlist occures to me - if I change the waypoint ID so that the cache appears on my GPSr with a more intelligable name, Cachemate then fails to merge and ends up duplicating the caches. I understand why it does this, but I wonder if there was some way of getting round it, mainly as the waypoint ID is easier to edit on the PDA than it is on the GPSr. Maybe on import it could check against caches with different Waypoint IDs but share name and coordinants say. Then it could either prompt for the user to choose whether to duplicate or merge, or allow the user to pre-configure this.

[+Learned Gerbil]

Somehow managed to duplicate a post.

Edited December 26, 2003 by Learned Gerbil

[+Maeglin]

Thanks again for the updates - and especially the effort you have gone to to produce the symbol selection I asked for.

It wasn't just you... others were asking for something similar

 

My prefered symbol for caches is the Flag - but this is one of the options that gives me the unhelpful default crosshairs symbol.

 

For the record I am using a GPS 320 and a PalmIIIxe

That's the problem, though. For most of the Magellan units, I can't find a symbol code for a flag. It was common enough, though, between the 5 lists (3 of them) to include it. Those lists are pretty specific, though, as far as models go.

 

BTW, another item for the wishlist occures to me - if I change the waypoint ID so that the cache appears on my GPSr with a more intelligable name, Cachemate then fails to merge and ends up duplicating the caches. I understand why it does this, but I wonder if there was some way of getting round it, mainly as the waypoint ID is easier to edit on the PDA than it is on the GPSr. Maybe on import it could check against caches with different Waypoint IDs but share name and coordinants say. Then it could either prompt for the user to choose whether to duplicate or merge, or allow the user to pre-configure this.

Would it work as well to make it merge based on coords instead of waypoint (as an option, of course)? That would certainly be easier, and it seems would accomplish the same goal. The only case would be if the coords had to be changed by the cache owner... in that case, you would end up with a dupe. The only problem with comparing coords is that it would make the merge process MUCH slower, because I'd have to parse them to get an accurate comparison.

[+Learned Gerbil]

Thanks again for the updates - and especially the effort you have gone to to produce the symbol selection I asked for.

It wasn't just you... others were asking for something similar

 

My prefered symbol for caches is the Flag - but this is one of the options that gives me the unhelpful default crosshairs symbol.

 

For the record I am using a GPS 320 and a PalmIIIxe

That's the problem, though. For most of the Magellan units, I can't find a symbol code for a flag. It was common enough, though, between the 5 lists (3 of them) to include it. Those lists are pretty specific, though, as far as models go.

 

BTW, another item for the wishlist occures to me - if I change the waypoint ID so that the cache appears on my GPSr with a more intelligable name, Cachemate then fails to merge and ends up duplicating the caches. I understand why it does this, but I wonder if there was some way of getting round it, mainly as the waypoint ID is easier to edit on the PDA than it is on the GPSr. Maybe on import it could check against caches with different Waypoint IDs but share name and coordinants say. Then it could either prompt for the user to choose whether to duplicate or merge, or allow the user to pre-configure this.

Would it work as well to make it merge based on coords instead of waypoint (as an option, of course)? That would certainly be easier, and it seems would accomplish the same goal. The only case would be if the coords had to be changed by the cache owner... in that case, you would end up with a dupe. The only problem with comparing coords is that it would make the merge process MUCH slower, because I'd have to parse them to get an accurate comparison.

The code for the flag is given as "k" in Magellan Waypoint Manager which is an application specific to 300 series Magellans. It may be the flag is called something else though - Diver down or something on my 320, but it is the only flag available.

 

I guessed that coordinates might cause trouble. Because coordinants might change, that was why I suggested a link between coordinants and the name of the cache - two out of three isn't bad. I can see this is not exactly straightforward.

[+JeremyA]

BTW, another item for the wishlist occures to me - if I change the waypoint ID so that the cache appears on my GPSr with a more intelligable name, Cachemate then fails to merge and ends up duplicating the caches.

I have a suggestion for a way round this which would avoid the extra import time that a more complex dupe search would create...

 

Why not just run your GPX file through GPSBabel before sending it to CacheMate? GPSBabel includes an option to replace the waypoint ID with a new short name based on the long name of the cache. If this works well then maybe something similar could be added to CMConvert.

 

Jeremy

[+Maeglin]

The code for the flag is given as "k" in Magellan Waypoint Manager which is an application specific to 300 series Magellans. It may be the flag is called something else though - Diver down or something on my 320, but it is the only flag available.

Thanks for the info. I've just uploaded version 1.11 of the Magellan plugin with the 300 series "diver down" symbol (k) mapped as "flag", and "major city" on most meridian/sportrak models (v) mapped as "filled circle".

[+GeckoGeek]

If this works well then maybe something similar could be added to CMConvert.

Or maybe the GPS export module.

[+Maeglin]

If this works well then maybe something similar could be added to CMConvert.

Or maybe the GPS export module.

The export plugins would be the best place, if the problem is needing different waypoint IDs only on the GPSr. If they're needed in both places (for example, for searching the list), then not so great. If I were to add an option to generate new waypoint IDs based on cache name in the plugins, then that takes care of both problems... you'd just use the "enter characters in list view" search feature in CacheMate to find a match. Those two bits of information and the coords are pretty much all that's currently passed to the plugins.

Edited December 26, 2003 by Maeglin

[+Hi-Tek]

No sweat

 

CMConvert 1.61 is now on the site, with the fix for that problem of yours.  Most of the work was in writing a UTF-8 decoder, which is apparently something the XML parser doesn't do for me.

It seems that CM 1.61 produces some spurious characters in the cache name which doesn't occur with the CM 1.6 version. Three examples are shown below (I've included waypoint numbers for info) ...

 

Waypoint GCG39N

Sandstorm’s Secret No3 – Twitcher’s Trail

should read ...

Sandstorm’s Secret No3 – Twitcher’s Trail

 

Waypoint GCG39PS

Sandstorm’s Secret No4 – Churchill’s Challenge

should read ...

Sandstorm’s Secret No4 – Churchill’s Challenge

 

Waypoint GCC5CB

Omallys’ Hat-Trick part 3: Water Meadow Wanderings

should read ...

Omallys’ Hat-Trick part 3: Water Meadow Wanderings

[+Learned Gerbil]

Thanks for further update - I will look at this later - I will also look at the GPSBabel suggestion.

[+Maeglin]

It seems that CM 1.61 produces some spurious characters in the cache name which doesn't occur with the CM 1.6 version. Three examples are shown below (I've included waypoint numbers for info) ...

They're not being produced by it... they're just not being filtered by it anymore. Those are Unicode characters encoded as UTF-8, which I didn't touch because I'm not really sure how to deal with them...

 

’ is Unicode 8217, which looks like '

– is Unicode 8212, which looks like -

 

The simplest thing to do would be to filter them out as I did before, and just deal with the high ASCII characters as far as actual conversion goes. Trying to take the Unicode characters and get them working properly in CacheMate itself I'm not so sure about, as I'm not sure what will be impacted by that (I'm using ASCII values 1 and 2 to delimit strings in some places).

[+Hi-Tek]

It seems that CM 1.61 produces some spurious characters in the cache name which doesn't occur with the CM 1.6 version. Three examples are shown below (I've included waypoint numbers for info) ...

They're not being produced by it... they're just not being filtered by it anymore. Those are Unicode characters encoded as UTF-8, which I didn't touch because I'm not really sure how to deal with them...

 

’ is Unicode 8217, which looks like '

– is Unicode 8212, which looks like -

 

The simplest thing to do would be to filter them out as I did before, and just deal with the high ASCII characters as far as actual conversion goes. Trying to take the Unicode characters and get them working properly in CacheMate itself I'm not so sure about, as I'm not sure what will be impacted by that (I'm using ASCII values 1 and 2 to delimit strings in some places).

If it comes down to a choice I'd prefer to stay with 1.61 purely for the fact it correctly displays 'squares' & 'cubes' in the cache descriptions page

[+Learned Gerbil]

Just to let you know I now see a very nice flag!

 

I just now need ot spendsome time on the GPSBabel suggestion.

[+Learned Gerbil]

Regretably, squares and cubes are much rarer than apostrophes etc. I see that it is important that clues are rendered proprerly, but a clue might depend on a character that is now being rendered improperly.

 

I hope a solution can be found.

[+Maeglin]

Regretably, squares and cubes are much rarer than apostrophes etc. I see that it is important that clues are rendered proprerly, but a clue might depend on a character that is now being rendered improperly.

More like:

 

earlier than 1.4 - High ASCII (including cubes/squares) and Unicode characters as UTF-8

 

1.4 (9/3) to 1.6 - High ASCII and Unicode characters not rendered at all

 

1.61 - High ASCII characters rendered properly, but Unicode characters as UTF-8

 

The characters that are in those titles are not normal apostrophes or dashes... they're Unicode characters that appear to look just like them. Leave it to character set designers to be redundant

 

There are 3 things I can think of to do:

 

1 - Translate Unicode characters into multi-byte as part of conversion, and hope it's portable enough in the GPL version of the converter and Palm OS can handle it correctly. There may also need to be a good bit of work in CacheMate itself to get it working reliably.

 

2 - Put a lookup table of redundant Unicode characters in the converter, to translate those into the closest ASCII characters, and dump those that can't be translated

 

3 - Clear out all Unicode characters

 

That's in order from most to least as far as work involved, information preserved, and least to most as far as likelihood of working. I'm currently debating between choices 2 and 3.

 

I could also leave it as is, since I might not be able to take care of all circumstances, but at least you'd know that something was there.

Edited December 26, 2003 by Maeglin

[+Learned Gerbil]

I am glad to hear that it isn't normal punctuation that is being caught.

 

As for leaving it as it is, I am a little concerned that the strings being produced are simply confusing to someone who has no idea what they are. A lookup table might be some use if it is possible to implement easily.

[+Maeglin]

As for leaving it as it is, I am a little concerned that the strings being produced are simply confusing to someone who has no idea what they are. A lookup table might be some use if it is possible to implement easily.

Agreed. After looking at the Unicode character tables, though, that lookup table might become pretty extensive if I want to cover all bases. The first character that someone complained about being missing in almost 4 months was a high ASCII character, though... those and Unicode characters were being filtered since version 1.4, and weren't being rendered correctly before that. Because of that, I'm halfway thinking of just filtering out Unicode characters. If something comes up in the future because those are missing, then I can start on some lookup table code and work on something to alert people to let me know if the converter runs into a character that it can't remap. In the meantime, at least there won't be any confusing characters like what Motley Crew noted.

 

Sound like a plan?

[+GeckoGeek]

The export plugins would be the best place, if the problem is needing different waypoint IDs only on the GPSr. If they're needed in both places (for example, for searching the list), then not so great.

True. No doubt one would want the GPS's waypoint name to match something in CacheMate so you could lookup the cache in CacheMate when it showed up on the GPS.

[+Learned Gerbil]

Sound like a plan?

Yes. It seems to me that the important thing is that almost all caches should render correctly. I nthe few cases they don't there should be some indication of what is going on, even if not immediatly resolvable i nthe field by the user.

[+Learned Gerbil]

True. No doubt one would want the GPS's waypoint name to match something in CacheMate so you could lookup the cache in CacheMate when it showed up on the GPS.

I have had a thought about the edited ID issue -

 

How about there being a fixed GC.com waypoint used as a unique ID that is seperate from (but by default used to generate) the current Waypoint ID field?

 

I realise that means an extra (uneditable) field and and an extra step on importing, but hopefully this would not take as long as comparing multiple fields as merging would still be based on the original GC.com waypoint ID whatever the use does.

[+Maeglin]

How about there being a fixed GC.com waypoint used as a unique ID that is seperate from (but by default used to generate) the current Waypoint ID field?

I can put that down as a maybe... at this point, though, not sure.

[+Maeglin]

Version 1.62 of CMConvert is on the site now, which should handle Unicode characters more cleanly, but still render high ASCII characters correctly. I'll keep looking into the best way to do the Unicode characters and that'll be happening in a future release. In the meantime, at least, you won't see the UTF-8 encoding of those things

[+Hi-Tek]

Version 1.62 of CMConvert is on the site now, which should handle Unicode characters more cleanly, but still render high ASCII characters correctly. I'll keep looking into the best way to do the Unicode characters and that'll be happening in a future release. In the meantime, at least, you won't see the UTF-8 encoding of those things

Thanks - 1.62 has cleared the problem.

[+Maeglin]

I've just uploaded version 1.63 of CMConvert. It adds a lookup table for the redundant characters in the Unicode character sets, mapping those to the corresponding high ASCII characters (all of which seem to be in the Palm OS built-in fonts). There are 25 of those, including the 2 that Motley Crew pointed out, and several that I found in entries for caches here in North Carolina.

 

In the Windows version, I've also updated the Expat DLL to version 1.95.7.

[+Maeglin]

I'm looking at the list of pending feature requests again, to see what I need to do in the next version, and coming back to the one for some kind of list coloration/highlighting in the main list view based on information in the record. That one needs some hashing out, I think. At first glance, seems like one way to go with be to have 3 color settings, with the first match in the list taking priority over the ones after it:

• Bookmarked
  
• Found
  
• Normal (neither bookmarked nor found)
  

The default would be no color set for the first two, and black for the 3rd one, to replicate what it's doing now. As far as highlighting on monochrome, there's only so many ways to do that and changing the list font could cause some confusion there, so I'm thinking about making this just affect color devices.

 

How does that sound?

[+Learned Gerbil]

Sounds fine for this non-colour user.

[+GeckoGeek]

Actually, I'd make "Found" be less emphasized then "normal". I'd think in most cases one would rather ignore "found". So it would be something like:

 

Bookmarked: Highlighted

Normal: Normal

Found: De-highlighted/gray etc.

 

In terms of the decision tree, bookmarked would take precedence over normal/found. Found would take precedence over normal.

 

How many options do you have for monochrome? If you have any at all, I'd like to see use mono users get something. One advice that comes up frequently is that you want to use a cheap Palm for caching since it's rather fragile and not up to getting wet or dropped.

[+Maeglin]

In terms of the decision tree, bookmarked would take precedence over normal/found.  Found would take precedence over normal.

Exactly how I had it In terms of visual representation, you'd have the option to have found caches stand out less than normal (not found) ones. The default would be to have it display as it already does, though, and you can configure it from there.

 

How many options do you have for monochrome?  If you have any at all, I'd like to see use mono users get something.  One advice that comes up frequently is that you want to use a cheap Palm for caching since it's rather fragile and not up to getting wet or dropped.

Actually, the only real highlight I can think of is to change the font to bold or something, but that wouldn't work depending on your default list font. It would also be a horror story to try and do free font selection, and deal with lines that aren't all the same height.

 

One thing I can think of is to do something similar to the travel bugs indicator, which would tack a "(" on the end of the line for bookmarked records, and "(F)" for found ones.

[+Learned Gerbil]

As far as I know there are three types of palms - colour, greyscale and mono.

 

Monos must be rare as my IIIxe which is a bit of a dinosaur supports greyscale (4 bit I think).

 

I would rather not see greys though as it makes greater demands on power and I would rather just filter out found caches when I am hunting.

[+Maeglin]

In the past, I usually leave the display at its default setting (mono, grey, color), no matter what it's actually capable of. That, plus I've never done anything with greyscale modes anyway, aside from creating icons that handle them.

[+GeckoGeek]

One thing I can think of is to do something similar to the travel bugs indicator, which would tack a "(" on the end of the line for bookmarked records, and "(F)" for found ones.

That's close to what I was thinking of. Maybe using a space just in front of the name for some kind of "status" mark. Use a "|" for found, "-" for bookmarked and "+" for both. While using punctuation might be less intuitive, it takes less screen space because you don't have to have a separating space between the name and the status mark.

 

Also, I like the idea of being at the front of the line as it helps you to visually filter. Placing it at the back of the line forces you to scan each line unless you right-justified the mark.

[+Maeglin]

The beginning of the line works, too It would also be pretty easy to line up columns that way as well, so that the status mark would be there, then the next "column" (a couple pixels over) would start the rest of the line. The idea of using punctuation marks is nice, but possibly less confusing (and just as doable) might be to use "-", "+" and "±" for bookmarked, found and both.

[+GeckoGeek]

The idea of using punctuation marks is nice, but possibly less confusing (and just as doable) might be to use "-", "+" and "±" for bookmarked, found and both.

Better yet!

[+Amazon Annie]

I just downloaded a new gpx file and used the new cmconvert and the squiggles I had previously are now nice quotation marks.

 

I just want to applaud Maeglin for all your hard work on this wonderful piece of software. I look foward to the next set of changes (I'm running a Sony Clie with colour)

 

Best $9.74 (Canuck Bucks) I've spent for software for my palm! Thanks Maeglin!!

[+Maeglin]

CMConvert 1.7 is now on the site. Anyone who's having problems with the latest versions crashing in some instances, this may fix your problem... something I didn't count on with the XML parser library, when the XML version tag is in the input file, but without an encoding name.

 

This one also adds some features. You can now access zipped GPX files directly, without having to unzip them first (the first GPX file in a ZIP file is read, and any other files ignored). The Windows version also now supports file drag/drop onto the CMConvert window, and also opening a file specified on the command line (meaning that you can drag and drop a file onto the CMConvert icon to launch it and open that file).

[+GeckoGeek]

Wish List:

 

1) A way to archive the database so that when I travel I can unload the current data to save memory space and then later restore it exactly. I see the memopad export, but I'm not sure as it will do the job. This may be doable just by playing in the backend with the Palm desktop, I'm not sure.

 

2) A way to export to GPX format on the desktop. Given the editing capability with CacheMate, I need a way to share my edited database with other things.

 

3) A connector to a mapping program. The GPX export would help with desktop mapping. After loading up USAPhotoMap I can see that seeing my points on a map is the way to go. I haven't yet tried it, but I plan to try Mapopolis on my Palm, so if there's any way to support a connection that, that would be on my list as well.

[+SBPhishy]

I would also like to add how impressed i am with the amount of support Maeglin gives to cachemate. I just started using cachemate on an ancient Palm III, and it works great. It has been a huge luxury to not have to sit and print cache pages.

 

Thanks again!

[+Maeglin]

1) A way to archive the database so that when I travel I can unload the current data to save memory space and then later restore it exactly.  I see the memopad export, but I'm not sure as it will do the job.  This may be doable just by playing in the backend with the Palm desktop, I'm not sure.

This can be done now, but it's a manual process... not sure how much I can improve on it, either. Basically, just copy the Items-cMat.PDB file from the backup directory and delete all of the items from the handheld database. To restore everything, just install that PDB file (as you would any other) and Hotsync.

 

2) A way to export to GPX format on the desktop.  Given the editing capability with CacheMate, I need a way to share my edited database with other things.

Nice idea... could do that with an external program that takes that Items-cMat backup file and generates a GPX file based on the contained info. Should be able to get most, but not all, information that was in the original GPX (sort of like decompiling a program after compiling it.. what you get will never match the original source). No idea offhand when I'll be able to get to that, though.

 

3) A connector to a mapping program.  The GPX export would help with desktop mapping.  After loading up USAPhotoMap I can see that seeing my points on a map is the way to go.  I haven't yet tried it, but I plan to try Mapopolis on my Palm, so if there's any way to support a connection that, that would be on my list as well.

Yeah, the GPX export could help with the PC-side mapping connections. As far as mapping on the PDA, that depends on the makers of mapping software supporting external programs feeding coordinates to them. In the case of Mapopolis, if they supported that, I'd already have a plugin to work with it. According to the docs for their external program interface, they might have supported that in the future, but when I asked them they said that they had no plans for it. Just how many faces are we wearing today?

 

If you know of any PDA mapping software that does support lat/lon input from another program on the PDA, please let me know so I can add support for it. I think GeoNiche has a mapping side to it, and I'm already looking at doing a plugin for that.