[MoNav Dev] 0.3.1 and 0.4 Roadmap

[Christian Vetter]

Hi,

Thanks for the great work on 0.3 everybody. However, after the release
is before the release *g*.

I think we should bring bugfix + smaller features releases in the 0.3
series more regularly. They should contain all bugfixes we apply as
well as smaller features that:
a) do not change the map format
b) do not change the UI dramatically ( small changes are ok, though )

So far we have:
- PBF parser is now standard complient
- XML parser bugfix for reading relations
- Preprocessor bugfixes related to packaging / output directory
- World map is now a SVG instead of a huge JPEG

I still plan to add support for implied tags ( fixes several issues )
and update some speed profile a little bit.
Do you have some specific things you want to be integrated into 0.3.1?

Aside from that we should plan what kind of larger changes we want to
incorporate into 0.4. So far it seems like:
- New UI ( Christopher is doing a lot of work there ):
* Restructure to be more configurable + better code + easier to use
* Changes IRenderer API to be an actual Widget -> Renderers can
provide transitions, we can insert Widgets at specific GPS locations,
we get clickable stuff in the map and most likely draggable routes. (
I will do most work for this )
* UI Plugins -> simple Wdigets that can be added to the UI and can
access some information ( e.g. overview world map, distance ruler
etc.... )
* maybe already: add POIs ( also requires new Plugin type )
- Routing improvements:
* maybe: Importer parses SRTM ( already halfway in the latest version
) -> requires changed to IImporter ( no more bidirectional edges??? )
* Simplify IImporter / refactor OSM Importer
* IGPSLookup changes to be able to map to several possible edges (
also required for SRTM data )
* optimize space consumption ( sacrifice some speed? good idea? at
the moment its completely optimized for speed )
* maybe: turn Restrictions -> might increase size greatly
* maybe: new MLD algorithm to support many routing profile with
little space. Maybe we can make use of some of OSRM, Dennis Luxen
plans to implement this.
- maybe: Client logic improvements:
* Recompute route only when necessary
* generate persistent driving instructions
- maybe: New AddresLookup plugin that can manage house numbers +
Importer should handle Karlsruher address schema ( optional though in
the downloadable map packages, coverage is not great everywhere )
- Auto-downloads for map packages ( Edith Brunel is working on that )
- maybe: QTileRenderer optimization ( James still with us? )
- Android release ( James or Edith )
- libOSMScout support

Seems like a lot, maybe we should divide it into more manageable
chunks? What is your opinion? More frequent releases? Did I miss
something? Is something a bad idea? Which maybes should we tackle and
which should we leave out for now?

Regards,

Christian Vetter

[JohnK]

Hi, Christian

What is MLD algorithm represent for?

Post by Christian Vetter
Hi,
Thanks for the great work on 0.3 everybody. However, after the release
is before the release *g*.
I think we should bring bugfix + smaller features releases in the 0.3
series more regularly. They should contain all bugfixes we apply as
a) do not change the map format
b) do not change the UI dramatically ( small changes are ok, though )
 - PBF parser is now standard complient
 - XML parser bugfix for reading relations
 - Preprocessor bugfixes related to packaging / output directory
 - World map is now a SVG instead of a huge JPEG
I still plan to add support for implied tags ( fixes several issues )
and update some speed profile a little bit.
Do you have some specific things you want to be integrated into 0.3.1?
Aside from that we should plan what kind of larger changes we want to
  * Restructure to be more configurable + better code + easier to use
  * Changes IRenderer API to be an actual Widget -> Renderers can
provide transitions, we can insert Widgets at specific GPS locations,
we get clickable stuff in the map and most likely draggable routes. (
I will do most work for this )
  * UI Plugins -> simple Wdigets that can be added to the UI and can
access some information ( e.g. overview world map, distance ruler
etc.... )
  * maybe already: add POIs ( also requires new Plugin type )
 * maybe: Importer parses SRTM ( already halfway in the latest version
) -> requires changed to IImporter ( no more bidirectional edges??? )
 * Simplify IImporter / refactor OSM Importer
 * IGPSLookup changes to be able to map to several possible edges (
also required for SRTM data )
 * optimize space consumption ( sacrifice some speed? good idea? at
the moment its completely optimized for speed )
 * maybe: turn Restrictions -> might increase size greatly
 * maybe: new MLD algorithm to support many routing profile with
