Orienteering NZ Wiki

Symbol/colour numbering, conversion to a standard, culling near-duplicates etc. Also the colour order, the overprint effect, and issues for colour-blind orienteers.

Anyone got any experience with “load symbols from…” I've avoided it because of fear of getting undefined symbols due to numbering changes, and I've done some laborious editing of old symbol tables to bring them into line with the current ISOM. And to do away with spurious duplicates caused by importing and pasting. Is there an easy way to tidy up symbol tables?

Yeah I have done it before, but the person to talk to is Greg. He is a legend doing it as he has to do it to convert maps for catching features

I presume Michael you have done a right click on the symbol table, - “select” - “unused”, right click on any of the many unused symbols, then delete. That gets rid of all the unused symbols including any normal symbols you haven't used yet. At least it leaves a very compact symbol table.

I have had all sorts of trouble importing symbols from other maps. To get just one or a few symbols in, I have created a separate map, deleting all the symbols I don't want, then imported it. Seems to keep it simple. What's very frustrating is importing another map with it's symbols. Sometimes in OCAD9 I have selected “Import symbols if symbol numbers exist but symbols are different” or “Import symbols if symbol numbers exist but symbols are different” and OCAD has introduced the symbols but refused bring in the map, leaving undefined rubbish on the screen or nothing on the screen, until I use “Import symbols and colors” which of course intoduces a enormous jumble of symbols and colours. The problem may be that the colour defnitions are different in the two maps. I notice that OCAD9 now lists colour numbers in the 100's and 200's if you open a new map. Older versions of OCAD used double digit colour numbers below 100. This might be why some of my imports have insisted on duplicating the colour set.

Does any one know if there a way of going through the list of colours and getting rid of any unused ones? And a way bringing up a list of symbols with their associated colour numbers, other editing each symbol separately.

There hasn't exactly been a flood of suggestions, which suggests it IS a knotty problem for maps that have had a long history. I'm not sure I like your method of getting rid of everything unused.

BTW I hereby announce that I am using the brown cross (NZ has not hitherto defined a standard use for this) for geocache sites. Normally hidden of course, but I've been successfully geocaching with my paper GPS.

The reason there hasn't been a flood of suggestions regarding unused symbols is most likely because is is not a problem for most mappers. Most of our(SOC) map files have got many unused symbols, most of them are generally moved down to the bottom of the symbol box out of the way. They don't interfere in any way with my work so why delete them? The map I'm working on at the moment has, amongst many other objects, got no pits. Should I happen to discover a pit in a new area of the map then it would be handy to have it in the symbol box rather than having to import it. As for unused colours, there may be some colours you think will never be needed,White for example, and some day you will discover that you actually do need a colour you have deleted. Sure, you can import or create it again but it is much simpler to leave the unused colours where they are.

The problem isn't unused symbols, but symbol proliferation. When you import or paste and the symbols differ in the slightest respect, you end up with additional symbols. I'm grabbing bits out of other files all the time - usu an old file which has the right layout which I gut and then bring into the latest version of the map. Whose symbols have probably “moved on” in many small respects…

I dont think there is a simple way around it but select and change, then checking to make sure nothing is wrong. Then delete the leftover symbol.

Back on the symbol proliferation problem, I'm trying to increase my understanding so I can minimise the problem at source. It may be that just writing down the problem that I perceive will solve it:-)) If you're not a regular OCAD user read no more.

When you IMPORT there's a choice of 3 options. The BOTTOM one “import symbols and colours” seems the worst, if there are any colour definition differences new colours get added to the colour table. Because they are at the bottom the colour-order gets completely stuffed up, fences may be covered by open land etc etc. Don't know why you would want BOTH versions of a colour.

The MIDDLE option “import symbols if symbol numbers exist but symbols are different” is what I have been using. I have been worried about losing any INTENDED differences between the symbol sets, but it leads to proliferation. Maybe it's no big deal, but see below.

The TOP option (and maybe that position suggests it should be the norm) is “import symbols only if symbol number do not exist”. This would mean that symbols that were different in the “from” file would adopt the properties in the “to” file. I guess that's OK provided that the “to” file has the preferred symbols and there are no numbering differences. So when I assemble a map from my latest “raw” map and a “layout” (border and legend etc from an old map of the same place) I need to go in the right direction. Otherwise detailed improvements in my symbols will be lost - and I am still finding the odd ISOM2000 change that I have not made.

