|
|
31-01-2010, 15:41
|
#391
|
Registered User
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
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.
|
|
|
01-02-2010, 12:20
|
#392
|
Registered User
Join Date: Jul 2008
Location: Kristiansand, Norway
Boat: Wasa 410
Posts: 309
|
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
|
|
|
01-02-2010, 15:29
|
#393
|
Registered User
Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
|
Status, quilting, dev team, etc...
Thanks Dave...
Quote:
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.
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
|
|
|
01-02-2010, 15:32
|
#394
|
Registered User
Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
|
Quote:
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
|
|
|
01-02-2010, 20:28
|
#395
|
Registered User
Join Date: Dec 2009
Location: Vic Aust.
Boat: Seawind1160
Posts: 72
|
Quote:
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.
|
|
|
01-02-2010, 20:56
|
#396
|
Registered User
Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
|
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
|
|
|
02-02-2010, 07:20
|
#397
|
Registered User
Join Date: Dec 2009
Location: Vester Skerninge, Danmark
Boat: Svendborg Senior DEN 38 Kate
Posts: 107
|
Hi Dave,
Quote:
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.
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
|
|
|
02-02-2010, 09: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
|
|
|
02-02-2010, 09:29
|
#399
|
Registered User
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
|
|
|
02-02-2010, 09:33
|
#400
|
Registered User
Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
|
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
|
|
|
02-02-2010, 09:39
|
#401
|
Registered User
Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
|
Quote:
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
|
|
|
02-02-2010, 09:53
|
#402
|
Registered User
Join Date: Dec 2009
Location: Vester Skerninge, Danmark
Boat: Svendborg Senior DEN 38 Kate
Posts: 107
|
Quote:
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
|
|
|
02-02-2010, 09:54
|
#403
|
Registered User
Join Date: Dec 2005
Location: Helsingborg
Boat: Dufour 35
Posts: 3,891
|
Quote:
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
|
|
|
02-02-2010, 12: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
|
|
|
02-02-2010, 13:07
|
#405
|
Registered User
Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
|
Quote:
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.
|
|
|
|
|
Thread Tools |
Search this Thread |
|
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
Advertise Here
Recent Discussions |
|
|
|
|
|
|
|
|
|
|
|
|
Vendor Spotlight |
|
|
|
|
|