Is there life after S52RAZDS ?

[JesperWe]

Me, I care about how my charts look on screen. Two years ago I created a comparison of chart rendering across various chart plotting softwares. (http://www.journeyman.se/charts/)

Since then, one of the things I've often thought about wanting to do is work on improvements for OpenCPN rendering. I never found time for it until now. But now I'd like to offer some thoughts and see what you think. I did try to search to forum for previous discussions along these lines and found very little, so I hope I am not reinventing the wheel again ;-)

The recent OpenGL development has improved chart looks by anti-aliasing certain elements. And I guess there is potential for more. But the looks of the symbology is still controlled by the living useability disaster that is S52RAZDS. Now some 12 years since that was created, we have better tools at hand...

Basically my thinking is that as long as symbology is defined using S52RAZDS, there will be no reasonable path forward.

What I would like to have long term is a framework for chart symbology that allows:

- Good looking symbology using antialiased graphics.
- Possibility to edit symbols in a contemporary image editor.
- National packages, that allow you to switch from US charting standards to those of other countries.
- Config files in XML, more human readable, and also read/writable by software. For example allowing creation of an OpenCPN chart skinning editor.

I did a small "Feasibility study" which was prompted by my being annoyed with the UWTROC04 symbol looking like some kind of giant spider crawling in the water.

I created better looking versions of a few symbols, and in a small hack in s52plib just went and replaced the bitmaps in *prule with better ones. (BTW, HPGL? In this day and age :-) )

The resulting output of this small test looks like below (animated image before/after). Notice appearance of UWTROS03, UWTROC04, LNDARE01, BCNTOW01, BOYSPR60 and BOYCAN60. And look at the image full size, not in the vBulletin scaled version!



I know some will probably say "I can't see the difference. Who cares?", but to me this kind of small polishing makes the chart easier to read and the product look more professional. Especially when it is carried through on all levels.

Performance wise, changing to a different way of defining the symbols will have zero impact on zoom/pan, since the same size/depth bitmaps are used. App invocation might see some impact, parsing XML and reading PNG files instead of parsing S52RAZDS maybe will be slower, but I have a hard time believing it would be noticeable, since it is a one time operation at invocation (or the first time the symbol is used).

Actually, the even better way to implement a replacement to S52RAZDS would be to use SVG. In this way the entire dataset could be in a single file, instead of an XML/PNG combo. But I have not found (after looking at everything I could dig up in Google) any reasonable reader for the full SVG spec that would be needed, like Element IDs and custom properties, that would integrate well with wxWindows.

Soo... I my general question is: Is this a good thing to work on? It's going to be a fair amount of work, and I don't see any point in embarking on it unless the project leader(s) approve of it.

[nohal]

Jesper...
As it's quite late here already, I will get back to you with more info tomorrow, but accidentally you again touched something I worked on a bit
Couple of links until then:
OpenCPN - Rasterization Rules Editor - Redmine
https://github.com/nohal/RleEditor
https://github.com/nohal/RleData

A fancier symbology is a nice idea for sure, but at the other hand now we are pretty close to the standard for ecdis systems (and to paper charts), so anybody coming from there is pretty happy - good reading at IENC Presentation Library 2.3 | IENC side of the OEF - the offshore version is probably similar, but unfortunately not publicly available.

Definitely not saying there's not enough room for improvements in this area...

Pavel

[JesperWe]

Originally Posted by nohal

you again touched something I worked on a bit

Of course ;-) You're a smart guy....

Originally Posted by nohal

OpenCPN - Rasterization Rules Editor - Redmine

Very (Very!) nice work. But no antialiasing support AFAICS, which makes it less useable for my purposes...

Originally Posted by nohal

(and to paper charts)

Yeah, as long as they're NOAA paper charts.... And still no antialiasing. As you say, room for improvement. This is what I would like to address.

[JesperWe]

Well, I decided to bite this one. Here is a status update. This is no longer an ugly hack but instead quite useable code. (remember to watch at 100% scale!)

Tell me what you think!

[cagney]

(remember to watch at 100% scale!)

Watch what? No links,attachments or pics.

Thomas

[JesperWe]

Hmm this vBulletin thing is no good when you are on limited bandwidth and surf without images... (I have a 10MB/day cap right now :-) )

The image is at http://journeyman.se/hd/chart2.gif

[Zoef]

The new version looks more clean-cut with crispier colors. An improvement.
What now?