I'll need to think about the hidden symbols that I use as drawing aids - making sure they have the same symbol numbers. More importantly there were some symbol number changes in ISOM2000 and this could mean that a pit (was 115) becomes a depression, a high tower (was 537) becomes a cairn, etc. The “from” map doesn't need to go back before 2000, only the symbol set, and I see lots of maps that borrowed early Mark Roberts symbol sets. Now I dig into it, there was a real basis for my habit of using the middle option.

But I guess if I trust the “from” file I could be using the top option. BUT which one applies when you use copy-and-paste? I suspect that it's the middle one. You aren't given any choice.

The colours are a potential nightmare. There are so many people using so many printers. Last time I used my own HP colour laser I had to change some of the colours and line thicknesses to get as aclose to ISOM 2000 as I could, BUT I made sure when I returned the updated map file that I also reset the colours etc to how I found them. It would be up to a club map printer person who sends maps to a regular digital printer to keep the specifications correct for that particular printing house and make sure a record is kept and things are put back to normal for filing.

Don't read this if you're not a regular OCAD user. It's messy. It's obviously not creating a great deal of difficulty, but with a new IOF mapping specification being worked on, it might.

I've been doing the job I hate - tidying up the symbol table on a map. I often refer to a new blank map for unadulterated symbol numbers. I am pretty sure that at some time in the past the green circle was 418 and the green cross was 419, because that's what's in many of my maps with a long history. Now, if you start a new blank map, the green circle is 419 and the green cross is 418.

Why worry? At best, if I were to import a recently made map into one of my older maps, OCAD adds new symbols to the table, ie 418.1 and 419.1 and I have a strange mixture. I end up with circles that could be 418.1 or 419.0, and crosses that could be 418.0 or 419.1. Or the other way round, I said it was messy! That's if I choose the option “import symbols if symbols are different” or “import symbols”.

At worst, if I choose “import symbols only if symbol number do not exist”, the circles become crosses and the crosses become circles. I am pretty sure this is what happens if instead of “import” you do a copy-and-paste.

I have been vaguely aware of this in connection with black symbols over 510 and brown symbols over 112, but thru a “feeling in my bones” generally use the “import symbols” option.

I would guess the green circle/cross thing came about by accident. The specifications list the circle and cross in the same paragraph “418, 419 Special vegetation feature”, and the example circle came first on the old speci and the example cross came first in the current one.

But the other symbol re-numbering happened when symbols were added or deleted from the specification. This is highly likely to happen in the coming revision. Should we be lobbying OCAD for a technical solution to this problem so that we don't have more trouble when the new speci comes out. Or (more powerfully) asking the IOF Mapping Committee to do so?

But maybe I'll wake up as if from a bad dream and someone will have given me the obvious solution?

Tidying up symbols is extremely messy. OCAD9 simplifies it to a degree. You have the “Compare” option which allows you to compare your map symbols against a standard (pressumably the standard ISOM2000)set.

You can also easily select what symbols have been used to create the map in one operation. This culls the unused icons and saves time. Export the ones you need to work on and save in one file. Export the culled ones and save in another file. Once you have done your editing and resaved, merge the two files and resave. BACKUP first.

For those still using OCAD8 (good on you), make friends with someone who is a competent OCAD9 user. The map/icons can be saved in OCAD8 format.

Can you give us a steer on using “compare”, Map Guy? I (re)tried it today (vs a new blank map) and the 11 pages of text are mostly inconsequential variations. These include that “colour is blue vs blue” which I suppose comes from slight differences in the recommended colour mix, or perhaps the colour numbering. And they include small size differences on circles and crosses - mine outside-to-outside and the blank map centreline to centreline.

As I didn't create all these symbols, I must suppose they came from variations in the OCAD default symbol set over the years. What I want is a report which highlights the REAL differences.

How do you export used or unused symbols? Must be staring me in the face but I can only see “load symbols”.

The easiest way to cull the unused icon symbols on a map is to import the map onto a BLANK map which has the SAME colour table. Only the icon symbols used in the map will be imported.

The symbol table again. And recalling that the IOF has started calling for submissions on a revision of the ISOM.

