Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 31-01-2010, 16:41   #391
Registered User
 
Don B. Cilly's Avatar

Join Date: Dec 2009
Location: Ibiza, Spain
Boat: At the moment, Chrome on Ubuntu I'm afraid, but I take out lots of little ones
Posts: 59
Quote:
Originally Posted by cagney View Post
Here is another patch.
This one works. I got it to compile on Karmic, whereas the giotypes.h one was just making things worse.

- D.
__________________

__________________
Don B. Cilly is offline   Reply With Quote
Old 01-02-2010, 13:20   #392
Registered User
 
jonasaberg's Avatar

Join Date: Jul 2008
Location: Kristiansand, Norway
Boat: Wasa 410
Posts: 291
Regarding quilting

I am not convinced about quilting being much better...

In some Swedish charts, part of the chart is marked "This are is not fully charted. Larger scale chart must be used!"
(Se attached example)

The only way to fix this would be to force the largest scale chart at all times. But that would mean that OpenCPN would jump to a larger scale chart even when you are within the fully charted part of the smaller scale chart. This can be confusing and unnecessary if you make a route through the eastern part of 615, but the application jumps to 6144 for a short period of time.

Nothing new but I will mention anyway:
In these two charts the difference in success with OpenCPNs interpretation of the georeferencing of Transverse Mercator charts is quite clear. The boat symbol is at the same position but the island "jumps" when changing between the charts. Easiest to see in an image browser when jumping between the two pictures.
A part of the jump is that the scale is a little different (1:17800 and 1:17700) - it would be nice if the scale/zoom jumps in CPN were some nice, even multiples instead of some unforeseeable jumps so it is possible to keep the scale when changing charts.

In some areas I imagine quilting would be really nice, in some areas a bit annoying,for example when comparing to a paper chart on the nav table.

So, my vote would be to make the quilting an option and make it a choice to keep the "chart bar"

/Jonas
Attached Thumbnails
Click image for larger version

Name:	615.jpg
Views:	92
Size:	427.5 KB
ID:	12939   Click image for larger version

Name:	6144.jpg
Views:	86
Size:	419.8 KB
ID:	12940  

__________________

__________________
jonasaberg is offline   Reply With Quote
Old 01-02-2010, 16:29   #393
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Status, quilting, dev team, etc...

Thanks Dave...

Quote:
Originally Posted by bdbcat View Post
This is classic organic development. Just barely manageable with 3 or 4 coders. Any more and we would need to stop and write/negotiate some specs. And we may come to that eventually, but I instinctively resist so far.....
re: dev style & team size - completely understood; I like your instincts and think .h / .c(pp) is fine for specs, maybe with a few comments on assumptions and shortcomings. The best projects I know of were done by small teams with minimal specs. Code doesn't lie, but docs (inc comments) almost always do. Good code interfaces/abstractions (struct & class defns...) and good file-to-class mapping will help keep folks from stepping on each other. Nothing new or unknown here.

Quote:
Here is another example to think about: In a quilted model, the notion of a "current chart" (ChartBase *Current_Ch in the code) goes away completely, to be replaced by a "current quilt". The chart select bar at the screen bottom goes away...etc., etc..... Turning quilting on and off will be a great big mode switch, affecting the UI just as much as the code guts.
Makes sense. To make things simpler in the code, then, I hope we remove the current chart and simple chart stack notion entirely, replaced with "active chartset"/"current quilt", whether or not the big mode switch is on or off. That is, I hope we don't have lots of "if (quilting) ... else ..." logic.

I think ideally, all but core display code would use current lat/lon and bounding georefs, and everything else would get mapped from that. The idea being that the lower the level of coordinate mapping and actual chart assignment, the more code can remove concern for "which chart", "what kind", "what projection", etc. It'll be interesting to see how this comes out...and whether additional indexes and inter-chart pointers are needed to quickly do chart selection on X-Y-Z (scale) axes.

All comments from someone not intimately familiar with the whole code base

Good luck, looking forward to it!

Mark
__________________
Psyches is offline   Reply With Quote
Old 01-02-2010, 16:32   #394
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by Don B. Cilly View Post
This one works. I got it to compile on Karmic, whereas the giotypes.h one was just making things worse.

- D.
Thanks Don. Thomas / cagney, let me know when you feel confident that enough compile & runs on linux have been done.

Mark
__________________
Psyches is offline   Reply With Quote
Old 01-02-2010, 21:28   #395
Registered User

