Feature Requests

[nohal]

Originally Posted by Baksteen

It is pretty clear why I wouldn't extend a really general standard with metadata dedicated to navigational charts, I think.

No, it is not clear to me why you would not extend a general standard that is designed to a) make extending trivial and b) be immune to breakage from such extensions.

Also, why would I add metadata if the currently-implemented standard is and will not be implemented.

Because we clearly stated that we will implement support for extensions that make sense while we also clearly stated that we will not implement support for stuff that does not. That would probably be a good enough reason for me, but I'm not you.

[Baksteen]

If a description of the contents of a rasterchart doesn't make sense I'll give up.

Literally every official nautical publication contains such a description, being it in plain readable text or a table. Again thanks for your time, but this is going nowhere.

[Montanan]

For it to fold the mapped route when you are done all by itself.

https://media.giphy.com/media/mPytjcsG3XS4o/giphy.gif

[nohal]

Originally Posted by Baksteen

If a description of the contents of a rasterchart doesn't make sense I'll give up.

Literally every official nautical publication contains such a description, being it in plain readable text or a table. Again thanks for your time, but this is going nowhere.

Can you point me to where such a description is in the electronic charts, being ENC or RNC and, if you manage to find such a thing, where it is used to store other types of metadata beyond textual description?
They do contain structured metadata for datums, units etc. though, so I fail to understand why you refuse to apply the same paradigm to your mbtiles products and keep insisting on placing this information into a description field, where it clearly does not belong.

[Baksteen]

Originally Posted by nohal

They do contain structured metadata for datums, units etc. though, so I fail to understand why you refuse to apply the same paradigm to your mbtiles products and keep insisting on placing this information into a description field, where it clearly does not belong.

Last try: MBtiles is a really general format, meant for online display. It doesn't even have metadata for CRS. I will not extend the metadata table in the standard because of for me obvious reasons. It just doesn't belong there.

I therefore cannot apply the same paradigm as for other -dedicated- nautical formats.

Still it is nice openCPN supports MBTiles because it is widely used and is fairly easy to generate. But, there is no place to display some information on the chart contents. Being it depth units or datums, maybe just a warning it is not suitable for navigation. It can be whatever. Let loose the depth units and datum; take an aerial picture. Would'nt you want to know it's surveying date, or what is actually in the bands?

And again, I'm not insisting in putting this particular data (depth units, datums etc) in the description. I'm asking to display the 'description'-entry, whatever it contains. It seems really odd, you have implemented to show empty lines for ID, Depth Units, Soundings, SOurce Edition and Updated (even contains a fixed date) for MBTile files, but are simply unwilling to show actual available metadata.

But it's fine, I won't convince you. I'll use a workaround.

[transmitterdan]

Originally Posted by Baksteen

Last try: MBtiles is a really general format, meant for online display. It doesn't even have metadata for CRS. I will not extend the metadata table in the standard because of for me obvious reasons. It just doesn't belong there.



I therefore cannot apply the same paradigm as for other -dedicated- nautical formats.



Still it is nice openCPN supports MBTiles because it is widely used and is fairly easy to generate. But, there is no place to display some information on the chart contents. Being it depth units or datums, maybe just a warning it is not suitable for navigation. It can be whatever. Let loose the depth units and datum; take an aerial picture. Would'nt you want to know it's surveying date, or what is actually in the bands?



And again, I'm not insisting in putting this particular data (depth units, datums etc) in the description. I'm asking to display the 'description'-entry, whatever it contains. It seems really odd, you have implemented to show empty lines for ID, Depth Units, Soundings, SOurce Edition and Updated (even contains a fixed date) for MBTile files, but are simply unwilling to show actual available metadata.



But it's fine, I won't convince you. I'll use a workaround.

I see no reason not to add nautical metadata to the mbTiles database schema. It can be done so as to conflict with nothing and makes sense. Adding meta data to a description or name field makes no sense and very poor design. It will lead to future disasters by navigators by confusing them.

Your argument that you don’t want to add to the database schema baffles me. Why not exactly?

[nohal]

Originally Posted by Baksteen

Last try: MBtiles is a really general format, meant for online display. It doesn't even have metadata for CRS. I will not extend the metadata table in the standard because of for me obvious reasons. It just doesn't belong there.

Why does metadata not belong to table named metadata, which obviously is there to contain metadata, please?

I therefore cannot apply the same paradigm as for other -dedicated- nautical formats.

INSERT INTO metadata VALUES('depth_units', 'METERS');

Paradigm applied, standard extended in a sane way, nothing existing gets broken, we will happily implement support for it. This easy.

