OSMTrack 2.1

In the recent time I have received a couple of automatically generated bug reports (the new bug reporting system does work!) And in parallel I have been working on some new features. As the time getting short at the moment I have decided to post a small update right now and not implement more features first.

Fixed:

• Fixed the OpenGL resource sharing bug. Actually I couldn't reproduce the issue, but I have found a bug that could cause the problem and fixed it. Let's hope the issue disappears.

Added:

• Filter to exclude outlier points. A handy thing if you don't like to wait at the beginning for GPS to achieve the needed accuracy.
  
  
  
  
  I made 4 presets for the filter that from my experience suite the mapping needs. Here are the values from right to left. The "best" setting allows only positioning accuracy 17 and 9 meters (iPhone delivers only discrete accuracy values and jumps between them) - which if you look on an aerial image would lie exactly on the street - indeed the best quality. The "normal" setting adds the 49 meters accuracy that is more or less acceptable for mapping purposes. This is what you typically get in a city due to GPS signal reflections, narrow streets, etc. If the GPS quality is extremely bad, you can switch down to "approximate" setting, which will also add 76 meters accuracy values, but be prepared to see only approximate geometry. For mapping purposes you really shouldn't go below these values, best of all not below the normal value, but if you don't care you can of course also switch the filter off.


• Database file is optimized after every delete operation. By default the database file doesn't change if you remove information from it. That means that it will indefinitely grow as you make more logs, and will not shrink even if you will delete them all. Somehow I always though that this may take long to optimize the database file. However, now I have made 2 different implementations for this feature: one asynchronous and one blocking. And it appears that blocking implementation also work fast enough. So I just go forward with a blocking version (the simpler the code the less is the probability that it has bugs).


• Testing the response from the OpenStreetMap server after a track upload to ensure the track upload was successful. In the previous version I have written that I test pretty much every operation that may fail. Well, there was one more operation, namely if by uploading a track the OpenStreetMap server returns some error description in HTML format. I haven't tested this before, now I do.

UPDATE: The OSMTrack 2.1 was approved and is available on the iPhone App Store.