Join Date: Dec 2009
Location: Ocean Grove Aus
Boat: adams 40
Posts: 70
Quote:
Originally Posted by jonasaberg View Post
I am not convinced about quilting being much better...

So, my vote would be to make the quilting an option and make it a choice to keep the "chart bar"

/Jonas
Yes please keep the chart bar.

May I also suggest the available charts in the chart bar show all charts that overlap the view window even if not avalable to display at the cursor location . I came up with a problem viewing chart NZ6823_1.kap (as recently discussed in the charts subforum). I was wanting to pan in to read the chart description text at the top edge but in doing so opencpn changed to the larger scale cm93 chart. I suspect why in this case (due to the introverted/concave chart limits bounding polygon) but net effect was I was unable to view this info.

It seems that chart quilting is under development (whilst Dave is away?) I'm not sure what is intended and apolgise for not pre investigating but may I add a comment.

I have worked extensively with CAD and one of concepts commonly adopted is layering. All data is shown within the view window unless that layers data is turned off. Photo editing has the same concept but with the added contol of transparancy eg GIMP transparency slider. To do this in OpenCPN may take a lot of work bit I'd hope that the present quilting development could be done such that it would be possible in future without total rework.

I see big benefits for a transparency control. To be able to superimpose chart datasets to verify accuracy or otherwise between them and display data that user wants to see without the clutter. I recently constructed a bsb "chart" from an aerial photo of our mooring grid which worked well, but I couldn't see at the same time the hard nav data such as lights on the underling cm93 chart. A transparency control might allow that.
__________________
otya is offline   Reply With Quote
Old 01-02-2010, 21:56   #396
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
otya, Jonas,

I think quilting will be important but I agree it poses some challenges, and I'll be interested to see how we can address them well. I also agree we should keep quilting as optional, at least because as jonas mentions, off-the-shelf raster charts have important information outside the chart area, and perhaps for other reasons too. And raster charts have been and will be an important source of nautical chart data.

Yes, Dave is somehow finding time to work on it while away, and all indications show it'll be an optional mode, and really must be for the reasons noted.

otya, I also really like your transparency idea; we've discussed the need for independent registered layer handlers, and transparency will be an important aspect in their control.

For an example of both layering possibilities and current issues with other implementations of quilting, see this geolocation.

On the upside, there is a slider in the upper right that controls the NOAA layer transparency and I've found that very useful. On the downside, note that the quilting implementation manages to chop out part of the south bay channel, and leaves lat-lon scale and other artifacts right in the middle of the chart view, perhaps hiding obstructions.

Mark
__________________
Psyches is offline   Reply With Quote
Old 02-02-2010, 08:20   #397
Registered User
 
sredna's Avatar

Join Date: Dec 2009
Location: Vester Skerninge, Danmark
Boat: Svendborg Senior DEN 38 Kate
Posts: 107
Hi Dave,

Quote:
Originally Posted by bdbcat View Post
Sredna....

Two things going on here:
1. constant ppm values for a Mercator chart are meaningful only measured along parallels of latitude, or the "x" direction without skew. Your code may be choosing the y direction in the wxMin() function....
I do not think that is what causes the problem. Maybe a little bit of it, but i checked, and the miscalculation happens no matter what direction is used. I will check again though.

Quote:
but more importantly....
2. A limitation of the current architecture requires that the ppm scale as passed to SetViewPoint() of a Raster chart must be a binary multiple of the chart native (1x) ppm scale. In 1.3.6 and below, this requirement is met by some code in chart1.cpp which makes this promise. This is done for performance reasons. You will need to do something similar to avoid funny display artifacts at arbitrary scale value.

See
ChartBaseBSB::GetClosestValidNaturalScalePPM(doubl e target_scale, double scale_factor_min, double scale_factor_max);

This limitation for raster charts is going away very soon now, as it is unwieldy for building chart quilts.....
I thought so. If the limitation stays for any case, I think it should be handeled by the SetViewPoint() function, in the spirit of object-oriented programming

Anders
__________________
sredna is offline   Reply With Quote
Old 02-02-2010, 10:09   #398
Registered User

Join Date: Feb 2010
Posts: 619
AIS functionality/debugging

This could fit in many threads, but it's mostly technical, so I put it here:

After some very promising experience sailing with OpenCPN (Congratulations to all the Team, really well done! ) I felt like taking a look inside.

