OSMTrack 1.0.1

I have just submitted an update for the OSMTrack application to the App Store. It fixes some minor issues I have found in the recent days:

• Faster upload. Writing the documentation it comes to my mind, that I must be transmitting the log twice: first time just at the beginning and second time after an authorization request is received. Inspecting the documentation and after several attempts it has appeared that, in fact, iPhone OS is optimized for downloading things, it will always send the first request without credentials and supply credentials only if required by the web server. Fortunately, there is a way to supply custom HTTP header fields, and I used this to add a manually created authorization header. Now the log is transmitted only once, upload is twice fast.


• Upload indication changed. Since now there is no authorization step inbetween indicating that upload is 50% done, progress indicator makes no sense any more. I have changed it to an activity indicator (you know, the rotating thing).


• Fixed GPX log format (time stamp is now UTC). This was a smaller bug from my side - I have written times in current time zone instead of UTC as required by the GPX standard.


• Fixed incorrect presentation of tracks in OSM map editing mode. I have originally written timestamps to the log very precisely - up to fractions of second (in "HH:mm:ss.SS" format to be exact). It is inline with the GPX specification, and such logs were indeed correctly understood by the API. However Potlatch has shown these logs as if the first point were somewhere far away. This was actually more difficult to find than to fix: timestamps are now written with up to 1 second preciseness.


• Same positions are written in log just once. If you have to stop and wait for a moment, the 1.0 would keep writing the same coordinates into the log all the time. This increases upload time, but is of no use for map creation. Now, if you don't move, coordinate updates are shown on the screen (I hope to implement filtering at some point in time, I will need the best timing there), but not written into log.


• More detailed error reporting for location errors. You shall never see it, actually. But in case if something is totally wrong, e.g. you have an iPod Touch or you are in a flight mode, you will now get a correct error message.


• More robust in low memory situations. Again, you shall never see it. The application is very careful of how it uses iPhone's memory. However, if other applications on your iPhone appear to have memory leaks, the leaked memory is not automatically cleaned when application exits. Thus it may appear that my application may be the unlucky one that encounters low memory situation and I should take care of it.

UPDATE: The update is available on the App Store since November, 20th.

Battery life

As you know, to save battery iPhone goes to stand-by if no touches have been made for certain time. Unfortunately, in stand-by a running application is sent to sleep as well, it is not able to perform any operations. Fortunately, it is possible for an application to switch off the stand-by timer (though if you press stand-by button iPhone will still go to standby).

For the OSMTrack application, I do switch off the timer during the logging phase. Obviously, it has a disadvantage to waste your battery very fast (I have not measured, but others report something like 3 hours). Be warned.

UPDATE: I have tested it yesterday, and it took me approximately 2 hours to go from full battery to below 20% (I got low battery warning). So best of all, connect your iPhone to some power supply when logging...

Available on the App Store!

The application has been approved and is now available on the App Store. (On iPhone go to the App Store and search for OSMTrack.)

1.0 is ready!

Though it has taken longer than I have ever expected, I finally managed to finalize the first version of the application and sent it today to Apple for review. Thanks a lot for waiting! I will let you know as soon as it will be approved (I hope it will).

On my next steps

My current goal is to finish a first version of the application ASAP. It will have only a minimal set of features, but it shall work and be available to everyone.

For the next improvement I have two options: either to start with drawing of the current track graphically or to implement smoothing. This update, for sure, will not yet show a graphical map: my goal is to have map rendering locally on the device, and making it a good quality is a very complex task, not for a fast update. For the first step I'm targeting to something similar to what GPS Kit does (only track, without map), but cooler :) It should already use OpenGL, support zooming, flying around, etc.

The second alternative is to implement smoothing, and I'm actually tending more to this option: the graphical presentation of a track is more an eye candy, while eliminating a manual pathway creation is a real improvement.

Smoothing, filtering and navigation

Though I knew that Kalman filter is typically used to correct noisy sensor data, I haven't supposed that there are BOOKS (Global Positioning Systems, Inertial Navigation, and Integration and Kalman Filtering: Theory and Practice Using MATLAB) written on how to apply Kalman filter to combine GPS and accelerometer data to improve localization quality. It seems also that implementing a Kalman filter is not quite a trivial task (one have to take care to avoid the lost of preciseness caused by that the real numbers are stored with limited accuracy only). All in all, I have to read more to be able to implement smoothing algorithm in a correct way. So, I'm not doing any smoothing in the 1.0 and postpone it to a later version.

For those unfamiliar with the subject: smoothing should enable creation of smooth pathways with minimal number of intermediate points directly during the collection of a GPS log. No manual paths creation should be required during the map editing any more.

It's runnng on the device!

Great news: today I have received my iPhone Dev program confirmed (after getting all the prerequisite formalities like receiving my own UStID, etc). I'm now able to install the app on my iPhone 3G and test. As promised, here is the first screenshot:

As you see, the first version is very minimalistic. It consists of a single screen organized from top to bottom to fulfill a single goal: collect a GPS log. At the top of the screen there is a compass (though it is not very useful at the moment: smoothing is yet to be implemented, the compass rotates back and forth due to GPS errors; more details on smoothing is in the next post) and current horizontal and vertical location accuracies as reported by the iPhone's CoreLocation framework. Below follows the current location panel containing the timestamp of last update and the coordinates. The middle panel contains the coordinates of the starting position and the bottom panel contains the coordinates of the final position in the track (not yet reached on the screenshot). You can start/stop tracking using the toolbar button at the bottom and as soon as the track is complete you can either trash it or send to the OSM server. That's it.

