0.3 Release Date / TODO
Christian Vetter
Could we make a release somewhere around Easter?
The todo list contains the following task left to do:
1) Bugs!
I don't know of any bugs we have to tacke for the relase. Did you
notice anything left to do in this regard?
2) Optimize qtile stylesheet
Still has to be done. Train tracks should only be visible at lower
zoom levels, buildings should also be pushed about 3 levels lower,
rivers should be drawn behind roads not in front of it, secondary
roads could be drawn one or to levels further up.
3) Update wiki!
Still has to be done. I will update the preprocessor's documentation,
but I am inherently bad at documenting the client. Volunteers step
forward *g*.
4) Create huge amount of map data
I believe Christoph has this covered? I noticed that the map data set
names ( "germany" ) are still in lower case. Also we could probably
increase the compression a bit, is this posible with zip? I managed to
compress the maps with 7zip, shaving of about 40% of the current zip
files.
5) Create binaries
Christoph also has done great work in this regard. Do the packages
include everything necessary ( icons, dependencies / dependency
information)? I will try do compile Windows Mobile and Symbian
binaries during the next days. @James: Could you build Android builds?
6) Write announcement
Should I create a wiki page for this or just write one myself?
7) Some tile-modules?
We might want to offer some tile modules for single map packages. Do
you think there is demand for this?
Do you think we could manage this till next weekend? Who wants to do what?
Regards,
Christian Vetter.
Christoph Eckert
> 1) Bugs!
> I don't know of any bugs we have to tacke for the relase. Did you
> notice anything left to do in this regard?
* An existing tracklog is rendered as soon the first GPS update is received
after startup. This should be changed to show it immediately. Hopefully it's
just a missing
emit tracklogChanged();
or so.
* AFAIR the automatic autocenter feature is enabled in case the user switches
to routing mode, but not when choosing one of the goto commands. Though the
code looks OK, I need to check this again. It's not a showstopper, though.
> 2) Optimize qtile stylesheet
> Still has to be done. Train tracks should only be visible at lower
> zoom levels,
I partly agree. As a cyclist, though, it's always good to see the railways
even at lower zoom levels, as those tracks often limit the choices for a
route.
> buildings should also be pushed about 3 levels lower,
> rivers should be drawn behind roads not in front of it, secondary
> roads could be drawn one or to levels further up.
Yep. AFAIR it is not an issue of the stylesheet, which I already tried to
tweak. James mentioned there might be a bug concerning the index. See the
archive, »Vectorrenderer omitting data«, 04. and 13.03.2011.
> 3) Update wiki!
> Still has to be done. I will update the preprocessor's documentation,
> but I am inherently bad at documenting the client. Volunteers step
> forward *g*.
Admittedly I have not yet understood how the wiki works. Will check again.
> 4) Create huge amount of map data
> I believe Christoph has this covered?
http://www.christeck.de/wp/2011/04/13/when-bollards-baffle-bicycle-routing/
All packages are updated, so bollards do not hinder the router for bike and
pedestrian routes.
> I noticed that the map data set
> names ( "germany" ) are still in lower case.
Well, this is due to the geofabrik filenames. Of course this could be changed
editing the processing script.
> Also we could probably
> increase the compression a bit, is this posible with zip? I managed to
> compress the maps with 7zip, shaving of about 40% of the current zip
> files.
I've chosen zip, as it is the format which can be extracted on most platforms
without the need to install additional software.
The last run took more than 24 hours (well, nice -n9 applied). I could try to
recalculate the maps to fix the lowercase filenames and using zip -9 for better
compression. However, this means I need to "hammer" the server again, and IMO
there will be no time left to test the updated maps before the release.
> 5) Create binaries
> Christoph also has done great work in this regard. Do the packages
> include everything necessary ( icons, dependencies / dependency
> information)?
On Windows, Ubuntu and Maemo menu entry is created for the user's convenience.
The debian packages are "dumb" installers, just placing the files in the file
system. The control files do not contain dependency checking:
Package: monav
Version: 0.3-1
Architecture: armel
Maintainer: Christoph Eckert <c...@christeck.de>
Installed-Size: 1456
Section: user/navigation
Priority: extra
Homepage: http://code.google.com/p/monav/
Description: Routing application
Allows to track the GPS position and provides very fast and exact route
calculation.
If someone can share the required depencency lines, I'll add them. However, I
did not intend to become a debian packaging expert til easter :) .
> I will try do compile Windows Mobile and Symbian
> binaries during the next days. @James: Could you build Android builds?
Would an NSIS installer work on Windows Mobile?
> 6) Write announcement
> Should I create a wiki page for this or just write one myself?
IMO it's up to the maintainer to make announcements :) .
> 7) Some tile-modules?
> We might want to offer some tile modules for single map packages. Do
> you think there is demand for this?
Does this mean packages which only contain osmrender or qtile renderer data?
No clue. My personal opinion: Provide osmrender only packages as soon MoNav is
capable of asking an online routing service for routes. This would be great
for people with less disc space left on their devices, but who own a fat
flatrate.
> Do you think we could manage this till next weekend? Who wants to do what?
Demanding. I can do some stuff the next two eves - maximum. I'd leave the map
packages as they are, check the two abovementioned bugs, update the binaries
and installers I've created and hopefully edit some wiki pages.
What I miss for an easter release is an easter egg. For example, MoNav could
talk to the user on Sunday: »The MoNav team wishes you and your family a happy
easter 2011. If you have good luck, MoNav will provide speech output in one of
the future easter releases.«
;)
--
Beste Grüße,
Best regards,
ce
Christian Vetter
On Sun, Apr 17, 2011 at 2:01 PM, Christoph Eckert <c...@christeck.de> wrote:
> * An existing tracklog is rendered as soon the first GPS update is received
> after startup. This should be changed to show it immediately. Hopefully it's
> just a missing
> emit tracklogChanged();
> or so.
>
> * AFAIR the automatic autocenter feature is enabled in case the user switches
> to routing mode, but not when choosing one of the goto commands. Though the
> code looks OK, I need to check this again. It's not a showstopper, though.
If you don't have time to look for this I could also do this.
> Yep. AFAIR it is not an issue of the stylesheet, which I already tried to
> tweak. James mentioned there might be a bug concerning the index. See the
> archive, »Vectorrenderer omitting data«, 04. and 13.03.2011.
Ok, then we should maybe leave it the way it is till after the release.
>> 3) Update wiki!
>> Still has to be done. I will update the preprocessor's documentation,
>> but I am inherently bad at documenting the client. Volunteers step
>> forward *g*.
>
> Admittedly I have not yet understood how the wiki works. Will check again.
You can either edit the wiki through the webinterface or through svn.
It is located under /wiki. You will have to use SVN if you want to
upload some images. Don't upload images like crazy, though, since the
SVN space is somewhat limited *g*.
> Well, this is due to the geofabrik filenames. Of course this could be changed
> editing the processing script.
Only if it does not involve much work.
> The last run took more than 24 hours (well, nice -n9 applied). I could try to
> recalculate the maps to fix the lowercase filenames and using zip -9 for better
> compression. However, this means I need to "hammer" the server again, and IMO
> there will be no time left to test the updated maps before the release.
Ok, then we shouldn't do it for this release's map data.
>> 5) Create binaries
>> Christoph also has done great work in this regard. Do the packages
>> include everything necessary ( icons, dependencies / dependency
>> information)?
>
> On Windows, Ubuntu and Maemo menu entry is created for the user's convenience.
Nice.
> The debian packages are "dumb" installers, just placing the files in the file
> system. The control files do not contain dependency checking:
>
> Package: monav
> Version: 0.3-1
> Architecture: armel
> Maintainer: Christoph Eckert <c...@christeck.de>
> Installed-Size: 1456
> Section: user/navigation
> Priority: extra
> Homepage: http://code.google.com/p/monav/
> Description: Routing application
> Allows to track the GPS position and provides very fast and exact route
> calculation.
>
> If someone can share the required depencency lines, I'll add them. However, I
> did not intend to become a debian packaging expert til easter :) .
Dito *g*. Nevertheless, If I stumble upon anything I'll let you know.
> Would an NSIS installer work on Windows Mobile?
You have to create Windows Mobile .cab files. Theere are programs that
will do that for you. However, I currently do not posses a WM device
and can only test it on the emulator.
>> 6) Write announcement
>> Should I create a wiki page for this or just write one myself?
>
> IMO it's up to the maintainer to make announcements :) .
Ok *G*
> Does this mean packages which only contain osmrender or qtile renderer data?
> No clue. My personal opinion: Provide osmrender only packages as soon MoNav is
> capable of asking an online routing service for routes. This would be great
> for people with less disc space left on their devices, but who own a fat
> flatrate.
I meant offline-tiles. But most likely nobody will use them anyway.
>> Do you think we could manage this till next weekend? Who wants to do what?
>
> Demanding. I can do some stuff the next two eves - maximum. I'd leave the map
> packages as they are, check the two abovementioned bugs, update the binaries
> and installers I've created and hopefully edit some wiki pages.
I should have most evenings available. If we do not manage to get
ready in time, we'll just move it to a later date. So do not stress
yourself unnecessarily *g*.
Regards,
Christian Vetter
Christian Vetter
won't run on larger maps, since currently the whole quadtile index is
loaded into memory. However, on Windows Mobile you only have 32MB
address space for small allocations.
Christoph Eckert
> 1) Bugs!
> I don't know of any bugs we have to tacke for the relase. Did you
> notice anything left to do in this regard?
issues I noticed during today's trip from Karlsruhe to Strasbourg:
* The fullscreen button on the N900 still shows the behaviour, that toggling
between full and normal screen consumes an incremental amount of time each
time used. May it be that some weird loop of events is causing this?
* The render thread for the qtiles is more than welcome. However, I got the
impression that rendering the tiles now often is delayed much more than
before. If feels like the render thread is paused by a couple of seconds every
now and then.
* The render additions I did back in february should be applied to 0.3. It's
now excessively tested, as I patched every build I did.
* Request: I abused the instruction labels to write the remaining route
distance into the display triggered by the distanceChanged() signal. I noticed
that the approximateDistance() method calculates the direct distance between
source and target, not the actual route distance. In case this is
intenational, I consider to add such a feature in 0.4.
* Request: The logger should provide information like current tracklog length,
average travel speed etc. Seems there's lot of room left for new features :) .
That's it so far. It was a great joy to have MoNav at my disposal during
today's trip. Once again, thanks so much :) .
Christian Vetter
On Mon, Apr 18, 2011 at 1:15 AM, Christoph Eckert <c...@christeck.de> wrote:
> Hi,
>
>> 1) Bugs!
>> I don't know of any bugs we have to tacke for the relase. Did you
>> notice anything left to do in this regard?
>
> issues I noticed during today's trip from Karlsruhe to Strasbourg:
>
> * The fullscreen button on the N900 still shows the behaviour, that toggling
> between full and normal screen consumes an incremental amount of time each
> time used. May it be that some weird loop of events is causing this?
I will look into this.
>
> * The render thread for the qtiles is more than welcome. However, I got the
> impression that rendering the tiles now often is delayed much more than
> before. If feels like the render thread is paused by a couple of seconds every
> now and then.
The behaviour before the patch was to render all tiles and then the
image to the screen. No tile are rendered while image are rendered to
the screen. This means it could take about twice as long to render all
tiles if you only have one core on the mobile phone. Nevertheless, it
should be worth it as the GUI is much more responsive.
>
> * The render additions I did back in february should be applied to 0.3. It's
> now excessively tested, as I patched every build I did.
Then add them.
>
> * Request: I abused the instruction labels to write the remaining route
> distance into the display triggered by the distanceChanged() signal. I noticed
> that the approximateDistance() method calculates the direct distance between
> source and target, not the actual route distance. In case this is
> intenational, I consider to add such a feature in 0.4.
The Coordinate's distance functions only compute the direct distance
between two GPS coordinates, not the route itself.
Christian Vetter
> between full and normal screen consumes an incremental amount of time each
> time used. May it be that some weird loop of events is causing this?
Try r522
Christoph Eckert
> > * The render additions I did back in february should be applied to 0.3.
> > It's now excessively tested, as I patched every build I did.
>
> Then add them.
Revision 527.
Christian Vetter
Christian Vetter
Christoph Eckert
> And take care to also commit it to the 0.3 branch *g*.
argh. Thanks for the valuable pointer :) .
Christoph Eckert
> How much will the size of the map package increase?
no clue; of course I also applied the patch to the preprocessor since feb, so
all packages generated on the osm server contain it already.
Christian Vetter
vector renderer also has its problems. Was the input data set
corrupted or does our coordinate transformation not work for Canada?
Christian Vetter
I just fixed a bug that produced corrupted bounding boxes for anything
left of 0° longitude *g*.
That fixes Canada's bounding box. Nevertheless, the qtile renderer
still does not render correctly anything below zoomlevel ~10
Christoph Eckert
> > And take care to also commit it to the 0.3 branch *g*.
>
> argh. Thanks for the valuable pointer :) .
backport done. Feel free to ping me again in case I messed it up again :) .
Christoph Eckert
> I fear you have to repeat some map preprocessing g
>
> I just fixed a bug that produced corrupted bounding boxes for anything
> left of 0° longitude *g*.
>
> That fixes Canada's bounding box. Nevertheless, the qtile renderer
> still does not render correctly anything below zoomlevel ~10
u-oh. This first requires rebuilding the proprocessor on
gauss.openstreetmap.de, which is not a straightforward job due to some local
protobuf libs and so on. Aynway, seems reprocessing the maps now is mandatory.
Christoph Eckert
> 4) Create huge amount of map data
> I believe Christoph has this covered? I noticed that the map data set
> names ( "germany" ) are still in lower case. Also we could probably
> increase the compression a bit, is this posible with zip? I managed to
> compress the maps with 7zip, shaving of about 40% of the current zip
> files.
I've updated the script, so the list now contains uppercase characters, which
are converted to lowercase while searching the geofabrik files. This won't help
with dashes (Czech_Republic) or german umlauts (Baden-Wuerttemberg instead of
Baden-Württemberg), though. I've also added the option -9 to zip.
Unfortunately the preprocessor currently does not compile on
gauss.openstreetmap.de. This needs to be fixed before reprocessing the map
material.
Christoph Eckert
> * An existing tracklog is rendered as soon the first GPS update is
> received after startup. This should be changed to show it immediately
client/routinglogic.cpp:
connect( this, SIGNAL(gpsInfoChanged()),
Logger::instance(), SLOT(positionChanged()) );
Obviously the Logger::instance() method needs to be called in some
constructor. Any hint what's the best place for it? main? Mainwindow?
Routinglogic?
Christian Vetter
I think I fixed that a few revisions back by explicitly getting the
track when creating a map widget. There should be no need to create
the Logger instance explicitly as it will be created by the routing
logic when the main window is created,
Christoph Eckert
> track when creating a map widget. There should be no need to create
> the Logger instance explicitly as it will be created by the routing
> logic when the main window is created,
even better.
BTW: May
http://code.google.com/p/monav/wiki/Downloads
direct to
monav.openstreetmap.de
Christian Vetter
http://monav.openstreetmap.de/
I will definitely do that for the release.
Christoph Eckert
> * AFAIR the automatic autocenter feature is enabled in case the user
> switches to routing mode, but not when choosing one of the goto commands.
> Though the code looks OK, I need to check this again. It's not a
> showstopper, though.
checked. Works in 0.3-stable. I guess I saw some hickups in the UI hack I did
recently.
Christoph Eckert
> 3) Update wiki!
> Still has to be done. I will update the preprocessor's documentation,
> but I am inherently bad at documenting the client. Volunteers step
> forward *g*.
http://code.google.com/p/monav/wiki/QTileRenderer
updated.
Christoph Eckert
> Still has to be done. I will update the preprocessor's documentation,
> but I am inherently bad at documenting the client. Volunteers step
> forward *g*.
http://code.google.com/p/monav/wiki/ProjectDescription
Done.
Christoph Eckert
> 5) Create binaries
> Christoph also has done great work in this regard. Do the packages
> include everything necessary ( icons, dependencies / dependency
> information)?
just to set things right: The Windows installer installs all Qt-dlls necessary
to run MoNav into the installation directory.
Christoph Eckert
> 3) Update wiki!
> Still has to be done. I will update the preprocessor's documentation,
> but I am inherently bad at documenting the client. Volunteers step
> forward *g*.
I've updated the client page a bit, but not too much:
http://code.google.com/p/monav/wiki/MoNavClient
If we went to release before friday (which IMO was a good thing) that's it, as
I still need to update maps and installers.
Christoph Eckert
> That fixes Canada's bounding box. Nevertheless, the qtile renderer
> still does not render correctly anything below zoomlevel ~10
http://monav.openstreetmap.de/mapsets/Canada.zip
was updated, using the adjusted script. I'll not be able to check whether the
bug is fixed, so it would be great if someone else checks this before I process
all the other maps.
Christoph Eckert
excellent, it now seems to work perfectly.