Lat/lon fixer may mis-guess lat/lon bug

[GoogleCodeExporter]

The Lat/Lon fixer script uses only the swver attribute to determine which 
flavor of the lat/lon bug the file has.

However, the lat/lon bug happens on export and is therefore dependent on the 
export version. Files created with one version and exported with a later one 
may have a different flavor of the bug than indicated by the swver attribute.

Files that have the exportver attribute set (to 00.7.01 or higher) don't need 
fixing at all (currently the fixer would swap the already correct lat/lon, 
corrupting an already-intact file).

Files with swid=00.7.00 and no exportver are also easy to handle, as they will 
be affected by the 00.7.00 lat/lon bug (unless someone downgraded and exported 
00.7.00 data with a 00.6.0x version).

Files with swid=00.6.0x and no exportver are trickier, as they may have been 
exported either with 00.6.0 or 00.7.00 and thus have either flavor of the bug. 
That can be determined only by examining the file and the locations in it. If 
the distance between the two positions of a scan is very long, and swapping 
lat/lon in the second scan decreases it, this is a sign of the 00.7.00 bug.

An attempt at identifying such files is in my version of the DB loader script at
http://www.gitorious.org/openbmap/openbmap/source/e579c96eac30fcb78987ffa2c86c79
83c7f02f61:tools

I have taken a very crude approach to estimating distance, namely
approx_dist = sqrt(delta_lat^2 + delta_lon^2). This should work sufficiently 
well outside of polar regions.

Note that my version still has a bug, as I examine only the first scan in the 
file. If lat and lon are nearly equal (i.e. near a curved line going from 0°E 
on the equator to the North Pole), it may mis-guess the type of bug. A better 
approach would be to examine all scans and use only those where the difference 
between lat and lon is above a certain threshold. E.g. if the timestamps differ 
by one second, lat/lon should differ by at least 0.001 degrees, which is about 
100 m on a great circle.

Original issue reported on code.google.com by mich...@vonglasow.com on 11 Sep 2013 at 12:21

[GoogleCodeExporter]

Original comment by wish7code on 12 Sep 2013 at 1:33

• Changed state: Started

[GoogleCodeExporter]

Kudos to Michael! Thanks a lot man!

With r94f374781c16 your changes have been integrated. The script is a monster 
now, as things turned out to be more complicated: Unfortunately xml-etree (base 
for cell/wifi-db-builder) is not suitable for fixing the bug as it destroys the 
original file format when writing back. So I had to go the hard way and parse 
the files line-by-line.

The fixes also have been re-applied on server-side. While only a couple of cell 
files were reclassified, lot more of wifi files have been affected.

Original comment by wish7code on 12 Sep 2013 at 9:25

• Changed state: Fixed