Selwyn has pointed out that (in addition to symbol renumbering between the 1990 and 2000 specifications) the symbol numbering in the sprint specifications is DIFFERENT AGAIN. There, the green circle is 418, the dot is 419 and the cross is 420.

This is not a problem if you start a fresh map with a fresh symbol table. But often we don't, I have my special symbols designed to be hidden, and therefore a new map will take the symbols from a previous one. Further I would think that at least some sprint maps start life as a regular map converted over to the sprint speci.

Calling here for opinions on what should be done about it. We could for example ask the IOF mapping committee not to arbitrarily change symbol numbering. Though I can't think of a good reason why they needed to renumber all the black symbols after 510 last time. (511-514 were shuffled, 515 disappeared, and everything after that came down by 1.) On the other hand there might be a good reason why the numbering might HAVE to be changed, and we might lobby OCAD for a technical solution which magically sorts out this stuff “behind the scenes”.

Regarding the symbol numbering differences: I wouldn't get too hung up about it as it only affects a few symbols and we know which ones they are. We are still going to use a green circle for a tree regardless of whatever number it has. I don't choose my symbols from the icon range by number, but by what they do (as illustrated by the picture on the icon).

The problem with symbol and symbol numbers in Ocad/IOF I think can be answered using accepted normal database standards.

In my work, I really cringe when someone reuses the same key for something else - this is an absolute no-no for the database world. Every object should have a unique key which does not change over time.

The IOF should come up with a numbering system which does not reuse a key for a symbol at any time in the future. This could be a simple number or unique letters. Other attributes like version, type, definition, colour, screens etc can all be related to the unique symbol. A symbol with a slightly different attribute (eg one version has line width 0.25 the other has 0.35) would require a different key.

Instead of the current funny numbering system in OCAD, the new unique numbers could be used meaning that importing symbols from other maps in the future would not be a problem. This could be done right now in OCAD but I think it will take a while for the IOF to assign unique keys if they ever get round to it.

OCAD 10 update 10.3.1 has just been released. A couple of things (there are others)which affect the the Standard and Pro versions include <snip>

ADD Map Information: Report button for symbols, colors, fonts etc. added to map info dialog

That report button might help with my nemesis - symbol table maintenance. Which symbols are used by each colour, how many objects etc. How many rocky objects on Earnscleugh Linley?

We could have done with that feature years ago Michael

<snip>

Question about overprinting: My understanding is that the NZ rules do in fact call for overprinting to be used, but this rule seems to be blatantly ignored because OCAD. So is this correct or am I missing something, like some important Technical Committee ruling?

15.1 Maps, course markings and additional overprinting shall be drawn and printed according to the IOF International Specification for Orienteering Maps. Deviations shall be approved by the NZOF Technical Committee.

Additionally, the pdf that Bryan linked to on the previous page of this discussion implies that the overprinting effect can be achieved with OCAD. It is unclear what version this applies to. Can anyone comment on that. Thanks.

I think we have been held back not by OCAD but our understanding, or lack of. OCAD has had a switch for “overprint effect” in its colour table since at least version 8. Trouble is, you can't see the effect on your screen or home printer. I think it puts some sort of coding into the EPS or PDF when you export. Then the printshop has to do something in their print management software to recognise it. Go back to that reference by Ken Dowling http://www.orienteering.asn.au/gfolder/mapping/Achieving-Overprint-in-Digital-Print-Maps.pdf

Since I couldn't see the effect I didn't use it, I've got heaps of files without the appropriate colours ticked for overprint, because they came from long ago, but a default new file will have the right colours set up for overprint. So, without believing in the overprint effect I have resorted to other mechanisms at least for purple: having a second purple below other colours (not very effective IMHO) or breaking circles and lines. However the overprint effect potentially helps with other colours as well, eg contours on green.

But maybe you all know this, and I'm just catching up. Ken, you read this forum, be good to have your thoughts.

Anyone can see 'overprint effect' once they have set up their PDF Abode reader.

Open up a PDF, then select 'Edit' (top next to 'file') > Preferences > Page display, then look for 'Use Overprint Preview“ > select 'always' > 'OK'

Ahaaaaaaah! Thanks heaps Jim!

