Ocpn-Draw and Boundary

[bcn]

The text markers don't scale.
Results in cluttering when zooming out - same as it happens with other vector chart objects or AIS targets.

[jongough]

Hubert,
I have put a test version of the watchdog plugin up in release 0450 of the OD plugin in git. This is enough to demonstrate that the messaging works. If you go into 'preference/anchor watch' you will find a button to give you the GUID of the surrounding boundary. If the boat is outside a boundary you will get nothing, if you move the boat into a boundary you will get its guid. The watchdog plugin is currently being modified by Sean, so I will not be making any further changes until that has been done, at which point we can try and make the anchor watch work properly.

Can you give me some more details about the EBL? My radar has static range rings and a static bearing line that can be draw. This allows seeing how far away an object is easily and if the angle to the object is increasing/decreasing (likely to miss) or static (likely to hit). I would have thought the watchdog plugin would be the control for this even if the OD plugin is used to draw the line. I think that a JSON message could be sent from watchdog to OD to specify the new boat location to allow a bearing line to be moved/rotated. Would it be possible to draw a couple of simple line diagrams that describe what you are after as I am sure I am making it more difficult than it is.

I have changed the text backing box a bit, but the fonts are asked for their metrics and the graphics libraries use this to determine the bounding box. Some of the fonts seem to be conservative with the truth in the sizes they are which causes the bounding box to be closer to some characters than others. At this point I can change the generic 'extra size' to allow a border, but I cannot really handle all fonts and sizes, so if it looks bad can you use a different font?

Jon

[jongough]

Hubert,
The text size is set by the user when selecting the font. The only thing that could be done is to blank out the text at some point and leave a little bounding box to show something is there. However, one of the complaints I have seen on the forum is that objects 'disappear' when the user zooms out, so if you had marked a bad rock (boundary) and put text beside it (text point) and then zoomed out you would loose the fact. As it currently works you will not as the point and text will always be visible. Do you have a suggestion as to when to hide the text, or how to determine when?

Thanks
Jon

Originally Posted by bcn

The text markers don't scale.
Results in cluttering when zooming out - same as it happens with other vector chart objects or AIS targets.

[rgleason]

Jon and Hurbert, this is starting to look pretty darn good! Lots of new capabilities and much more progress than I made with rtlsdr AIS over the last 3 weeks..very exciting. Of course I have a lot of catchup to do. The developments with Watchdog are super, need to find out and learn more.

You probably know these.. I write extemporaneously so please correct if I have this wrong..(anyone)
EBL = Electronic Bearing Line, a line that originates at the boat location and rotates left or right indicating a +/- degrees from the heading(?) -Control of this line is a pair of buttons (clockwise and counterclockwise), maybe using the arrows?
VRM = Variable Range Marker, usually a dashed circular range line which is simply increased or decreased and shows the "range" from the origin or boat location.
Yes these would be useful with Watchdog anchor (and some other DR functions.)

From CAD there are some basic concepts related to Text and other "non real world" entities that needs to be understood and handled appropriately. Text is a "non real world entity" whose size is usually determined by visibility at the "plotting" scale (in CAD). In our case there is no plotting, so the size of the text needs to be determined by the most appropriate scale to view the entities being drawn. In CAD we have macros which allow us to set text "styles" for consistency and then to simply change the plotting scale which then calculates the resultant "real world" text height, then allowing the user type text with assurance that it will not need to be changed when plotted.

I do not believe we need this elaborate a system for text, but it is helpful to think about "non-real world" text and the need to select a "real world" text height that for a certain scale that is appropriate for viewing the drawing. It may become useful to have the text change somehow (become more transparent, disappear, or just stay the same, or perhaps change size relative to the scale for scales immediately above and below the selected "viewing scale"). I hope this does not sound too complicated, because it need not be. It just helps to think about it.

Which version of Opencpn should we be using? (I may just try the plugin with 4.1.602)

Sorry, it took me a couple of days to catch up with other things.

[jongough]

Rick,
I have just used 0450 with OCPN 602 and it works fine. I compiled both OD and Watchdog against OCPN 718, so if you do get 'funny' behaviour you should try against the latest OCPN.

With text and scaling, what would be the 'natural' scale at which to show the correct font point size? At some point in the zooming the size of the font would have to decrease to avoid the clutter effect that Hubert is showing. However, there is also a minimum size at which the text will become unreadable and that is totally dependent on the device being used for display, the resolution on that device (i.e. the software render resolution) and the users eye sight. Perhaps a 'Hide Text' option from right click may work in the short term, what do you think?

