Saturday, May 9, 2009

1.5.1 Update available

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

Wednesday, April 29, 2009

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.

Tuesday, March 24, 2009

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.

Tuesday, February 3, 2009

OSM4iPhone gets a web site

As you may have noticed, there is a new menu nearby the blog title. I have finally found time and made OSM4iPhone own web site. As the OSMTrack application advances, new features appear that need to be covered in the documentation. However pushing the complete documentation as blog posts seem to be bad both for me - it gets more difficult to track comments if pushing so many posts at once, and for you - you need to dig in to find the help.

For now the web site consists of a title page and the promised updated OSMTrack 1.5 documentation. But I also plan to add an FAQ page to explain what was my original idea of how I the app is to be used, and why certain features are there and others are not.

Thursday, January 15, 2009

OSMTrack 1.5

I have yesterday submitted the OSMTrack 1.5 update to Apple and they were so fast that just a few hours later the update was online. Wow! I haven't expected this. This is why this announcement comes after the update is in fact available.

A lot has changed in the application since the last update. In fact, I almost have rewritten it with better design, a lot of optimisations, etc., etc. But first things first.

The major visible change is the support of multiple tracks. Yes, now you can collect as much tracks as you want without bothering to upload them immediately (though you should write the tags and description to not forget where you were). This is extremely useful if you don't have network coverage (or it is expensive - not everyone has unlimited contracts). Or if you don't have time to wait until upload finishes. To support multiple tracks the complete storage of tracks has been re-implemented and now uses SQLite database. It has been done to support future graphical presentation of tracks (and later maps). Even now, it has an advantage that you can store as much tracks as you have place on your iPhone - almost unlimited. Of course, you can also delete tracks by swiping left or right over the track title similar to how deleting of emails has worked in the first version of the Mail application before "Edit" button has appeared (I will also add the Edit button in the next update).

The next visible improvement is the "Slide to stop" control in place of the stop button. Now I always put my iPhone in my pocket when logging and don't worry about occasional buttons presses.

Now "invisible" changes. I have discovered that the less resources the app uses (mainly the less memory it uses) the better and the faster GPS fix I get. So I have made a lot of internal optimizations in the software. Now with more features it uses almost 200kB less memory than the original version. I have got rid of XIB-based views (pre-compiled user interface stored separately from the application) and rewritten the application to create the UI programmatically. All images used in the application are now when possible scalable and always optimized. Everywhere where only possible I have tried to avoid storing data if I can recreate it fast.

I have not changed the compass implementation though I have seen complaints that it doesn't work well. I tested my implementation and the new Apple-own implementation against a normal magnetic compass. Both implementations are equally bad. Well, not equally but bad. Apple's implementation is much more conservative than mine, the compass needs significant time to start showing any direction. However, I have seen Apple's implementation sometimes showing me consistently wrong direction (in fact, South was where North should be). My implementation is more sensitive, it starts showing some direction almost immediately (sometimes even if you don't move). Of course, in my implementation the direction is not very accurate and my implementation is more prone to errors. But I have seen (almost) correct results equally often in both implementations. I think a much more work has to be done to get significantly better results. I will have to do this work later when I have a graphical map as a background, so I just kept my implementation at the moment since I can easier change it later.

I will post an updated version of the user guide in the next days.

Sunday, January 11, 2009

App Store reviews and 2 month results

Recently I got a bad review on a german App Store from a guy claiming he couldn't figure out how to use the app.

Ok, I know there are people who never visit support websites and never read user manuals. I can live with it. Nevertheless, I tried to make the application so that it just cannot be used wrong. Usability is one of my main goals. But have I really achieved it?

If you like the OSMTrack and think the application is actually good, please take a little bit of your time and write a review on the App Store. Reviews help sales a lot. Right now, except for just two reviews on the german App Store, I haven't seen any other reviews for any other country in the world, though I have to admit, I checked only a couple of countries where most copies were sold. By writing a review you will help me to further develop the application.

I can also add that in two month there were sold approximately 2 to 3 hundreds of copies worldwide. Together with approx. $0,7 revenue per copy (depending on the exchange rate) this means that I shouldn't get rich any time soon, don't worry ;) Additionally, I haven't seen any of these money yet, as Apple bundles them per region (like US or Europe) and postpone the payment until the result reaches $250 (sorry Apple, I hope this was not your commercial secret). Anyway, thanks a lot to everyone who bought the application! This is actually great and I haven't expected there are so many people actively contributing to the Open Street Map, considering the small market share of the OSMTrack multiplied by the fact that not everyone owns an iPhone 3G.

Tuesday, November 18, 2008

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.