Would'nt you want to know it's surveying date, or what is actually in the bands?

Of course I would love to know all this, from sane metadata in the tileset that can be handled in a sane way.

It seems really odd, you have implemented to show empty lines for ID, Depth Units, Soundings, SOurce Edition and Updated (even contains a fixed date) for MBTile files, but are simply unwilling to show actual available metadata.

We have not implemented anything, we are waiting for mbtiles tilesets containing this metadata in a sane way that can be processed in a sane way. There are no such tilesets available at this moment. You, for example, even refuse to start producing them for reasons I do not understand.

[Baksteen]

Ok, this was clearly a misunderstanding. I thought you meant actually contributing to the standard. I still have some doubts on extending this, because of the information is then probably being lost in other software packages. But will create a tileset with this extended metadata. Will contain update_date, depth_units, soundings_ref, attribution.

edit:
https://filebin.net/754whqj56195cnm6

[nohal]

Originally Posted by Baksteen

Ok, this was clearly a misunderstanding. I thought you meant actually contributing to the standard. I still have some doubts on extending this, because of the information is then probably being lost in other software packages. But will create a tileset with this extended metadata. Will contain update_date, depth_units, soundings_ref, attribution.

edit:
https://filebin.net/754whqj56195cnm6

Of course publishing, well documented, metadata extension and eventually merging it to the standard is the obvious next step in your efforts of making mbtiles fit for your application, which will clearly benefit others with similar use case.

[tedcoats]

Hi,
I appreciate the on-going development of OpenCPN - we are all indebted to those at the technical end of this - thanks!
The split screen feature is really good - but assumes that screens are positioned in landscape - long dimension horizontal. I am about to get a larger screen. This would be better mounted in portrait mode. Is it possible to have the split in the screen horizontal so that a portrait mount is better utilized?
Cheers
Ted

[PJHoffnet]

Initially posted as a question in the forum, no responses so I guess the feature doesn't currently exist.

- In the Route and Mark Manager (particularly route and track) I'd like to add additional columns such as a column that shows the length of the route/track.

While the Properties view for each route/track has that information, along with things like speed and time to complete a route at a specific speed, being able to see that information for several routes in one view would be prefered (at least for me).

Bonus points if speed could be changed 'live' for individual routes in the list of routes so, while looking at a string of routes you could voyage plan.

Thanks in advance.

[rgleason]

PJ
We don't recognize bonus points. You could post a detailed feature request in tracker, vote for it and get others to vote, then the developers/programmers may consider it, or you could make the code changes and make a PR.


PS: I once posted a pic of jelly beans to a programmer friend who was especially helpful working out knotty problems with celestial_navigation, weatherfax and weather_routing to get it to build. I was very grateful, but in retrospect, I think that was a bit insulting, although not intended. So, I will thank Stelian again for his fine work.

Originally Posted by PJHoffnet

Initially posted as a question in the forum, no responses so I guess the feature doesn't currently exist.

- In the Route and Mark Manager (particularly route and track) I'd like to add additional columns such as a column that shows the length of the route/track.

While the Properties view for each route/track has that information, along with things like speed and time to complete a route at a specific speed, being able to see that information for several routes in one view would be prefered (at least for me).

Bonus points if speed could be changed 'live' for individual routes in the list of routes so, while looking at a string of routes you could voyage plan.

Thanks in advance.

[Baikal]

Tested the work of MbTiles satellite maps of large territories with 19 and 18 layers for local detailed areas and 14 layers for overview maps and 10 layers of the world map.
The hardware of my computer is pretty powerful. Read speed SSD 3431.806 MB / s but I see a big frieze in 3 seconds with zoom on layer 19.
On a computer with a regular HDD frieze, more than 3 minutes and you have to complete the CPN process.

The problem seems to me that in the MbTiles display, the display was removed depending on the scale.

I built a CPN assembly with a low display scale. and it became much better even on a regular HDD. This was the case at the very beginning of mbtiles support development.

I think the format MbTiles should be displayed on the scale and the layers on which it is made.

[Baikal]

Originally Posted by rgleason

I just substituted FV3GFS instead of GFS in my email, and it worked fine, does this look right?

Thank you Pavel and Dave.

With the addition of another type selection, this should become very useful.

Since June 14, FV3GFS Sail Docs is not working
Who knows what?

[cagney]

Originally Posted by Baikal

Since June 14, FV3GFS Sail Docs is not working
Who knows what?

Because GFS has been updated to FV3, so that when you now request GFS you actually gets "FV3GFS". https://www.mlive.com/weather/2019/0...g-june-12.html

Thomas