little space. Maybe we can make use of some of OSRM, Dennis Luxen
plans to implement this.
 * Recompute route only when necessary
 * generate persistent driving instructions
- maybe: New AddresLookup plugin that can manage house numbers +
Importer should handle Karlsruher address schema ( optional though in
the downloadable map packages, coverage is not great everywhere )
- Auto-downloads for map packages ( Edith Brunel is working on that )
- maybe: QTileRenderer optimization ( James still with us? )
- Android release ( James or Edith )
- libOSMScout support
Seems like a lot, maybe we should divide it into more manageable
chunks? What is your opinion? More frequent releases? Did I miss
something? Is something a bad idea? Which maybes should we tackle and
which should we leave out for now?
Regards,
Christian Vetter

[Christian Vetter]

Hi,

It is a new routing algorithm which exploits the network topology
instead of the edge weights.

Regards,

Christian Vetter

Post by JohnK
Hi, Christian
What is MLD algorithm represent for?

Post by Christian Vetter
Hi,
Thanks for the great work on 0.3 everybody. However, after the release
is before the release *g*.
I think we should bring bugfix + smaller features releases in the 0.3
series more regularly. They should contain all bugfixes we apply as
a) do not change the map format
b) do not change the UI dramatically ( small changes are ok, though )
 - PBF parser is now standard complient
 - XML parser bugfix for reading relations
 - Preprocessor bugfixes related to packaging / output directory
 - World map is now a SVG instead of a huge JPEG
I still plan to add support for implied tags ( fixes several issues )
and update some speed profile a little bit.
Do you have some specific things you want to be integrated into 0.3.1?
Aside from that we should plan what kind of larger changes we want to
  * Restructure to be more configurable + better code + easier to use
  * Changes IRenderer API to be an actual Widget -> Renderers can
provide transitions, we can insert Widgets at specific GPS locations,
we get clickable stuff in the map and most likely draggable routes. (
I will do most work for this )
  * UI Plugins -> simple Wdigets that can be added to the UI and can
access some information ( e.g. overview world map, distance ruler
etc.... )
  * maybe already: add POIs ( also requires new Plugin type )
 * maybe: Importer parses SRTM ( already halfway in the latest version
) -> requires changed to IImporter ( no more bidirectional edges??? )
 * Simplify IImporter / refactor OSM Importer
 * IGPSLookup changes to be able to map to several possible edges (
also required for SRTM data )
 * optimize space consumption ( sacrifice some speed? good idea? at
the moment its completely optimized for speed )
 * maybe: turn Restrictions -> might increase size greatly
 * maybe: new MLD algorithm to support many routing profile with
little space. Maybe we can make use of some of OSRM, Dennis Luxen
plans to implement this.
 * Recompute route only when necessary
 * generate persistent driving instructions
- maybe: New AddresLookup plugin that can manage house numbers +
Importer should handle Karlsruher address schema ( optional though in
the downloadable map packages, coverage is not great everywhere )
- Auto-downloads for map packages ( Edith Brunel is working on that )
- maybe: QTileRenderer optimization ( James still with us? )
- Android release ( James or Edith )
- libOSMScout support
Seems like a lot, maybe we should divide it into more manageable
chunks? What is your opinion? More frequent releases? Did I miss
something? Is something a bad idea? Which maybes should we tackle and
which should we leave out for now?
Regards,
Christian Vetter

[Christoph Eckert]

Hi,

[...]

Post by Christian Vetter
- World map is now a SVG instead of a huge JPEG

client.pro now contains
QT += svg xml
May I savely assume that I now could make use of QXmlStreamReader and
QXmlStreamWriter? This would be good news, as my tracklog writer and reader
does a lot of string comparison work and seems to be slow due to this.

[...]

Post by Christian Vetter
Aside from that we should plan what kind of larger changes we want to
* Restructure to be more configurable + better code + easier to use

Since yesterday, Maemo got its own toolbar and menu, so changes for the
desktop won't break the UI for Maemo. However, it's currently very "Maemo and
all the rest" centric, which will in turn make it difficult for friends of
Android to create their own menus and toolbars. I will check how this can be
changed.

