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
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.