Thread: Re: [Gpsbabel-misc] Waypoint names in comments
Brought to you by:
robertl
From: Robert L. <rob...@us...> - 2006-09-15 20:24:47
|
> What about a templating engine that understood a few basic tags like %n= = > for name. > = > If I did it would it be committed? I won't blanket pre-approve it, of course, but I'm interested in the idea= =2E Would it be a filter? = How do you express the tags to GPSBabel? Would it be done in a way similar to the CET layer? Would it be good or bad if we used tags that wre compatible with GSAK when possible? http://gsak.net/help/hs10300.htm Are tags for names enough or do we REALLY want fullscale programmatic manipulation of the waypoints? (Maybe I want to set icons conditionally.= Now we're back in the land of embredding languages...) |
From: Robert L. <rob...@us...> - 2006-09-15 21:02:23
|
> > I won't blanket pre-approve it, of course, but I'm interested in the idea. > = > I wouldn't expect you would :D I know you know that. I just didn't want to set precedent for other budd= ing contributors. = > A filter is probably the most complete way to do it, supporting changin= g a = > limited number of options. Of course this all depends on what we store= in = > the structs for Geocaches. I agree. That interacts badly with the various GUIs, but I'm not sure th= at's a deal-breaker. We don't have trivial access to all the information contained in a PQ and= I'm not sure we should. GSAK, for example, can specialize in such things bec= uase the "G" in its name is for "Geocaching". (The "G" in "GPSBabel" is somet= hing else...) Things like diff and terr are easy - and are already in struct = waypt but I'm not sure we want to get into things like "last four logs" and suc= h. > I would think it would be good - they should be relatively easy to pars= e. = I should probably ask Clyde if he'd mind. = |
From: Jason S. <rai...@ta...> - 2006-09-15 21:08:46
|
On Fri, 15 Sep 2006, Robert Lipe wrote: >>> I won't blanket pre-approve it, of course, but I'm interested in the idea. >> >> I wouldn't expect you would :D > > I know you know that. I just didn't want to set precedent for other budding > contributors. Understood - it was more of a "I've already done the pain on my end to deal with my specific case, so before I spend time making a more general solution wanted to know if it was worth it" thing.. >> A filter is probably the most complete way to do it, supporting changing a >> limited number of options. Of course this all depends on what we store in >> the structs for Geocaches. > > I agree. That interacts badly with the various GUIs, but I'm not sure that's > a deal-breaker. Only in the sense that they won't be able to create pretty GUI's for it in a progmatic way since it will require inputing the templeted string. > We don't have trivial access to all the information contained in a PQ and I'm > not sure we should. GSAK, for example, can specialize in such things becuase > the "G" in its name is for "Geocaching". (The "G" in "GPSBabel" is something > else...) Things like diff and terr are easy - and are already in struct waypt > but I'm not sure we want to get into things like "last four logs" and such. Hrm. What I need is a way for my filter to tell the reader it's interested in extra elements. How gross does that sound? "Hey Mr GPX reader - could you kindly grab the groundspeak:name tag for me since I need it for my templating engine" Jason -- Jason Slagle /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . |
From: Robert L. <rob...@us...> - 2006-09-15 21:20:40
|
(Moved to -code) > > We don't have trivial access to all the information contained in a PQ= > = > Hrm. What I need is a way for my filter to tell the reader it's = > interested in extra elements. How gross does that sound? "Hey Mr GPX = > reader - could you kindly grab the groundspeak:name tag for me since I = > need it for my templating engine" See, this is where you make me publicly confess my "GPSBabel isn't really= a geocaching-specific program" is a bit of a ruse. Struct waypt has a stru= cture in it called 'geocache_data' that is populated with the interesting stuff= from a Grounsdspeak PQ by the GPX reader. Things that are NEEDED (OK, wanted= ) by other modules are grabbed by the GPX reader on the way in. There is a way that you can actually reach into the XML tree and slurp ou= t things we didn't catch on the way in. See 'text.c' for an example of how= that can be done. It's not very fast and this is one of the reasons why our = XML reader consumes buckets of memory when you start tossing a couple hundred= thousand waypoints around from a GPX file. :-) I think most of the interest things that you'd want to use for tags are already in geocache_data. Of course, I'm going to tained in that becuase= they're the things *I* was interested in and/or needed for formats like t= he Explorist .gs writer. |
From: Alan <al...@al...> - 2006-09-15 21:47:28
|
Using XCSV style sheets, I'm attempting to concatenate two OFIELDS together using the no_delim_before option. Is this how it's specified? I haven't had any success and I haven't seen any examples either. Thanks, Alan [snippet of OFIELDS] OFIELD DESCRIPTION, "", "%s" OFIELD SHORTNAME, "", "%s","no_delim_before" |
From: Jason S. <rai...@ta...> - 2006-09-15 20:30:57
|
On Fri, 15 Sep 2006, Robert Lipe wrote: > >> What about a templating engine that understood a few basic tags like %n >> for name. >> >> If I did it would it be committed? > > I won't blanket pre-approve it, of course, but I'm interested in the idea. I wouldn't expect you would :D > Would it be a filter? A filter is probably the most complete way to do it, supporting changing a limited number of options. Of course this all depends on what we store in the structs for Geocaches. > How do you express the tags to GPSBabel? > > Would it be good or bad if we used tags that wre compatible with GSAK > when possible? http://gsak.net/help/hs10300.htm I would think it would be good - they should be relatively easy to parse. Let me try to write a simple parser and then fit it into a filter. I'm looking for a small programming project to play with anyways. > Are tags for names enough or do we REALLY want fullscale programmatic > manipulation of the waypoints? (Maybe I want to set icons conditionally. Now > we're back in the land of embredding languages...) This is a start at least - something that could be built on by others. Ubercool would be the ability to make things like filters modules that could be loaded so it'd be easy to distribute certain filters as seperate modules, but thats a much worse can of worms :P Jason -- Jason Slagle /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . |