OSMTrack 2.5

In the recent time it happens that the development advances faster than I thought. And now I'm happy to present you yet another update. The application IMHO looks much more polished compared to the 2.0 and 2.1 versions. The only issue from the 2.0 which was not improved is the waypoint support, all other parts of the application have had some progress. Here are the improvements in detail:

• Display points from all tracks in the vicinity. Basically, now you can see all track points you have logged previously and which are still on your iPhone. This is not exactly the same as having a complete map, but at least you can see whether you have already taken a certain path or not.





• Current scale and current GPS accuracy value label. Finally I managed to implement writing text on OpenGL window (which appeared to be not too difficult at all - just re-using some example code, though removed due to different reasons from the current version of the documentation). Having the current scale value together with previous tracks on the screen is very practical indeed.
  
  
  
  


• Asynchronous deletion of tracks and database file is optimized at exiting the traces management part if changed. As my tracks database grows (it is now approximately 30.000 GPS points at the moment) the deletion of tracks indeed has become slower. So I have changed the way the track deletion is implemented to asynchronous (in a separate thread - you don't need to wait for one deletion is completed to start a next one) and additionally separated the database file optimization from the track deletion. The database optimization is now done just once after you clicked the 'done' button in the track management screen.


• French localization. Many thanks to Laurent Goussard for translating all but one strings used in the application and Manfred Müller for translating the last one.

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.

OSMTrack 2.0 approved

The OSMTrack 2.0 is now approved and available for download from the App Store. Please upload your tracks before updating, the update process cleans up the database (read the previous post for more details).

OSMTrack 2.0

After a very long delay I'm finally happy to announce the next major OSMTrack update. The version 2.0 is a complete from scratch rewrite of the application. It contains a lot of visible as well as under-the-hood changes and improvements, the overall application design has been changed too. Now it is a sustainable end extensible platform that should be easy to add new features in the future.

The main visible changes are:

• All new UI with graphical track view at the main screen. It is OpenGL based, you can scroll it with a swipe, zoom with a pinch, changes of current location and position accuracy are animated. The original scale is 1 pixel per meter (the scale ruler is to be added in an update, read below). To return to the original scale and position double tap on the view.
  
  
  
  
  
  


• Multiple tracks done right - with tracks list editing, number of points for each track, graphical track view, etc.
  
  
  
  
  
  


• Sending tracks per email added.
  
  
  


• Preliminary support for waypoints. A new waypoint can be added by taping on the 'pin' button in the logging state. It currently lacks the visual confirmation (the waypoint is initially hidden below the cursor), just don't worry, you will see that a waypoint has been placed when you move further. Additionally it is currently not possible to give a name to the waypoint.
  
  
  


• Support for both landscape and portrait modes throughout the application.

The less visible but important changes include:

• Application-wide handling of errors: every single operation that may fail is now guarded, and if it has failed either the user is notified (non-critical errors) or a new 'inform the developer' hidden feature comes to the light that will ask whether you would like to send me an email crash report with detailed error information (critical errors).

And now a little bit about things that are not included into the current update (but are wishful to have):

• First of all, some architectural changes have required to slightly change the database format. Though it was theoretically possible to implement a database conversion, I have decided to not do it for the current upgrade. It is nice to have but it would take too much of my resources to make it right (in a background thread with a notification when finished). For the next releases when I will already support background operations I will definitely do this, but not this time. Please upload your existing tracks before upgrading.


• It is a little bit disturbing to not have the current scale and exact location accuracy (you can asses location accuracy when in the default scale 1 meter per pixel by looking at the accuracy circle - similar as in the Maps application, but you don't see the exact number) written on the display. The reason for that is that OpenGL per se does not include support to draw strings. To draw a string in OpenGL one has to do a little of magic with patterns. I have seen an example implementation integrated in a big framework, it is not that difficult, but as I don't use any OpenGL framework I have to do it myself. Then you will also see the current scale and exact location accuracy.


• The current update still does not have a slippy map background though many other applications do. In the next quick step I'm going to enable you to see all the traces located on your iPhone for the current region - this is not exactly the map, but a step towards it. And in a future, yes, I'm going to implement local vector-based map management, not just bitmaps.


• The current support of waypoints is called "preliminary", and it is. I'm very well aware that this is a desirable feature, and I'm going to continue developing it. Including textual waypoint names, images from camera and audio recordings for JOSM audio mapping.

The update is sent to Apple for review. I will inform you as soon as it is available.

1.5.1 Update available

The 1.5.1 update is approved and available for download. Uploading to OSM shall work again now.

Traces do not appear on the OSM Server issue

As you may have heard, on April 21st the OpenStreetMap server has migrated to the new version of the API. Together with switching on the new API version, the old API version was switched off. This has brocken the application. Unfortunately, the issue was not really predictable nor testable in advance: in a normal production evironment if you have multiple applications working with your API, migration is normally stepwise, and the old API is not switched off immediately. For the OSMTrack it was not possible to test the new API before the switch was made: though it was online for some time already, before April 21 the new API was in a read only mode - not really useful for an application that only writes data. Furthermore, the switched-off API has returned error as text inside an HTML document - it's ok if you have the function integrated in a web application running in a browser, but pretty difficult to parse for other types of applications. That's why you didn't get any error messages but the tracks have never appeared on the server. The fix was simple, I incremented the API number and everything works again. However, before you get the update it has to go through the Apple review process, it may take a couple of days. I'm sorry for the issue and thank you for your patience.

Roadmap

I have been asked what my next plans are, especially in comparison to Track'n Trail application. Well, right now I'm indeed working on implementing a graphical track presentation similar to Track'n Trail. If everything goes well, OSMTrack should become almost on a par in functionality with the Track'n Trail app soon (it will not support adding waypoints - they are of no use for the Open Street Map contributing; and sending tracks per email will possibly be added only with iPhone OS 3.0).

For the timing it is difficult to say right now. I have started OSMTrack with very simple architecture, so to say, let's try it and see what emerges out of it. Now I'm trying to develop a sustainable and extensible design, capable of doing much more then it does now. Also I 'm using OpenGL - technology which is new for me, I need some time to get familiarized with it, especially because OpenGL ES implementation of iPhone needs some special approaches different from OpenGL on desktop.

For the slippy map, this will be the next step. However, none of the existing frameworks - route-me, CloudMade iPhone Maps Library and a new iPhone OS maps framework suffice my requirements. In fact, I've even created a sample application branch using route-me framework, but it was slow and had bad GPS reception (it seems GPS reception quality depends on how busy the iPhone is). My requirements are simple - tracking shall work also in places where there is no network coverage. For this I need maps being rendered from local vector data (of course, it is also possible to use pre-cached bitmaps, but read further). This is why I'm doing it with OpenGL. Maps will be done in multiple steps, starting with street map only - no colorful areas like forests, lakes, etc. (currently OpenGL ES implementation on iPhone doesn't provide GL Utility library helping to draw arbitrary poligons, not just triangles).

And the final step on the OSMTrack roadmap is map editing. At least for the map editing I will definitely need local raw vector maps. I have not even started thinking on how it may look like, but still I'm trying to design tracking functionality so generic that it shouldn't require changes even when map editing is implemented. This is the difficulty.