Active Topics
-
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 3 hrs, 50 mins ago -
Nokia Booklet 3G (RX-75) Drivers (60)
to Alternatives by Maemish - 5 days, 11 hrs ago - more...
 |
|
2007-05-21
, 15:02
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#22
|
Originally Posted by KerwoodDerby
The "port" will probably be built on GTK (requiring GTK for Windows), so it's not really a port so much as switching between using Hildon UI elements and "normal" GTK elements. It will uglify the code a little, but it won't bloat the executable.
Embarking on a cross-platform effort is not for the faint of heart. My impulse is to urge you to first find a like-minded confederate to "own" that porting job. You have to weigh the risk of burnout (from taking on too much yourself) against the risk of a crappy port due to a too-loosely-coupled collaboration.
I will start with a Maemo-specific design, since that is my priority, and I'll just keep in mind that I'll want it to (someday) work with normal GTK as well. Then, I'll change the maemo-specific bits to build differently depending on the target environment.
|
|
2007-05-21
, 15:08
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#23
|
Originally Posted by fldude99
Maemo Mapper had "connection independent functionality" (sans routing) long before Navicore's software came to the maemo platform.
It's a great application..but with the inroads of navicore with connection independent functionality..is there a reason to continue on this path..
As others have mentioned, the existence of an alternative doesn't refute the desire for a free, open source solution. If that were the case, Maemo Mapper never would have come about in the first place, as GpsDrive had already been ported to maemo.
|
|
2007-05-21
, 15:16
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#24
|
Originally Posted by lbattraw
I've done a proof-of-concept with GDBM (a simple hash-key-value system), and I was able to reduce disk space requirements (on a 1k-block file system) by about 40%. (That number may not be representative; it is based on only about 10,000 zoom-level-0 maps.)
I would also be curious to see which DB engine you might choose since obviously it can't be too big, but performance might be marginal for some of the simplest ones.
I'm still investigating alternatives, though. Someone mentioned CDB, but that's less useful in a constantly-changing map cache scenario. Maemo Mapper already uses sqlite3, so if I can reuse it for the map cache (POI would still be in a separate database) with sufficient performance, I will prefer to do that. sqlite3 (or any relational database, for that matter) could also give me the opportunity to implement more complex features, such as "aging out" (based on either time or fixed-disk-space) of older, not-recently-accessed maps .
I'm also open to suggestions.
|
|
2007-05-21
, 15:18
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#25
|
Originally Posted by fredoll
Sounds like a great idea, but it also sounds like something that will take some work to get right. Post a feature request and I'll keep it in mind as a future feature.
It would also be nice to allow an integration with a contact database (via plugin I suppose) It would allow to store GPS coordinate for contacts and a "go to contact" functionnality ...
What do you think ?
|
|
2007-05-21
, 15:26
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#26
|
Originally Posted by insert_nick
One problem is that the convenience of being able to "move a single file" also precludes the capability to, for example, download maps to your desktop and copy them into your Nokia device. You'd have to first transfer the database from the Nokia device to your desktop, download maps to the database, then transfer the database back to the Nokia device.
Really glad to hear, finally, there's some hope we are getting rid of that filesystem approach for maps. Go, go, do whatever you need to completely remove it and replace with something better: achieving the possibility to move a single file rather than gazillions of tiny files back and forth the card would be super-great!
It sounds like most people don't care too much about that drawback, though, so I'll just release a FS-to-DB converter, and that will be that.
Originally Posted by insert_nick
I promise you that 2.0 will be usable on the 770. Some of the newer features may require more RAM (or even swap space), but they can all be disabled. 2.x will never run as fast as 1.x (which, admittedly, suffered from intense over-optimization), but it will always be usable on the 770, even if some of the more CPU- and memory-intensive features are not.
On 770, I think you should give the user the possibility of turning on/off those eyecandies (antialias, transparency, rotation, perspective) as I suspect they could reduce performance. And I must say the route calculation web service often doesn't respond, so it would be wise implementing that in the software (even if it takes hours to give a response).
 |