Post by Christian Vetter
* Changes IRenderer API to be an actual Widget -> Renderers can
provide transitions, we can insert Widgets at specific GPS locations,
we get clickable stuff in the map and most likely draggable routes. (
I will do most work for this )

Draggable routes would be a nice gimmick. But frankly, I doubt there is a
practical use on mobile devices with small screens.

Post by Christian Vetter
* UI Plugins -> simple Wdigets that can be added to the UI and can
access some information ( e.g. overview world map, distance ruler
etc.... )
* maybe already: add POIs ( also requires new Plugin type )

I wonder wether we should add isolated dwellings and localities to the address
search. That's where they belong to, but I guess it would pollute the live
search results. Should those be treated as POIs?

Post by Christian Vetter
* maybe: Importer parses SRTM ( already halfway in the latest version
) -> requires changed to IImporter ( no more bidirectional edges??? )

Of course this would be appreciated for bike routing. However this means we
need to copy 500GB of SRTM data to the machine which does the preprocessing.
I'm curious if there will be enough space left for this on osm.de (hm, maybe
the data is already there for some other project).

[...]

Post by Christian Vetter
* Recompute route only when necessary
* generate persistent driving instructions

IMO it would be great to have a notification when approaching the next crossing
- once. This could at least be used to acoustically alert the user. I'm not
talking about actual turn instructions yet, though :) .

Post by Christian Vetter
- maybe: New AddresLookup plugin that can manage house numbers +
Importer should handle Karlsruher address schema ( optional though in
the downloadable map packages, coverage is not great everywhere )

Of course this would be a great step towards "serious" car routing. As the
data is not complete enough, would this result in a search either by nearby
streets (the current behaviour) or an additional zip/postal search, or a
combined search?

Maybe User:Twain, who has worked on Nominatim, can share some hints concerning
the various address mapping schemas used in OSM. If MoNav gets widely used one
day, the schema supported by MoNav will have an impact on how mappers map
addresses. IMO we should be careful not to support any schema available. OTOH
we will quickly get accused that we do politics here when we prefer one schema
over another.

Post by Christian Vetter
- Auto-downloads for map packages ( Edith Brunel is working on that )

Welcome Edith :) .

Post by Christian Vetter
- maybe: QTileRenderer optimization ( James still with us? )

Street name rendering and fixing the zoom levels would be great.

Post by Christian Vetter
- Android release ( James or Edith )

Android installers would be great to broaden the user base.

Post by Christian Vetter
- libOSMScout support

Is there someone actively working on it, or are volunteers still wanted?

Post by Christian Vetter
Seems like a lot, maybe we should divide it into more manageable
chunks? What is your opinion? More frequent releases? Did I miss
something? Is something a bad idea? Which maybes should we tackle and
which should we leave out for now?

As a fan of Scrum, I'd better split it down to small managable chunks. We all
do this in our spare time. IMO it's better to get small improvements
completely done instead of starting huge changes which then will remain
unfinished for a long time. Shouldn't Mercurial serve us well concerning this?

My personal opinion:
* 0.3 is a past release. Only bug fixes should make it into a 0.3.1.
* Create incremental 0.4 "possibly shippable" builds/installers to gather
feedback from end users (actually there will be none, but you theoretically
got the chance :) .
* Repeat the regular builds, until the goals of the release are reached.

Some things that come to my mind:

* Save (and load?) routes to GPX, at least on the Desktop. Option to save as
rte or trk. Should be easy to add. I found it more interesting to write a new
class that manages the GPX IO.

* i18n. I know I will get punished for that, but I'd include the qm files into
the binary until we have more than 5 translations, for easy "the binary
contains it all" installations. I already have done this for my other
projects, and could easily set this up for a german translation, at least.

* Surely not for 0.4, but IMO routing over polygonal areas would be great.
These days mappers draw a lot of helper lines across places and areas to get
the desired routing, which simply is a dirty hack IMO. It also has been
mentioned during the »Accessible Routing« discussion.

* The trackinfo page will keep me busy for a while. Once started, you
immediately learn what you did wrong in the past and which features you want
to hack next :) .

* I once lost a track, as I obviously shut down the N900 while it was writing
to the file. Easy to do, but requires testing.