Currently everything except sending to the OSM server is implemented and works. I hope to complete the posting to the server in the next few days.

Once again on Open Source and iPhone

It has been discussed a lot recently that iPhone SDK's license agreement prohibit developers to discuss any technical details or issues related to the development. Not that I didn't know that, but a detail that was new for me (I have just never thought about it) is that open source iPhone applications are in fact completely prohibited by the license agreement: making an application open source means sharing its source code, and this is not allowed.

Another detail, or better say a comment made by someone during a discussion of why the BoxOffice (Now Playing) application has been removed from the App Store: Apple could potentially be not very excited of developers getting donations and making their apps free, as it means Apple lose its 30% by not being able to sell the application (read it here: http://forums.macrumors.com/showpost.php?p=5990223&postcount=90). Though, possibly the application has been removed due to the SDK license agreement violation (its source code is available at google code).

On re-usage of third-party software

To say from the beginning: if there are things that I can reuse - great. However, I don't like to just port an existing application to the iPhone. By doing so I would get an old existing application running on the iPhone - not an iPhone application with its unique user experience. This is not my goal.

Similarly, I would be happy to re-use existing (open source) frameworks, however it may appear to be impractical: Cocoa APIs are quite different compared to (GNU, Linux or other) APIs commonly used in open source projects. Possibly it will take less time to e.g. rewrite the map rendering part than to port e.g. Mapnik to Cocoa and OpenGL ES. Though, we will see.

To jailbreak or not to jailbreak?

To legally distribute iPhone applications one has to become a registered iPhone developer and pay Apple 79 € annually. There is of cause also another way - to distribute the application via Installer.app for jailbroken iPhones only. But it would limit the usefulness of the applications to those people only who are agree to void their iPhone's warranty by jailbreaking it. I do not like to go the jailbreak way unless Apple will not let me into the App Store due to some reason.

So I have to live with 79€ annual fee. I see two possibilities how I can return this money: either I make the application non-free (e.g. $0.99 - the lowest rate available in the App Store) or I ask for donations and make it free. Please vote in the form at right what would be your preferable solution.

By the way, due to the App Store there probably will be a very few open source iPhone projects: first you have to pay for the development and second since applications are digitally signed and tracked every developer has a personal responsibility for his applications. He has to know the code as good as if he has written it himself. This eliminates the advantages of community-based development.

Why OSM4iPhone or current issues with OpenStreetMap

Well, having said what I'm going to do a couple of words are needed why I'd like to do it. First of all, I truly beleive that OpenStreetMap may become extremely popular. Same big as Wikipedia at the very least. But if Wikipedia is extremely useful to get some information, the most exciting in OpenStreetMap is the map making. It's like a game, you know, you can put your house onto the map, a tiny lake nearby it, basically anything. It is like creating your own world. However, to be such exciting the process of map making shall be very simple and intuitive. Unfortunately, the simplicity of map making is currently not on the strong side of the OSM.

First of all, you need to have a dedicated GPS device (not many normal people do have one). Then you have to go to some not yet mapped area and collect the needed data. IMHO, this is the best part - a kind of discovery of unknown lands. However, at least for me, the fun part stops here - the rest is work. When you have your GPS log you have to return home, connect your GPS device to a computer, transmit the data and convert it into the format accepted by OSM (most people do not care about formats, and with basic command line conversion tools probably they will not be able to accomplish this operation). Next you have to edit the map. In general, this could be a fun part but currently too complex and time consuming: you create every road manually by connecting points which you add yourself and use the GPS log as a mere visual hint to where put your points.

What is my proposal? I would like to put the complete map creation process into a single device - the iPhone - the device that many people will have anyway. No boring PC homework anymore - just discover the world and make the map at the same time (and after you done post it to the OSM server instantly). I have chosen the iPhone because I personally like it, because I beleive that its user friendliness would be a great benifit for the application, and even more important, I like to develop for it (in contrast to e.g. Windows Mobile). Then I would like to try to apply some advanced statistical stuff to create ways directly from the GPS data. Being used by robots to automatically generate maps for high precision navigation, I beleive, these methods should work well for OSM.

Why not a web application? Well, web applications work good only until you have network coverage (and in some places, e.g. for cycling maps, maybe you don't). Furthermore, native applications provide better flexibility and performance - very important thing for we are targeting to a 'fun' application.

OSM4iPhone

As reflected in its name this blog is about development of native iPhone appliactions to work with OpenStreetMap (http://openstreetmap.org). I'm writing applications and not application because currently I have 2 applications in my mind: one very simple to just collect GPS coordinates from the iPhone's CoreLocation framework, pack them into a GPX file and post this file to the OSM server. I beleive, this application still would be a step forward compared to the current situation as it would combine the GPS data collection and transmission to the OSM server in one step, eliminating the need to transfer the GPS log to computer and then to convert it into the GPX format. And, by the way, having a full control of the data will allow to apply statistical algorithms to create smooth pathways right out of the device, eliminating most of the handwork of creating paths in the editor later. The second application should be a full-featured OSM viewer-editor application to enable all map creating operations directly on the iPhone.

I don't like to start right away with the second application because, first, it is quite complex and would require some significant time to develop, and second, I beleive the first application has some worth of its own even without the possibility to see the map.