As this is the first pass at putting text on the screen I want to try and keep it simple. I think Dave would like to be able to put rich text up as well, but that is a bit more complicated, especially if you want transparent backgrounds. I tried it and gave up and went back to what you see now.

Range rings are already available at the boat, they just have to be adjusted from the options page. For drag-able rings we will need to workout how to make it natural. Is this facility required in the real world, or the armchair world? I find it difficult enough when sailing to add new waypoints, etc. in, but that just may be the motion of our boat.

Jon

[rgleason]

Jon,
I was just able to compile the most recent Opencpn v4.1.718 and in the process of fetching from upstream learned about pushing to my repos copy online. That is a workflow I had not figured out.

Also I get fetched and was able to fast forward to your
ocpn_draw_pi-0.4_0100-win32

but I do not seem to be on the right branch... it does not have the text... I guess I have to checkout 4_0150 tomorrow morning and install the 4.1.718 version.

--what would be the 'natural' scale at which to show the correct font point size?
It would vary based upon which scale chart was being used, but the text size would be most appropriately set as some % of the size of the depth text for each chart, if that can be accomplished. --have not thought about this problem that much. ...so maybe it would depend on what chart scale was actively being used...then the text height could be entered at that height or some % difference from that? --Just and idea.

I do agree we want to keep it simple but useable.

The EBL and VRM are implimented in most radars, they exist so that you can set them on a boat that is of concern, and then 5 minutes later you have a much better sense of what course they are on and how fast and if they are going to be a problem. For anchoring I think it would also be useful to set EBL and VRM on a known fixed geographic or man made object and then wake up and check it.

[rgleason]

For some reason my charts disappeared again while using the wrong version of the plugin. Force full rebuild does not seem to fix it. I think I'll deal with this tomorrow when I have the right version.
Nite.

[jongough]

Rick,
You need to ensure that you are using 0.4-0450 for your testing, there are many changes between 0100 and 0450. Just look in the CmakeList.txt file and you will see the version there. I think you need to 'fetch' and 'rebase' to get to the correct level.

For the EBL to move with the boat will need OD to receive the NMEA messages and then move the two points needed to draw a path so that EBL then moves with the boat. I will have a think about how that can be done easily.

I really want this plugin to be available for OCPN 4.2 to allow users a chance to give it a go. Currently I am trying to slow down on the new features being added unless they are simple.

Jon

[bcn]

The cluttering is an issue covered by the SCAMIN attribute of an object of a vector chart:

http://www.iho.int/mtg_docs/com_wg/D...sion_paper.pdf

