This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
AvNav implementation in OP2
#21
Hmm - not completely clear what you want to achieve.
First of all it would be good to know what software you are running on your Pi3 and how the communication is running.
I guess you would like to have your data on the Pi4 in AvNav?

If you have it coming in to SignalK on the Pi4 as NMEA0183 it should go to AvNav out of the box.
Which openplotter-avnav and which avnav version you you have on the Pi4?

In AvNav on the status page you should see a connection to signalk (Socket Reader to localhost port 10110).
If you are on a real recent AvNav there is an edit button beside each connection where you can check the settings again.
If AvNav is seeing valid NMEA the status indicator on this connection should turn green.
Reply
#22
Small addition:
I guess you need to enable the SignalK to NMEA 0183 on the Pi4 (Openplotter).
For GPS RMC should be sufficient.
But I have no idea if there is a plugin that converts back SignalK AIS data to 0183.

But if you have the NMEA data available on your Pi3 it would be easy to configure an additional SocketReader in AvNav to get the data directly from the Pi3, port 10110. You yould even limit this to AIS data by setting up a filter there (assuming you route the position data via SK on Pi3->SK on Pi4->plugin->0183->AvNav).
Reply
#23
(2021-03-27, 12:34 PM)wellenvogel Wrote: Hmm - not completely clear what you want to achieve.
First of all it would be good to know what software you are running on your Pi3 and how the communication is running.
I guess you would like to have your data on the Pi4 in AvNav?

If you have it coming in to SignalK on the Pi4 as NMEA0183 it should go to AvNav out of the box.
Which openplotter-avnav and which avnav version you you have on the Pi4?

In AvNav on the status page you should see a connection to signalk (Socket Reader to localhost port 10110).
If you are on a real recent AvNav there is an edit button beside each connection where you can check the settings again.
If AvNav is seeing valid NMEA the status indicator on this connection should turn green.
The pi three is running raspian with signalK installed. 
I want to achieve NMEA data from two sources into the pi3 I then want that data sent over WiFi to the network then I want to see it on the Pi4 running openplotter. I can see the data in the signalK dash in openplotter but it doesn't show in AvNav. Which I would have thought it should given that openplotter is supposed to be configured to distribute the data received to all apps. 
Additionally I want the AIS data output to a UDP feed to vessel finder - but I can decipher that from the SignalK documentation.
I'm a marine electronics engineer and work with NMEA data everyday but this is the first time that I have tried to get SignalK working and am finding the dodgy documentation frustrating. 
I understand the status indicators on AvNav as I have it working with direct connections. Just can make it all work over the network.

(2021-03-27, 08:17 PM)wellenvogel Wrote: Small addition:
I guess you need to enable the SignalK to NMEA 0183 on the Pi4 (Openplotter).
For GPS RMC should be sufficient.
But I have no idea if there is a plugin that converts back SignalK AIS data to 0183.

But if you have the NMEA data available on your Pi3 it would be easy to configure an additional SocketReader in AvNav to get the data directly from the Pi3, port 10110. You yould even limit this to AIS data by setting up a filter there (assuming you route the position data via SK on Pi3->SK on Pi4->plugin->0183->AvNav).

Does SignalK output NMEA0183 on 10110 by default?
How do I add an additional output or change the port number?

Cheers

   

Got it working. I was trying to read SK data on port 3000

Now to try and convert some useful charts. I tried to convert the free raster charts for NZ using the converter in Windows but it failed on a couple of files and then stopped processing the rest - any chance that there could be an option added to skip files with errors? Charts are available here https://www.linz.govt.nz/sea/charts/info...#nzmariner

LINZ NZ also has vector charts available for free that I use in OCPN. They are S63 format and require the usual user keys etc.. Is there anyway to read the charts already install for OCPN use? Perhaps a modification of the osenc plugin?

Thanks for the pointers
Chris
Reply
#24
I also found plugin to output SignalK data to an AIS service and a whole host of others that were not showing up initially (and the list box to select all was scrolled just off the top of the relevant window!)
Reply
#25
(2021-03-27, 09:58 PM)Littlechay Wrote: Now to try and convert some useful charts. I tried to convert the free raster charts for NZ using the converter in Windows but it failed on a couple of files and then stopped processing the rest - any chance that there could be an option added to skip files with errors? Charts are available here https://www.linz.govt.nz/sea/charts/information-about-charts#nzmariner

Basically NZ chartset can be converted.For this you have to delete all non KAP files (txt, pdf,bsb) from BSB_ROOT. Tried this. resulting GEMF is really big (even split into 2 files). What I don't like is "quilted" view.


Attached Files Image(s)
       
Reply
#26
(2021-03-28, 09:37 PM)BlackSea Wrote:
(2021-03-27, 09:58 PM)Littlechay Wrote: Now to try and convert some useful charts. I tried to convert the free raster charts for NZ using the converter in Windows but it failed on a couple of files and then stopped processing the rest - any chance that there could be an option added to skip files with errors? Charts are available here https://www.linz.govt.nz/sea/charts/information-about-charts#nzmariner

Basically NZ chartset can be converted.For this you have to delete all non KAP files (txt, pdf,bsb) from BSB_ROOT. Tried this. resulting GEMF is really big (even split into 2 files). What I don't like is "quilted" view.

Thanks. Yes I found that was the reason and converted on file successfully. I don't need a full set, or at least not at any one time so I think I can split it up into subsets. The quilted view is a problem. I'll look into some way of stripping of the borders etc.. OCPN manages so must just display the chart bounds and apply transparency to the borders or something Smile

