would it be possible to integrate the app with Google Latitude?

is that in your plans?

does anyone have the same problem?
in the newest version the app closes when i type enter in the search bar after typing an adress.

Integration with social sites is not planned in near future. It may be implemented later as a plugin for CloudGPS.

Could you try running /opt/cloudgps/cloudgps from terminal and paste the output after the crash here? There should also be /tmp/cloudgps-query-tmp.js file with the results from geocoding provider. Please attach it here.

on this command:
/opt/cloudgps/cloudgps

i get the following output:
drawGLScene GL_ERROR: 500

on the 2nd command it tells me premission denied

Second thing is a file name not a command to execute. Please paste here its contents after search crash.

this file doesnt exist.
i cant find it in this path.
maybe thats the reason why the app closes when i search for something.

You had this file earlier - when you tried to execute it you got 'permission denied' because it is not an executable file. Please check again because I suspect that the crash is caused by different format of returned json response. This file should contain the actual response and it would be fairly easy to spot the crash cause by looking at its contents.

Couple other questions:
1. Which search provider are you using? (it is saved in /home/user/.cloudgps/config.ini in geocodingProvider line)

2. Does the crash occur when using other providers (press s, shift+s to cycle providers)?

If /tmp/*.js file really is not there after the crash it would help to debug the app using gdb. That will require to adding sdk repository, installing gdb, and debugging the app using it. Are you willing to do that? I will guide you of course if you do.

it suddenly worked after reinstalling it!
i dont know why.
thx for help

alright, have been testing 0.5.6 on my travels. some feedback. some you may be already aware of.

soooo smooth. even the new motorola xoom tablet with all new google maps is not this smooth

route tracking
- the line to follow disappears regularly, even when walking.
- the directions and distance dialogue is often wrong and quite hard to read.
- long pressing on the map to bring up the menu to place markers/clear can sometimes end up in odd locations and off the screen making menu unusable.
+ what would be handy with route tracking is if it preloads the tilemaps for the route programmed at current zoom levels. if you change zoom level it should precache again. sometimes when travelling 'fast' on full google satellite hybrid it can get left far behind
+ checking to make sure you are on the current route. if not, re-route from current position.

tiling and rendering (mainly using google satellite/hybrid)
- sometimes there are lines and gaps between the tilemaps in 2d and 3d mode.. they come and go.
- sometimes there are issues rendering cached tiles completely and then it completely stops renderering any tiles cached or not. have to restart to restore. caching issue or renderer locked ?

other
- sometimes when in bad areas and gps reception comes and goes, the map can bounce around from where you are (gps lock) to some place miles away (a-gps) and back and forth. it sometimes closes cloudgps via a clean exit. it doesnt show any error in terminal
- when starting cloudgps, although i have 0.5.6 installed, it says v0.5.5 in the top left corner.

get a couple of errors in terminal sometimes on starting up it closes straight down.

drawGLScene GL_ERROR: 500
and
Segmentation fault


thanks again for the best mapping tool ever!

Thanks for your feedback. There are few problems mentioned that I was not aware of. I will briefly respond to each of your observations.

I have not seen that on my devices. The only thing that I know of is that the route is drawn using all points, capped at constant number of points. So if a route is very long (more than 200-300km in practice) only a part of route will be drawn (from start to some point). This will be addressed in one of next versions.

Could you provide more detailed description of what is happening and maybe some steps to reproduce the problem?

This is first release with routing and this issues are known and will be addressed.

Some info about workarounds: popup menu works properly only when facing north (pressing compass icon will make that) and only in 2d. Markers should work facing any direction but only in 2d.

And of course I will work on these issues on next releases.

CloudGPS does preload some area around current view and forward. If download is too slow to do that precaching will also not work.

You can also use route overview flyby to preload tiles around the route.

That is quite easy. Will be there in one of next versions.

Red lines are drawn around tiles that failed to load or download. This is not really user friendly and I will remove it. I spent some time trying to avoid the gaps but it is quite hard.

At least in 2d when facing north there are no gaps and maps should be pixel-perfect on N900.

Rendering should never get locked. I use CloudGPS quite extensively and it just never does. Tile loading on the other hand can easily get locked. Tile loading uses only two threads on N900 (I benchmarked it and it is the most optimal value for N900). When there are two downloads in progress every new download request gets queued until one of those two finish because starting new thread is just too heavy for N900. Downloading currently uses blocking API and this means that it can easily get stuck waiting for data from network. I plan to rewrite downloading using non-blocking API so that:
- there will be many simultaneous downloads possible (up to twenty for example) per one thread,
- downloads that are in progress and are not necessary anymore will be canceled,
- downloads stalled will be canceled and retried,
- it will use even less resources than current implementation.

This should resolve the issue you described and should also improve responsiveness and tile loading time a lot.

CloudGPS shows your current locations as it is served by backing location service. Currently it is liblocation and it will probably be changed to QT Mobility in next version. No matter which API it uses the behavior should never get close to what you described. I have no idea what could be wrong, what you described clearly negates what is said about GPS in liblocation documentation for Maemo. Are you using CSSU?

There was an dependency error in 0.5.5 package and I reuploaded the same package with dependency fix without changing the version in sources. Package version had to be incremented because otherwise it would be rejected by autobuilder. Preparing the version for MCC2011 was a real marathon for me. I was coding for almost whole two days and nights in a row. I knew that the release will have more bugs than previous one but I wanted to add routing, turn-by-turn directions and route flyby.

GL_ERROR: 500 can be safely ignored. The other thing indicate some stability problem. If you are able to make the app crash please post steps to reproduce the crash here. I am currently not aware of any situations that will make it crash in practice. In theory there are many things that can go bad - for example non-parsable search results will probably make the app crash. I will also use valgrind for next releases which should improve stability.

Thanks for using it and providing feedback. I do not think it is the best yet. But I really hope I will make it the best someday.