Mardy (Articoli su mapper)http://mardy.it/it/categories/mapper.atom2024-02-02T20:11:04ZAlberto MardeganNikolaName change Mapper -> Mapper-o and UI help neededhttp://mardy.it/it/blog/2010/04/name-change-mapper-mapper-o-and-ui-help.html2010-04-29T18:17:00+04:002010-04-29T18:17:00+04:00Alberto Mardegan<p>The title says it all: for the next version I plan to change the name from Mapper to the definitely much better sounding <em>Mapper-o</em>. I might still be convinced to change the plan and use a different name, if someone happens to suggest something I cannot resist to.</p><p>Anyway, the main reason behind the change is that a project named Mapper <a href="http://maemo.org/packages/view/mapper/">already exists</a> in maemo for the N900, although so far it's only available in extras-devel; and going back to “Maemo Mapper” doesn't look like a great option, considering that Meego is the future (and maybe some other platforms, who knows?). So, I needed a different name which would:</p><ul> <li>be recognizable by users already familiar with it</li>
<li>possibly start with the same letters, so that users would still find it in the application manager when looking for Mapper</li>
<li>hopefully be found in search engines when someone searches for “mapper”</li>
<li>sound really, really cool</li>
<li>make people wonder why the helsinki I chose it</li>
</ul><p>And “Mapper-o” is also easy to pronounce: in fact, there are no rules on how to pronounce it! I myself read it as one would read the word “màppero” in any phonetic language (which English is not), to prove that even the silliest reading sounds just too cool. ;-)</p><p>As a slightly different topic, <b>Mapper-o is looking for help</b> from icon/graphics/UI designers: <a href="http://talk.maemo.org/showthread.php?p=633554#post633554">thread post in t.m.o.</a>. If you happen to be interested, don't hesitate to step in! The glory is waiting for you!</p><p>The title says it all: for the next version I plan to change the name from Mapper to the definitely much better sounding <em>Mapper-o</em>. I might still be convinced to change the plan and use a different name, if someone happens to suggest something I cannot resist to.</p><p>Anyway, the main reason behind the change is that a project named Mapper <a href="http://maemo.org/packages/view/mapper/">already exists</a> in maemo for the N900, although so far it's only available in extras-devel; and going back to “Maemo Mapper” doesn't look like a great option, considering that Meego is the future (and maybe some other platforms, who knows?). So, I needed a different name which would:</p><ul> <li>be recognizable by users already familiar with it</li>
<li>possibly start with the same letters, so that users would still find it in the application manager when looking for Mapper</li>
<li>hopefully be found in search engines when someone searches for “mapper”</li>
<li>sound really, really cool</li>
<li>make people wonder why the helsinki I chose it</li>
</ul><p>And “Mapper-o” is also easy to pronounce: in fact, there are no rules on how to pronounce it! I myself read it as one would read the word “màppero” in any phonetic language (which English is not), to prove that even the silliest reading sounds just too cool. ;-)</p><p>As a slightly different topic, <b>Mapper-o is looking for help</b> from icon/graphics/UI designers: <a href="http://talk.maemo.org/showthread.php?p=633554#post633554">thread post in t.m.o.</a>. If you happen to be interested, don't hesitate to step in! The glory is waiting for you!</p>Mapper and N900 battery lifehttp://mardy.it/it/blog/2010/04/mapper-and-n900-battery-life.html2010-04-11T14:49:00+04:002010-04-11T14:49:00+04:00Alberto Mardegan<div class="separator" style="clear: both; text-align: center;"><a href="http://www.mardy.it/archivos/imagines/mapper-portrait.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="400" src="http://www.mardy.it/archivos/imagines/mapper-portrait.png" width="240"></a></div>In this lovely sunny Sunday I decided to pick up my bike for the first time after the winter hibernation and go for a trip around the Seurasaari bay, just next to Helsinki centre. Of course I took my N900 with Mapper with me, to make it record the GPS track into a GPX file which I will then use to geotag the photos I took with <a href="http://en.wikipedia.org/wiki/Minolta_AF#7">my film camera</a> (which is a rather advanced model capable of storing the time of the pictures in its internal memory), and to visualize my track in some sports tracking website. While it will take quite some time before I'll be able to show you the pictures I took (I've just started this film roll, and I don't use this camera often), I can show you how the Mapper-generated GPX track looks like in <a href="http://www.runsaturday.com/">runsaturday.com</a>, a sports tracking website where one can upload his own GPS tracks and get them analyzed and put into different charts:<br>
<ul><li><a href="http://www.runsaturday.com/act/257164/subView/Player">My biking trip in runsaturday.com track player</a></li>
<li><a href="http://www.runsaturday.com/act/257164/subView/Charts">Pace, speed, altitude charts</a> </li>
</ul>As a geek, watching these data is enough to stimulate me to do some sports. :-)<br>
<br>
In the screenshot posted to the right, you can see my development version of Mapper with portrait mode support (mostly useful when walking or cycling) with the track shown in red. I fully charged my N900 just fifteen minutes before starting the trip, so here you can see how the battery level looks like after about 1 hour and half (the trip itself lasted 1 hour and 18 minutes, as shown in the small info panel on the upper right of the map); from such a quick test it's hard to say how many hours the device would last, but I was positively surprised that the battery was still in a good shape.<br>
The reason why I was expecting the battery level to be lower is that (besides running a version of Mapper with all optimizations disabled) so far I didn't take power consumption into much consideration during the development; there is a lot of room for improvements I'm aware of, namely:<br>
<ul><li>Avoid drawing while the screen is off</li>
<li>Use longer intervals on the GPS device</li>
</ul>...and probably many more I'm not aware of. While the first item is quite easy to implement and unlikely to cause any evil side-effects, the second can be tricky because it also alters the quality of the generated GPX track, so it probably needs to be a user configurable setting. On the other hand, I assume that forcing GPS updates to happen no often than every 10 seconds while the screen is off is reasonable — and it might actually improve the quality of the GPX track, whose charts in runsaturday.com now appear very jagged. In any case, it's something that needs to be tested on the field.<br>
<br>
And to conclude with good news, turn-by-turn navigation with visual and voice announcements is coming soon on your favourite Mapper. :-)<div class="separator" style="clear: both; text-align: center;"><a href="http://www.mardy.it/archivos/imagines/mapper-portrait.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="400" src="http://www.mardy.it/archivos/imagines/mapper-portrait.png" width="240"></a></div>In this lovely sunny Sunday I decided to pick up my bike for the first time after the winter hibernation and go for a trip around the Seurasaari bay, just next to Helsinki centre. Of course I took my N900 with Mapper with me, to make it record the GPS track into a GPX file which I will then use to geotag the photos I took with <a href="http://en.wikipedia.org/wiki/Minolta_AF#7">my film camera</a> (which is a rather advanced model capable of storing the time of the pictures in its internal memory), and to visualize my track in some sports tracking website. While it will take quite some time before I'll be able to show you the pictures I took (I've just started this film roll, and I don't use this camera often), I can show you how the Mapper-generated GPX track looks like in <a href="http://www.runsaturday.com/">runsaturday.com</a>, a sports tracking website where one can upload his own GPS tracks and get them analyzed and put into different charts:<br>
<ul><li><a href="http://www.runsaturday.com/act/257164/subView/Player">My biking trip in runsaturday.com track player</a></li>
<li><a href="http://www.runsaturday.com/act/257164/subView/Charts">Pace, speed, altitude charts</a> </li>
</ul>As a geek, watching these data is enough to stimulate me to do some sports. :-)<br>
<br>
In the screenshot posted to the right, you can see my development version of Mapper with portrait mode support (mostly useful when walking or cycling) with the track shown in red. I fully charged my N900 just fifteen minutes before starting the trip, so here you can see how the battery level looks like after about 1 hour and half (the trip itself lasted 1 hour and 18 minutes, as shown in the small info panel on the upper right of the map); from such a quick test it's hard to say how many hours the device would last, but I was positively surprised that the battery was still in a good shape.<br>
The reason why I was expecting the battery level to be lower is that (besides running a version of Mapper with all optimizations disabled) so far I didn't take power consumption into much consideration during the development; there is a lot of room for improvements I'm aware of, namely:<br>
<ul><li>Avoid drawing while the screen is off</li>
<li>Use longer intervals on the GPS device</li>
</ul>...and probably many more I'm not aware of. While the first item is quite easy to implement and unlikely to cause any evil side-effects, the second can be tricky because it also alters the quality of the generated GPX track, so it probably needs to be a user configurable setting. On the other hand, I assume that forcing GPS updates to happen no often than every 10 seconds while the screen is off is reasonable — and it might actually improve the quality of the GPX track, whose charts in runsaturday.com now appear very jagged. In any case, it's something that needs to be tested on the field.<br>
<br>
And to conclude with good news, turn-by-turn navigation with visual and voice announcements is coming soon on your favourite Mapper. :-)Automating the release process for Maemo applicationshttp://mardy.it/it/blog/2010/03/automating-release-process-for-maemo.html2010-03-30T19:28:00+04:002010-03-30T19:28:00+04:00Alberto Mardegan<p>Releasing a Maemo application to the Extras-devel repository is a rather simple operation, yet it can be a bit time consuming and one can always make small mistakes which, although always easily recoverable, again lead to a waste of time.<br>
<br>
The release process typically consists of:<br>
<br>
</p><ol><li>cleaning the source tree from all unwanted files (built binary objects, editor backup copies, core-dumps and what not)</li>
<li>building the debian package, which involves remembering the command to be used, typically something like <code>dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git</code></li>
<li>uploading the resulting files to the Maemo build robot, according to one of the methods described <a href="http://wiki.maemo.org/Uploading_to_Extras#Upload">here</a></li>
</ol>Although none of these steps is especially difficult, there are several things that can go wrong or that can make the process annoying:<br>
<ul><li>you can easily forget to delete core dumps and other temporary files from the source tree, which might even contain sensitive information</li>
<li>remembering (or looking up in the shell history) the command for building the package </li>
<li>if you use the <a href="https://garage.maemo.org/extras-assistant/index.php">Extras Assistant</a> you'll be dealing with a comfortable tool, but not as fast as the command line</li>
<li>if you have already made several releases and didn't delete the old files, you'll have to browse through them to find the latest version</li>
</ul>The solution I've come up with is this simple script:<br>
<pre>#! /bin/sh
set -e
BASEDIR="$(mktemp -d)"
cd "$BASEDIR"
git clone --depth 1 -l "$HOME/git/maemo-mapper"
cd maemo-mapper
git checkout origin/fremantle
dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git
cd ..
scp *.tar.gz *.diff.gz *.changes *.dsc mardy@drop.maemo.org:/var/www/extras-devel/incoming-builder/fremantle/
</pre><br>
<p>It's certainly not a script that you would find in a shell programming manual, but it does its job: first, it creates a temporary directory, then it clones the local git repository (which ensures that there won't be any unwanted files in the tree), then it selects the desired branch (if it's not the master branch), builds the package and uploads it to the builder. If any of these steps fail, the script terminates. Feel free to adapt it to your needs and use for your own releasing pleasure. :-)</p><br>
<p>As a side note, I've used it just now to release <a href="http://www.mardy.it/archivos/maemo/maemo-mapper_3.0+beta4_armel.deb">maemo-mapper 3.0+beta4</a>, which doesn't include any remarkable features but comes with a redesign of the menus which are now drawn in the maemo5 style.</p><p>Releasing a Maemo application to the Extras-devel repository is a rather simple operation, yet it can be a bit time consuming and one can always make small mistakes which, although always easily recoverable, again lead to a waste of time.<br>
<br>
The release process typically consists of:<br>
<br>
</p><ol><li>cleaning the source tree from all unwanted files (built binary objects, editor backup copies, core-dumps and what not)</li>
<li>building the debian package, which involves remembering the command to be used, typically something like <code>dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git</code></li>
<li>uploading the resulting files to the Maemo build robot, according to one of the methods described <a href="http://wiki.maemo.org/Uploading_to_Extras#Upload">here</a></li>
</ol>Although none of these steps is especially difficult, there are several things that can go wrong or that can make the process annoying:<br>
<ul><li>you can easily forget to delete core dumps and other temporary files from the source tree, which might even contain sensitive information</li>
<li>remembering (or looking up in the shell history) the command for building the package </li>
<li>if you use the <a href="https://garage.maemo.org/extras-assistant/index.php">Extras Assistant</a> you'll be dealing with a comfortable tool, but not as fast as the command line</li>
<li>if you have already made several releases and didn't delete the old files, you'll have to browse through them to find the latest version</li>
</ul>The solution I've come up with is this simple script:<br>
<pre>#! /bin/sh
set -e
BASEDIR="$(mktemp -d)"
cd "$BASEDIR"
git clone --depth 1 -l "$HOME/git/maemo-mapper"
cd maemo-mapper
git checkout origin/fremantle
dpkg-buildpackage -rfakeroot -sa -us -uc -i -I.git
cd ..
scp *.tar.gz *.diff.gz *.changes *.dsc mardy@drop.maemo.org:/var/www/extras-devel/incoming-builder/fremantle/
</pre><br>
<p>It's certainly not a script that you would find in a shell programming manual, but it does its job: first, it creates a temporary directory, then it clones the local git repository (which ensures that there won't be any unwanted files in the tree), then it selects the desired branch (if it's not the master branch), builds the package and uploads it to the builder. If any of these steps fail, the script terminates. Feel free to adapt it to your needs and use for your own releasing pleasure. :-)</p><br>
<p>As a side note, I've used it just now to release <a href="http://www.mardy.it/archivos/maemo/maemo-mapper_3.0+beta4_armel.deb">maemo-mapper 3.0+beta4</a>, which doesn't include any remarkable features but comes with a redesign of the menus which are now drawn in the maemo5 style.</p>Fixing berserk rotations in Mapperhttp://mardy.it/it/blog/2010/03/fixing-berserk-rotations-in-mapper.html2010-03-16T16:53:00+03:002010-03-16T16:53:00+03:00Alberto Mardegan<div class="separator" style="clear: both; text-align: center;"><a href="http://www.mardy.it/archivos/imagines/angle_diff.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="198" src="http://www.mardy.it/archivos/imagines/angle_diff.png" width="320"></a></div><p>Maemo Mapper has a nice feature which is called "automatic rotation" and consists in automatically rotating the map so that the direction you are going to is always oriented toward the top of the screen. The direction information comes from the GPS device, and applications can access it from a <a href="http://maemo.org/api_refs/5.0/5.0-final/liblocation/LocationGPSDevice.html#LocationGPSDeviceFix">liblocation structure</a>.<br>
Unfortunately, while this value is rather reliable when you are moving fast, it's totally pointless when you are not moving: and this can be easily seen in the alpha versions of Mapper, when the map starts spinning crazily as soon as you stop moving. One thing that I didn't notice is that besides giving the direction, liblocation also gives the estimated error: the <tt>epd</tt> field in the <tt>LocationGPSDeviceFix</tt> structure represents the error on the angle, as a value from 0 to 359. In my opinion it doesn't make much sense to have an error greater than 180 on an angle, so I assume that it must be divided by two.</p><p>In the image on the right, the <tt>epd</tt> is represented by 2 × β. Now, if v⃗<sub>0</sub>is the current direction the map is oriented towards, and v⃗<sub>1</sub> is the new direction reported by the GPS with an error (uncertainty) of β, how do we decide if (and how much) we should rotate towards v⃗<sub>1</sub>?<br>
The algorithm I've implemented goes like this:<br>
</p><ul><li>if β is greater than 90°, ignore the information altogether (i.e., don't change the rotation). Or,</li>
<li>if α (the angle between v⃗<sub>0</sub> and v⃗<sub>1</sub>) is less than 5°, then let the map rotate to v⃗<sub>1</sub>. Or,</li>
<li>rotate towards v⃗<sub>1</sub> by γ = α × <sup>(90 - β)</sup>⁄<sub>90</sub>, that is the rotation is limited according to the error.</li>
</ul>I've been testing the algorithm in the last few days, and it is indeed a huge improvement over the previous situation: now the map does not rotate while I'm not moving, or it does fairly seldom. But still, the map almost always rotates once just right after stopping, and not by a small amount, which is pretty annoying as it means that most of the times when you pause you'll have the map wrongly oriented — and pauses are usually the very moment when you'd look at the map...<p>I'll investigate this a bit more; this means that I'll have to keep a terminal window open with a view on the <tt>syslog</tt>, while using Mapper :-)</p><div class="separator" style="clear: both; text-align: center;"><a href="http://www.mardy.it/archivos/imagines/angle_diff.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="198" src="http://www.mardy.it/archivos/imagines/angle_diff.png" width="320"></a></div><p>Maemo Mapper has a nice feature which is called "automatic rotation" and consists in automatically rotating the map so that the direction you are going to is always oriented toward the top of the screen. The direction information comes from the GPS device, and applications can access it from a <a href="http://maemo.org/api_refs/5.0/5.0-final/liblocation/LocationGPSDevice.html#LocationGPSDeviceFix">liblocation structure</a>.<br>
Unfortunately, while this value is rather reliable when you are moving fast, it's totally pointless when you are not moving: and this can be easily seen in the alpha versions of Mapper, when the map starts spinning crazily as soon as you stop moving. One thing that I didn't notice is that besides giving the direction, liblocation also gives the estimated error: the <tt>epd</tt> field in the <tt>LocationGPSDeviceFix</tt> structure represents the error on the angle, as a value from 0 to 359. In my opinion it doesn't make much sense to have an error greater than 180 on an angle, so I assume that it must be divided by two.</p><p>In the image on the right, the <tt>epd</tt> is represented by 2 × β. Now, if v⃗<sub>0</sub>is the current direction the map is oriented towards, and v⃗<sub>1</sub> is the new direction reported by the GPS with an error (uncertainty) of β, how do we decide if (and how much) we should rotate towards v⃗<sub>1</sub>?<br>
The algorithm I've implemented goes like this:<br>
</p><ul><li>if β is greater than 90°, ignore the information altogether (i.e., don't change the rotation). Or,</li>
<li>if α (the angle between v⃗<sub>0</sub> and v⃗<sub>1</sub>) is less than 5°, then let the map rotate to v⃗<sub>1</sub>. Or,</li>
<li>rotate towards v⃗<sub>1</sub> by γ = α × <sup>(90 - β)</sup>⁄<sub>90</sub>, that is the rotation is limited according to the error.</li>
</ul>I've been testing the algorithm in the last few days, and it is indeed a huge improvement over the previous situation: now the map does not rotate while I'm not moving, or it does fairly seldom. But still, the map almost always rotates once just right after stopping, and not by a small amount, which is pretty annoying as it means that most of the times when you pause you'll have the map wrongly oriented — and pauses are usually the very moment when you'd look at the map...<p>I'll investigate this a bit more; this means that I'll have to keep a terminal window open with a view on the <tt>syslog</tt>, while using Mapper :-)</p>Mapper removal from maemo Extras repositoryhttp://mardy.it/it/blog/2010/03/mapper-removal-from-maemo-extras.html2010-03-15T21:03:00+03:002010-03-15T21:03:00+03:00Alberto Mardegan<p>As probably many users of Mapper have noticed, sometimes while using this application the device gets stuck for a variable amount of seconds. Even though the situation is not easy to trigger, and I've seen it myself only two or three times out of several months of development, it's still a serious problem for a device which is meant to be used also as a phone.</p><p>Unfortunately, the problem doesn't lie in Mapper itself, and there is very little I can do to work around it. I had a chance to run it on the coming PR1.2 fremantle release, and it seems not to be happening there. Anyway, as you can see from <a href="http://talk.maemo.org/showthread.php?t=47327">this thread</a> and from <a href="http://talk.maemo.org/poll.php?do=showresults&pollid=362">the related poll</a>, the preferred decision is to remove Mapper from Extras.</p><p>On the other hand, for the majority of people (at least judging from the feedback Mapper lately received) the application is quite stable, so I wouldn't like to deprive users of possible updates. For this reason, I'm going to periodically post here links to application releases; of course if you have read the paragraph above you are also aware of the potential problems of these releases (occasional freezes of your device, when using the application). I'm linking them as <tt>.deb</tt> packages, so to discourage the unexperienced user from using them. :-)</p><br><br>
<p>So, here we go with <a href="http://www.mardy.it/archivos/maemo/maemo-mapper_3.0+beta2_armel.deb">maemo-mapper_3.0+beta2_armel.deb</a>. Changelog (including changelog of the previous unreleased version, too):</p><small><pre>maemo-mapper (3.0+beta2) unstable; urgency=low
* Fix calculation of path distances, not to include breaks.
* If a tile is missing, try to show a scaled image from another zoom level.
* Fix a potential out-of-array memory access.
-- Alberto Mardegan <mardy> Sat, 13 Mar 2010 09:33:17 +0200
maemo-mapper (3.0+beta1) unstable; urgency=low
* Add About dialog.
* Add panel with track and route informations.
* Remove obsolete menu items.
* Fix "Error saving maps. Disk full?" message (see
https://bugzilla.gnome.org/show_bug.cgi?id=612729).
* Do not retry downloading of tiles if we already know it will fail.
-- Alberto Mardegan <mardy> Fri, 12 Mar 2010 21:56:48 +0200
</mardy></mardy></pre></small><br>
<br>
<p>Happy mapping! :-)</p><p>As probably many users of Mapper have noticed, sometimes while using this application the device gets stuck for a variable amount of seconds. Even though the situation is not easy to trigger, and I've seen it myself only two or three times out of several months of development, it's still a serious problem for a device which is meant to be used also as a phone.</p><p>Unfortunately, the problem doesn't lie in Mapper itself, and there is very little I can do to work around it. I had a chance to run it on the coming PR1.2 fremantle release, and it seems not to be happening there. Anyway, as you can see from <a href="http://talk.maemo.org/showthread.php?t=47327">this thread</a> and from <a href="http://talk.maemo.org/poll.php?do=showresults&pollid=362">the related poll</a>, the preferred decision is to remove Mapper from Extras.</p><p>On the other hand, for the majority of people (at least judging from the feedback Mapper lately received) the application is quite stable, so I wouldn't like to deprive users of possible updates. For this reason, I'm going to periodically post here links to application releases; of course if you have read the paragraph above you are also aware of the potential problems of these releases (occasional freezes of your device, when using the application). I'm linking them as <tt>.deb</tt> packages, so to discourage the unexperienced user from using them. :-)</p><br><br>
<p>So, here we go with <a href="http://www.mardy.it/archivos/maemo/maemo-mapper_3.0+beta2_armel.deb">maemo-mapper_3.0+beta2_armel.deb</a>. Changelog (including changelog of the previous unreleased version, too):</p><small><pre>maemo-mapper (3.0+beta2) unstable; urgency=low
* Fix calculation of path distances, not to include breaks.
* If a tile is missing, try to show a scaled image from another zoom level.
* Fix a potential out-of-array memory access.
-- Alberto Mardegan <mardy> Sat, 13 Mar 2010 09:33:17 +0200
maemo-mapper (3.0+beta1) unstable; urgency=low
* Add About dialog.
* Add panel with track and route informations.
* Remove obsolete menu items.
* Fix "Error saving maps. Disk full?" message (see
https://bugzilla.gnome.org/show_bug.cgi?id=612729).
* Do not retry downloading of tiles if we already know it will fail.
-- Alberto Mardegan <mardy> Fri, 12 Mar 2010 21:56:48 +0200
</mardy></mardy></pre></small><br>
<br>
<p>Happy mapping! :-)</p>