maemo.org - Talk - View Single Post - [Announce] modRana: a flexible GPS navigation system

MartinK	2010-12-15 , 00:37
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#405

Originally Posted by woody14619

Get outta town! You had a FR too!? Small world. I have a GTA02v5 sitting on a shelf right now collecting dust. I keep meaning to bring it into work to flash it with the latest qtmoko (they just release v30 this week), but I keep forgetting it. (I don't have a windows box at home anymore, and the linux tools for FR never worked right for me...) I hear it's almost working as a reliable phone now... But then I heard that from some people the whole time, and mine was never good at keeping a GSM signal, yet alone handling calls or text. :P

I think I have seen a lecture about QtMoko by one of the developers (maybe it was even the main developer ? I'm not really sure) on the OpenMobility conference, that took place april. It looked very usable even then

BTW, there is a (bit old) howto for running modRana on QtMoko

BTW, concerning flashing - I have been using dfu-util in Linux to flash about everything in Neo, including rootfs (SHR), kernel and even the non-hardwired bootloader quite recently - without issues once I set the correct path and usb id.

Originally Posted by gkuenning

Of course, none of these solve the "Turn left on Street Andrews Street" problem; I'm not sure how that could be handled without true natural-language processing.

Well, the street names actually come enclosed in <b></b> tags. The enclosed text could be taken as a whitespace separated string and only those St. that have no whitespace behind them would be substituted

IMO, this looks like a textbook use-case for a regexp ->
I think I'll just add support for adding custom regexps to the filter file

Something like:

Code:

regexp;your_regexp_code

Originally Posted by jj0

You need to be careful with these, they do not work as expected, which relates to the previous post also. Basically modrana just does a plain substitution, not whole words. I.e. if you have
Code:
St;Street
this is wrong as then for instance "Park Street" will be read as "Park Street reet"
so maybe it should be:
Code:
St ;Street

Yep, its just really simple exact-match (including whitespace) substitution right now. It also applies ALL the rules, one after another, going from the first line to the last.

So you should use either

Code:

St. ;Street

Code:

St.;Street

, depending on how the streetnames are shortened and also watch out for substituting to something that might match match a rule further down the list

Originally Posted by gkuenning

I'm pretty sure it just overwrites things, unless the file has been specially marked in the distribution. One way to handle that problem would be to auto-merge it with a similar file in the user's home directory; then the one in /home/user could be used for personal localizations.

OK, upgrade-time merging seems like the best way, it might be less confusing than having two separate default (always overwritten by upgrade)/user(never overwritten by upgrade) filter files, etc. I just hope all the needed utilities are there in our (quite) limited busybox shell

Also, there might be problems with order of the rules in the merged file.

Also, thanks for all the new substitution rules!

Just a question to the gkuenning ones:

Code:

Ave;Avenue
Cir;Circle
Hts;Heights
Hwy;Highway
Ln;Lane
Pde;Parade
Pkwy;Parkway
Pl;Place
Plz;Plaza
Rd;Road
Sq;Square
Tce;Terrace
Trk;Track
Wy;Way

Is there really no period behind those abbreviations ? It hight potentially mangle some unabbreviated street names (5th Avenue -> 5th Avenuenue), like jj0 mentioned earlier.

Originally Posted by jj0

BTW, the new version is MUCH slower in loading the individual tiles for display, must be doing some caching or what-have-you, but now there is a noticeable lag, and the "Loading..." text showed for about a second or so, with every tile upon first display, then when it's redisplayed, i.e. zoomed out and back in, it's instantaneous, but it used to be instantaneous before...

I have changed how tile drawing/loading works. The drawing function previously handled everything - not only drawing but also caching the tiles (loading from file/sqlite or starting download threads) in case they were not in the memory cache.
This froze the whole GUI once there were enogh new tiles on the screens, because the drawing function waited for all the new tiles to load. There was also no limit on the number of concurrent download threads, which is another matter. I think you can imagine what happened if you entered an area with poor network coverage at hight speed without any thread-count limit

I have changed how tile drawing works like this:

the drawing function now only draws tiles that are cached in the memory cache, if there is a cache miss, it sends a loading request for the missing tile and loads a "Loading..." placeholder tile in the cache - like this, only one loading request is sent per missing tile
a separate consumer thread handles the loading request queue - it either loads the tile from local storage (file/sqlite) or sends a download request to the download request pool
a second consumer thread is responsible for starting the download threads, it also makes sure that the number of concurrent download threads never exceeds a given limit (20 by default), unprocessed download requests time-out after 30 second

The slower apparent loading of tiles might be caused by the default once-per-second screen refresh.

If you are not dragging the map, modRana updates the screen only once per second, as this is the shortest interval I can get a new fix in. Not much sense to update more often IMO. The first redraw draws the "Loading..." tiles and sends loading requests. And only the next redraw that happens a second later shows the actual tiles that were loaded to the cache in the meantime.

I think sending a screen redraw request once a tile is finished loading might improve/fix this.

__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)

Quote & Reply |

The Following User Says Thank You to MartinK For This Useful Post:
Wikiwide