Beta Test / Technical

[Don B. Cilly]

Originally Posted by cagney

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.

[jonasaberg]

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

[Psyches]

Thanks Dave...

Originally Posted by bdbcat

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.

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]

Originally Posted by Don B. Cilly

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

[philocat]

Originally Posted by jonasaberg

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.

[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

[sredna]

Hi Dave,

Originally Posted by bdbcat

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.

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

[PjotrC]

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

[sredna]

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

[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]

Originally Posted by sredna

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

[sredna]

Originally Posted by 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

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

[cagney]

Originally Posted by Psyches

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

[PjotrC]

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

[antonm]

Originally Posted by Psyches

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.