projections alpha test

[LeaseOnLife]

Originally Posted by ChuckSK

Check this out!

Attachment 104559


chuck

Way cool. Just need a compiled version for my Win7 Boat-PC and I am in, helping testing in my home waters...

Dirk

[seandepagnier]

Originally Posted by ChuckSK

Check this out!

Attachment 104559


chuck

Nice.. so it works on windows. Did you manage to play around with it any more? Panning should be faster in course up mode for example (especially with tide stations enabled) but quilting ENC in course up should also work (broken in master) and of course all the projections (gnomonic is my favorite) which you can access with the context menu.

There is even an experimental projection view (not really fully implemented with the < > keys)

Did anything break seriously? I really want to merge this work but it's a lot of changes and it's certain to have cause problems I cannot find.

[ChuckSK]

OK Sean, this is too much.

Quilted skewed charts, rotated, tilted, with AIS, tides and currents.



The only important issue is CM93 charts don't display; singly or quilted.

I will attempt a pull request with the tweaks needed to satisfy windows.

chuck

[ChuckSK]

Sean

I realized I cannot submit a pull request on your fork. Here is a diff file instead. Not every change was tested to determine if it is absolutely necessary.

diff --git a/include/LLRegion.h b/include/LLRegion.h
index c44c761..7ddb834 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -45,7 +45,7 @@ struct contour_pt
 typedef std::list<contour_pt> poly_contour;
 class LLBBox;
 
-class work;
+struct work;
 class LLRegion
 {
 public:
diff --git a/src/LLRegion.cpp b/src/LLRegion.cpp
index bcfc4c1..9a3d941 100644
--- a/src/LLRegion.cpp
+++ b/src/LLRegion.cpp
@@ -174,7 +174,7 @@ static inline int ComputeState(const LLBBox &box, const contour_pt &p)
 
 inline bool TestPoint(contour_pt p0, contour_pt p1, double x, double y)
 {
-    contour_pt p = {.y=y, .x=x};
+    contour_pt p = { y, x};
     return cross(vector(p0, p1), vector(p0, p)) < 0;
 }
 
@@ -254,7 +254,8 @@ struct work
     LLRegion &region;
 };
 
-static void LLvertexCallback(GLvoid *vertex, void *user_data)
+
+static void CALLBACK LLvertexCallback(GLvoid *vertex, void *user_data)
 {
     work *w = (work*)user_data;
     const GLdouble *pointer = (GLdouble *)vertex;
@@ -263,27 +264,28 @@ static void LLvertexCallback(GLvoid *vertex, void *user_data)
     w->contour.push_back(p);
 }
 
-static void LLbeginCallback(GLenum which) {}
+static void CALLBACK LLbeginCallback(GLenum which) {
+}
 
-static void LLendCallback(void *user_data)
+static void CALLBACK LLendCallback(void *user_data)
 {
     work *w = (work*)user_data;
     if(w->contour.size()) {
         w->region.contours.push_back(w->contour);
         w->contour.clear();
-    }
+    }    
 }
 
-static void LLcombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4],
+static void CALLBACK LLcombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4],
                       GLdouble **dataOut, void *user_data )
 {
     work *w = (work*)user_data;
-    GLdouble *vertex = w->NewData();
-    memcpy(vertex, coords, 3*(sizeof *coords));
-    *dataOut = vertex;
+    GLdouble *vertex = w->NewData(); 
+    memcpy(vertex, coords, 3*(sizeof *coords)); 
+    *dataOut = vertex;    
 }
 
-static void LLerrorCallback(GLenum errorCode)
+static void CALLBACK LLerrorCallback(GLenum errorCode)
 {
     const GLubyte *estring;
     estring = gluErrorString(errorCode);
@@ -298,7 +300,7 @@ void LLRegion::Intersect(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO);
+    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO, false);
 }
 
 void LLRegion::Union(const LLRegion& region)
