NOAA RNCs ar going away.

[P_Dub]

People are removing the lights showing those circle around lights (Scandinavian type (sorry for you fellows)); this method is innapropriate and that is most likely the reason for the remarks of some. I did mentioned it a few times, but nobody listen, that is a foolishness of IMO. Why not replace it with a proper light sign like we are use to in North America.
Also, the future of ENC is to allow for depth varying according with the tide gauge recording, which would be another change to get acustom with.
Bye bye.

[Kettlewell]

I did mentioned it a few times, but nobody listen, that is a foolishness of IMO. Why not replace it with a proper light sign like we are use to in North America.

I've seen some ENC renderings where the buoy numbers look just about the same as the sounding numbers making them hard to read. ENCs seem to assume that they are being viewed solely with a GPS chart plotter running showing the boat's position accurately, but sometimes, like in the fog, you really want to know what number and color buoy you should be seeing. I have seen places where two channels intersect and it can be confusing as to which channel you are in, like in Woods Hole for example. The green #1 in the Strait and the red #2 in Broadway can look like the channel markers from a distance, which puts you right on Red Ledge. I have seen a big sportfishing boat perched there high and dry on the rocks.

[Mal Reynolds]

NOAA is in the process of "rescheming" ENC charts to mbtiles: https://www.nauticalcharts.noaa.gov/...al-charts.html

Status of the rescheming progress here: https://distribution.charts.noaa.gov/ENC/rescheme/

The rescheming has much more of the aesthetic look and available detail of raster charts in a natively electronic format that will be much more efficiently maintained and upgraded over time.

If you run OpenCPN, you can download and use the mbtiles here: https://distribution.charts.noaa.gov/ncds/index.html

I've been using the new format over the Summer in Maine. It's terrific. Place names are too small, but I understand they will be addressing this with further updates.

Note that if you use a chartplotter, you are locked in to whatever format they want to provide, and there are lags between NOAA updates and when they make it to your chartplotter.

Discussion here:

https://www.youtube.com/watch?v=YaHsqWkPCwQ&t=3s

[bcn]

Rescheming and publishing in mbTiles format are two different shoes:


The first one, which goes in parallel ceasing RNCs, is described in detail in the link cited above.

Creating mbTiles is another way of filtering data: it's about transforming an ENCs image, like taking a snap-shot of the screen, portraying the information represented in that moment. No way to query an object or to display objects that are not shown for what reason so ever.
The mbTiles are rasterized screen images, but I would not call them RNCs.

The same issue applies to mbTiles generated via SASPlanet from sources like the Navionics online-charts.


So be aware of the inherent limitations.



(In theory mbTiles dose allow for vector image tiles, but in all of our cases here, this is not the case)

[requiem]

Originally Posted by sailingharry

As an example of the problems that this creates, imagine entering Annapolis harbor. Up ahead, you see a quick flashing green. Which buoy is that. On the attached ENC from Navionics, it will probably take you a while to find it. On the attached RNC from OpenCPN, it is shown on the image.
Even more amazing, at this scale the ENC doesn't even show buoy numbers

I normally keep them off due to clutter, and because pulling up the details is pretty quick, but this is with them enabled...

Attachment 282119

As for Winyah Bay, the "danger layer", as one might call it, is the safety contour. If someone can't be bothered to set it...

Attachment 282120

For me, a major issue is that ENCs have been rolled out for professional mariners, who are trained on them and the software, but have simply been "made available" without much in the way of software or training for anyone else. (Again, Navionics isn't using ENCs. It's using electronic charts, a distinction along the same lines as that between a SPOT and a PLB.)

I'm not sure it's reasonable to expect to simply hand someone an app (or even a paper chart) and expect them to navigate safely with it. Some of us may have had the "private tutor" experience with a parent or other mentor teaching them many things perhaps now taken for granted. Others may have gone through school, or are simply self-taught.

Chotu mentioned "if those people were kind of new and didn’t have the experience to know you should start a channel like that at the safe water mark...", to which I'd ask, why do they not know this? Is this not like handing someone the keys to a truck, setting them loose inside Stuttgart, and expecting them to reach their destination without multiple traffic tickets?