* Improve address and bookmark handling/dialogs.

* Write bookmarks (and/or waypoints :) to a standard GPX file instead of the
config.

Well, there are plenty of entries in my TODO list :) .

[Christian Vetter]

Hi

Post by Christoph Eckert
client.pro now contains
QT += svg xml
May I savely assume that I now could make use of QXmlStreamReader and
QXmlStreamWriter? This would be good news, as my tracklog writer and reader
does a lot of string comparison work and seems to be slow due to this.

Yes you can :-D

Just don't load several megabytes. Maybe check the filesize beforehand
and only load large files if the user agrees?

Post by Christoph Eckert
Draggable routes would be a nice gimmick. But frankly, I doubt there is a
practical use on mobile devices with small screens.

Most likely we will even explicitly deactivate this on mobile devices.
However, being able to click on map elements will come in handy ( POIs
etc )

Post by Christoph Eckert
I wonder wether we should add isolated dwellings and localities to the address
search. That's where they belong to, but I guess it would pollute the live
search results. Should those be treated as POIs?

Difficult to answer. I guess from a data point of view a POI would
make more sense since there is at most one street attached to it, most
of the time even without a name.

Post by Christoph Eckert

Post by Christian Vetter
 * maybe: Importer parses SRTM ( already halfway in the latest version
) -> requires changed to IImporter ( no more bidirectional edges??? )

Of course this would be appreciated for bike routing. However this means we
need to copy 500GB of SRTM data to the machine which does the preprocessing.
I'm curious if there will be enough space left for this on osm.de (hm, maybe
the data is already there for some other project).

I borrowed some ideas from srtm2wayinfo, namely loading SRTM tiles on
demand into the cache directory. Works quite well and you only
download tiles when preprocessing a dataset for the first time ( and
its not 500 GB *g* -> 70 MB for Germany )

Post by Christoph Eckert

Post by Christian Vetter
 * Recompute route only when necessary
 * generate persistent driving instructions

IMO it would be great to have a notification when approaching the next crossing
- once. This could at least be used to acoustically alert the user. I'm not
talking about actual turn instructions yet, though :) .

Yes, definitely planned.

Post by Christoph Eckert

Post by Christian Vetter
- maybe: New AddresLookup plugin that can manage house numbers +
Importer should handle Karlsruher address schema ( optional though in
the downloadable map packages, coverage is not great everywhere )

Of course this would be a great step towards "serious" car routing. As the
data is not complete enough, would this result in a search either by nearby
streets (the current behaviour) or an additional zip/postal search, or a
combined search?

I would suggest offering one AddressLookup plugin which uses strict
Karlsruher Schema search to encourage mappers using the schema. Our
current address search plugin could always be available as a fallback.

Post by Christoph Eckert
Maybe User:Twain, who has worked on Nominatim, can share some hints concerning
the various address mapping schemas used in OSM. If MoNav gets widely used one
day, the schema supported by MoNav will have an impact on how mappers map
addresses. IMO we should be careful not to support any schema available. OTOH
we will quickly get accused that we do politics here when we prefer one schema
over another.

As far as I understand OSM policies everybody does what he wants, so
we can support what we want *g*. But I guess you are right, if Twain
has already gathered experience with this we should ask him. However,
I would be happy if we could get away with just supporting one data
schema.

Post by Christoph Eckert

Post by Christian Vetter
- maybe: QTileRenderer optimization ( James still with us? )

Street name rendering and fixing the zoom levels would be great.

I wrote James a while ago, I am not sure whether he is still working
on MoNav. If we do not hear from him soon I would suggest we fix this
ourselves.

Post by Christoph Eckert

Post by Christian Vetter
- Android release ( James or Edith )

Android installers would be great to broaden the user base.

Especially since Nokia will not support Qt on Windows Phone.

Post by Christoph Eckert

Post by Christian Vetter
- libOSMScout support

Is there someone actively working on it, or are volunteers still wanted?

I am looking into it. Tim did a great amount of improvements during
the last months. However since there is so much else to do I haven't
found enough time yet. So if someone else steps up to do this... your
welcome *g*. Maybe we should wait for the planned changes to
IRenderer, though.