OCPN does honor this attribute (almost always - I've seen problems with lighthouses on S-63 charts).
For AIS targets a similar concept is used for shipnames. They show up from a user defined scale on. Might be applied to AIS objects in total.

And we might consider to
- have a user defined SCAMIN
- or to define a general SCAMIN for texts

What happens with the rest of user created objects?
Routes and tracks have no SCAMIN neither. Should they?

Hubert

[bcn]

Originally Posted by jongough

I really want this plugin to be available for OCPN 4.2 to allow users a chance to give it a go. Currently I am trying to slow down on the new features being added unless they are simple.

Jon

4.2 is still way down the road. With the next beta we should have a broader base for testing and perhaps more people to try-out and to generate ideas.

About EBL/VRM I will draw some material togethe later today.

[rgleason]

EBL & VRL will need OD to draw a path. -Yes, additions to plugiin API I guess?

Have now compiled and installed 4.1.718 and then updated and fast forwd Ocpn_draw to 0.4-0450 and compiled and installed. I found that there was a simple problem with directory path when installing to a parallel setup. The plugin exe seems to always create an OpenCPN/Plugins/ directory. So I found that directory under my Opencpn4.1.718 program directory and simply copied the ocpn-draw plugin and data directory to the correct plugins/ directory. ..then deleted opnecpn/plugins/...
Might be confusing to a new user with parallel installs.

I've done some testing to understand the text problems and what needs to be done.
It appears that the text is staying the same "real world screen size or height" as we scale up or down. This is acting differently than the other text that Opencpn uses in the charts. Please compare the chart text with the ocpn-draw text in the snapshots below. The chart text gets smaller when you zoom out and then finally disappears. The ocpn-draw text stays very legible.

I believe the text scaling device is working, but perhaps it should be applied just once, and only once... at the exact time of placement on the chart using the scale that the current screen is using... Now I am realizing that the selection is "Font" size. That font size is probably referencing some real world scale 1:1 (Screen size= Real world size ?) Since when we zoom out the text effectively gets bigger relative to the chart, you must be accounting for the amount scaled out in calculating the text height. --We don't need to do that. That will make the text act similar to the regular chart text.

I have a question about "Center View". When I use this it seems to make my charts disappear and also eventually freezes opencpn. Is this intended to just center the view to the selected ocpn-draw entity without changing charts or scale?
- For ocpn-draw objects that are much much smaller should it also zooom in or out to put the objects visible on the screen? --maybe that is a different button or setting.

One thing I noticed this time, was that I wanted the ability to Move the entire border all at once. There does not appear to be a way to do that. Also it might be good to have a way to "rotate" the object too.

I realize that you want this tool to be simple to use, and so do I, but it is turning into a pretty powerful one and it is inevitable that there will need to be some editing tools.

Jon, you have done a great job getting it to this point, showing great persistence. Thank you from all of "us"!

Later : Don't know why the last "Good Whale Watch" got moved to the bottom. It should not have moved.

[rgleason]

Jon, I don't think my explanation was as clear as it should have been.
1. The "Great Whale Watch" GWW boundary is a "real world" object. It was placed on the chart and it stays there without changing its position. It is like an island or land.
2. Text needs to be legible at a certain user determined scales (like printing plans), and to have a uniform look we often want text to have certain predefined styles and to be "printed" at certain uniform sizes, say "small" "medium" and "large".
3. In CAD we have to be very clear about this because drawings can get very messy looking and impossible to read without having the printed text (at different scales) uniform sizes. For our purposes, we need to make this simpler I think.
4. Perhaps to start, the user should just select a font size that looks appropriate for the scale that they want to view the drawing at. Once the text is entered, it's size or height is set and when you zoom out the text gets proportionally smaller, etc.
5. Later if we find it would be useful to have some Text "styles" which remember certain settings, someone else can program that.

[rgleason]

It might be nice to have a way to "match" a text entity which is a way of copying all the font, color, background color and transparency information.

[jongough]

Hi,
I am currently in a fight with windows fill of boundaries when using opengl. There appears to be something wrong with the way tessellation is occurring. Under linux it all works, but under windows it seems to go awry with, I think, the 'winding'. I need some help to understand or fix this issue.

I have attached two images, the one with the hole in the star is from windows, the other is from linux.

It is both the same code. The star is hard coded into the routine so that I can see that tessellation is actually working (without it under windows the fill does not work). You can see that the middle of the star is missing under windows, so there is something wrong. I have been using ocpndc.cpp for handling opengl, but for this test I took a copy of it and created the star.

This is the tessellation code:

#i
fdef ocpnUSE_GL

typedef union {
    GLdouble data[7];
    struct sGLvertex {
        GLdouble x;
        GLdouble y;
        GLdouble z;
        GLdouble r;
        GLdouble g;
        GLdouble b;
        GLdouble a;
    } info;
} GLvertex;

void APIENTRY ODDCcombineCallback( GLdouble coords[3], GLdouble *vertex_data[4], GLfloat weight[4],GLdouble **dataOut )
{
    GLvertex *vertex;

    vertex = new GLvertex();
    gTesselatorVertices.Add(vertex );

    vertex->info.x = coords[0];
    vertex->info.y = coords[1];
    vertex->info.z = coords[2];

    for( int i = 3; i < 6; i++ ) {
        vertex->data[i] = weight[0] * vertex_data[0][i] + weight[1] * vertex_data[1][i];
    }

    *dataOut = &(vertex->data[0]);

}

void APIENTRY ODDCvertexCallback( GLvoid* arg )
{
    GLvertex* vertex;
    vertex = (GLvertex*) arg;
    const GLdouble *ptr = (const GLdouble*)arg;
//    glVertex2f( (float)vertex->info.x, (float)vertex->info.y );
    //glVertex3d( vertex->info.x, vertex->info.y, vertex->info.z );
    //glColor3dv(ptr + 3);
    glVertex3dv(ptr);
}

void APIENTRY ODDCerrorCallback( GLenum errorCode )
{
   const GLubyte *estring;
   estring = gluErrorString(errorCode);
   wxLogMessage( _T("OpenGL Tessellation Error: %s"), estring );
}

void APIENTRY ODDCbeginCallback( GLenum type )
{
    glBegin( type );
}

void APIENTRY ODDCendCallback()
{
    glEnd();
}
#endif          //#ifdef ocpnUSE_GL

void ODDC::DrawPolygonTessellated( int n, wxPoint points[], wxCoord xoffset, wxCoord yoffset )
{
    if( dc )
        dc->DrawPolygon( n, points, xoffset, yoffset );
#ifdef ocpnUSE_GL
    else {
# ifndef ocpnUSE_GLES  // tessalator in glues is broken
//#ifndef __WXMSW__
//        if( n < 5 )
//#endif            
# endif

//        {
//            DrawPolygon( n, points, xoffset, yoffset );
//            return;
//        }

        GLUtesselator *tobj = gluNewTess();

        gluTessCallback( tobj, GLU_TESS_VERTEX, (_GLUfuncptr) &ODDCvertexCallback );
        gluTessCallback( tobj, GLU_TESS_BEGIN, (_GLUfuncptr) &ODDCbeginCallback );
        gluTessCallback( tobj, GLU_TESS_END, (_GLUfuncptr) &ODDCendCallback );
        gluTessCallback( tobj, GLU_TESS_COMBINE, (_GLUfuncptr) &ODDCcombineCallback );
        gluTessCallback( tobj, GLU_TESS_ERROR, (_GLUfuncptr) &ODDCerrorCallback );

        //gluTessNormal( tobj, 0, 0, 1);
        //gluTessProperty(tobj, GLU_TESS_BOUNDARY_ONLY, GL_TRUE);
        //glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
        gluTessProperty(tobj, GLU_TESS_WINDING_RULE, GLU_TESS_WINDING_NONZERO);
//        gluTessProperty(tobj, GLU_TESS_WINDING_RULE, GLU_TESS_WINDING_ODD);

        if( ConfigureBrush() ) {
            glColor3ub(100, 100, 100);
/*            gluTessBeginPolygon( tobj, NULL );
            gluTessBeginContour( tobj );
                GLdouble tri[3][3] = {75.0, 75.0, 0.0,
                                        125.0, 175.0, 0.0,
                                        175.0, 75.0, 0.0};
                gluTessVertex(tobj, tri[0], tri[0]);
                gluTessVertex(tobj, tri[1], tri[1]);
                gluTessVertex(tobj, tri[2], tri[2]);
            gluTessEndContour( tobj );
            gluTessEndPolygon(tobj);
*/            gluTessBeginPolygon(tobj, NULL);
            gluTessBeginContour(tobj);
                    GLdouble star1[5][3] = {250.0, 50.0, 0.0,
                        325.0, 200.0, 0.0, 
                        400.0, 50.0, 0.0,
                        250.0, 150.0, 0.0,
                        400.0, 150.0, 0.0};
                    for( int i = 0; i < 5; i++ ) {
                        GLvertex* vertex = new GLvertex();
                        gTesselatorVertices.Add( vertex );
                        vertex->info.x = star1[i][0];
                        vertex->info.y = star1[i][1];
                        vertex->info.z = star1[i][2];
                        vertex->info.r = star1[i][3];
                        vertex->info.g = star1[i][4];
                        vertex->info.b = star1[i][5];
                        gluTessVertex( tobj, (GLdouble*)vertex, (GLdouble*)vertex );
                    }
                    
            gluTessEndContour( tobj );
            gluTessEndPolygon(tobj);
            gluTessBeginPolygon(tobj, NULL);
            gluTessBeginContour(tobj);
            
            for( int i = 0; i < n; i++ ) {
                GLvertex* vertex = new GLvertex();
                gTesselatorVertices.Add( vertex );
                vertex->info.x = (GLdouble) points[i].x;
                vertex->info.y = (GLdouble) points[i].y;
                vertex->info.z = (GLdouble) 0.0;
                vertex->info.r = (GLdouble) 0.0;
                vertex->info.g = (GLdouble) 0.0;
                vertex->info.b = (GLdouble) 0.0;
                gluTessVertex( tobj, (GLdouble*)vertex, (GLdouble*)vertex );
            }
            gluTessEndContour( tobj );
            gluTessEndPolygon(tobj);
        }

        gluDeleteTess(tobj);
        for (unsigned int i = 0; i<gTesselatorVertices.Count(); i++)
            delete (GLvertex*)gTesselatorVertices.Item(i);
        gTesselatorVertices.Clear();
        
    }
#endif    
}

If anyone can shed some light on this it would wonderful.

Jon

[jongough]

Rick,
The code for copying a point (text, boundary, etc.) exists already, there just isn't a way to execute it, i.e. it needs new menu item to allow the creating of a point based on the current point, I just haven't got round to it.

Jon

Originally Posted by rgleason

It might be nice to have a way to "match" a text entity which is a way of copying all the font, color, background color and transparency information.