Or, if someone buys a used table saw, can't be bothered to look for a copy of the manual or other safe operating instructions, and tries to work it out for themselves, what are the odds they'll know to be concerned about kickback, or still have all their fingers at the end of the year?

[requiem]

Ehh, looks like the attachments broke...

Software should be able to display the light characteristics, like this:


Or like this... (Coastal Explorer doesn't show the buoy numbers, but it's a one-touch access.)


As for Winyah Bay, one newer concept with ENCs that I think most miss is the concept and use of the depth settings, e.g. safety depth and safety contour. But, this goes back to the training/education issue.

[sv_pelagia]

FYI...

Canada's CHS is also in the process of phasing out RNCs.
https://www.cruisersforum.com/forums...d.php?t=260775

[Kettlewell]

For reference, here's what the Winyah Bay entrance looks like with the RNC on Open CPN. So much better! I'll take the RNC any day.

[CaptTom]

Originally Posted by JBP

It's a shame. The RNC's have so much more information than the ENC's.

Originally Posted by bcn

That's perhaps not that correct. Actual RNCs and ENCs share the same data base.

No, they don't.

I'm all for progress, and I'll get used to the ENC's. I don't really have any complaints about the look, or how they're displayed. I can even get used to data appearing and disappearing as I scale in and out. That's true with paper charts, too.

My beef is that it would appear NOAA went with the low bidder on digitizing the charts. Specifically, data is missing and labels are in the wrong place.

First, lots of place names and shoreside structures were removed. They're not in the data anymore, at any zoom level. I always like to give a geographic reference when communicating my location, especially in an emergency situation. But many of those place names (bays, harbors, islands, rivers, towns, etc.) are just not there.

I can see the argument against including shoreside structure. I personally found it helpful to know there's a town, or a rail yard, or a few scattered houses on shore. Very helpful in piloting. But, OK, nobody does that any more. They've got their heads buried in a screen. Fine. I don't like it, and I don't think it's safe, but I get why NOAA doesn't want to be in charge of mapping every land feature along every coast.

What I find comical is that these low-bidder digitizers (probably in some foreign country, with a different native language) made some pretty poor decisions on what place names to include. The big, bustling harbor name is missing, but some lone hill, miles inland, or worse yet, some bog far from navigable waters, is included. At least cartographers who did the raster charts had some clue as to what was and wasn't important to the mariner.

The labels are another example where having a cartographer at a drafting table was an advantage. Say you've got a few islands and points of land in a harbor. The cartographer would try to put the labels wherever it would be easiest to identify which point it was referring to. At some scales, it might be to the left of the island. Others, to the right, below or above. No matter which chart you looked at, you could figure out which was which.

Along comes the low-bidder digitizer. They see the words "Pumpkin Island" on the first chart, and duly enter that label's exact location. But as the charts are scaled in and out, that location can look closer to another feature, or out in the middle of nowhere. Some chart plotters will left-justify the label, others right-justify or center the label. There's a good chance it won't match up with the point it's intended to identify.

Again, these are artifacts of the process, nothing against the format. ENC's can and should be done a lot better than they are today. Done right, they can be even better than RNCs.

I only hope, over time, there's a budget to go and fix all these issues. Until then, I'll keep the old RNCs handy. Not for navigating, but for identifying where I am.

[requiem]

Originally Posted by CaptTom

But as the charts are scaled in and out, that location can look closer to another feature, or out in the middle of nowhere. Some chart plotters will left-justify the label, others right-justify or center the label. There's a good chance it won't match up with the point it's intended to identify.

This is an interesting one. I agree there's a huge issue around identifying and retaining appropriate local names, but the labeling is a bit less simple.

With raster you have the option of printing at any angle you want. On an ECDIS (the intended display unit for ENCs), I believe there are certain specifications around font & symbol size, as well as placement. I mention this as a reference for some underlying "why"s, because obviously other nav software will be written however the creator preferred. These standards were initially developed back in the 80s and 90s, and so might still carry some limitations from that era.

The specs in play:

One of those specs is that text should be readable from a meter away, and thus symbol and text size should be about 4mm minimum in height. (Looks glaringly at Navionics.) The other is that text should always be drawn screen-up, so that if you're proceeding, say, due south, and have the display set to course-up, all your labels won't be upside down.