@@ -308,7 +310,7 @@ void LLRegion::Union(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_POSITIVE);
+    Put(region, GLU_TESS_WINDING_POSITIVE, false);
 }
 
 void LLRegion::Subtract(const LLRegion& region)
@@ -416,15 +418,15 @@ void LLRegion::PutContours(work &w, const LLRegion& region, bool reverse)
     }
 }
 
-void LLRegion::Put(const LLRegion& region, int winding_rule, bool reverse)
+void LLRegion::Put( const LLRegion& region, int winding_rule, bool reverse)
 {
     work w(*this);
-
-    gluTessCallback(w.tobj, GLU_TESS_VERTEX_DATA, (GLvoid (*) ()) &LLvertexCallback);
-    gluTessCallback(w.tobj, GLU_TESS_BEGIN, (GLvoid (*) ()) &LLbeginCallback);
-    gluTessCallback(w.tobj, GLU_TESS_COMBINE_DATA, (GLvoid (*) ()) &LLcombineCallback );
-    gluTessCallback(w.tobj, GLU_TESS_END_DATA, (GLvoid (*) ()) &LLendCallback);
-    gluTessCallback(w.tobj, GLU_TESS_ERROR, (GLvoid (*) ()) &LLerrorCallback);
+   
+    gluTessCallback( w.tobj, GLU_TESS_VERTEX_DATA, reinterpret_cast<_GLUfuncptr> ( &LLvertexCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_BEGIN, reinterpret_cast<_GLUfuncptr>  ( &LLbeginCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_COMBINE_DATA, reinterpret_cast<_GLUfuncptr>  ( &LLcombineCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_END_DATA, reinterpret_cast<_GLUfuncptr>  ( &LLendCallback ) );
+    gluTessCallback( w.tobj, GLU_TESS_ERROR, reinterpret_cast<_GLUfuncptr> ( &LLerrorCallback ) );
     gluTessProperty(w.tobj, GLU_TESS_WINDING_RULE, winding_rule);
     gluTessProperty(w.tobj, GLU_TESS_BOUNDARY_ONLY, GL_TRUE);
 //    gluTessProperty(w.tobj, GLU_TESS_TOLERANCE, 1e-5);
@@ -436,7 +438,7 @@ void LLRegion::Put(const LLRegion& region, int winding_rule, bool reverse)
     PutContours(w, *this);
     PutContours(w, region, reverse);
     contours.clear();
-    gluTessEndPolygon(w.tobj);
+    gluTessEndPolygon( w.tobj ); 
 
     Optimize();
     m_box.SetValid(false);
diff --git a/src/bbox.cpp b/src/bbox.cpp
index ef1aee5..9347834 100644
--- a/src/bbox.cpp
+++ b/src/bbox.cpp
@@ -320,7 +320,7 @@ wxBoundingBox& wxBoundingBox::operator+(wxBoundingBox &other)
 // makes a boundingbox same as the other
 wxBoundingBox& wxBoundingBox::operator=( const wxBoundingBox &other)
 {
-    assert (other.GetValid());
+ //   assert (other.GetValid());
 
     m_minx = other.m_minx;
     m_maxx = other.m_maxx;
diff --git a/src/canvasMenu.cpp b/src/canvasMenu.cpp
index 3f41e26..16b89a8 100644
--- a/src/canvasMenu.cpp
+++ b/src/canvasMenu.cpp
@@ -276,7 +276,7 @@ wxMenu *MenuAppend2( wxMenu *menu, wxString label)
 #if defined(__WXMSW__) || defined(__OCPN__ANDROID__)
    
     wxFont *qFont = GetOCPNScaledFont(_("Menu"));
-    item->SetFont(*qFont);
+//    item->SetFont(*qFont);
 #endif
     menu->Append(wxID_ANY, label, item);
     return item;
diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index 5fc26d8..a535088 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -1721,7 +1721,8 @@ void glChartCanvas::RenderChartOutline( int dbIndex, ViewPort &vp )
 
         bool begin = false, sml_valid = false;
         double sml[2];
-        float lastplylat, lastplylon;
+        float lastplylat = 0.0;
+        float lastplylon = 0.0;
         for( int i = 0; i < nPly+1; i++ ) {
             if(nAuxPlyEntries)
                 ChartData->GetDBAuxPlyPoint( dbIndex, i%nPly, j, &plylat, &plylon );
@@ -2582,10 +2583,10 @@ void glChartCanvas::DrawRegion(ViewPort &vp, const LLRegion &region)
 
     GLUtesselator *tobj = gluNewTess();
 
-    gluTessCallback(tobj, GLU_TESS_VERTEX_DATA, (GLvoid (*) ()) &glVertex3dv);
-    gluTessCallback(tobj, GLU_TESS_BEGIN, (GLvoid (*) ()) &glBegin);
-    gluTessCallback(tobj, GLU_TESS_END_DATA, (GLvoid (*) ()) 0);
-    gluTessCallback(tobj, GLU_TESS_END, (GLvoid (*) ()) &glEnd);
+    gluTessCallback( tobj, GLU_TESS_VERTEX, reinterpret_cast <_GLUfuncptr>  ( &glVertex3dv ) );
+    gluTessCallback( tobj, GLU_TESS_BEGIN, reinterpret_cast <_GLUfuncptr> ( &glBegin ) );
+   // gluTessCallback( tobj, GLU_TESS_END_DATA, reinterpret_cast <_GLUfuncptr> ( 0 ) );
+    gluTessCallback( tobj, GLU_TESS_END, reinterpret_cast <_GLUfuncptr> ( &glEnd ) );
 
     gluTessNormal( tobj, 0, 0, 1);
 
@@ -2992,7 +2993,8 @@ void glChartCanvas::RenderRasterChartRegionGL( ChartBase *chart, ViewPort &vp, L
             }
 
             float *coords;
-            float convertedcoords[2*tile->m_ncoords];
+            float *convertedcoords = new float[2 * tile->m_ncoords];
+          //  float convertedcoords[2*tile->m_ncoords];
             if(use_norm_vp)
                 coords = tile->m_coords;
             else {
@@ -3011,6 +3013,8 @@ void glChartCanvas::RenderRasterChartRegionGL( ChartBase *chart, ViewPort &vp, L
 
             if(!texture)
                 glEnable(GL_TEXTURE_2D);
+
+            delete [] convertedcoords;
         }
     }
 
diff --git a/src/viewport.cpp b/src/viewport.cpp
index 48da635..0c64a0d 100644
--- a/src/viewport.cpp
+++ b/src/viewport.cpp
@@ -133,6 +133,9 @@ ViewPort::ViewPort()
     pix_height = pix_width = 0;
     b_MercatorProjectionOverride = false;
     lat0_cache = NAN;
+    m_projection_type = 1;
+    pitch = 0;
+
 }
 
 // TODO: eliminate the use of this function
@@ -144,7 +147,8 @@ wxPoint ViewPort::GetPixFromLL( double lat, double lon )
 
 wxPoint2DDouble ViewPort::GetDoublePixFromLL( double lat, double lon )
 {
-    double easting, northing;
+    double easting = 0;
+    double northing = 0;
     double xlon = lon;
 
     /*  Make sure lon and lon0 are same phase */

chuck

[LeaseOnLife]

Sean

Thanks to Chuck I have a version of your branch to play with on Windows7. I tested a few simple cases, displaying Polyconic as Polyconinc. Grid lines match well and the waypoints and tracks did not end up on land as with current/main 4.xx series. Displaying Polyconic as Mercator works well here too. Nice work!

But trying to do a Polyconic => Polar or Polyconic => Gnomonic causes latitude gridlines on the chart not to match Opencpn's overlay grid. Try with any of the freely available NOAA RNC for the Great Lakes, my home turf is 14852_1.kap

Dirk

[did-g]

Hi,

Originally Posted by boat_alexandra

Did anything break seriously? I really want to merge this work but it's a lot of changes and it's certain to have cause problems I cannot find.

Nice, but:
- it doesn't compile with gcc 4.6.3, in src/LLRegion.cpp
contour_pt p = {.y=y, .x=x};
Too cutting edge syntax :)

- It doesn't run when compiled with debug, on startup:

wxBoundingBox& wxBoundingBox::operator=(const wxBoundingBox&): Assertion `other.GetValid()' failed.

#4 0xb6fe5d67 in __GI___assert_fail (assertion=0x8506176 "other.GetValid()", file=0x8506120 "src/bbox.cpp",
line=323, function=0x8506200 "wxBoundingBox& wxBoundingBox::operator=(const wxBoundingBox&)") at assert.c:103
#5 0x0819e16f in wxBoundingBox::operator= (this=0x95c83c4, other=...) at src/bbox.cpp:323
#6 0x081cf124 in LLBBox::operator= (this=0x95c83c4) at include/bbox.h:88
#7 0x0824d8e2 in LLRegion::operator= (this=0x95c83bc) at include/LLRegion.h:49
#8 0x08246378 in QuiltCandidate::GetCandidateRegion (this=0x95c83b0) at src/Quilt.cpp:131
#9 0x08249e28 in Quilt::Compose (this=0x8a023a0, vp_in=...) at src/Quilt.cpp:1462
#10 0x081dae44 in ChartCanvas::SetViewPoint (this=0x88a89b8, lat=26.490100000000002, lon=-82.049300000000002, scale_ppm=0.079156197607517242,
skew=0, rotation=0, projection=0, b_adjust=true, b_refresh=true) src/chcanv.cpp:3278
#11 0x08181153 in MyFrame::DoChartUpdate (this=0x889a690) src/chart1.cpp:7220
#12 0x08166d01 in MyApp::OnInit (this=0x86c7d60) at src/chart1.cpp:2024

Didier

[seandepagnier]

Originally Posted by ChuckSK

Sean

I realized I cannot submit a pull request on your fork. Here is a diff file instead. Not every change was tested to determine if it is absolutely necessary.

I didn't know how, but it's possible to submit a pull request to the branch. Anyway, I accept patches as well

diff --git a/include/LLRegion.h b/include/LLRegion.h
index c44c761..7ddb834 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -45,7 +45,7 @@ struct contour_pt
 typedef std::list<contour_pt> poly_contour;
 class LLBBox;
 
-class work;
+struct work;
 class LLRegion
 {
 public:

I want to understand why this is needed.

@@ -298,7 +300,7 @@ void LLRegion::Intersect(const LLRegion& region)
         return;
     }
 
-    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO);
+    Put(region, GLU_TESS_WINDING_ABS_GEQ_TWO, false);
 }

Is this required to build or run correctly, or you think a better style?

diff --git a/src/bbox.cpp b/src/bbox.cpp
index ef1aee5..9347834 100644
--- a/src/bbox.cpp
+++ b/src/bbox.cpp
@@ -320,7 +320,7 @@ wxBoundingBox& wxBoundingBox::operator+(wxBoundingBox &other)
 // makes a boundingbox same as the other
 wxBoundingBox& wxBoundingBox::operator=( const wxBoundingBox &other)
 {
-    assert (other.GetValid());
+ //   assert (other.GetValid());
 
     m_minx = other.m_minx;
     m_maxx = other.m_maxx;

Any suggestion to make this hit so I can analyze it better? Maybe my assertions are off. In any case, I don't think this is the correct fix.


I will merge your patch and make some changes as I see fit.


As for polyconic charts in polar coordinates... I think I know the problem and I can fix that one very easily, but otherwise I will find a way to fix it somehow anyway.

[ChuckSK]

Hi Sean

Those changes are not required. They are left over from my trial and error testing; sorry.

[SamsonovAnton]

Originally Posted by boat_alexandra

mercator, polar, and spherical projections supported by pressing '1', '2', '3'

Originally Posted by boat_alexandra

I fixed some things and added gnomonic projections.

Since the latter message, I cannot switch between projections by pressing 1, 2, 3 or 4, neither can I toggle grid lines by pressing G, like one of your recent patches suggests; standard one-key shortcuts are working meanwhile. Moreover, your version does not display latitude labels after 60°.


For testing purposes, I created a fake North Pole chart (save the attached 001POLEN.000.doc as “001POLEN.000”). Due to high amount of efforts required to generate charts programmatically (despite numerous helper functions, it still takes about 20 kilobytes of code to get a 5500-byte chart file, of which 1500 bytes are the DDF header), it contains very few data, but should be enough to start looking for rendering errors.

Here is my own simplified rendering in Equidistant Cylindrical projection (aka Plate Carrée, aka Simple Cylindrical):

From North (90° N) to South (85° N):

• unsurveyed area (90° N to 89° N), depicted in gray;
• depth area (89° N to 85° N), depicted in cyan;
• ice area (89° N to 86° N), depicted in semi-transparent light gray over the cyan depth area;
• traffic separation line (starting at 88° N 180° W and going to 135° E and then returning to 87° N), depicted in pink;
• spot soundings (85.5° N to 87.5° N and 120° E to 165° E), depicted in violet;
• landmarks at Geographic North Pole (90° N 0° E) and Magnetic North Pole (86.3° N 160° W), depicted in orange.

A textual dump in HTML is attached as 001POLEN.html.doc (strip “.doc”).

Here is my simplified rendering in Equidistant Conical projection (aka Conic, aka Simple Conic):

Small gap between 180° W and 180° E is perhaps due to computation errors and/or over-aggressive rendering optimizations, rather than due to the fact that the value 179.9999999° E is actually used in this chart instead of 180.0° E to ensure software compatibility.

My rendering in Orthographic Azimuthal projection looks basically the same as the one in Equidistant Conical, but it does not have the gap and yet has some shapes screwed (missing or incorrect), — indeed, it is not easy to handle charts that span 360° and optimize for speed and node count at the same time. Therefore I do not attach this bad rendering.

Tried this chart with existing software:

• OpenCPN — import succeeds, but no chart boundaries are visible;
• SeeMyENC — depth area and ice area both cover the Geographic North Pole, although they should not; unsurveyed area is not visible at all;
• PolarView NS — chart manager error: “Unable to add cell” (pretty verbose!);
• Fugawi View ENC — displays Magnetic North Pole only.

Your are welcome to try anything else you have access to.

[ChuckSK]

Hi Sean

This patch fixes a problem with charts that straddle the IDL. PointsCCW is used in different ways for charts and viewports, so I duplicated it to make changes. I'm sure there is a more elegant solution.

diff --git a/include/LLRegion.h b/include/LLRegion.h
index 7ddb834..48ebd04 100644
--- a/include/LLRegion.h
+++ b/include/LLRegion.h
@@ -56,6 +56,7 @@ public:
     LLRegion( size_t n, const double *points );
 
     static bool PointsCCW( size_t n, const double *points );
+    static bool PointsCCWidl( size_t n, const double *points );
     
     void Print() const;
     
diff --git a/src/LLRegion.cpp b/src/LLRegion.cpp
index 4490f46..4febcb1 100644
--- a/src/LLRegion.cpp
+++ b/src/LLRegion.cpp
@@ -66,6 +66,14 @@ LLRegion::LLRegion( size_t n, const double *points )
     InitPoints(n, points);
 }
 
+double cidl( double val )
+{
+    if( val > 180.0 ) return val -= 360.0;
+    if( val < -180.0 ) return val += 360.0;
+    return val;
+}
+
+
 // determine if a loop of points is counter clockwise
 bool LLRegion::PointsCCW( size_t n, const double *points )
 {
@@ -83,6 +91,25 @@ bool LLRegion::PointsCCW( size_t n, const double *points )
     return total > 0;
 }
 
+// determine if a loop of points is counter clockwise
+bool LLRegion::PointsCCWidl( size_t n, const double *points )
+{
+    double total = 0;
+    int pl = 2 * ( n - 1 );
+    double x0 = points[0] - points[pl + 0];
+    double y0 = cidl(points[1] - points[pl + 1]);
+    for( unsigned int i = 0; i<2 * n; i += 2 ) {
+        int pn = i < 2 * ( n - 1 ) ? i + 2 : 0;
+        double x1 = points[pn + 0] - points[i + 0];
+        double y1 = cidl(points[pn + 1] - points[i + 1]);
+        total += x1*y0 - x0*y1;
+        x0 = x1, y0 = y1;
+    }
+    return total > 0;
+}
+
+
+
 void LLRegion::Print() const
 {
     for(std::list<poly_contour>::const_iterator i = contours.begin(); i != contours.end(); i++) {
@@ -483,7 +510,7 @@ void LLRegion::InitPoints( size_t n, const double *points)
     std::list<contour_pt> pts;
     bool adjust = false;
 
-    bool ccw = PointsCCW(n, points);
+    bool ccw = PointsCCWidl(n, points);
     for(unsigned int i=0; i<2*n; i+=2) {
         contour_pt p;
         p.y = points[i+0];

chuck

[seandepagnier]

Chuck,

Thank you for the patch. I was certain I dealt with charts straddling the idl, but didn't test this case recently, I will take a look again. I just pushed a few more fixes. I have a few minor things still, then I hope to start making pull requests (first with changes that are unlikely to break anything) but eventually I must try to push the LLRegion logic which is almost guaranteed to cause some fallout, although I know it fixes a lot of problems.

[rgleason]

These are some more exciting things happening. Wow.

[seandepagnier]

Originally Posted by ChuckSK

Hi Sean

This patch fixes a problem with charts that straddle the IDL. PointsCCW is used in different ways for charts and viewports, so I duplicated it to make changes. I'm sure there is a more elegant solution.

Chuck,

your patch was not technically correct because it broke the case when the viewport crosses both 0 and 180 meridian at the same time. I have corrected the issue (was it only raster charts?) and so it should be fixed now. I never saw any rendering errors (did you find this?) but only now realized it was doing more work than it should be in this case. Maybe in some case the quilt was wrong but I couldn't find it. I don't have any vector charts besides cm93 that cross the idl, and cm93 uses 0-360 so the issues with it are on the 0 meridian already.

I found that in a few cases performance is actually worse so I really need to correct this. What do you think of tilted mode? Is it worth it or just a gimmick? I saw a screenshot of garmin doing this so I didn't want them to have something we don't when it took about 5 lines of code to add. In any case several things should not be tilted, and it's also not possible to make routes in this mode yet.

[ChuckSK]

Sean

Yes there were rendering errors while panning raster charts that straddled the IDL. That is all working now. I knew there must be a better fix.

The tilted mode may be a gimmick but I like it.

[seandepagnier]

Chuck

I made a few more fixes (mainly I broke the performance in dc-mode which is fixed now)

As for tilted mode, I am still struggling with the calculations to make the measurement and route tools work properly. I used gluUnProject but unfortunately I want to specify screen x and y, but object z, to determine object x and y, not screen x, y and z. I will try to download the source code to glu so I can dissect it.

I think tilted mode will become much more useful once we can get topo data for the land (possible plugin) and also maybe we can render the contours in the sea using 3 dimensions (with lighting) which could be useful in harbors, but we would want to have fairly high resolution soundings.

Otherwise, are there any serious issues with this? Any cases performance is noticeably worse that master? If not, I will break the changes into more reasonable commits (this eliminates the changes that changed things back etc..) but I maybe have to wait until after 4.2 is released before this can be considered.