Thread: [Gpsbabel-code] Bensman Issue?
Brought to you by:
robertl
From: Clyde E. <cw...@ii...> - 2004-02-23 06:14:32
|
>(Clyde, since you're building "fixed" versions of the file that you're >handing GPSBabel, we've had a user request to "fix" the <URL> that gets >passed to us so an export to a file format with a URL link goes to the >local hard drive. Let's talk about the 'Bensman' issue on the -code >list if that doesn't make sense.) Correct. It makes no sense to me. Please explain. |
From: Robert L. <rob...@us...> - 2004-02-23 06:39:08
|
> >handing GPSBabel, we've had a user request to "fix" the <URL> that gets > >passed to us so an export to a file format with a URL link goes to the > >local hard drive. Let's talk about the 'Bensman' issue on the -code > >list if that doesn't make sense.) > > Correct. It makes no sense to me. Please explain. Thanx for the follow-up. I asked this be moved here becuase we have a couple of programs with the same issue - you were just hte one with the user that explained it most clearly. :-) This originally started as a feature request in GPSBabel, but after cross-examining him, I think this belongs up in GSAK (and spinner and similar). Let's talk it through and see if you agree. In short, by my understanding, you're taking a GPX file with <url> tags and creating an HTML image of the cache page on the local filestore, but leaving the <url> pointing to the "real" page. For a disconnected user (think geocacher with laptop in the car) the link in the file that he just pulled into S&T, Ozi, or SAPlus now goes to the "wrong" place - he want it to go to file://d:\mycaches\GC1234.html instead of http:/geocaching.com/whatever.asp?guid=forsaken-id-number-to-identify- uvery-molecule-in-the-universe. I could do a lot of hand-waving (pathname conventions, directory names, case conversions, suffixes, etc.) and synthesize the URL tag, but it occurs to me that you're rewriting this data _anyway_ and you already have these these things. Does it make sense to write the output to include the <url> tag to reference the local copy and perhaps add an additional <a href> to point to the site on gc.com when you write the HTML? This way we'd require no special casing in GPSBabel to teach it geocaching or GSAK name conventions. His argument 'my cache pages are always in c:\mystuff and the cache name is always upper case and they're always ".htm" seemed sound to him, but just won't work in a general case program like GPSBabel. This really makes the most sense when you think about map programs that include the ability to click on a marker to bring up a cache page - you probably want it to bring up the local copy by default and if there happens to be a linky link to the master site in that page, great. In my own little geocaching page maker thingy, it's done as Javascript so that Plucker won't convert it... $ more 100155.html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Dragon Micro #2</title> </head> <body> <script type="text/javascript"> <!-- document.write('<a href="http://www.geocaching.com/seek/cache_details.aspx?ID=10 0155&decrypt=y">Page on Geocaching.com<\/a><br>') Does that help you understand what this user was wanting and why I think it's better done upstream from GPSBabel? Do you agree with that line of reasoning? Thanx! RJL |
From: Clyde E. <cw...@ii...> - 2004-02-23 07:18:17
|
Ok, now that makes sense ;-) Thanks for the very lucid explanation - I wish some of my users were as= clear! You are 100% correct, this should be done in GSAK and not GPSBabel. Not all= users will have generated the local file store with the offline HTML pages= (this is an optional feature), but I can at least provide an option in= GSAK to ask the question or allow for this. What I will need to do is find out which mapping products (that GSAK= currently supports) that allow this URL linking so I can make the= corresponding changes. Cheers Clyde *********** REPLY SEPARATOR *********** On 23/02/2004 at 12:31 AM Robert Lipe wrote: >> >handing GPSBabel, we've had a user request to "fix" the <URL> that gets >> >passed to us so an export to a file format with a URL link goes to the >> >local hard drive. Let's talk about the 'Bensman' issue on the -code >> >list if that doesn't make sense.) >> >> Correct. It makes no sense to me. Please explain. > >Thanx for the follow-up. I asked this be moved here becuase we have a >couple of programs with the same issue - you were just hte one with the >user that explained it most clearly. :-) > >This originally started as a feature request in GPSBabel, but after >cross-examining him, I think this belongs up in GSAK (and spinner and >similar). Let's talk it through and see if you agree. > >In short, by my understanding, you're taking a GPX file with <url> tags >and creating an HTML image of the cache page on the local filestore, >but leaving the <url> pointing to the "real" page. For a disconnected >user (think geocacher with laptop in the car) the link in the file >that he just pulled into S&T, Ozi, or SAPlus now goes to the "wrong" >place - he want it to go to file://d:\mycaches\GC1234.html instead of >http:/geocaching.com/whatever.asp?guid=3Dforsaken-id-number-to-identify- >uvery-molecule-in-the-universe. > >I could do a lot of hand-waving (pathname conventions, directory names, >case conversions, suffixes, etc.) and synthesize the URL tag, but it >occurs to me that you're rewriting this data _anyway_ and you already >have these these things. Does it make sense to write the output to >include the <url> tag to reference the local copy and perhaps add an >additional <a href> to point to the site on gc.com when you write the >HTML? This way we'd require no special casing in GPSBabel to teach it >geocaching or GSAK name conventions. His argument 'my cache pages are >always in c:\mystuff and the cache name is always upper case and they're >always ".htm" seemed sound to him, but just won't work in a general case >program like GPSBabel. > >This really makes the most sense when you think about map programs that >include the ability to click on a marker to bring up a cache page - you >probably want it to bring up the local copy by default and if there >happens to be a linky link to the master site in that page, great. > >In my own little geocaching page maker thingy, it's done as Javascript >so that Plucker won't convert it... > >$ more 100155.html ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> ><html> ><head> ><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"> > <title>Dragon Micro #2</title> ></head> ><body> ><script type=3D"text/javascript"> ><!-- >document.write('<a >href=3D"http://www.geocaching.com/seek/cache_details.aspx?ID=3D10 >0155&decrypt=3Dy">Page on Geocaching.com<\/a><br>') > > >Does that help you understand what this user was wanting and why I think >it's better done upstream from GPSBabel? Do you agree with that line of >reasoning? > >Thanx! >RJL |
From: Robert L. <rob...@us...> - 2004-02-23 07:35:27
|
"Clyde England" <cw...@ii...> wrote: > Ok, now that makes sense ;-) > > Thanks for the very lucid explanation - I wish some of my users were > as clear! Trust me that it wasn't that clear originally. I thought about this off and on for most of a day before I realized that I solved this about two years ago in this exact way ('fixing' it upstream) and then concluded this should be your problem. :-) > all users will have generated the local file store with the offline > HTML pages (this is an optional feature), but I can at least provide > an option in GSAK to ask the question or allow for this. You probably want to tie that to the data you hand to GPSBabel down that pipe more than the HTML itself, but it sounds like you're hot on the case. > What I will need to do is find out which mapping products (that GSAK > currently supports) that allow this URL linking so I can make the > corresponding changes. Actually, if you just pass the "fixed" URL in the data you pass to GPSBabel (assuming you use GPSBabel for all your file I/O) , it comes out almost clean - and you don't have to maintain an external list at all, right? The only thing that change doesn't get you is a link on the HTML you generate to the "real" page. What I do in my GPX reader is generate a GPX file (that I later pass to GPSBabel) that contains only the things required to make it validate and that I know GPSBabel will use later: ... <wpt lat="36.135633" lon="-86.596000"> <time>2003-11-05T00:00:00</time> <name>GCH55Q</name> <desc><![CDATA[Two Grand For Tennessee]]></desc> <url>100310.html</url> <groundspeak:cache xmlns:groundspeak="http://www.groundspeak.com/cache/1/0"> <groundspeak:type>Traditional cache</groundspeak:type> <groundspeak:container>Regular</groundspeak:container> <groundspeak:difficulty>1.5</groundspeak:difficulty> <groundspeak:terrain>1.5</groundspeak:terrain> </groundspeak:cache> </wpt> ... When I invoke GPSBabel later, I use the "urlbase" option to fix up the pathnames This is probably wrong for your model - you'll know the full pathname and the namespace conventions so you'll just want to fix the tag to be be <url>file://d:/whereever/you/put/it/GCH55Q.html</url> or whatever... Re-generating the (minimal) GPX gives you a chance to apply ignore lists, filters, corrections, URL fixups, and such. If you've never used one of the mapping programs that lets you bring up a cache page by clicking on it, try it out. I use S&T for this and for trip planning, it's very sweet. RJL |