Thursday, December 10, 2009
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).
Tuesday, December 1, 2009
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:
The less visible but important changes include:
And now a little bit about things that are not included into the current update (but are wishful to have):
The update is sent to Apple for review. I will inform you as soon as it is available.
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.
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)