As a simple test/excercise, I made some changes to the the AIS target presentation to bring it more in line with IMO recommendations.

1. highlight the target currently selected for query dialog (a 4-cornered frame around it)
2. remove course predictor/ROT indicator for lost targets
3. mark lost targets with a single strike across

Having done that I went ahead to experiment with more:

4. uniform interpretation of "moored/anchored" (in some cases it used to mean just "low speed", regardless of navigation status)
5. highlight "moored/anchored" and display Class B in special way (this is purely a matter of taste, I've seen the discussions on colors, etc...)

Then I went to experiment with implementation of the

6. missing AIS message types (notably the Aid To Navigation Report - 21).

I tried very carefully to keep the coding style and to be very defensive. What stops me now is the usage of GetInt() function to parse the Bitstring in ais.cpp. In the case of message 18 (and all others) it works as expected; seemingly identical call in the case of message 21 returns wrong Lon/Lat (inconsistent values), but always correct MMSI. When I put in some debugging ThreadMessage(), OpenCPN (or rather WX) crashes on doing a Printf() to a wxString object. I have seen the earlier posts (#220 from blubaju of 2009-10-31) about DualCore crashes. Has this been isolated/solved? Does any of this sound familiar?

Also, maybe someone has some real !AIVDM messages type 21 (AidToNavigation) for testing. I use a hand-made one, which has a potential for error, but not for the inconsistency and the crash, I think. Still some weeks, before I will get real data from the air... Of course, this is just excercise, real implementation of messages 21 etc. would need some discussion first.

I build on Vista32 Business with VC2008, virtual ports s/w from VSPE, single processor affinity set.

If any of the 1-5 above can be useful, I'd be most happy. For 6 I'm still working...

Cheers,

Piotr
__________________
PjotrC is offline   Reply With Quote
Old 02-02-2010, 10:29   #399
Registered User
 
sredna's Avatar

Join Date: Dec 2009
Location: Vester Skerninge, Danmark
Boat: Svendborg Senior DEN 38 Kate
Posts: 107
Hi Piotr,

That all sounds very nice to me

May I recommend using std::cout for debugging? wx strings needs to be converted, for example wxString::mb_str() or wxString::c_str().

Anders
__________________
sredna is offline   Reply With Quote
Old 02-02-2010, 10:33   #400
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Anders (sredna), I suggest you carefully construct a few simple routes with easy-to-calc leg lengths on X & Y varying by lat, on one or a few charts of varying scale (only Mercator proj) , and then determine if it's the distance calc that's off or the map to pix (or something else...),for both X (lon) & Y (lat). That should help narrow the prob down. After looking at the code it wasn't really obvious to me where the prob could be, but I don't know the charts you used or the routes you set up.

Mark
__________________
Psyches is offline   Reply With Quote
Old 02-02-2010, 10:39   #401
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by sredna View Post
Hi Piotr,

That all sounds very nice to me

May I recommend using std::cout for debugging? wx strings needs to be converted, for example wxString::mb_str() or wxString::c_str().

Anders
Piotr, ditto what Anders said. Also, I use VSE2008...it has great debugging support. I was out when blubaju posted, so don't have much context on that issue. If you post details re: GetInt() in ais.cpp, I'll try to help. I don't have AIS support on my boat, but if you'll capture the stream and send it, I should be able to roughly simulate. The current release has an NMEA window, so cut & paste may work just fine (I haven't tried it yet).

Mark
__________________
Psyches is offline   Reply With Quote
Old 02-02-2010, 10:53   #402
Registered User
 
sredna's Avatar

Join Date: Dec 2009
Location: Vester Skerninge, Danmark
Boat: Svendborg Senior DEN 38 Kate
Posts: 107
Quote:
Originally Posted by Psyches View Post
Anders (sredna), I suggest you carefully construct a few simple routes with easy-to-calc leg lengths on X & Y varying by lat, on one or a few charts of varying scale (only Mercator proj) , and then determine if it's the distance calc that's off or the map to pix (or something else...),for both X (lon) & Y (lat). That should help narrow the prob down. After looking at the code it wasn't really obvious to me where the prob could be, but I don't know the charts you used or the routes you set up.

Mark
Hi Mark,
I have found roughly a working formula, details posted in the sf forum (https://sourceforge.net/projects/ope...2/index/page/1). I work on getting a testing version ready for testing, I just have a few more things to fix before I am ready, maybe later tonight (CET).

I use cm93 vector maps for testing, they are precice enough I believe.

Anders
__________________
sredna is offline   Reply With Quote
Old 02-02-2010, 10:54   #403
Registered User

Join Date: Dec 2005
Location: WNA
Boat: Dufour 35
Posts: 3,122
Quote:
Originally Posted by Psyches View Post
Thanks Don. Thomas / cagney, let me know when you feel confident that enough compile & runs on linux have been done.

Mark
Ok Mark, go ahead and include the patch.
Ideally more user should have tested the patch , but after having fired up my eeepc 901 with ubuntu 9.10 and installed without problems it ought to be alright.
Thanks Don for testing on linux!
One thing though, the installation now required the package "libgtk2.0-dev" , which was not necessary earlier.

Thomas
__________________
cagney is offline   Reply With Quote
Old 02-02-2010, 13:26   #404
Registered User

Join Date: Feb 2010
Posts: 619
Anders, Mark...

Thanks for quick answer! I attach the code for case21, i.e. Aid To Navigation report. I think it is an independent piece and can just go into ais.cpp to replace the empty switch case. It is mostly copied verbatim from case 18.

The AtoN sentences I try are:

!AIVDM,1,1,,A,B39RU@P01`@20i7lkkcB0P2001nP,0*14

!AIVDM,1,1,,A,E39RU@P0004810HSrIqT000000000,2*74

!AIVDM,1,1,,A,E39RU@h0004810HSrIqT000000000,2*4c

They do not crash OpenCPN, just produce inconsistent values:

5:07:52 PM: NMEA Data Source is....None
5:10:41 PM: AIS type 18...(MMSI,lon,lat,utcsec:211330370, 8405090, 32821050, 4 ) ....type 18 message decodad always OK
5:10:41 PM: AIS type 18...(MMSI,lon,lat,utcsec:211330370, 8405090, 32821050, 4 )
5:10:41 PM: AIS type 18...(MMSI,lon,lat,utcsec:211330370, 8405090, 32821050, 4 )
5:10:43 PM: AIS type 18...(MMSI,lon,lat,utcsec:211330370, 8405090, 32821050, 4 )
5:11:05 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330371, 262143, 56370507, 8 )
5:11:05 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330371, 134016, 19456, 0 ) ....here the input is the same as 1 above
5:11:07 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330371, 262143, 56370507, 8 ) ... same here again
5:11:34 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330370, 262143, 56370507, 8 ) .... now different
5:11:34 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330370, 134016, 19456, 0 ) ...same again
5:11:36 PM: AIS type 21...(MMSI, lon,lat,utcsec:211330370, 262143, 56370507, 8 ) ...same again
5:11:42 PM: opencpn::MyFrame exiting cleanly...
5:11:43 PM: opencpn::MyApp exiting cleanly...

I know that using the same MMSI for ClassB and AtoN message is not natural, but testing with just two first ones gives the same result. That is why I moved the third case to the end.

Thanks again,

Let me know if you want all the files (ais, chcanv, .h and .cpp).

Piotr
Attached Files
File Type: doc case21.txt.doc (1.8 KB, 32 views)
__________________
PjotrC is offline   Reply With Quote
Old 02-02-2010, 14:07   #405
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by Psyches View Post
Thanks Don. Thomas / cagney, let me know when you feel confident that enough compile & runs on linux have been done.
I should say that this patch fixed my problem with the build on Debian. So I am waiting for it to be incorporated to the source tree, so I can proceed with my Debian packaging.
__________________

__________________
antonm is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Beta Marine Diesel michaelmrc Engines and Propulsion Systems 48 23-03-2016 14:44
Need some technical advice....antennas. Just a Tinch Marine Electronics 15 01-12-2007 16:57
Blue Sea Systems Technical Brief GordMay Electrical: Batteries, Generators & Solar 0 16-03-2007 05:16
technical difficulties witchcraft The Sailor's Confessional 1 30-05-2005 15:09
Dow Corning Technical Manual GordMay The Library 0 12-04-2005 17:25


Our Communities

Our communities encompass many different hobbies and interests, but each one is built on friendly, intelligent membership.

» More about our Communities

Automotive Communities

Our Automotive communities encompass many different makes and models. From U.S. domestics to European Saloons.

» More about our Automotive Communities

Marine Communities

Our Marine websites focus on Cruising and Sailing Vessels, including forums and the largest cruising Wiki project on the web today.

» More about our Marine Communities


Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 10:56.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.