I spend most of my day hacking your code, I hope you'll not be to unhappy about the mess I created .

I solved gpsd issue, by removing low level socket processing and replacing it with gpsd-client hight level library. While I don't especially like their API, I think that it is the best way to make sure your software to automatically support next version of gpsd. Don't you agree ? Using low level API might be an other option, but I did not try that path. This being said having gpsd as a daemon handle super user using for access to /dev/ttyUSB0 very nicely and allow opencpn to run without root privilege. It also allows more than one application to use simultaneously a share gps (if ever this could be useful on a boat ???).

Diging GPSd source code, I find that they have an NMEA emulation mode "n" command. Nevertheless as "w+" is the recommended one I stick on their recommendation. At the end of the day parsing one or the other message is more or less equivalent.

wx-widget bug/limitation. The hardest problem came from with wx-widget, when parsing float it make the accemption that they should conform to local language. I'm French and for us it is not "5.025" but "5,025" . Obviously when wxstring.ToDouble receives "5.05" on a French computer it refuses it. The only hack I found was to "unset LANG" environment variable before starting opencpn. I'm sure that placing the right "wxlocale" call at the right place should fix this, but I spend few hours and miserably failed.

About the graphic, the bug still exist . Even though after my hack on nmea.cpp is disappear . I found out a memory violation during some of my test, unfortunately your code does not run with electicfence malloc debugger and I was not able to find the problem.

Conclusion: your last CVS version did not solve my graphic problem, but since I hack nmea.cpp the probleme is not visible anymore .

As said in my previous post, I found that string->float convention routine used by opencpn (wxstring.ToDouble) can fails whenever your system is not set for English locale. In fact any language that uses ',' as decimal punctuation will fail (French, German, ...)

Here after two images with the same config, the same computer, the same maps, ... the only difference is that:

one as LANG=fr_FR.UTF-8 (default for Ubuntu in France)

one second one I unset LANG to shift back to English before starting opencpn.

As you can see, it is clear that LANG creates a problem far biger than GPSd interpretation (what I thought previously). As those wxstring->float conversion routine are use in many different places, it is far easier to "unset LANG" before launching opencpn, than try to fix it up. Further more wxwidget version 3.0 should solve the problem with a new conversion routine wxstring.ToCDouble

Conclusion: French, German, ... if you get the blue screen of death . Do not forget to "unset LANG" before starting opencpn. Or use a small shell script like following one:

This FR/DE language problem regarding the decimal character seems to have first appeared in Ubuntu Version 8 and later. So far, I cannot reproduce on Ubuntu 7. Did you see this on Ubuntu 7? Anyone using opencpn 1.3.0 on non-English Ubuntu Version 7?

We will have to do some thinking to figure out the "right" way to handle this problem until we reach wxWidgets Version 3. Here are some of the issues:

1. BSB raster charts will always (?) use "." in their header definitions.
2. Should opencpn configuration file, for example, use the locale character, or force the "." in strings such as "Lat = 45.0000", "PlanSpeed = 5.5", etc.
3. Same for SENC files. All(?) S57 ENCs use ".", I think....
Lots the consider.....

Sorry to be pedantic, but there is no Ubuntu "version 7" or "version 8". The version numbers look like 9.04 - which means 2009 (9) April (04). The reason this matters is that 8.04 is a way different beast than 8.10, and 9.10 will be significantly different than 9.04. And of course to add to the confusion there's the additional animal alliterations. Thanks!

Scotte...
What ever Linux version you use, the "unset LANG" will work. It might be useless, but it cannot hurt. This until opencpn does not have locale translation .

In fact I tried to "unset" it directly in opencpn code, but unfortunately wxwidget main is hidden and wxlocale is set before you get the opportunity to change it. I have nevertheless no doubt that it could be changed with the right call to wxlocale function, but I'm not an wx.... expert and all my tries fail.

The best waiting option might be to retrieved wxstring.ToCDouble from 3.0 cvs tree and stick it to opencpn code.

I have the same graphics problems using Debian 5.01 64bits non-english, compiled using wx libraries from debian repository. When I install wxWidgets 2.8.10, I couldn't compile.
I got a lot of wxstrings errors!!!!!!

To Dave...

As you see in fulup´s images the WVS only appears in north hemisphere...
and I notice because I live in south!

In wvschart.cpp, WVSChart::RenderViewOnDC, I comment
if(lat_min < 0)
lat_min = 0;
and seems to work. The code above that apparently need some attention.

As I'm afraid your weekend could be too long and boring, here an idea for yet an other new feature for 1.3.2 .

New zoom with mouse's wheel is great , but when switching from one chart to an other one, you loose zoom adjustment. It would be great if opencpn could remember current zoom independently for each chart. Then when navigating in between many charts for one given zone, you would not have to readjust zoom value, after each chart selection.

I personally mostly use CM93 charts, but sometime to double check a detail I shift temporally to SHOM/BBS and then return to CM93, this is exactly when my zoom preference disappear .

I don't want to delay the issue of v. 1.3.2 , BUT, I would be grateful if the following issues could be fixed:
1. Reading and displaying AIS targets
2. Reading and displaying ARPA targets (NMEA data)
3. A listing of ship names within the geographical parameters of the map.
4. Only accepting data within the maps geographical parameters. Or, alternatively within a 200 nm radius of the centre of the map. This will enable users to also connect to existing AIS networks via IP and Port.

What I personally appreciate in OpenCPN is its simplicity. It loads very quickly, and it is not crammed with countless options which I don't even understand (I also use Maxsea with SHOM raster charts. I must know one hundredth of its possibilities.)
As far as I am concerned, adding too many features would not be a good idea, although a mouse wheel zoom would be great.

There are quite a few freely available charts to use with OpenCPN.
The first place to check is this site: Inland Waters Resources
Here you will find links to all US and Brazil charts and much more.
A list of European Inland water charts ( S57 vector charts ) has just been added, among them all Dutch Inland (and some coastal) waters.