Post by Christoph Eckert

Post by Christian Vetter
Seems like a lot, maybe we should divide it into more manageable
chunks? What is your opinion? More frequent releases? Did I miss
something? Is something a bad idea? Which maybes should we tackle and
which should we leave out for now?

As a fan of Scrum, I'd better split it down to small managable chunks. We all
do this in our spare time. IMO it's better to get small improvements
completely done instead of starting huge changes which then will remain
unfinished for a long time. Shouldn't Mercurial serve us well concerning this?

It should, since merging should work way better than with SVN.
Currently I would favor us working on individual feature branches and
merge them back as soon as they are stable. Then we could always
release the current "default" branch without much changes. We should
avoid having everything done in one big chunk.

Post by Christoph Eckert
* Save (and load?) routes to GPX, at least on the Desktop. Option to save as
rte or trk. Should be easy to add. I found it more interesting to write a new
class that manages the GPX IO.

Maybe we should add an interface for Track/Route files so we can
easily add more formats later on. But I do not know what the input /
output will be. Will it contain the route? Waypoints? Track? Driving
Instructions?

Post by Christoph Eckert
* i18n. I know I will get punished for that, but I'd include the qm files into
the binary until we have more than 5 translations, for easy "the binary
contains it all" installations. I already have done this for my other
projects, and could easily set this up for a german translation, at least.

I guess this was long overdue. However, I believe I did not surround
all strings with the "tr()" function, so we would have to go over the
code and find all places where this is necessary.

Post by Christoph Eckert
* Surely not for 0.4, but IMO routing over polygonal areas would be great.
These days mappers draw a lot of helper lines across places and areas to get
the desired routing, which simply is a dirty hack IMO. It also has been
mentioned during the »Accessible Routing« discussion.

Yes, that would be nice... might be easy for bicycle routing... might
be really hard for pedestrian ( too many places will kill the
performance ). Luckily I know several routing algorithm experts who
are also somewhat interested in this, maybe they will come up with a
solution if we wait long enough *g*.

Post by Christoph Eckert
* The trackinfo page will keep me busy for a while. Once started, you
immediately learn what you did wrong in the past and which features you want
to hack next :) .

Good luck *g*.

Post by Christoph Eckert
* Improve address and bookmark handling/dialogs.
* Write bookmarks (and/or waypoints :) to a standard GPX file instead of the
config.

Hmm good idea. Is this widely supported? When introducing GUI plugins
I would love to move the bookmark functionality into a plugin.

Post by Christoph Eckert
Well, there are plenty of entries in my TODO list :) .

Hehe, I guess we won't run out of work for the next years.

Regards,

Christian Vetter

[Christoph Eckert]

Hi,

Post by Christian Vetter
I borrowed some ideas from srtm2wayinfo, namely loading SRTM tiles on
demand into the cache directory. Works quite well and you only
download tiles when preprocessing a dataset for the first time ( and
its not 500 GB g -> 70 MB for Germany )

NASA changes the directories for the data every now and then, I guess to avoid
too greedy download managers. If you build around their directory structure,
you will need to adjust the preprocessor every now and then.

[...]

Post by Christian Vetter
I would suggest offering one AddressLookup plugin which uses strict
Karlsruher Schema search to encourage mappers using the schema. Our
current address search plugin could always be available as a fallback.

If we keep in mind that
* MoNav is very euro centric (currently using metric dimensions only)
* There are areas (like the Czech republic) where the Karlsruhe schema does
not fit well
I'd support this at 120%.

[...]

Post by Christian Vetter
Especially since Nokia will not support Qt on Windows Phone.

Fortunately OSRM exists :) .

[...]

Post by Christian Vetter
It should, since merging should work way better than with SVN.
Currently I would favor us working on individual feature branches and
merge them back as soon as they are stable. Then we could always
release the current "default" branch without much changes. We should
avoid having everything done in one big chunk.

OK, I try to do it this way with the UI overhaul. I'm currently struggling
with the stacked widget to get the toolbars hidden when loading the
modulechooser and the like. Hope to get this running these days.

Post by Christian Vetter

Post by Christoph Eckert
* Save (and load?) routes to GPX, at least on the Desktop. Option to save
as rte or trk. Should be easy to add. I found it more interesting to
write a new class that manages the GPX IO.

