Visit our Popular Forums

transmitterdan · 04-02-2015, 04:53

Quote:

Originally Posted by boat_alexandra

Would it be useful to quilt skewed charts?

Yes, it would stop people asking about it. Along the US intracoastal waterway there are many skewed charts. It "surprises" users when quilting goes off suddenly. They look to the preferences checkbox and see it has gone off. They click it back on but it just goes back off again. This seem illogical to most users I think. In reality when traveling the waterway it isn't a truly difficult problem. But it generates a lot of questions before they use O in anger.

seandepagnier · 04-02-2015, 05:11

I didn't write the quilting routine. I can say that implementing this without opengl support would possibly result in something so slow as to be unusable on most computers.

The quilting support predates opengl support, but I can say with opengl there should be no noticable slowdown and it should probably be supported, as long as they are simply rotated but still in mercator coordinates.

Supporting quilting of mercator with non-mercator charts is non-trivial as the charts would have to be "converted" but it is my intention to support this in the future. This would for example allow mercator charts to be displayed in a polar projection, or some other projection.

bdbcat · 04-02-2015, 11:48

Sean...

Quilting skewed charts will not be trivial, even on OpenGL.
The quilt algorithm relies heavily on wxRegion. wxRegion considers skewed regions to be composed of a very large number of rectangles, each of which is a single scan line. So the iterative painting of a window, hit testing, etc. even in GL, requires lots of loops.

We now go through some hoops to avoid working with any wxRegions that have any skewed segments, since it is very slow.

What will fix this would be a whole new concept of "Screen Regions", defined by some vector notion instead of a raster notion. And that will be a non-trivial piece of work.

Of course, simple rendering of skewed charts with OpenGL may by done by leaving the skewed charts until last, and simply rendering them overtop of whatever else may be aleady on the screen, using a suitable clip region. Here OpenGL rotation will help. But the hit test and data structure problem remains.

More thoughts appreciated.

Sorry
Dave

transmitterdan · 04-02-2015, 14:26

Dave,

Do you think it is feasible to pre-process skewed raster charts once (similar to the SENC conversion process) into a north up format and thus avoid doing it in real time?

seandepagnier · 04-02-2015, 16:48

Quote:

Originally Posted by bdbcat

Sean...

Quilting skewed charts will not be trivial, even on OpenGL.

The quilt algorithm relies heavily on wxRegion. wxRegion considers skewed regions to be composed of a very large number of rectangles, each of which is a single scan line. So the iterative painting of a window, hit testing, etc. even in GL, requires lots of loops.

We now go through some hoops to avoid working with any wxRegions that have any skewed segments, since it is very slow.

I feared this without looking at the code closely. My point was that in theory it's possible to support with good performance using opengl.

Quote:

What will fix this would be a whole new concept of "Screen Regions", defined by some vector notion instead of a raster notion. And that will be a non-trivial piece of work.

I think this is eventually needed so that we can support many types of projections besides mercator. Maybe the screen regions could handle cm93 cells that are highly irregular better.

Something is needed for overlapping charts (moving mouse over charts changes alpha blend of charts in quilt) This also allows comparison to vector/raster much easier and allows for chart corrections much more easily. For example, google earth images are nearly perfect they can usually be used to correct less accurate charts.

Quote:

Of course, simple rendering of skewed charts with OpenGL may by done by leaving the skewed charts until last, and simply rendering them overtop of whatever else may be aleady on the screen, using a suitable clip region. Here OpenGL rotation will help. But the hit test and data structure problem remains.

More thoughts appreciated.

This would be a way to maybe to hack in support, but I think it will cause more problems (anomalies) than it would solve if these charts aren't specified the same way as the other ones in the quilt which relies on Regions.

seandepagnier · 04-02-2015, 16:52

Quote:

Originally Posted by transmitterdan

Dave,

Do you think it is feasible to pre-process skewed raster charts once (similar to the SENC conversion process) into a north up format and thus avoid doing it in real time?

This is also not possible because the boundaries of the valid chart region are not parallel to the meridians and parallels.

transmitterdan · 04-02-2015, 18:32

Quote:

Originally Posted by boat_alexandra

This is also not possible because the boundaries of the valid chart region are not parallel to the meridians and parallels.

I was thinking that the skewed chart would be converted to a "new chart" wherein it was north up and rectangular (in a projection sense not literally) like a normal non-skewed chart. The complex transformations to do that would only be done once. There would be extra space added to the chart to fill the surrounding region not taken up by the skewed graphical data. If this "extra" space was transparent it would not obscure any other adjacent charts. The user should not be able to tell the difference. This region would have to be transparent in the visual as well as interactivity sense. If a mouse is clicked in the transparent region the click would have to be recognized as falling through the "invisible" region and onto the "visible" adjacent chart.

wdkester · 04-02-2015, 19:20

Quote:

Originally Posted by transmitterdan

Quilting will come back on automatically once you get off the skewed chart. Try panning over away from the skewed chart or just selecting a different chart using the blue or green bars at the bottom of the screen. Skewed charts are indicated at the bottom with a red diagonal strip in the blue bar. Click one that isn't skewed.

This issue does not arise for ENC charts.

I don't think I have turned quilting off since the DMA chart project. I've been creating a ICWW chart group so have been screwing around with skewed charts a lot. Try this:

