Active Topics

 



Notices


Reply
Thread Tools
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#71
Originally Posted by penguinbait
I recieved no response from the last time, so I will try again. Any chance maemo-mapper will work with TerraServer, they have better resolution than google maps and appear to be free to use and distribute, see below.


http://terraserver.microsoft.com/about.aspx?n=AboutFaq

Are there any restrictions on what I can do with the images that I download?

The images from the U.S. Geological Survey, and are freely available for you to download, use and re-distribute. The TerraServer team and the USGS appreciate credit for their work on this project by displaying the message "Image courtesy of the USGS".
Sorry for missing your question to first time around. I have no plans at the moment to get Maemo Mapper to work with TerraServer.

But if anyone wants to write a patch (as was done to incorporate the initial Google Maps satellite data), feel free to do so.
 
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#72
Originally Posted by mwiktowy
If it is a choice between a high CPU fancy rubber-band selection or a simple low CPU remember the last two taps, I would be very happy sticking with this existing two taps solution. It is much better than those fields being left blank.

In my experience, the current usability problem with the current approach is that the map scrolls when you are trying to make your selection ... often times scrolling your intended second point off the screen. The solution is to zoom out to a bigger area and then manually change the zoom selection back to your intended scale to download.

It would be great if the selection box idea could be done efficiently but I am pretty happy with the esisting simple approach.
In my currently planned ConOp, there will be no CPU-intensive "rubber-banding" in the final solution. I'm not going to force users to needlessly drag their potentially-old stylus across their potentially-fragile screen just to define a download area. There will simply be a "Select from Map" button on the "Download by Area" dialog box that will hide the dialog box and allow the user to select (with visual feedback) opposite corners of their desired download area - in the future, it may even allow you to draw arbitrary polygons, but let's take it one step at a time.

Basically, you'll be "drawing" your download area on the map, and when you're done, you'll be taken back to the "Download by Area" dialog box and the coordinates will be automatically entered into the fields.

Not only is this more intuitive than the "use last two center points" approach, it's also less obtrusive, since CPU is not used to continuously keep track of your previous center points (on the wild chance that the user is actually wanting those center points for the "Download by Area" dialog box).

But the "use last two center points" was simple to implement and is in the code now - it's a stop-gap until I design and implement something better.
 
penguinbait's Avatar
Posts: 3,096 | Thanked: 1,525 times | Joined on Jan 2006 @ Michigan, USA
#73
No problem, I know you are quite busy with your app, and we all appreciate it. I am unfortunately a unix admin, not a programmer. Although I may play around with the web API.

Any people out there who can program ,hook it up

Originally Posted by gnuite
Sorry for missing your question to first time around. I have no plans at the moment to get Maemo Mapper to work with TerraServer.

But if anyone wants to write a patch (as was done to incorporate the initial Google Maps satellite data), feel free to do so.

Hopefully someone will hook it up, its way better maps than google, I think I already mentioned that

Thanks again,
 
Posts: 373 | Thanked: 56 times | Joined on Dec 2005 @ Ottawa, ON
#74
Since getting my shiny new GPS module and trying it out in some typical use-cases I came up with another item on my wishlist for an already extremely useful app.

Dynamic Zoom levels:

I find myself manually shifting back and forth between different zoom levels to see different details. Some of the reasons for shifting zoom are:
- see small street names
- see more detailed maps that have street names of smaller streets
- have a consistant scale of tiles and avoid ugly interfaces between different rez maps joined together
- near my destination and looking to fine tune directions

I was wondering if there was some effective ways to automate this and came up with a few dynamic zooming strategies that might be useful and reduce the amount of interaction needed between the driver and the 770:

1) Speed dependant zoom level (constant time width map)
- This mode would zoom in as your speed decreases. So as you are cruising along the highway, the map will zoom out. If you are in a residential neighbourhood where the speed limit is lower, the map will zoom in to give you navigational detail now that you are going a speed where you can deal with more info. In essence, the width of the displayed map is what would you could drive in a fixed time ... regardless of your speed. The zoom buttons will adjust the upper zoom scale bound that your speed range is divided into (i.e. change slope of speed vs. zoom level line). Some jitter control is needed to avoid maps flipping back and forth rapidly at certain threshold speeds.

2) Best Available Zoom (show best 1X scaled map tiles)
- This mode just shows you the most detailed map in your cache at the native zoom level of the map tile. It would also pick the best zoom level where all the maps displayed on screen are from the same zoom level to avoid seams between different scaled maps. People can fill their cache with detailed city maps of their destination or important turns and zoomed out maps of the freeway in between and the dynamic zoom will follow along without having to do any cache image scaling. Zoom buttons adjust lower floor of zoom levels.

3) Closest to Zoom level (constant distance with consistant zoom level tiles across screen)
- This mode is closest to the current manual zoom selection and will keep the manually selected zoom level but will pick tiles from a zoom level that can be scaled uniformly to fill the screen. If the entire screen can be filled with tiles of the appropriate zoom level then it will work just like the manual zoom does now. If the displayed areas needs tiles from different zoom levels, it will pick the tiles from the highest zoom level shown and scale them up. For example, if the users selects a zoom level of 2 and some zoom level 3 tiles will need to be used and scaled up, then only zoom level 3 tiles will be used and scaled up instead of partially using the available 2's. This mode is purely for a consistant look across the screen by getting rid of any seam between mismatching scales of map tiles. Zoom buttons adjust desired distance across screen as it does now.

Just some thoughts for consideration for addition to the todo list ... sorry for the long post.
 
