ODraw - beta 1.1

[bcn]

Is there a Window Installer for the recent versions available? Havn't seen any neither on Github nor on Rick's site...

Thanks

Hubert

[rgleason]

Hubert, don' t know which branch to compile. Sean and Jon are busy working out line segments I think. Best to wait until Jon advises.

[jongough]

Hubert,
I have made 1.1.14 available on github as a windows installer. I have not added any new language files, so there will be english terms used for the new functionality. I will upload the pot file to crowdin soon.

Sean wants me to add a capability to bypass using JSON messaging to help speed up boundary searching by the weather plugin, so I am looking into that at the moment. I 'think' the Guard Zone stuff is now working and drawing correctly and will work with watchdog 1.9.047.

Jon

[bcn]

Guard zones:
When no heading information in the stream, then heading = 0 is used
Fallback to COG and a warning perhaps?
COG works correctly for me

Errors when applying properties:
entering an angle for point two is ignored (value of point 1 displayed for point 2 after entering into properties again) and something wrong is with the drawing logic. You get either a line (that should be always pointing away from the boat when using the same angle, but sometimes this not the case neither) or some strange start point.
Tested first staticly and then with VDR.
See the screenshots attached. OpenGL ON

What might be handy for our OriginalPoster and requester of the feature Palolo1 is a table to define zones (zone vector1, vector2, v..., vectorN):
GZ1: 150/1.5 ; 180/2 ; HDT
GZ2: -130/7.5 ; -45/10 ; COG
GZ3: -130/7.5 ; -45/10 ; HDT
..
GZN: 35/12.5 ; -70/15 ; fix
A guard zone editor with the most important parameters.

[bcn]

Now playing with OpenGL ON/OFF.
The second and forth screenshot have the second angle corrected to 150

[bcn]

Jon,

I've noticed that the changes of OD objects during the sessions are written only to the .changes.XML file and are applied to ODnavobj.xml once closing the program. Is this intenionally?

The xml for the GZ4:

<opencpn:path>
    <opencpn:type>GuardZone</opencpn:type>
    <name>GZ 4</name>
    <opencpn:guid>2ea20000-ff2f-43c2-aa3f-751e45dcffff</opencpn:guid>
    <opencpn:viz>1</opencpn:viz>
    <opencpn:active>1</opencpn:active>
    <opencpn:style active_colour="rgb(255, 0, 0)" active_fillcolour="rgb(255, 0, 0)" inactive_colour="rgb(192, 192, 192)" inactive_fillcolour="rgb(192, 192, 192)" width="2" style="100" fill_transparency="175" />
    <opencpn:persistence>0</opencpn:persistence>
    <opencpn:centre_on_boat>0</opencpn:centre_on_boat>
    <opencpn:rotate_with_boat>1</opencpn:rotate_with_boat>
    <opencpn:maintain_with>0</opencpn:maintain_with>
    <opencpn:GZ_CentreLat>41.26</opencpn:GZ_CentreLat>
    <opencpn:GZ_CentreLon>1.92</opencpn:GZ_CentreLon>
    <opencpn:GZ_FirstLineDirection>135.89</opencpn:GZ_FirstLineDirection>
    <opencpn:GZ_SecondLineDirection>150.00</opencpn:GZ_SecondLineDirection>
    <opencpn:GZ_FirstDistance>0.37</opencpn:GZ_FirstDistance>
    <opencpn:GZ_SecondDistance>0.24</opencpn:GZ_SecondDistance>
    <opencpn:ODPoint lat="41.254369726" lon="1.926790825">
      <opencpn:type>Guard Zone Point</opencpn:type>
      <time>2016-06-17T10:16:35Z</time>
      <name>First</name>
      <sym>Circle</sym>
      <opencpn:guid>6fe0ffff-57f4-4eea-96ba-5f9e32690000</opencpn:guid>
      <opencpn:viz>1</opencpn:viz>
      <opencpn:viz_name>0</opencpn:viz_name>
      <opencpn:auto_name>1</opencpn:auto_name>
      <opencpn:arrival_radius>0.000</opencpn:arrival_radius>
      <opencpn:ODPoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" width="2" line_style="100" />
    </opencpn:ODPoint>
    <opencpn:ODPoint lat="41.255926341" lon="1.924791434">
      <opencpn:type>Guard Zone Point</opencpn:type>
      <time>2016-06-17T10:16:42Z</time>
      <name>Second</name>
      <sym>Circle</sym>
      <opencpn:guid>2d900000-39fc-4d8a-9862-cf4548b5ffff</opencpn:guid>
      <opencpn:viz>1</opencpn:viz>
      <opencpn:viz_name>0</opencpn:viz_name>
      <opencpn:auto_name>1</opencpn:auto_name>
      <opencpn:arrival_radius>0.000</opencpn:arrival_radius>
      <opencpn:ODPoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" width="2" line_style="100" />
    </opencpn:ODPoint>
  </opencpn:path>

