Re: [Gpsbabel-code] Route simplification, anyone?

 Re: [Gpsbabel-code] Route simplification, anyone? From: Ron Parker - 2003-12-02 20:57:06 ```At 02:50 PM 12/2/2003 -0600, Robert Lipe wrote: >But I did have an algorithm squirrelled away that I'd intended >to use for this on a rainy day. Based on my limited understanding of >such things, it looks like you used the same formulae. Probably. There are basically two ways to do it, and my way eliminates points based on the height of the triangle formed by a point and its neighbors: the flatter the triangle, the more likely it is to be removed. (The other way does it based on the angle at the apex of the triangle; I could easily add an option to do it that way, too.) Note how nicely this depends on my having split off grtcirc.c not so long ago; I've been planning this for a while. >> Do let me know if there are any problems with this; > >Looking at the code, I see no problems with it. Was it intentional >that it work for both tracks and routes? Yes, though I haven't tested it with tracks. The only thing I did to make it work with tracks was include the test for track mode in the test for that one fatal error. ```

 [Gpsbabel-code] Route simplification, anyone? From: Ron Parker - 2003-12-02 20:03:28 ```You knew it was coming when you heard I bought a MeriPlat. You knew I couldn't help but put the routes from Street Atlas into the Plat, and you knew I'd run into that 50-point limit pretty quickly. And you knew I'd try to solve it. Admit it. You were counting on it. Well, I did. And I did. I've written a filter that removes points from a route, starting with the point that will affect the actual path of the route the least and progressively removing more and more important points until it reaches your goal. It can refine a 1688-point, 400-mile long Street Atlas route down to a 50-point 'arc' route and not deviate by more than 3/4 mile from the original route. You can try it by downloading http://parkrrrr.com/News/smplrout.zip and applying the diffs to your local Babel, and making appropriate changes to the Makefile of course. Do let me know if there are any problems with this; if I haven't heard anything, I'll commit it sometime soon. ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Robert Lipe - 2003-12-02 20:51:09 ```Ron Parker wrote: > quickly. And you knew I'd try to solve it. Admit > it. You were counting on it. Well, I won't pretend that I didn't know who the best man for the job was. :-) But I did have an algorithm squirrelled away that I'd intended to use for this on a rainy day. Based on my limited understanding of such things, it looks like you used the same formulae. > Do let me know if there are any problems with this; Looking at the code, I see no problems with it. Was it intentional that it work for both tracks and routes? > if I haven't heard anything, I'll commit it sometime > soon. Please hold off until I spin 1.2.1 - I have a set of last-minute changes pending to one format that blocked that from being a trivial release... Thanx! RJL ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Ron Parker - 2003-12-02 20:57:06 ```At 02:50 PM 12/2/2003 -0600, Robert Lipe wrote: >But I did have an algorithm squirrelled away that I'd intended >to use for this on a rainy day. Based on my limited understanding of >such things, it looks like you used the same formulae. Probably. There are basically two ways to do it, and my way eliminates points based on the height of the triangle formed by a point and its neighbors: the flatter the triangle, the more likely it is to be removed. (The other way does it based on the angle at the apex of the triangle; I could easily add an option to do it that way, too.) Note how nicely this depends on my having split off grtcirc.c not so long ago; I've been planning this for a while. >> Do let me know if there are any problems with this; > >Looking at the code, I see no problems with it. Was it intentional >that it work for both tracks and routes? Yes, though I haven't tested it with tracks. The only thing I did to make it work with tracks was include the test for track mode in the test for that one fatal error. ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Ron Parker - 2003-12-02 20:59:05 ```At 02:50 PM 12/2/2003 -0600, Robert Lipe wrote: >Please hold off until I spin 1.2.1 That and a nagging fear that it didn't quite fit into the filter schema were what kept me from committing it already. :) ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Alex Mottram - 2003-12-03 14:00:07 ``` >>Ron Parker wrote: >> > >>>> Why is it that mag_waypt_pr sanitizes shortnames but >>>> mag_route_trl does not? Shouldn't they match? > >> >>route_trl was written by Alex, who also has a Plat. >> >>It should definitely cleanse them or else "invalid" characters won't get >>filtered correctly. This is particularly bad on the 315 and earlier >>models. That sprintf at 1300 should be calling the cleanser. >> >>Wanna tackle that? > I think I'll let Alex tackle it this close to a release. Here's the patch for that. If no one else is sitting on a patch for magproto, I can commit it. One thing this doesn't fix is mkshort() on points with no description/notes. I think these are more likely in routes / tracks than anywhere else. ./gpsbabel -i gpx -f reference/route/route.gpx -o magellan -F foo dies a horrible segv death in mag_waypt_pr. Based on the current code, "-s" on a magproto route is going to kill it anyway based on the fact that the waypoints will write "OnLfToLv" as the point name and the route will reference a point named "GCFOO". (this is all starting to come back to me now). I'd try to roll a fix for mkshort()ing routes in magproto, but I don't know if mucking with the boilerplate magellan stuff is a good idea pending a release. And I think it'll slam into the unique-ing of shortnames, which may require even more mucking in places that probably don't want to be mucked with. ;) ... alex Index: magproto.c =================================================================== RCS file: /cvsroot/gpsbabel/gpsbabel/magproto.c,v retrieving revision 1.72 diff -p -u -r1.72 magproto.c --- magproto.c 29 Oct 2003 03:37:52 -0000 1.72 +++ magproto.c 3 Dec 2003 13:49:09 -0000 @@ -1269,7 +1269,7 @@ mag_route_trl(const route_head * rte) waypoint *waypointp; char obuff[256]; char buff1[64], buff2[64]; - char *pbuff; + char *pbuff, *owpt; const char * icon_token; int i, numlines, thisline; @@ -1297,7 +1297,12 @@ mag_route_trl(const route_head * rte) else pbuff = buff2; - sprintf(pbuff, "%s,%s", waypointp->shortname, icon_token); + owpt = waypointp->shortname; + owpt = mag_cleanse(owpt); + + sprintf(pbuff, "%s,%s", owpt, icon_token); + + xfree(owpt); if ((tmp == &rte->waypoint_list) || ((i % 2) == 0)) { thisline++; ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Robert Lipe - 2003-12-03 17:16:11 ```> Here's the patch for that. If no one else is sitting on a patch for At a blush, this looks OK. Please add it. > anywhere else. ./gpsbabel -i gpx -f reference/route/route.gpx -o magellan > -F foo > dies a horrible segv death in mag_waypt_pr. Odd. Doesn't for me. > Based on the current code, "-s" on a magproto route is going to kill it I consider that a "doctor, doctor" problem. > I think > it'll slam into the unique-ing of shortnames, which may require even more > mucking > in places that probably don't want to be mucked with. ;) Yes, let's not. It's a largish can of worms. Thanx, RJL ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Alex Mottram - 2003-12-03 18:46:45 ```>At a blush, this looks OK. Please add it. committed moments ago. > > anywhere else. ./gpsbabel -i gpx -f reference/route/route.gpx -o magellan > > -F foo > > dies a horrible segv death in mag_waypt_pr. > >Odd. Doesn't for me. Rats. I left the -s -r off the command line. Essentially it does this: Starting program: /home/alex/src/gpsbabel/./gpsbabel -s -r -i gpx -f reference/route/route.gpx -o magellan -F foo Breakpoint 1, mkshort (h=0x8086378, istring=0x0) at mkshort.c:235 235 char *ostring = xxstrdup(istring, file, line); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x400b168d in __strdup (s=0x0) at strdup.c:42 That's coming from the mkshort() call in map_waypt_pr. But like you said, that's a "fringe-ish" thing for a different day. :) ... alex ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Robert Lipe - 2003-12-03 20:37:13 ```> Starting program: /home/alex/src/gpsbabel/./gpsbabel -s -r -i gpx -f > reference/route/route.gpx -o magellan -F foo > > Breakpoint 1, mkshort (h=0x8086378, istring=0x0) at mkshort.c:235 > 235 char *ostring = xxstrdup(istring, file, line); > (gdb) n > > Program received signal SIGSEGV, Segmentation fault. > 0x400b168d in __strdup (s=0x0) at strdup.c:42 > > That's coming from the mkshort() call in map_waypt_pr. But like you > said, that's a "fringe-ish" thing for a different day. :) As Ron and I discussed last night, this is just the lid on this can of worms. Routes are often made of ordered waypoints and contain interiour references to them. If we run around renaming them willy-nill, we have to rename the interiour references, too, and we don't even try to do that. This is another reasons why arbitrary route/track conversion is Really Hard. As consideration, take a 50 point route with 8 character mixed case names from a Magellan and convert it to an Etrex 20 point route with 6 character fixed case names. Ron's new filter thingy helps, but the naming problem is substantial unless you basically throw them away and "force" the names to be something dumb and mechanical. It's icky. RJL ```
 Re: [Gpsbabel-code] Route simplification, anyone? From: Ron Parker - 2003-12-03 20:43:02 ```At 02:36 PM 12/3/2003 -0600, Robert Lipe wrote: >As consideration, take a 50 point route with 8 character mixed case >names from a Magellan and convert it to an Etrex 20 point route with >6 character fixed case names. Ron's new filter thingy helps, but the >naming problem is substantial unless you basically throw them away and >"force" the names to be something dumb and mechanical. The only problem there is the naming one. The filter does just throw away points; it never creates new ones, so the old names for the points that are kept would still be there. ```