I couldn't immediately track it down, but I believe the placement of labels is also fixed, e.g. they will always be offset the same distance and direction from what they label. (It might be different for buoys vs other objects, and for "areas" such as a bay or city placement might be more flexible.)

Work likely can and should be done to properly select and prioritize place names, if it's not already. But, the physical placement of text on screen will likely not return to the paper style due to issues around rotation: such precise jig-saw puzzle fitting really only works if the chart has a fixed orientation. Once things can rotate that becomes very hard to do on the fly, and there's a good chance of confusing which label applies to which object.

I am curious how many use heading-up or course-up display modes with RNCs, compared to with ENCs.

The concept shift:

Paper charts have a great deal of clutter on them, and careful manual work is needed to ensure everything fits together, like loading a dishwasher after a massive dinner party. The intent of the specs is to reduce potential for confusion, which means a strong emphasis on de-cluttering (remove distractions) and fixed placement (remove ambiguity).

The power of ECDIS lies in conveying operational information quickly, clearly and comprehensively through a picture, a birds-eye view of the ship and her surroundings. Text should be avoided on this graphical operational display unless it is absolutely necessary, because it conveys limited information and, since it has to be written large to be readable, causes confusing clutter. -- The S-52 specification, on displaying text

This concept shift is the idea that one can pare down the display to the key elements needed for safe navigation, eliminating unneeded clutter, but still being able to add or remove layers of detail as needed in different stages of the chart usage, e.g. initial passage planning vs underway monitoring of position. I think many apps focus on trying to recreate the paper experience rather than finding more effective ways to manage this de-cluttering concept.

[CaptTom]

I certainly see the problems with getting the labels right. The "old way" where a cartographer chose the size and location for the label, based on the scale of the chart being drawn, worked well. But of course that's not ever going to happen again.

So, what's the solution? I don't agree with the premise that text should be avoided altogether. That seems like a very lazy way to "solve" the problem. More of an excuse than a well-thought-out resolution.

Picture this: You're in an unfamiliar location and someone on board is injured. You need to make a mayday call. But your chart shows only bottom contours, ATONs and navigational hazards. Sure, you can give latitude and longitude, but if you include a place name, it'll get the attention of local boaters who may be able to help. And if the chart shows shoreside infrastructure like buildings, villages and docks, you might have a clue as to which direction to head toward to get help.

Sorry, I just don't agree that text has no place on the display. I do agree there needs to be a better way to display it. It needs to be oriented correctly and visibly associated with the object it's labeling. IMHO, that should have been considered while the standards were being developed, rather than just throwing their hands in the air and declaring text obsolete.

[bdbcat]

All...
Here is a little color regarding the "feature name" rendering logic used by ENCs.


1. The ENC cell itself is essentially a database, containing features and objects with attached attributes such as location, characteristics (e.g. buoy type and color, name), etc. One important attribute encoded by the cartographer is something called SCAMIN. This is the minimum display scale at which the object should be displayed.
Logic goes like this: As you zoom out, the display scale goes down. At some point, assuming the feature is itself drawn at a readable size on the screen, the screen becomes too cluttered to safely interpret. So less critical features are de-prioritized by the cartographer, in an attempt to improve usability.
Note: Critical point: There are no other data in the published ENC cell stipulating how the various feature should be drawn on the screen. However, the cartographer may, by careful selection of attributes, tune the most-probable on-screen rendering logic. More on that in #2.



2. All chart plotters, ECDIS systems, and PC software based navigation systems use an internal module to translate the encoded cell data into a rendered image on the screen. This module is typically called "PLIB", or "Presentation Library".
Approved ECDIS systems generally use something called the S52 PLIB. This is a standardized library, with a very detailed and concise method of rendering defined for every possible feature that might be found in the ENC. ECDIS systems undergo an official qualification process before type approval, where the PLIB implementation is fully validated.
Alternatively, chart plotters and PC-based systems are free to use any PLIB implementation they choose. Most such systems generally start with S52, but add enhancements as their authors perceive their target users might appreciate. And this is why we see variations among the available chart plotters, even though they are often using the same ENC cell data.