It used to be that WYSIWYG was an advanced feature of software. Now WYSIWYG is expected, so much so that I haven't heard the term in years.

Well experimenting with “the overprint effect” brings back “what you see is NOT NECESSARILY what you get” and it might be a mixed blessing. To summarise, when you tick the “overprint” box for a colour then it becomes darker when it is drawn over another colour. Something that we might want to do with purple. But you don't see the effect on the screen. You only see it in the pdf when you adjust your preferences. I think you only see it on the paper if you print from Adobe Reader. At a commercial printer, the operator has to do something to recognise overprint.

Now the crunch point (correct me if I'm wrong). Many maps are drawn with colours on top of other colours. Either little overlaps to speed up drawing, or in some cases a dirty great big overlap. Switching on overprint for the colours recommended in the spec (purple black brown blue green) may cause unwanted darkness variations. Streams on yellow will become green. So will a pond unless you cut a hole in the yellow.

We may have been saved from problems only by (a) old files including files that borrow their symbols from old files, which don't have overprint ticked (b) our commercial printers don't usually have overprint switched on. But if you started a new file in OCAD you could get darker contours in green (good) and green streams in yellow (bad). Strangely, a fresh OCAD file (from version 11) has control circles in a no-overprint purple.

Add to my understanding, all. Come in, Jymbo and Ken.

Overprinting - Michael that's a good point. I am thinking though that the yellow colours default is not ticked for overprint. So surely/maybe that means that a blue will not overprint on yellow. However the blue is ticked so not completely confident that this is the case. Need someone to try it!

Selwyn has confirmed that there's a printing pitfall which may one day hit you when you pick up your maps (how long before the event???) Blue over yellow which looked fine on the screen in OCAD may turn out green. What follows is a bit tentative, if anyone can show that this is all a bad dream please say so.

It would arise from an OCAD file with the OCAD default colour table, which has certain colours ticked in the “Overprint” column. (I.e. you made it using File..New.. and picked the ISOM 1:10,000 or 1:15,000 symbols) Overprint sounds like a good idea but it is bad for blue and may be “interesting” for other colours too. (It might be good for purple, that's why we are experimenting.)

When you look at your file in OCAD the blue replaces the yellow. When you make a pdf an “overprint” code is put into the pdf. When you inspect the pdf in Adobe Reader the blue replaces the yellow UNLESS you flick a switch in the edit preferences. When you print the pdf on your home printer the blue may turn into green. We haven't sorted out what controls this, there's an overprint switch in the print dialogue under “advanced” but it sometimes works, sometimes not.

Who knows what is going to happen at your print-shop on the Friday before the event? They may use Adobe Reader to send your file to their printer, or they may have fancy printer-management software. Whatever, the result may not be as it seemed to you on your screen. Until we get a better handle on this, it would seem advisable to inspect your colour tables and make sure “overprint” is off for blue. And colours should not be drawn on top of other colours even if they seem to block out the underneath one.

This is how OpenOrienteering does it http://sourceforge.net/p/oorienteering/tickets/193/

And in the software it is as simple as selecting a checkbox.

Thanks Fraser. It seems that OOM calculates the result of one colour on top of another in a different way to OCAD. I didn't try to understand alpha blending and whatnot, I was interested in whether there are any unexpected results. So I repeated the exercise above, a new map with default symbols etc. In OOM with the default view settings I see a blue stream and a blue pond on top of yellow. Making a pdf I got a blue pond but a green stream. (I think this arises from OOM having two blues - one with overprint on and the other with overprint off.) In Adobe Reader the green-ness was less evident on the screen than on the paper, and didn't respect the Adobe settings. There might be pitfalls in OOM too.

Been checking some colour settings this afternoon and reading a few old posts here. So just to answer your question 18 months later Michael, yes there is more than one blue used in OOM and the stream uses “Blue above Brown”. For some reason the “knockout” option is not turned on for this colour in the default colour settings. Once selected it should have the desired effect.

I was looking at the default sprint colours there. I see the default colors are setup differently for the 1:10,000 symbol set. Not sure why that is, but both have the knockout turned off for the colour used by the stream symbol.

I write a report for each map I deliver and I'm including the same thing each time - the “hidden symbols” that I add for internal cartographic purposes. So I've put them on my website as www.mapsport.co.nz/mappershiddensymbols.html