[jongough]

Hubert,
I missed applying the changes to the whole GZ when the properties were updated. This had the effect of the vectors not being reflected in the ODPoints, hence the weird drawing and selectability. Have fixed this in 1.1.15. Can you try your tests again and see if switching OpenGL now works. I do not get any movement of the ends or the change in shape that you have experienced.

I am not quite sure what to do about the HDM/COG if the HDM is not available and a COG is. I will have a think.

For a GZ editor, do you want a new dialog and if so where would you want it launched from? A GZ is defined by two vectors and the ODPoints follow this, they are there to enable mouse editing of the GZ. So a simple dialog is possible. Do you think it would confuse having all GZ's displayed in one dialog?

There is still a drawing difficulty when zooming in. This is due, I think, to a calculation issue when translating Lat/Lon to pixels, or in the distance/direction between two Lat/Lons (not sure which). This is shown best in the non OpenGL drawing where the outer Point is not at the end of the arc, it appears to be inside the arc. In OpenGL you will see this as the last segment going from the arc to the Point as a straight line. This is annoying, but I think the GZ still works OK and is usable like this for the moment.

Jon

[jongough]

Hubert,
All changes are only written to the ODnavobj.xml.changes file during the session. When OD is closed, normally with OCPN, the changes are then written to the ODnavobj.xml file. This is the way that OCPN works and allows for changes to be applied over a crash. In the case of GZ's it allows for the persistence settings to work.

Jon

[jongough]

Hi,
I have implemented a binary API access to OD. This is to help reduce the overhead caused by JSON messaging. For high volume messages it makes sense, for low volume messaging then the JSON method should probably still be used.

I have created a pull request against the watchdog plugin with and implementation of 'FindPathByGUID' to show how it is done and to act as a proof of concept. This has been implemented in patch 1.1.16 of OD.

I know this is a bit in the weeds, but if it helps performance then it is worth it. Thanks to Sean/Rick for the suggestions and hints of code that do this.

Jon

[seandepagnier]

Is there any plan to support import/export of geojson?

[jongough]

This is the first request for it. Having looked at the specification it could probably be supported, but some of circular drawings may be difficult as they are made up of many straight lines, and therefore the polygon would have a large number of sectors and hence make the JSON message quite big. In OD this information is stored as vectors and knowing what to do with these is able to be rendered.

What use do you think geojson would have? Who would use the output and what for? Is this needed for OD 1.2 (i.e. the next release)?

[jongough]

Hi,
I have just put up patch 1.1.17 which implements a new API to OD for faster access. This has been requested for the weather routing plugin, but will be useful to other plugins that want direct access to the information and don't want the overhead of using JSON messages. I have created an install package for windows for OD 1.1.17 and WD 1.9.048, both of which are available on github for OD in the releases section.

Jon

[jongough]

Hi,
I have just put up patch 1.1.17 which implements a new API to OD for faster access. This version implements 3 API's:

• OD_FindPathByGUID
• OD_FindPointInAnyBoundary
• OD_FindClosestBoundaryLineCrossing

These have been requested for the weather routing plugin, but may be useful to other plugins that want direct access to the information and don't want the overhead of using JSON messages. I have created an install package for windows for OD 1.1.17 and WD 1.9.048, both of which are available on github for OD in the releases section.

Jon

[rgleason]

Jon, added this page to Plugins Manual
Ocpn_Draw ODAPI | Official OpenCPN Homepage

Maybe it should be with Plugin Documentation?

[rgleason]

Jon,
WatchDog first needs to check if OD objects exist and if they do not exist there should be a message or something and maybe change that Alarm to Purple color.

I just ran a previous test with Watchdog with some alarms in it that I had set up, but the OD objects were deleted. Watchdog simple accepts the OD objects and sits there looking with no heads up message that the OD objects do not exist.

The objects were several guard zones that I had set up with the ship.

PS: When I go into the Alarm GUID field it does have a popup message that says the guid does not exist.
However if someone has set up guard zones previously and expects them to be there (but they've been deleted or something) when they start Watchdog, perhaps there should be some checking first to alert if there are any Guid's missing.

Small procedural detail with big consequences. - Granted this is pre-release testing of concept code.

Amendment: I think the Watchdog Alarm checkbox should be unchecked and the Alarm text should be changed to purple if the GUID does not exist. If the user tries to turn on the checkbox, then a message comes up "Guid does not exist"