Maybe we should add an interface for Track/Route files so we can
easily add more formats later on. But I do not know what the input /
output will be. Will it contain the route? Waypoints? Track? Driving
Instructions?

To avoid confusion, here's my point of view (I might be wrong in some
details).

GPX supports three data types: wpt, rte, trk. Garmin use[sd] it this way:

* wpt are more or less user generated POIs, as they provide fields for name,
description, icon and so on ("car parking", "nice biergarten", "here I lost my
GPSr" :) ). wpt IMO is widely used to exchange POIs and similar data.

* trk is a recorded track. I've seen various flavours, where some applications
even added names and descriptions to trkpt. No clue whether this is compliant
with GPX. Actually, it's a widely spread file format.

* rte is a collection of start, end, and via-points which are used by the
routing algorithm. I've barely seen this kind of data type by other
applications.

That's why I started to use the name "via", just to distinguish the route
vertices from "waypoints", whose name is a bit misleading.

I would save the RoutingLogic's waypoints (actually souce, target, and vias)
as rte, and all nodes that can paint the route into the display as a trk - at
the user's choice.

An abstraction interface that allows us to add kml or csv support later on was
a great idea.

[...]

Post by Christian Vetter
I guess this was long overdue. However, I believe I did not surround
all strings with the "tr()" function, so we would have to go over the
code and find all places where this is necessary.

No prob. I'd offer to do the complete work of a first german translation
(including the infrastructure changes). I guess it will consume one evening.
It will be more difficult to actually get translators.

[...]

Post by Christian Vetter
Yes, that would be nice... might be easy for bicycle routing... might
be really hard for pedestrian ( too many places will kill the
performance ). Luckily I know several routing algorithm experts who
are also somewhat interested in this, maybe they will come up with a
solution if we wait long enough *g*.

"Even better" :) .

Post by Christian Vetter

Post by Christoph Eckert
* The trackinfo page will keep me busy for a while. Once started, you
immediately learn what you did wrong in the past and which features you
want to hack next :) .

Good luck *g*.

Currently it's an ugly desert of numbers, which does not honour the individual
track segments. I'd like a solution which provides a nice graphical overview,
but have no good idea yet. I guess V 0.1 will remain the style it is, though I
still want to add figures like the average speed and the current elevation.

[...]

Post by Christian Vetter
Hmm good idea. Is this widely supported? When introducing GUI plugins
I would love to move the bookmark functionality into a plugin.

If there is a standard, then it is GPX wpt. I see the following benefits:

* Sometimes config files couse trouble, especially when updating applications.
The usual trick is to remove the config to get the default configuration.
Currently this would render your saved route and bookmarks unreachable.

* Using GPX, the user can easily use his bookmarks, waypoints, pois,
whatsoever in other applications.

* Maybe users will be able to export such a file from their contacts. I do not
know of any addressbook which provides exporting of contacts as GPX, but why
does KDE provide saving latlon with a contact if there's no such use?

Post by Christian Vetter

Post by Christoph Eckert
Well, there are plenty of entries in my TODO list :) .

Hehe, I guess we won't run out of work for the next years.

As long it is fun, there's nothing wrong with that. Once again, I really
enjoyed MoNav during a trip from Darmstadt to Aschaffenburg last weekend. Heck,
you really hooked me on your damn code *g*.

[Christoph Eckert]

Hi,

Post by Christoph Eckert

Post by Christian Vetter
I guess this was long overdue. However, I believe I did not surround
all strings with the "tr()" function, so we would have to go over the
code and find all places where this is necessary.

No prob. I'd offer to do the complete work of a first german translation
(including the infrastructure changes). I guess it will consume one
evening. It will be more difficult to actually get translators.

one-hour-hack:
http://christeck.de/stuff/monav-i18n.tar.gz

To update the .ts and .qm files after code changes:
lupdate client/client.pro
lrelease client/client.pro

hg diff shows the additions to 0.3. Actually I should do it using the uing
branch, but this sample code shows how I'd do it.

If you prefer, we could also install the qm files separately. However, I
dislike using "make install" to avoid a messed system.

Feedback welcome. If there is none, I'll add this to the uing branch :) .