|
2007-05-21
, 15:30
|
|
Posts: 1,310 |
Thanked: 820 times |
Joined on Mar 2006
@ Irving, TX
|
#27
|
I also vote for the database style map storage. The "one file per tile" just is too much of a burden for the file system.
Feature request: Can you add selectable "smart" auto scale function to the Mapper? How this might work is that the zoom level depends on either:
1) Speed: Maybe at highway cruising speed the screen would cover approx. 5 minutes (selectable?) of travel. Once the speed increase/decrease the map zooms automatically. (However, stop and go traffic might become problematic...)
2) Approaching waypoint/turn: The map zooms in automatically so that the turn can be seen in the screen with maximum detail. For example once the waypoint is within the 5 minutes window (as in 1 above), this zoom function takes over so that the waypoint is always seen in the screen.
Just one idea that could be automated, which I found doing manually when traveling with the MaemoMapper...
Feature request: Can you add selectable "smart" auto scale function to the Mapper? How this might work is that the zoom level depends on either:
1) Speed: Maybe at highway cruising speed the screen would cover approx. 5 minutes (selectable?) of travel. Once the speed increase/decrease the map zooms automatically. (However, stop and go traffic might become problematic...)
2) Approaching waypoint/turn: The map zooms in automatically so that the turn can be seen in the screen with maximum detail. For example once the waypoint is within the 5 minutes window (as in 1 above), this zoom function takes over so that the waypoint is always seen in the screen.
Just one idea that could be automated, which I found doing manually when traveling with the MaemoMapper...
|
|
2007-05-21
, 15:35
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#28
|
Originally Posted by fldude99
Maemo Mapper is a hobby, so I don't plan on ever requiring "fair" compensation. The hobby is compensation enough! I do greatly appreciate the generosity of those who have donated, though.
As long as Gnuite is compensated fairly (not a voluntary contribution), a 2.0 would be great, especially moving away from the millions of files system.
Originally Posted by insert_nick
Unfortunately, since the route direction data is based on free-form text, I have to use a generated voice. I could probably work out a way to record and use simple directions like "Turn left", but without context (like "in 500 feet" or "at Main Street"), it's not very useful.
Something other than the mechanical voice would be great for the "routing" feature.
 |
|
2007-05-21
, 15:41
|
|
Posts: 701 |
Thanked: 21 times |
Joined on Feb 2006
@ Italy
|
#29
|
John, I would like to know (either you ever want to do it or not*) how it would be possible to calculate routes offline, given that MM just loads images that could be highways and streets but could be also 2-century old maps, or satellite images (on which the streets are quite hard to identify on zooms less than 2 or 3).
Will we ever see something like this?
*I say this because lots of people are asking for it, and because it is already into the garage feature request, despite I usually download my route instantly through the phone or the day before, through my internet connection at home.
Will we ever see something like this?
*I say this because lots of people are asking for it, and because it is already into the garage feature request, despite I usually download my route instantly through the phone or the day before, through my internet connection at home.
__________________
--
Does life seem worthwhile to you?
--
Does life seem worthwhile to you?
|
|
2007-05-21
, 15:43
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#30
|
Originally Posted by sherifnix
I have avoided taking screen real estate from the map in favor of context-sensitive (tap and hold) menus, but the advent of the GPS info panel sort of shattered that dream, so maybe it's time to add a toolbar.
I have found MaemoMapper to be a little confusing, and I consider myself fairly a savvy user. I think that using some of the screen real estate to put some basic buttons/shortcuts on the left or right side would be excellent.
Originally Posted by insert_nick
You can tap-and-hold on anywhere on the map and download a route to that location from your current location. As for "Favorites": I have wanted a tap-browsable location selector in Maemo Mapper for some time. The existing text-completion is just not usable enough, especially with the maemo bug(?) that requires you to use the D-Pad to actually select a completion. I'll get to it someday...
Some examples of these shortcuts might be:
(Favorites) - Ala Google Maps, tap it and you get a list of common addresses you use.
(Map to from GPS Location) - So it can map to an address from where you are with just a few touches.
(Map from Address to Address) - With easy access to favorites.
I would have no problem stuffing a 4gb card specifically for MaemoMapper if it provided those functions. I think ease of use, and routing should be your targets for 2.0!
Concerning the database style... I wouldn't mind moving forward and just going with the one file. I've found moving thousands of files back and forth to be painful for my memory cards and I wouldn't miss any merging benefits the old style provides.