3. Back to feature labels: S52 PLIB specifies exactly where a feature label appears on-screen, relative to the ENC declaration of the feature's geographic position and attributes. So many character spaces to the left, or right. Justification. Text size, etc. This is all standardized. PLIBs based on S52 tend to follow these instructions, because the cartographer knows that S52 is the basis for most PLIBs in common use. She/he chose the correct attributes for the feature in the cell, so that the label will appear in a sensible location as rendered. As you can see, there is a bit of an assumption bias toward S52 built into the cell data.


Enough theory.
For reference, OpenCPN uses a PLIB based on S52, with a very few enhancements. Enhancements include:
a. Improved object rendering for things like buoys, beacons, and lights.
b. Ability to change the font and base size of labels on-screen.
c. Ability to disable all SCAMIN processing, useful for some poorly encoded ENC cells.
d. Ability to change (by config editing) the basic colors used for things like land areas, sea areas, etc.



And that is about it. We chose this strategy for OpenCPN so that we could refer to an IMO accepted standard, rather than have endless debates about what/how to render ENCs usefully.


Sorry for the long-winded school call. Rendering of ENCs is, as you may now understand, not a trivial thing.


Dave

[requiem]

Dave, any chance you have an idea of what we might see with regards to the S-101 standard? I have read it allows more control over text positioning, but I suspect it will be a few more years before it becomes commonplace?


Careful use of the SCAMIN attribute should be sufficient to permit local names to show up at an appropriate zoom, so I do think something went wrong with the inclusion (or rather omission) of local place names in many places (or at least those places where people raised complaints).

For example, someone was able to label each of these small local coves on the Marin coast:

[CaptTom]

Thanks Dave!! That's a great overview and I learned a couple of things.

I'm especially interested in the SCAMIN attribute. I assumed there must be some prioritization of objects so that they could be displayed at the proper scales. Somewhere I read that this prioritization was only done by the display software, and was nowhere to be found among the data. I feel better that someone actually had to decide this value based on some passing familiarity with the data being digitized.

I assume that getting centuries' worth of cartography data digitized in a short time and on budget probably meant that whoever was doing the digitizing was nowhere near as familiar with the area being digitized as the person who originally drew the charts. So I accept that the quality of the data will be lower, at least until the next survey.

I'm curious how labels are defined, when they identify non-point objects. Say, a harbor, bay, peninsula or island. A great example is a river. In old raster charts, you might find at some scales the river is just a narrow ribbon on the chart, with the name carefully written in letters shorter than the width of the river. The name curves with the river, rather than being written in a straight line. I'm sure there's no way to digitize that!

From what I've seen, it looks like the digitizer just picks a few spots along the river (or in the harbor, or on the island, or whatever) and plunks a point at each, with the attribute of the name of the feature. As I scale in and out, more or fewer of these names appear on my screen. At some scales, they make perfect sense. At others, it's hard to tell which feature they are associated with.

Most frustrating is when you're offshore, but have to scroll over and zoom way in to see the names of even the busiest harbors or most prominent islands along the coast you're passing. Surely some places are important enough to show up even at small scales.

It is good to know there's a standard for justification and padding of these labels. That should help. If I know to always look, say, to the right of objects for their labels, I'll know that it's not the label for the object to the left.

There's still the problem (in some areas) of objects which were never digitized, at any scale. Important things like local place names, shoreside structures and geographic features which are helpful in piloting, or giving your position to rescuers. I don't think that will ever change. I've taken to keeping Google Maps open on my phone or tablet while navigating unfamiliar coastlines. I suppose that's OK. No sense having my tax dollars duplicate the effort Google is already doing.

[Kettlewell]

There's still the problem (in some areas) of objects which were never digitized, at any scale. Important things like local place names, shoreside structures and geographic features which are helpful in piloting, or giving your position to rescuers. I don't think that will ever change. I've taken to keeping Google Maps open on my phone or tablet while navigating unfamiliar coastlines. I suppose that's OK. No sense having my tax dollars duplicate the effort Google is already doing.

Yes, Google Maps can be very helpful for the land information that is missing from charts, and I have found the satellite view will often allow me to identify things that are not labeled and missing from the default map view.