Thanx.   Applied.   When I wrote this in '06, I apparently forgot that alt_unknown was a negative value.

I also removed that annoying embedded version in setup.iss.in.

RJL

On Sat, Oct 16, 2010 at 10:03 AM, Steve Trabert <tsteven4@qwestoffice.net> wrote:
Here is an replacement to altsignpatch.txt.  the code fixes are the same but this adds a testcase to improve the test coverage.  Files that need to be added are also included as attachments.  The new testcase is in death valley so we have elevations above and below 0.  test coverage is improved but still incomplete.

once again gui/setup.iss is unintentionally included in the patch.

Steve

On 10/15/10 10:20 PM, Steve Trabert wrote:
It turns out the sign thing ran deeper than expected.  Here is the sign patch.  I only found one module, stmsdf.c, that got the min and max altitudes correct.  Also of note only the kml test cases caught any changes.

The trivial feature patch is not included, but I will send it later (and after the sign patch is resolved so I can start from that base).

Once again setup.iss is in the patch file unintentionally due to keyword lines.

Best,
Steve

On 10/15/10 6:52 PM, Robert Lipe wrote:
This is so straight-forward that a single patch is fine.

It's almost certainly a case the max/mins never getting changed from their initial ridiculous values because we had no altitudes to add to the bounding set.

Thanx,
RJL

On Fri, Oct 15, 2010 at 6:43 PM, Steve Trabert <tsteven4@qwestoffice.net> wrote:
Robert,

I have a patch that does not switch m to km or ft to miles for kml altitudes.  I left depth alone.  However, I believe I have found an existing bug revealed in one of the test cases.  The minimum altitude was reported previously as  621371.192 mi for segmented_tracks-track.kml and segmented_tracks.kml.  It is now reported as 3280839896.719 ft.  But all the elevations tags in the input gpx file segmented_tracks.gpx are 0.000000.  So it appears there was and is a bug in finding the minimum altitude.  I can look into this.  Would your prefer one feature patch and one bug patch, or everything at once?

Steve


On 10/13/10 5:16 AM, Steve Trabert wrote:
Robert,

I agree.  General usage seems to require different conversions for horizontal and vertical distances.  One of the changes I was merging from my personal modifications was the addition of a format_altitude function.  I'll send in a patch for review. 

Steve

On 10/12/10 7:29 PM, Robert Lipe wrote:


On Tue, Oct 12, 2010 at 4:21 PM, Steve Trabert <tsteven4@qwestoffice.net> wrote:
Matt,

I have noticed that the kml writer likes to switch units of elevation from feet to miles (at 5280 ft) or m to km (at 1000m).  This comes from fmt_distance() in units.c.  When I think of a mountain I think of the elevation in feet or meters irrespective of the magnitude of the elevation, but I cannot find any standard for this preference.  In aviation do you think of altitudes in feet or meters irrespective of the magnitude?  If I could find some justification for my preference I would submit a patch.

Right now, the same code is used for linear distance, whether that's horizontal motion or altitude.  Between this and the previous request perhaps it makes sense to provide different functions or at least an additional argument that allowed changes like this and the original one in the thread to be implemented.

RJL


 

Steve


On 10/11/10 10:13 AM, Matt Cunningham wrote:

Hello GPSBabel-ers

I hope this is the correct way to ask for a feature request.  During the conversion of files to the KML format, it is possible to choose the units;  s=statute, m=metric, n=nautical.  Is it easy to create a fourth set, e.g. a=aviation?

I only found GPSBabel today and so far it meets all of my needs.  But the unit set could be slightly better.  Nautical is the best option for aviation, but the altitude is also given in nautical miles.  If this could be changed to feet, that would be fantastic and perfect for aviation-based users!  (knots for speed, nautical miles for distance, feet for altitude)

Best regards

Matt

------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb
_______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@lists.sourceforge.net To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gpsbabel-misc@lists.sourceforge.net
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc



------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
Gpsbabel-code@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code