I'm getting there. I like the idea of a server based system. I'll be giving it a trial run on a two week trip in may so will let you know how it goes.

Cheers
Reply
#27
I had a look into the conversion.
Not sure what is going on with the strange borders - some tests with single charts looked completely ok. I will just run the complete conversion - maybe some of the charts miss correct PLY entries ( cutlines).
Unfortunately we currently cannot handle charts that cross -180. I will have a look at this.
It would be helpfull if you could provide the conversion log and the .vrt files from the work dir (they are small...) - they contain the CUTLINE info in metadata.
Most probaly I can also make the converter continue on errors. It is a bit of a tradeoff - maybe you would be surprised later to miss some charts.
Andreas
Reply
#28
Quote:The quilted view is a problem.
@Littlechay: do you really also see this on Windows? I made some quick tests with a subset on Windows - and do not have this issue at all.
It seems to be related to some new GDAL version - but should not be there on Windows.
When you use the chart just be sure to copy all parts of the created gemf to the AvNav server. Uploading inside the app will not work for multi part gemf.
But I guess I will change the size limit so that you will get bigger gemf's in one chunk.

Ok, after some final checks:
1. I guess the problem with the quilted view should not be there for you except if you run a GDAL version between 3.0 and 3.1.1.
2. If you run from the GUI there should be one gemf at the end
3. The remaining problem are charts that cross 180 - but the set seems to be usable after conversion


Best regards
Andreas
Reply
#29
(2021-03-29, 09:55 AM)wellenvogel Wrote:
Quote:The quilted view is a problem.
@Littlechay: do you really also see this on Windows? I made some quick tests with a subset on Windows - and do not have this issue at all.
It seems to be related to some new GDAL version - but should not be there on Windows.
When you use the chart just be sure to copy all parts of the created gemf to the AvNav server. Uploading inside the app will not work for multi part gemf.
But I guess I will change the size limit so that you will get bigger gemf's in one chunk.

Ok, after some final checks:
1. I guess the problem with the quilted view should not be there for you except if you run a GDAL version between 3.0 and 3.1.1.
2. If you run from the GUI there should be one gemf at the end
3. The remaining problem are charts that cross 180 - but the set seems to be usable after conversion


Best regards
Andreas

I'm not sure about the quilted issue on windows.. I meant that it would be a problem in general. I have not managed to produce a set to quilt yet. 

I stripped the BSB files etc out as you suggested and tried to run a conversion on the whole set and got this output in the converter window.

Code:
C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ1490604.vrt -> C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles/NZ1490604.zxy .................
2021/03/29-23:37:03 creating base tiles for C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ1490604.vrt finished

2021/03/29-23:37:03 creating base tiles for C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ615501.vrt at zoom level 15
2021/03/29-23:37:03 running C:\Users\tweed\AppData\Local\avnav\python\python.exe C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py -c -t C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles -p zxy -z 15 C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ615501.vrt
Traceback (most recent call last):
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py", line 1448, in <module>
C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ615501.vrt -> C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles/NZ615501.zxy ....................
   main(sys.argv)

 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py", line 1441, in main
   parallel_map(proc_src,sources)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\tiler_functions.py", line 70, in parallel_map
   return list(map(func,iterable))
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py", line 1350, in proc_src
   cls(src,dest,options).walk_pyramid()
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py", line 779, in walk_pyramid
   self.write_tilemap()
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\tiler_tools\gdal_tiler.py", line 931, in write_tilemap
   open(os.path.join(self.dest,'tilemap.xml'),'w').write(tilemap_txt)
 File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\cp1252.py", line 19, in encode
***Converter finished ***
UnicodeEncodeError: 'charmap' codec can't encode character '\x96' in position 271: character maps to <undefined>
2021/03/29-23:37:09 ERROR: Traceback (most recent call last):
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1786, in <module>
   main(sys.argv)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1747, in main
   generateAllBaseTiles(outdir,mercator)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1332, in generateAllBaseTiles
   generateBaseTiles(chartEntry,outdir)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1322, in generateBaseTiles
   raise Exception("unable to convert chart "+chartEntry.filename)
Exception: unable to convert chart C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ615501.vrt

ERROR: Traceback (most recent call last):
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1786, in <module>
   main(sys.argv)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1747, in main
   generateAllBaseTiles(outdir,mercator)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1332, in generateAllBaseTiles
   generateBaseTiles(chartEntry,outdir)
 File "C:\Users\tweed\AppData\Local\avnav\chartconvert\read_charts.py", line 1322, in generateBaseTiles
   raise Exception("unable to convert chart "+chartEntry.filename)
Exception: unable to convert chart C:\Users\tweed\AvNavCharts\nz3\work\BSB_ROOT\basetiles\NZ615501.vrt
2021/03/29-23:37:09 ERROR: conversion failed

I have attached the .vrt files in a zip
and the log file (delete the .doc on the end )

Cheers
Chris


Attached Files
.doc   avnav-chartconvert.log.doc (Size: 278.53 KB / Downloads: 246)
.zip   basetiles.zip (Size: 852.51 KB / Downloads: 215)
Reply
#30
Ok, we are getting closer...
So you seem to have a different default encoding on windows then me.

I guess I have to explicitly ensure UTF8 everywhere.
Could you maybe try to set the environment variable PYTHONUTF8=1 before you start the conversion?
Reply


Forum Jump:


Users browsing this thread: 27 Guest(s)