Opened 11 years ago

Closed 10 years ago

#549 closed defect/bug (fixed)

"Friendly" latitude/longitude values

Reported by: mvglasow Owned by: Singesang
Priority: trivial Milestone: version 0.2.0
Component: osd/core Version: git master
Severity: Keywords:
Cc:

Description

In order to get current position displayed in OSD, the only way currently is by using position_coord_geo, which returns a NMEA-style string. It would be much nicer if there was an attribute returning the coordinates in a more pleasant way, similar what the internal GUI menu does with

<script>write(position_coord_geo)</script>

It would be preferable to have two attributes, one for latitude and one for longitude, in order to display them in separate rows.

Attachments (2)

friendly_coord.diff (5.3 KB) - added by mvglasow 11 years ago.
navit_3471_ticket_549_2.patch (6.3 KB) - added by mvglasow (2) 10 years ago.
Patch for friendly coordinates (fix the fix)

Download all attachments as: .zip

Change History (19)

comment:1 Changed 11 years ago by mvglasow

I'm now working on a patch for that. With this, it will be possible to specify a format for position_coord_geo to get values like the following:

position_coord_geo[pos_deg]: 45.4641° N 09.1916° E position_coord_geo[pos_degmin]: 45°27.8478' N 09°11.4960' E position_coord_geo[pos_degminsec]: 45°27'50.87" N 09°11'29.76" E

position_coord_geo[lat_deg]: 45.4641° N position_coord_geo[lat_degmin]: 45°27.8478' N position_coord_geo[lat_degminsec]: 45°27'50.87" N

position_coord_geo[lng_deg]: 09.1916° E position_coord_geo[lng_degmin]: 09°11.4960' E position_coord_geo[lng_degminsec]: 09°11'29.76" E

comment:2 Changed 11 years ago by mvglasow

*grmph* I put the line breaks there for a reason... here's it again, for better legibility:

position_coord_geo[pos_deg]: 45.4641° N 09.1916° E
position_coord_geo[pos_degmin]: 45°27.8478' N 09°11.4960' E
position_coord_geo[pos_degminsec]: 45°27'50.87" N 09°11'29.76" E

position_coord_geo[lat_deg]: 45.4641° N
position_coord_geo[lat_degmin]: 45°27.8478' N
position_coord_geo[lat_degminsec]: 45°27'50.87" N

position_coord_geo[lng_deg]: 09.1916° E
position_coord_geo[lng_degmin]: 09°11.4960' E
position_coord_geo[lng_degminsec]: 09°11'29.76" E 

comment:3 Changed 11 years ago by mvglasow

Patch attached; unfortunately I have no way to test it yet.

Changed 11 years ago by mvglasow

comment:4 Changed 11 years ago by mvglasow

Replaced patch - the previous one had a typo in it

comment:5 Changed 11 years ago by tiiiim

In the attached diff, I think the lines which include just DEGREES in osd core should be DEGREES_DECIMAL - the program will only compile when that change is made....

comment:6 Changed 11 years ago by mvglasow

tiiiim, you're probably right - I'm still struggling with cegcc (the C compiler of the binary dist only returns errors, and building includes some other pitfalls). I'm still hoping to resolve it soon and then I'll be able to test patches before submitting them.

comment:7 Changed 10 years ago by kazer

  • Milestone set to version 0.2.0

comment:8 Changed 10 years ago by akashihi

  • Resolution set to fixed
  • Status changed from new to closed

Applied in r3410

Thanks for patch!

comment:9 Changed 10 years ago by mvglasow (2)

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from enhancement/feature request to defect/bug

just had a quick look at it, there still seems to be a bug somewhere: position_coord_geo[pos_deg] gives 45°27'50.87" N 09°11'29.76" E, instead of 45.4641° N 09.1916° E. The output I am getting is what I expect for position_coord_geo[pos_degminsec]. I'll take a look at the code as soon as the SVN checkout is finished.

comment:10 Changed 10 years ago by mvglasow (2)

so far there's no obvious error in the code... there's a small typo in line 318: the comment still reads DEGREES when it should be DEGREES_DECIMAL, nothing critical but it should be fixed sometime to avoid confusion.

What I do see however is:

  • DEGREES_MINUTES_SECONDS is also used in the else part as a kind of fallback, in case an invalid format or none at all is specified
  • the lat_degmin format gives the same incorrect output (both latitude and longitude, in degrees/minutes/seconds)

I'll keep searching...

comment:11 Changed 10 years ago by mvglasow (2)

judging from the above, it seems that the whole format evaluation part never gets executed and Navit always falls back to the default of deg/min/sec; this may mean we're getting a null pointer for the format string... I'll need to look into where the code gets called.

comment:12 Changed 10 years ago by mvglasow (2)

now I'm kind of lost... the code that sets the format string which is passed to osd_text_format_attr is in the osd_text_prepare function (also in osd_core.c), lines 1160-1185 (SVN as of today).

Since the label is

${vehicle.position_coord_geo[lat_degmin]}

the expression

((oti->section == attr_vehicle
oti->section == attr_navit) && subkey)

should evaluate to true and oti->format should be set subsequently. This code is the same for all labels that refer to a member of the vehicle or navit sections; hence the format should work for all or none of these.

I do see, however, that the only uses of formats so far are for members of the navigation section, which are handled by the lines of code just before. However, the only difference I can make out is that navigation needs to do some processing twice in order to handle something like ${navigation.item[1].length[unit]}.

Any ideas why the format string for vehicle.position_coord_geo gets ignored?

comment:13 Changed 10 years ago by mvglasow (2)

I've finally capitulated and installed Linux on my laptop... and continued hunting down the error:

osd_text_format_attr definitely gets null pointer for oti_format, explaining why we always fall back to the default case.

Apparently osd_text_split does not parse vehicle.position_coord_geo[lat_degmin] correctly and returns NULL for the format part...

comment:14 Changed 10 years ago by mvglasow (2)

correction: osd_text_split is already called with the [lat_degmin] part missing in the argument, the error is not in osd_text_split but occurs at an earlier point.

comment:15 Changed 10 years ago by mvglasow (2)

Shame on me... the error was in my navit.xml, I was looking at the wrong element. It seems to work now, the only exception being [pos_degminsec], which causes the position to be displayed in decimal degrees. This may have to do with the particular coding (this format is caught by a generic else, while all the others are done through a string comparison); I'll look into it tonight.

comment:16 Changed 10 years ago by mvglasow (2)

I've straightened things out: seems it was unfortunate to define format names that are substrings of another name; as a result, the code would match "pos_degmin" to "pos_degminsec", resulting in the above behavior. All other format strings would get evaluated in a strict more-specific-first order and hence have no problem. This is fixed now; the patch was tested on WinCE with [pos_degminsec] (as the format which experienced the problem), no format (since handling of that case changed) and [pos_degmin] (as one of the unaffected formats, to test for regressions). All produced the expected output.

As a side-effect, I added some documentation to undocumented functions that I came across (those which I fully understood) and fixed another slight documentation error (DEGREES changed to DEGREES_DECIMAL).

Patch follows.

Changed 10 years ago by mvglasow (2)

Patch for friendly coordinates (fix the fix)

comment:17 Changed 10 years ago by akashihi

  • Resolution set to fixed
  • Status changed from reopened to closed

Applied in r3490

Note: See TracTickets for help on using tickets.