Sounding size adjustment on Vector Charts

[bcn]

P_Dub,

nope, the soundings are not fonts - not texts - but symbols/bitmaps.
So you can't say: Arial Black 12p

And the clearer gray and the black ( that's within the Safety Contour defined by the user) form part of the S52 standard as well.

Hubert

[P_Dub]

Originally Posted by bcn

P_Dub,

nope, the soundings are not fonts - not texts - but symbols/bitmaps.
So you can't say: Arial Black 12p

And the clearer gray and the black ( that's within the Safety Contour defined by the user) form part of the S52 standard as well.

Hubert

Try it you will see, that is the way to do it in CAD and the program for making the charts.

[P_Dub]

Here is a way to alter the soundings size.

[rgleason]

As several pointed out, including RDr, I believe, with pixel density of screens getting denser, there will need to be a change in the ECDIS symbols, because they will occupy the same number of pixels, but appear to be smaller and smaller with each increase in pixel density. So it is inevitable that things will change with vector charts and the underlying symbols.
Who knows how the symbols will change, increase in size, or morph to some other system.

What is important is to adapt and improve legibility even if it is within the framework we currently have. P_dub thank you for the Nobeltec screenshot, that is helpful information too.

We're learning a lot about how things are rendered, and it is a complex topic, with lots of user ideas, but it seems like we should be able to make some useful changes.

[HappySeagull]

Originally Posted by P_Dub

Also, one thing that could be change while you are at it, is to make the soundings normally darker and independent of the setting of Deep depth or Shallow depth adjustment.
Best Regards and Happy New Year to everyone.
P_Dub

ah,well..it took me awhile to get back to it, but increasing SAFETY DEPTH seems to be the way to get darker soundings....

[bcn]

Cause that's as it is defined in S-52: Black in shallow waters as defined by Safety Depth and Gray for the rest...

[P_Dub]

Originally Posted by bcn

Cause that's as it is defined in S-52: Black in shallow waters as defined by Safety Depth and Gray for the rest...

There must be a way to modify this, as some company have done it!
Regards

[nohal]

P_Dub...
Yes, we can paint it in pink if we want. The questions involved are completely different: Do we want to deviate from the IHO standard? How exactly do we want to deviate from the IHO standard?

Pavel

[bcn]

In this context I see three issues

- compliance or not = we can do what we want for sure
- de-cluttering - just have look here for more inputs:
Dynamic Decluttering
- screen resolutions and requirements under several platforms - from 4" to 30" and from 480x600 to 5K

The three deserve a debate on its own

Hubert

[P_Dub]

Originally Posted by nohal

P_Dub...
Yes, we can paint it in pink if we want. The questions involved are completely different: Do we want to deviate from the IHO standard? How exactly do we want to deviate from the IHO standard?

Pavel

Well, the recommanded IHO standard were made many years ago (end of 1980) and the computers have change a lot since, but some people are slow to update!

[bcn]

Originally Posted by P_Dub

Well, the recommanded IHO standard were made many years ago (end of 1980) and the computers have change a lot since, but some people are slow to update!

The latest version is from 2014.
Yes, making standards, maintaining those and proposing future ones (the S-100 series in our case) is a task that usually takes more time than one would like to see. (Why do you think the CM93/2 charts do exist still?)
And it even fails.

But don't underestimate the guys from Hamburg, Oslo and Taunton - and in some places in US, Japan and Korea or Australia. They know very well about this issues...

[nohal]

P_Dub...
This really helps finding the best solution, many thanks. Nobody ever said that we will not implement it, all we want is to do it right. The more valuable, to the point, contributions like this you will make, the longer it will take, obviously.

Pavel

[P_Dub]

Originally Posted by nohal

P_Dub...
This really helps finding the best solution, many thanks. Nobody ever said that we will not implement it, all we want is to do it right. The more valuable, to the point, contributions like this you will make, the longer it will take, obviously.

Pavel

Sorry if I frustated someone, it was not my intention.

[bcn]

Originally Posted by P_Dub

Sorry if I frustated someone, it was not my intention.

No issue from my side - these are the points we have to discuss in order to getting better --> from a sailors point of view

[rgleason]

Could be simple, since pixel density has increased, how about double (or 1.5x -1.75x) the pixel density of the underlying symbols file? Or perhaps the soundings symbols. Then there would be less pixelation and further scaling increases would be possible.

Dynamic declutter sounds pretty good, how expensive in terms of processing?
Does this soundings symbol overlap with any other?

Before drawing a soundings symbol check to see if its insertion point is =< (3 x symbol pixel height) of any other symbol insertion point? If it is, don't insert it or draw it.

This would act as a filter before drawing the sounding symbols. It might even speed up redraw a little because un-needed sounding symbol bitmaps will be skipped.

That would solve the scaled out problem when soundings overlay on top of each other.

How to solve the soundings symbol problem ?
1. User options control to change a scale factor for size of soundings.
2. What gets changed?
- Underlying soundings symbols, increased in pixel density by some factor. This may be a challenge unless gimp has simple tool that can do it.
- Accept the soundings symbols as they are an render them larger at time of insertion. This will work for a little while while industry catches up.