Posts: 177 | Thanked: 4 times | Joined on Apr 2006 @ Wirral, UK
#75
gnuite,
How can I get rid of some stored addresses in the GPS Driving Directions web service?
 
teemu's Avatar
Posts: 40 | Thanked: 1 time | Joined on Nov 2005 @ Espoo, Finland
#76
Hi,

I'm still getting the "Error parsing GPX file" errors when downloading the route from Maemo Mapper v0.2.3. Any idea what might be causing this? If I download the route using the web service and after re-saving it using the Notes application the route works. So seems like there is some format problem or something.

Sorry if this issue has already been dealt with. These threads are just so long that I don't have time to go them through.
__________________
Teemu

www.teemuharju.net
 
Posts: 26 | Thanked: 2 times | Joined on Dec 2005
#77
Originally Posted by teemu
Hi,

I'm still getting the "Error parsing GPX file" errors when downloading the route from Maemo Mapper v0.2.3. Any idea what might be causing this? If I download the route using the web service and after re-saving it using the Notes application the route works. So seems like there is some format problem or something.

Sorry if this issue has already been dealt with. These threads are just so long that I don't have time to go them through.
The problem has been reported previously, but has not been solved. It appears to me that any non-ASCII character in the .gpx file will lead to a parsing error being reported. This takes away some of the fun from an otherwise brilliant application, for those located in in countries where road and city names contain non-ASCII characters. I vote for inserting this problem into the to-do list.

Regards,
Reiner
 
Posts: 13 | Thanked: 0 times | Joined on Feb 2006
#78
Originally Posted by pdq
The problem has been reported previously, but has not been solved. It appears to me that any non-ASCII character in the .gpx file will lead to a parsing error being reported. This takes away some of the fun from an otherwise brilliant application, for those located in in countries where road and city names contain non-ASCII characters. I vote for inserting this problem into the to-do list.

Regards,
Reiner
Yep, I think this is a very high priority staff... all the route system is not functional outside English countries.

Regards
 
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#79
Originally Posted by pdq
The problem has been reported previously, but has not been solved. It appears to me that any non-ASCII character in the .gpx file will lead to a parsing error being reported. This takes away some of the fun from an otherwise brilliant application, for those located in in countries where road and city names contain non-ASCII characters. I vote for inserting this problem into the to-do list.

Regards,
Reiner
Thanks for your feedback. I haven't yet figured out why non-ASCII characters cause parsing errors - the XML parsing code should be able to handle arbitrary UTF-8, although I haven't tested this fully. I will attempt to address all of these kinds of issues as I introduce localization into the codeline.

Feel free to investigate the error yourself and submit a patch if you need a fix faster than I can provide one.

I apologize for the inconvenience.

On a side note, which has nothing to do with your post: already it seems that this project is spiraling out of my control and that I should just release it into the garage and let everyone else hack at it as they please.

Maemo Mapper was everything that I wanted even before I released v0.1. I've been using it since January, when I first got my GPS receiver, but I thought I would put in the extra effort to make it accessible to the public. I've been trying to be accommodating, and although I have gotten a lot of great feedback regarding some things, like internationalization and color customization for the color-blind, there are just too many suggestions for just one guy with a full-time job to handle.

I use Maemo Mapper v0.2.3 because it is light, fast, and it fits exactly with my use cases. I don't want to use it as a speedometer. I don't want to use it with satellite maps or with maps that require "nudging" or multiple map repositories. I don't want to use it to find the nearest pizza joint. I don't want to spin donuts in my parking lot and use Maemo Mapper to measure the turning radius of my car. I don't even want to use it to download maps onto the device. My Map Cache and my use cases have not changed since January.

But some people do want to do those kind of things. And a lot of these things make perfect sense, like map downloading. Everyone has different use cases. So eventually some of this functionality may go into Maemo Mapper. But I don't think that I'll be using any version past v0.2.3 (except when I port it to the 2006 OS), because at 92k installed it is already bigger than I wanted it to be. Yeah, 92k is not that big, but lean-and-mean was the whole reason that I ditched GPS Drive.

I'm afraid that once collaborate development begins (through the garage or otherwise), Maemo Mapper will eventually turn into GPS Drive. Which would be cool with me, because like I said, I'm fine with it as is right now, and I don't plan on using any version after the upcoming 2006 OS version (except for testing, obviously).

Sorry for the rant; just had to get that off my chest. I appreciate all of your suggestions, I really do. I just want to prepare you in case your suggestion doesn't actually make it into Maemo Mapper. You can always add your particular suggestion on your own, as Armin has done. That's what open source is for. And someday, the subversion repo will be open enough that you guys can go crazy.
 
Posts: 4 | Thanked: 0 times | Joined on May 2006
#80
Originally Posted by mwiktowy

...I am finding that there is the odd map that gets downloaded from Google Maps that is in the wrong scale (I believe this is Google's fault as it seems to cough up random things when the server is busy ...
What happens is that you see a previous zoom level image. The image for the current zomm is corrupted. The file exists but the image is corrupted(might not even be an image). Maemo check for the file name and find the file there so it doesn't download, but cant load image over the previous square, so it doesen't get refreshed. You have to (as you noticed) delete that corrupted file so it will get downloaded. It is a game of hide and seek, but if you move them to windows folder, but if you dump the map cache into lets say picasa, you can see which pictures are not coming up, can't be displayed, and delete those from you cache, after that they will get downloaded again.
 
Reply


 
Forum Jump


All times are GMT. The time now is 08:43.