1. Pan down the East Coast until you get to 34 45N in the middle of your screen. Make sure tha quilting is on.
2. Zoom in a bit until and select 12208-1. You should have Rudee inlet at the top of your screen zoom until you get a 1:1 scale approx.
3. Pan to the west until you see 12206-2 which is part of the ICWW. It's easy for me because I have a route. You should see a section of the ICWW running E to W and a skewed chart NW to SE.
4.Select 12206-2 and pan back to the East until the the skewed chart disappears.
5. You may have to wait a few sec but an unskewed chart(12208-1 in my case) will appear on the screen. Pan South a bit and you will see its borders; not quilted with anything. I've tried this several times and once a smaller scale unskewed chart was selected off screen but you could see that the chart bar had turned light blue for this chart.
6. Check options and quilting is not set
7. Pan around and charts will pop in and out skewed and unskewed, but quilting won't reset itself.
8. However when I manually (as you suggested) select a chart from the chart bar, quilting magically reappears.

I think this will happen anywhere up and down the coast. The key may be to select a skewed chart and then pan to the East where there are no unskewed charts.

I think this is not a big deal, once I understood it. But I think I would rather have quilting reset (if it was set in the first place) if a quiltable chart is displayed.

I guess I have too much time on my hands as I have created a chart group of ICWW charts which nullifies the behavior above .

seandepagnier · 04-02-2015, 23:13

Quote:

Originally Posted by transmitterdan

I was thinking that the skewed chart would be converted to a "new chart" wherein it was north up and rectangular (in a projection sense not literally) like a normal non-skewed chart. The complex transformations to do that would only be done once. There would be extra space added to the chart to fill the surrounding region not taken up by the skewed graphical data. If this "extra" space was transparent it would not obscure any other adjacent charts. The user should not be able to tell the difference. This region would have to be transparent in the visual as well as interactivity sense. If a mouse is clicked in the transparent region the click would have to be recognized as falling through the "invisible" region and onto the "visible" adjacent chart.

Handling the rotation isn't the issue with opengl at least, but so far I don't think we support invisible regions based on pixel values, only on the chart boundary in the header.

.Paul. · 05-02-2015, 08:52

The NOAA Chart Reprojector can be used to make north-up Mercator KAP charts from skewed ones. It also reprojects transverse Mercator, universal transverse Mercator, polyconic and Lambert conformal conic KAP charts to Mercator. Conversions to other projections are possible, but not of much interest when quilting is the goal.

NOAA's reprojector was written to work with BSB 2 charts. It converts the image to the new projection, and it makes some changes in the KAP header corresponding to the new image. The REF table is updated to work with the new image. The border polygon (PLY) table does not change for the projection. When a BSB 3 chart is processed, it does NOT calculate new GeoRef polynomial coefficients (WPX, WPY, PWX, PWY), and the ERR table is not updated. In general, the polynomials and ERR table values will be wrong. OpenCPN detects big errors in the polynomials, but small errors might slip by. A simple fix is to delete the polynomial coefficients and REF table from the KAP header. The VER/3x should also be changed to VER/2 in case the chart gets processed by a program that uses the version number. I change the KAP header in a copy of the original file before feeding it into the reprojector. Alternatively, the fixes could be made in the KAP after it is output from the reprojector.

The reprojector can change the horizontal datum. I have not tested this.

In addition to making charts that can be quilted from skewed or non-Mercator ones, the reprojector changes NOAA's Lambert conformal conic KAP charts into Mercator charts that OpenCPN can use.

Charts that are output by the reprojector are not official navigation charts.

I don't recommend the NOAA Chart Reprojector for casual users.

Paul

K_V_B · 05-02-2015, 10:07

On my Mac OpenCPN 4.0 crashes when you try to access the help function. This is on yosemite
To reproduce: Start OpenCPN. Select "about", then "help". OpenCPN immediately crashes.

Krist

CarCode · 05-02-2015, 13:30

Krist,
which browser you have? The 'help' should start the standard browser in your system. I have Firefox 35.0.1 with Yosemite 10.10.2 as standard and no crash.
Gerhard

ptulp · 06-02-2015, 09:08

Quote:

Originally Posted by K_V_B

On my Mac OpenCPN 4.0 crashes when you try to access the help function. This is on yosemite
To reproduce: Start OpenCPN. Select "about", then "help". OpenCPN immediately crashes.

Krist

I also see this problem on Maverick 10.9.5.
The problem is with wxWidgets 3.0.2, where the function MyFrame::LaunchLocalHelp using the depreciated call GetLanguageInfo( wxLANGUAGE_DEFAULT )->CanonicalName;
This is replaced by the call GetLanguageCanonicalName( wxLANGUAGE_DEFAULT );

So when I replace the following code I don't see the problem:
void MyFrame::LaunchLocalHelp( void ) {
#ifdef __WXOSX__
wxString def_lang_canonical = wxLocale::GetLanguageCanonicalName( wxLANGUAGE_DEFAULT );
#else
wxString def_lang_canonical = wxLocale::GetLanguageInfo( wxLANGUAGE_DEFAULT )->CanonicalName;
#endif
wxString help_locn = g_SData_Locn + _T("doc/help_");