Importing event data

Audience: Event organisers bringing courses, classes and entries into an event.

How to populate classes, courses, controls, and competitors by importing from IOF XML files, OJSON files, Purple Pen, a spreadsheet, or Eventor — so you don't have to enter everything by hand.

Overview

Manager supports these ways to bring data in:

Method	What it gives you	When to use
IOF XML files (.xml)	Courses, controls, classes, competitors, clubs, relay teams, start times	You have export files from your course setter (IOF CourseData — OCAD, Condes, Purple Pen) or entry system (IOF EntryList, ClassList, StartList). Manager reads IOF XML version 3.
OJSON files (.json)	Any of the above, often from one file	You have an event exported from another meshO Manager, or from software that writes Orienteering JSON. See Importing an OJSON file.
Purple Pen file (.ppen)	Courses and controls	Your course setter uses Purple Pen and you have the .ppen file.
CSV entry list (.csv)	Competitors, classes, clubs, start times	Your entries are in a spreadsheet, or a SportSoftware OE-CSV export. See Importing entries from a CSV.
Eventor	Classes, competitors, clubs, relay teams, start times, IOF IDs	Your federation uses Eventor for entries and you've configured the connection in Settings.
Ranking list (.xml, .json, .csv)	Rankings, applied to competitors the event already has	You've been handed a ranking list and want to seed the start draw with it. See Importing rankings.
IOF IDs (.csv, .xml, .json)	IOF IDs, filled in on competitors the event already has	Your entries arrived without IOF IDs. See Importing IOF IDs.
Start blocks (.csv, .json)	Which start block each competitor runs in	You arranged start blocks in a spreadsheet. See Importing start blocks.

These are not mutually exclusive — you can import courses from Purple Pen and competitors from Eventor for the same event, for example.

Manager reads what the file is, not what it's called. A JSON document saved as .txt, or an IOF XML file saved as .json, still imports as what it actually is. (The one exception is telling a Purple Pen file from an IOF XML file, which goes by the .ppen extension.) A file can be up to 50 MB.

Where to import

Open the event dashboard and click Import on the Event data card. The same Import event data dialog opens from the Import action on the Courses, Classes, Competitors, Relay teams and Starts pages too. It has up to three tabs:

• Local files — choose a file from your computer: IOF XML, OJSON, Purple Pen, CSV, or a start-block JSON file.
• Linked event — re-import data from the Eventor event this event is linked to (useful for picking up late entries). Shown only when the event is linked and Eventor is switched on.
• Other event — search for any Eventor event and import from it, with the option to link it for future re-imports. Shown only when Eventor is switched on.

The Local files tab has one row per kind of file, in two groups:

• Set up the event — Courses, Classes, Entries and Start times, in the order you would usually import them. These add and update what the file describes; a class list or an entry list can also remove what it leaves out, but only if you say so (see When a file is missing competitors or classes you already have).
• Fill in competitors already entered — Rankings, IOF IDs and Start blocks. Each row of the file is matched to somebody the event already has, by ID, card or name. Nobody is added or removed.

Each field lists the formats it takes until you choose a file; a long file name is shortened to fit, and hovering over it shows it in full. Choose the file, then click Import on the same row. Where a row has an ⓘ beside its name, it says anything particular to that import — for courses, how to export them from Condes or OCAD.

Row	Takes
Courses	IOF XML, OJSON or Purple Pen
Classes	IOF XML or OJSON
Entries	IOF XML, OJSON or CSV
Start times	IOF XML or OJSON
Rankings	IOF XML, OJSON or CSV
IOF IDs	IOF XML, OJSON or CSV
Start blocks	JSON or CSV

When an import finishes, a summary says what was added, updated and deleted, and lists any warnings. A long list of warnings is shortened on screen; Download warnings saves all of them as a spreadsheet, with where each one was found, so you can work through them.

Importing IOF XML files

Course data (IOF CourseData XML)

Upload a file containing course and control definitions — the output of your course-setting software (e.g. OCAD, Condes, Purple Pen).

What gets created:

• Controls — one for each control referenced by a course. Normal controls keep their punch code; Start, Finish and Check controls are imported as named map positions (e.g. "Start 1") with no code of their own — radio routing for those types comes from the event's start/finish/check unit-code lists.
• Courses — each course with its ordered chain (Start → middle controls → Finish). Each course's Start and Finish are recorded individually, so a multi-Start map imports as two courses anchored at different Start controls. If a course finishes at the very flag it started from — Condes writes this by naming one Start control for both ends — Manager anchors the course on a Finish control instead — one the file itself declares, or one Manager creates when the file declares none — and says so in the import summary. Check the course on the Courses page afterwards: at an event with more than one finish, the one it picked may not be the one you meant. A start and a finish are separate controls here, and a course that mixed them would be one the Courses page then refused to save.
• What each control is worth — for a score course, where the file prices its controls. IOF CourseData states the points on the course control, so one flag appearing on three courses is priced three times; Manager prices the flag itself, once for the whole event. Every course repeating the same price is the ordinary case and passes without comment. If two courses price one control differently, the first is kept and the import summary says which courses disagreed — Manager has nowhere to hold two prices for one flag, and you can settle it on the Controls page. A course file that prices nothing leaves the points exactly as you set them.
• Class course assignments — if the file contains ClassCourseAssignment entries (most course setters export them, e.g. Purple Pen and OCAD), each named class gets its course pool set to the named course(s) — no manual assigning needed, even when the course names don't match the class names. The file is authoritative for the classes it names (their pools are replaced); classes it doesn't name are untouched. An assignment is skipped — and reported in the import summary — when the class name doesn't match any class in the event or the course name isn't recognised. Classes are matched by name, and the assignments are remembered on the courses, so they apply whichever you import first — classes before the course file, or the class list afterwards.
• Per-competitor course locks — if the file contains PersonCourseAssignment or (for relays) TeamMemberCourseAssignment entries, each one locks the named competitor to the named course (see Locking a competitor to a course). Competitors are matched by their Eventor/IOF person ID, then by bib number. An assignment is skipped — and reported in the import summary — when the competitor can't be matched, the course name isn't recognised, or the course isn't in that competitor's class course pool. So import competitors (and, for relays, their bibs via the start list) before the course file if you want these locks applied.

After a course import, the Assign Courses to Classes dialog opens automatically — but only if at least one class is still without a course. If the file's class course assignments covered every class, there's nothing left to do and the dialog stays closed.

Tip: If a control code in the file already exists in the event, it's matched and updated rather than duplicated.

From Condes or OCAD

If the courses were created in Condes or OCAD, then use the standard IOF CourseData XML.

Condes: open your event, then File → Export → Export course data as XML…. Choose IOF Version 3.0 and UTF-8 encoding (both recommended), and export. Upload the resulting .xml here.

OCAD: use Course Setting → Export → Course Data (XML)… and choose the IOF XML v3 format. Upload the resulting .xml here.

Note on coordinates: Condes and OCAD write control positions as millimetres on the printed map, not as real-world latitude/longitude. That's expected — Manager uses the map-relative positions and leg lengths from the file. (For multi-map events, Condes exports controls for one chosen canvas/map at a time, so export from the map whose control positions you want.)

Class list (IOF ClassList XML)

Upload a file defining classes.

What gets created:

• Classes — one for each class defined in the file.

Entry list (IOF EntryList XML)

Upload a file of competitor entries — typically exported from your entry system.

What gets created:

• Competitors — one for each entry, with name, card number, and class assignment.
• Clubs — any clubs referenced by competitors that don't already exist.
• Classes — any classes referenced by competitors that don't already exist.
• Relay teams — for a relay, each team entry with its leg runners.

Rankings in an entry list

Most entry lists carry no ranking at all — there is no ranking field in the IOF XML standard. The nearest thing it has is a <Score>, and what a score means is whatever its type says: World Ranking points, a series total, anything.

So Manager reads a score as a ranking only when its type says it is a rank (Rank or Ranking), and leaves every other kind of score alone. That is not caution for its own sake: World Ranking points run the other way — bigger is better — so a points value read as a place would seed your whole field backwards and nothing on screen would say so.

You aren't left guessing, though. If the file carried scores Manager wouldn't read, the import summary says so once per kind, naming the type and how many entries had one — so a file that did carry something doesn't just appear to have lost it. Scores with no type at all are counted the same way, in a note of their own, since there is no name to give them. And a value labelled as a rank but not actually a place (a decimal, a negative, a zero) is reported as a warning; that entry keeps whatever ranking it already had.

An OJSON entry list or start list carries rankings properly, with no labelling to get right — Manager writes them into the files it exports, too, in both formats. See Exporting the entry list.

If what you have is a ranking list rather than an entry list — a spreadsheet, or a federation's published file — import it separately: see Importing rankings.

Start list (IOF StartList XML)

Upload a file of allocated start times — typically exported from an entry system or start-list draw tool. An OJSON file works too, but only a start list document: a result list's start times are when people actually started, and an entry list has none, so both are turned away.

What it does:

• Matches competitors by person ID, then card, then name, and sets their allocated start times.
• Captures each competitor's bib number from the file, so a later course-data import can match per-competitor course assignments by bib (important for relays).
• Skips competitors who have already punched (so a late re-import can't overwrite a result).
• Does not create competitors on its own: runners the file names who aren't entered are listed in a Competitors not entered box, and only the ones you tick are added (Will be added counts them). A few can't be ticked, and say why: a name two competitors already share, a relay leg runner (who is entered with their team — import the entry list or build the team first), or somebody the file lists twice.

Re-importing

You can re-import the same file (or an updated version) at any point while setting up. Manager matches existing items by their identifiers — the control code for a control, the course's ID in the file (or its name when the file gives none) for a course, the name for a class, and the person ID, card or name for a competitor — and updates them rather than creating duplicates.

A re-import only changes what the file actually says. This matters more than it sounds, because by the time you re-import — one late entry, a corrected class — the event has moved on, and everything the day has added to a competitor lives in the fields the file has never heard of. An IOF entry list carries no bib number and no start time at all, so a file that mentions neither leaves both exactly as they are:

• bib numbers — from a bib allocation, or typed in;
• start times — from the start list, the draw, or a chasing start;
• card numbers — including the hire card handed over at the desk;
• class and club, where the file names neither;
• and the things only the desk ever knows: hired items, notes, start-time requests, custom fields, rankings.

The same holds for classes: an IOF class list states a name, a short name and an order, so a re-import leaves the class's courses, its mass start and restart, and its score settings exactly as you set them.

And for controls: a course file describes where the controls are and which course visits them, and nothing else about them. So re-importing a corrected course file — the ordinary thing to do when a control moves — leaves everything you set on the Controls page alone: the clock offset, the faulty flag, the replacement code, the radio name, and the score points. A file that does state something still wins, and a score course's file does state the points.

The same goes for what you set on a course that an IOF XML or Purple Pen file has no way to say: whether its first control is its start and its last control its finish, and its loops (a star relay or butterfly course). A re-import keeps them — unless the corrected course no longer comes back to the same control between loops, in which case the loops no longer fit and are dropped. See Starting or finishing at a numbered control and Courses with loops.

The exception is an OJSON file, which is an export of a whole event rather than a set of courses, and does describe all of those. Importing one applies what it says, including clearing a setting the document does not carry — so a control repaired between two events does not arrive faulty in the second. A control the document never mentions at all (one that appears only as a code on a course) is left alone, like any other course file's.

A value the file does carry still wins, every time: a re-import is how you fix a card number or move somebody between classes. The rule is only that silence means "no opinion", never "empty it".

When a file is missing competitors or classes you already have

Only you know whether an entry list is the complete list of everyone entered, or a partial one to add on top of what's already in the event — runners you added by hand, imported from a CSV, or who turned up and entered on the day. So when a file omits competitors (or classes) the event already has, Manager stops and asks. Nothing is written until you answer.

You get a list of exactly who (or what) is missing from the file — competitors that already have downloaded race data are flagged — and one decision to make:

• Import on its own treats the file as a partial list. Everything in it is added or updated, and anyone missing from it is left exactly as they are. Nothing is deleted.
• Turn on Also remove these competitors (or classes) first, and the file is treated as the complete list: anyone missing from it is removed along with any results they have.
• Cancel — nothing at all happens; the event is untouched.

The toggle is off until you turn it on, so Import on its own never takes anybody away. An import that only adds and updates never asks — it just runs.

Course files never delete courses — courses absent from the file are always left in place. To start the courses again from the file, use Delete all courses… first — see Deleting them all at once.

When a file holds more than one race

A multi-day carnival's files are usually one file covering every day: one entry list with everybody's entries, one start list with everybody's start times for each day, one course file with each day's courses. A meshO event is one day, so Manager stops and asks which race this event is. Nothing is written until you answer.

You get the races the file names — its own names and dates where it gives them, otherwise just "Race 1", "Race 2". Choose one and select Import; only that race's data is imported. Nothing is picked for you, and Cancel leaves the event untouched.

This applies to the entry list, the start list and the course file, and only to IOF XML files — an OJSON export and a Purple Pen course file describe one race each, so there is nothing to ask. It doesn't apply to a class list (the format has no way to say which race a class list is for) or to a rankings import (a ranking belongs to the runner, not to a day, and is the same whichever day you import).

Manager only asks when the file can actually be split. A file that names three days in its header but tags none of its entries or start times with one is a single day's file with a carnival's header, so it imports without a question rather than asking one whose answer could change nothing.

Three things worth knowing about how the IOF format writes this:

• An entry with no race on it is entered in every race, which is what the standard says it means. So a runner who is down for all three days arrives whichever day you pick, and only the ones tagged for a particular day are held back. The same goes for a start time.
• A runner with no start time on the day you pick isn't imported at all — they aren't in that day's field, so they're not offered as a runner your event is missing either.
• The file may not name its races at all and only tag its contents with numbers, or — in a course file — simply hold one block of courses per day in order. Manager still spots the several races and asks, listing them by number.

Import each day into its own event, choosing the matching race each time. If the days belong together as a carnival, see Multi-stage events.

When a file brings the event's own settings

An OJSON file describes the event it came from, including the rules the times and scores in it were worked out from:

• its mass start, its restart and whether a punched start overrides the allocated start — which decide how every competitor's start time is worked out;
• its course format, its default points per control, its time limit and its penalty per minute — which decide what a score course is worth and what a late finish costs.

Manager never takes any of them quietly. If the file's differ from this event's, importing entries or start times stops and shows you both sides — this event's setting and the file's, one row per setting that would actually change — before anything is written:

• Apply event settings — this event takes the file's settings, and then the import runs. It is all of them or none: you cannot take the file's score rules while keeping your own mass start.
• Import without them — the entries and their times still arrive, and the event keeps its own settings. A time the file's settings produced is then stored on each competitor individually, so if you move this event's mass start afterwards those runners stay behind at the old time; and a score the file's rules produced is worked out again against this event's numbers, so the same card can be worth something different here.
• Cancel — nothing at all happens; the event is untouched.

A file stating the settings this event already uses never asks, so re-importing costs you nothing.

When a file brings courses scored in any order

An OJSON file says how each course is scored — in the printed order, as a scatter course (a set number of controls, any order), or as a score course. Importing one brings that with it, along with how many controls a scatter course requires, so the courses score the same way in this event as they did in the event the file came from.

A Purple Pen file says it too. A course set as a score course (kind="score") used to be skipped outright, so a Purple Pen score event imported as its controls and no courses at all; it now imports as a score course, with each control's points taken from the course setter's own values. And because the file states the format, re-importing it puts the course back to a score course rather than leaving whatever was set in Manager.

An IOF XML course file can say it too, but only in one shape and only if the software that wrote it bothered. There is no "this is a score course" element in the standard; what there is, is a flag on each control saying it may be visited in any order. A course whose every control carries that flag and carries points is a score course and nothing else, so Manager imports it as one. Condes writes both. Purple Pen's IOF export writes neither.

Manager will not guess beyond that, and the import summary tells you when it has not:

• Any order, but no points reads like a scatter course, and two things are missing. The standard has nowhere to say how many of the controls a runner has to find — which is the whole definition of a scatter course — and Manager's "all of them" means every control in the event, not the ones this course lists, which at an event with line courses beside it would demand those too. So the course keeps the event's format and you set the right one on the Courses page.
• Only some controls in any order — a free-order loop inside an ordered course — is not a shape Manager has. Taking the any-order half would throw away the order from the rest.

Either way the points still come in, so setting the format afterwards is all that is left to do.

If your score course came from Purple Pen, import the .ppen, not the IOF XML. Purple Pen's IOF export of a score course writes the controls and leaves the course out of the file entirely — there is nothing for Manager to read, so no course and no points arrive. This is a limitation of the export, not of the import; the .ppen carries everything.

One thing to expect on the Courses page afterwards: a scatter or score course arrives with no control sequence. That is not a failed import. Those courses are run against every control in the event, so a sequence is not what they are scored on and the file does not carry one — listing the controls in play as though they were an order to visit them in would be inventing one. If you later switch such a course back to a line course, import the course file (IOF XML or Purple Pen) to give it its printed sequence.

Every control in the event is where such a course starts. If two of them share one set of flags — a short course and a long one — open the course, go to its Controls tab and take the ones it does not use off. That is the course's own answer and nothing else at the event changes: the control stays in the forest and on every other course. An OJSON file carries those removals; an IOF XML course file has nowhere to say them.

Importing an OJSON file

OJSON (Orienteering JSON) is the format Manager exports a whole event in, and other software can write it too. One OJSON document can describe the classes, courses, controls, competitors, relay teams and start times together, so the same file can go into the Courses, Classes, Entries and Start times rows — in whatever order suits, exactly as with a set of IOF XML files. Each row takes what it is about from the file:

• Courses — the controls and courses, including how each course is scored and what each control is worth. Unlike an IOF XML file, an OJSON file also says everything about a control and a course that you'd otherwise set by hand, so importing one applies all of it — see Re-importing.
• Classes — the classes.
• Entries — classes, clubs, competitors and relay teams, with their rankings and IOF IDs.
• Start times — only from a start list document (see Start list).

Two questions are particular to OJSON, and each is asked before anything is written:

• Event settings in this file — if the file's start and scoring rules differ from this event's. See When a file brings the event's own settings.
• Custom fields in this file — if the file records competitor custom fields this computer has no definition for. Include custom fields adds them to Settings → Custom fields, so their values are shown; Import without them still imports the values and keeps them, but nothing displays them until a field of the same name is defined. Cancel imports nothing.

For the format itself, see OJSON.

Importing entries from a CSV

The Entries row also takes a spreadsheet saved as CSV: a SportSoftware OE-CSV export, or any delimited file with one entry per row. Choose the file and click Import, and the Import entries from CSV dialog opens:

• At the top it says whether Manager recognised the file as OE-CSV or is reading it as a Delimited file, and how many rows it holds.
• Delimiter — semicolon, comma or tab. Manager detects it; change it if the preview looks wrong.
• First row is a header — on when Manager recognised the first row as column headings.
• Match each field to a column in your file — a drop-down per field: Full name, or Given name and Family name; Competitor ID; IOF ID; Class (short) and Class (full name); Club ID and Club name; Card / chip no.; Bib / start no.; Start time; Birth year and Sex; and one for each of your own custom fields. Manager fills in the ones it recognised from the headings; choose (not mapped) for a column you don't want used.
• Preview — the first rows as Manager reads them with that mapping.

If the entries are in an .xlsx workbook, use Save as / Export in your spreadsheet program to write a .csv first.

Import stays disabled until a name is mapped and at least a class or a card column. A CSV exported from Manager's own competitor list or start list maps itself, so a list you export, edit in a spreadsheet and import again needs no mapping. See Exporting the entry list.

What happens:

• Each row is matched to a competitor already in the event by Competitor ID, then card, then name. A match is updated; anyone else is added.
• A CSV import never removes anybody. Competitors already in the event who aren't in the file are left as they are, so a partial spreadsheet can be merged in safely. To replace the whole list with the file's, empty it first with Delete all competitors.
• A class or club the file names that the event doesn't have is created.
• A start time in the file becomes that competitor's own allocated start — unless it is just the class's or event's mass start, which it is left to.
• A filled custom-field cell replaces what the competitor holds; a blank one leaves it alone.
• A row Manager can't use — a card with no name, say — is skipped and listed in the summary; the rest still import.

Importing rankings

A ranking is a competitor's place on an external ranking list — 1 being the best-ranked athlete. Ranking lists are published separately from entries and republished every few weeks, so they are imported separately: Rankings is its own row on the Local files tab, in Fill in competitors already entered.

This import only ever fills in the Ranking field of competitors the event already has. It creates nobody, deletes nobody, and changes nothing else. Import your entries first.

Which files Manager accepts

Three kinds, and the only thing that differs between them is how much you have to say about the file:

File	What Manager reads	What you have to do
IOF XML (.xml)	A competitor list, or an entry list, in which an athlete carries a score labelled as a rank	Nothing — choose the file and import it
OJSON (.json)	Any OJSON document that lists entries: an entry list, a start list, or a result list	Nothing — choose the file and import it
CSV (.csv)	A spreadsheet of places, in whatever columns your list happens to use	Say which column is which, in the dialog that opens

An IOF XML or OJSON file says what each number in it is, so Manager reads it as it stands: choose the file, click Import, and it imports in one step. A spreadsheet says nothing about itself — one list's third column is a place, another's is a points total — so a CSV always goes through the column-mapping dialog first. That is the whole of the difference; everything after the file is read is the same for all three.

Note: If your ranking list is an .xlsx (or anything else a spreadsheet program opens), use Save as / Export to write a .csv first.

Which IOF XML files carry a ranking

IOF XML has no ranking field. The nearest thing it has is a <Score>, and what a score means is whatever its type says — so Manager reads a score as a ranking only where the file lists people and the score is labelled as a rank (Rank or Ranking). Two documents qualify:

• A competitor list — a list of athletes and the scores they hold. This is the shape a federation ranking list is usually published in.
• An entry list — the entries for an event. A relay's leg runners count too: a runner on leg 2 carries a ranking exactly as an individual entrant does.

A results file does not work, and Manager tells you rather than importing something wrong. The scores in a results file are what someone scored on the day — World Ranking points, most often — and points run the opposite way to a place: bigger is better. Read as places, 1250 points would become "1250th", and your whole field would be seeded backwards with nothing on screen to say so. So Manager reads the file, declines it, and reports:

No rankings were read: the scores in a results file are points rather than places on a ranking list. Import a competitor list or an entry list instead.

Any other IOF document — a start list, a class list, a course file — is turned away outright, with "Check that the file is a ranking list": there is nowhere in those for a ranking to be.

The same care applies inside a file that does work. A score of any other type — or with no type at all — is left alone, and the import summary says so once per kind, naming the type and how many entries carried one. A file that did carry something never just appears to have lost it.

What an OJSON file needs

Nothing in particular. A ranking travels on the entry itself in OJSON, so any document that lists entries is already a ranking list: an entry list, a start list, or a result list all work, and there is no separate ranking-list file to produce. Last season's result list, exported from Manager, seeds this season's draw exactly as it stands.

Importing rankings from a CSV

A spreadsheet is the way a ranking list most often arrives, and the only one of the three that needs anything from you before it can be read.

What the file needs

Two things, in whatever columns and whatever order your list happens to use:

1. The ranking — a whole number. 1 is best.
2. Something that says whose ranking it is — any one of an IOF ID, a competitor ID (the organiser's own entry number), a card number, or a name. A name can be one full-name column or separate given-name and family-name columns.

Extra columns — club, class, region, points, anything — are ignored. You don't need to tidy the file up first.

Mapping the columns

Choose the file and click Import, and the Import rankings from CSV dialog opens. Manager reads the file, guesses how it's put together, and shows you what it found so you can correct it:

• Delimiter — semicolon, comma or tab. Manager detects it; change it here if the preview looks wrong (all of one row crammed into a single column is the usual symptom).
• First row is a header — on when Manager recognised the first row as column headings. If your file has no headings, switch it off and every row is treated as data.
• A drop-down per field — Ranking (place), IOF ID, Competitor ID, Card / chip no., Full name, Given name, Family name. Manager pre-fills the ones it recognised from the headings; set any it missed, or (not mapped) for a column you don't want used. With no headings to go on it guesses that the first column is the place and the second is the name, and tells you it guessed.
• Preview — the first few rows of the file as Manager reads them, so you can check the mapping against real data before committing.

The Import button stays disabled until you've mapped the ranking column and at least one way of identifying the athlete; the dialog says so while that's outstanding.

How rows are matched to competitors

Manager works down the strongest identifier it has, per row: IOF ID, then competitor ID, then card number, then name. Names are compared with accents and capitalisation ignored, so asa lindstrom finds Åsa Lindström.

Two consequences worth knowing:

• One row seeds every entry that person holds. Someone entered in two classes is two competitors in the event, and both get the ranking — ranking only one of them would leave the other unseeded in a draw you believed was seeded.
• Two rows about the same person both apply, in file order, so the last one wins.

What happens to rows that don't land

Nothing is written for them, the rest of the file still imports, and you're told which rows and why. After the import, the summary reports Rankings: n updated, and lists any rows that reached nobody — the first ten, with the name and ranking the file gave and one of three reasons:

• not entered in this event — nobody in the event matched. Expect a lot of these if you imported a national list: most of the country isn't at your event. But every row failing usually means the file identifies athletes some other way than your entries do — a mis-mapped identity column, most often — and Manager says so separately when nothing at all matched.
• more than one competitor has that name — the row's only usable identifier was a name two entrants share, and nothing in it says which of them it means. Manager won't guess. Give that competitor an IOF ID or competitor ID that matches the file, or set their ranking by hand.
• its card or ID belongs to more than one competitor — the row's card number, competitor ID or IOF ID is held by two differently named people (a shared hire card, most often, or a reused organiser number), and the row has no name to settle it, or a name that is neither of theirs. Manager won't guess here either. Add the athlete's name to the file (or correct it, if it names neither of them), or set their ranking by hand.

Each is named by where it sits in the file: the line number in a CSV, or the athlete's position in the document for an IOF XML or OJSON file — so you can go and look at it either way.

Individual rows can also be skipped:

• A row that states a ranking but nothing to say whose it is — no ID, no card, no name — is skipped, in all three formats.
• A negative ranking is never stored, in any format. In a CSV the row is refused and the reason given; in an IOF XML or OJSON file it's counted in a notice of its own. Either way that competitor keeps the ranking they already had.
• In an IOF XML file, a score labelled as a rank but not actually a place — a decimal, or a zero — is treated the same way: reported, and the entry left as it was. (A zero does mean something in the other two formats — see Clearing a ranking.)
• In a CSV, a ranking that isn't a number skips that row, and a blank ranking cell is passed over in silence. A published list often names everyone and leaves the unranked blank, and an import never clears a ranking a file says nothing about.

Clearing a ranking

Setting a ranking works the same in all three formats. Clearing one does not, and it's the one asymmetry worth knowing about:

• A CSV or an OJSON file can clear a ranking, by stating 0. Zero is how Manager writes "not ranked", so a 0 in the ranking column is read as an instruction: that competitor's stored place is removed.
• An IOF XML file cannot. There is no way to write "not ranked" in IOF XML — an unranked athlete simply has no <Score>, which says nothing rather than saying zero, and a file that says nothing never overwrites what you already have. So an IOF XML import only ever sets a ranking or leaves it alone.

If you need to clear rankings from an IOF XML list, clear them on the competitors themselves (the Ranking field on the Details tab, emptied) or import a CSV with 0 in the ranking column.

That aside, the rule across every import in Manager is the same: a file that says nothing about a ranking leaves the stored one alone. Re-importing an entry list or a start list can't quietly wipe the rankings you've already set.

Re-importing

Run it again whenever a new list is published. A competitor who already holds the ranking the file would give them is left untouched, so re-importing the same file changes nothing at all — and the summary shows no Rankings line, because nothing was updated.

Importing IOF IDs

An athlete's IOF ID is their number at the International Orienteering Federation — the one key that means the same person in every system, and the one the IOF ranking is matched on. Entries often arrive without it: the entry list you download from the Eventor website carries Eventor's own person IDs but no IOF IDs, even for athletes who have one. IOF IDs is its own row on the Local files tab, below Rankings, for filling them in afterwards.

Like the rankings import, it only ever fills in the IOF ID of competitors the event already has. It creates nobody, deletes nobody, and changes nothing else.

Which files Manager accepts

File	What Manager reads	What you have to do
CSV (.csv)	An IOF ID column, plus a competitor ID, card or name column. The IOF world ranking file works as downloaded from ranking.orienteering.org — Manager recognises its IOF ID, First Name and Last Name columns.	Check the columns in the dialog that opens
IOF XML (.xml)	Any competitor list, entry list, start list or result list in which a person carries an <Id type="IOF">	Nothing — choose the file and import it
OJSON (.json)	Any document that lists entries	Nothing — choose the file and import it

Eventor's own entry list (what Eventor's API returns, as opposed to the IOF XML file its website offers) is read too. A file that names people but carries no IOF IDs at all — the Eventor website's entry list, most often — is reported as exactly that, rather than as a file that matched nobody. An IOF ID the file states that isn't a whole number is reported by row. A file that lists nobody at all — a class list, say — is turned away with a message saying so.

In the CSV dialog, the IOF ID column can't also be the column that says whose ID it is: map a competitor ID, card or name column as well. A CSV without a header row is read as the world ranking's own order — IOF ID, first name, last name — until you change it.

Importing IOF IDs from Eventor

If the event is linked to its Eventor event, Eventor itself is usually the better source: tick IOF IDs under Data to import on the Linked event tab — on its own, with Entries and Classes unticked — and click Re-import. Manager reads each entrant's IOF ID from Eventor and gives it to the competitor whose Eventor ID matches, without importing or changing anything else. That works even when the entries themselves came from a file.

Leave Entries unticked when all you want is the IOF IDs. With Entries ticked, the entries import runs first and — as it always has — takes Eventor's IOF ID over the one a competitor holds, so the rule below doesn't protect it.

An event created from a file isn't linked yet. It becomes linked when you import into it from the Other event tab with Link to event ticked — tick IOF IDs there too, and untick Entries and Classes, to do both in one go — or when you upload its results or start list to Eventor. The Other event tab lists Eventor events from today onwards unless Event history in Settings → Eventor reaches further back, so for an event that has already run and was never linked, either reach back there or import a file instead: the world ranking CSV covers the athletes it ranks.

How rows are matched to competitors

Much as rankings are: competitor ID (for an event whose entries came from Eventor, that is the Eventor person ID), then card number, then name, with accents and capitalisation ignored. One row reaches every entry that person holds. Because an IOF ID is never replaced once it's set, the match is stricter than the rankings one:

• A competitor whose competitor ID differs from the row's is somebody else, even if their card or name matches — the usual case is an Eventor entrant you haven't imported yet.
• A row matched on its card has to agree on the name, when it has one: cards are hired and shared.
• A name, card or competitor ID that two people share is never guessed at: neither gets the ID, and the summary names the row.
• If the row's IOF ID already belongs to somebody else in this event, it isn't moved: the summary names both people, because one of them is wrong.

An IOF ID you already have is never replaced

This is where IOF IDs differ from rankings. A ranking goes stale and the newest list is right; an athlete's IOF ID doesn't change. So when a file offers a competitor a different IOF ID from the one they already hold — on any of their entries — Manager keeps theirs and says so in the summary: "… already has IOF ID 44831, so 34775 was not written over it." That is usually an athlete with two profiles at the IOF, or a row that matched the wrong person — only you can tell which. If the file is right, change the ID on the competitor by hand.

For the same reason, one IOF ID goes to one person, and one person gets one IOF ID. If a file offers the same ID to two different people, or two different IDs to one person — the world ranking lists two athletes of the same name, say — neither is written, and the summary names them. The first row is no more likely to be right than the second.

What the summary says

IOF IDs set: n counts the competitor entries given an ID. IOF IDs already set: n counts the athletes who already had the ID the file offered. Rows that matched nobody in this event: n counts the rows that matched no competitor at all; a row passed over for a reason — a conflict, a shared name — is named in the summary instead. Expect the unmatched number to be large for the world ranking — it lists several thousand athletes, and a small fraction of them are at any one event. If nothing matched, Manager says so separately: that usually means the file identifies athletes differently from your entries. Importing from Eventor shows the same three counts in its summary.

IDs matched on a competitor ID are also added to the Competitor Registry, so they show in Settings → Competitors and a later event imported from Eventor starts with them. IDs matched only on a card or a name stay in this event: a name is good enough for one event's field, not for every event after it. The registry is only ever filled in: if it already records a different IOF ID for a competitor, it keeps that one and the summary says so. An entry list imported from a file doesn't read IOF IDs from the registry, so an event built from the Eventor website's file needs this import again. An event set to ignore the registry keeps its IDs to itself.

Running the import again changes nothing: a competitor who already holds the ID is left alone.

Importing start blocks

Start blocks cut a class's start window into chunks, so you can say which chunk a competitor runs in. They import and export as a file of their own — useful for working on a long list in a spreadsheet, or carrying last year's arrangement into this year's event.

Like a rankings import, this one is run against an event that already has its competitors. It creates nobody and deletes nobody, and it touches two things: each matched competitor's block, and how many blocks each class named in the file is cut into.

Getting a file to start from

Export one first, and fill it in — the export lists everybody entered in a class that has blocks switched on, assigned or not, with the headers this import already recognises.

• Competitors → Actions → Start blocks (CSV) or Start blocks (JSON), for the whole event.
• The Export button on the class's own Assign blocks… dialog, for that one class.

A class with Start blocks switched off isn't in the file at all, so switch blocks on for the classes you want before exporting.

Importing

Two ways in, and they differ only in what they're allowed to touch:

• Import data → Local files → Start blocks, which imports every class the file names.
• The Import… button on a class's Assign blocks… dialog, which only ever touches that class — so one class's spreadsheet can't rearrange another's, whatever else is in the file.

A start-block JSON file names its own fields and imports in one step. A CSV asks you which column is which first, exactly as a rankings CSV does; the mapping is filled in for you when the headers are recognisable.

What the columns mean

Column	What it does
Start block	The competitor's own block, counting from 1. Empty says nothing and leaves their current block alone; 0 takes them out of their block.
Start blocks	How many blocks the row's class is cut into. Repeated on every row of that class. Importing it sets the class up.
Class	Which of a competitor's entries the row is about.
IOF ID, Competitor ID, Card, First name / Surname	Who the row is about — at least one is needed.

How rows are matched to competitors

By IOF ID, then the organiser's competitor ID, then card number, then a name only one competitor in the event has — the same ladder a rankings import uses.

Where the two differ is the class. A ranking belongs to a person, so one row sets it on every entry they hold. A start block belongs to an entry in a class: block 3 divides Junior Boys' start window and means nothing at all in M21. So a row that names a class reaches only that competitor's entry in that class — and if they aren't in it, the row is reported rather than applied somewhere else.

A row that names no class at all falls back to the ranking behaviour and reaches every entry that person holds. Files Manager exports always name the class.

Why the number of blocks travels with the file

A file of block numbers imported into an event whose classes have no blocks would import perfectly cleanly and change nothing you could see — every number would be outside the range of a class with no blocks, and the draw would ignore them all.

So the file carries each class's block count too, and the import applies it. The summary says so separately, as Start blocks: 2 classes configured, because a file changing your draw settings is worth being told about.

What happens to rows that don't land

They're listed when the import finishes, with the reason:

• not entered in this event — nothing matched. Usually somebody who has withdrawn since the file was written; also what a mis-mapped identity column looks like.
• more than one competitor has that name — the row's only usable key is a name two people share, and nothing tells them apart. Neither is given a block.
• its card or ID belongs to more than one competitor — the row's card number, competitor ID or IOF ID is held by two differently named people (a shared hire card, most often), and the row's name — if it has one — is neither of theirs. Neither is given a block.
• not in that class — the competitor was found, but they've changed class since.
• this event has no such class — the class named isn't one this event has. Check the spelling against your class list.
• two classes have this name — one class's short name is another's full name, so the name in the file fits both. Rename one of them and import again.

Re-importing

Run it again whenever the list changes. A competitor already in the block the file would give them is left untouched, and a class already cut into that many blocks is left untouched, so re-importing the same file changes nothing at all.

Importing from Purple Pen

Purple Pen .ppen files are handled the same way as IOF CourseData XML. Upload the .ppen file via the Import event data dialog → Local files tab → Courses row.

What gets created:

• Controls — extracted from the Purple Pen event definition, including any Start, Finish and Check controls as named map positions.

• Courses — each course with its full chain (Start → middle controls → Finish). Per-course Start and Finish anchors are preserved, so a .ppen with multiple Starts imports cleanly.

• Score courses — a course set to Score in Purple Pen imports as a score course, and the points you gave each control come with it. This is the one course file that states how a course is scored, so it is also the one whose re-import restores that setting. A control's points belong to the control, not to the course, so if two score courses share a control and give it different points, the first is kept and the import summary says so.

• Control positions — where each control sits on the map. Once you have uploaded and calibrated the event map, these let the Radio control placement screen put your controls on it, and a re-import of the .ppen keeps the positions you set there. See The event map and radio placement.

Note: Purple Pen provides courses and controls only. You still need to import (or create) classes, competitors, and start times separately. Where each course is a class of its own, Auto create classes from courses makes the classes in one step.

Importing from Eventor

Eventor integration lets you pull entry data directly from your federation's system without handling files.

Prerequisites

Before you can import from Eventor, switch on Enable Eventor and configure the connection in Settings → Eventor:

• Host name — the URL of your Eventor instance.
• API key — your Eventor API credentials.
• Organisation ID — your club or federation's Eventor organisation ID.

If Eventor is not configured, Manager will tell you when you try to import and point you to Settings.

The Eventor tabs list events from today onwards. To import from an event that has already run, reach back further with Event history in Settings → Eventor.

Creating an event from Eventor

If you don't have an event yet, the fastest path is New event → Import from Eventor… on the Events page — it creates the event and pulls in classes, competitors, clubs, and start times in one step. See Creating an event from Eventor for the full walkthrough.

Importing into an existing event

If you've already created an event and want to pull Eventor data into it:

1. Open the Import event data dialog (see Where to import).
2. Use the Other event tab to find the Eventor event: search by name, or narrow the list with Club/state.
3. Select it, and under Data to import tick what you want: Entries, Classes, Start times and IOF IDs. Two more ticks are offered while the event isn't linked yet:
   • Link to event — link this event to the Eventor event, so you can re-import later with one click and upload the start list and results to it.
   • Event details — take the event's name, date, discipline and location from Eventor.
4. Click Import. The summary lists what was added and updated, and whether the event was linked and its details updated.

Re-importing from Eventor

As entries close and start lists are published, you'll want to pick up the latest data. If the event is linked to an Eventor event:

1. Open the Import event data dialog.
2. Go to the Linked event tab. It says which Eventor event this one is linked to.
3. Under Data to import, tick what to bring in. Entries and Classes are ticked to begin with; tick Start times once the draw is published on Eventor, and IOF IDs to fill those in (see Importing IOF IDs from Eventor).
4. Click Re-import.

Manager fetches the latest data from Eventor, matching it against the competitors already in the event. New entries are added; updated entries are refreshed. If the draw hasn't been published yet, the summary says start times are not yet available.

Re-importing one stage of a carnival. Every stage of a multi-race Eventor event is linked to the same Eventor event, so this tab looks the same on each of them. It names the race the stage came from — Stage 2: Middle — and only that race's entries and start times are imported. If the tab warns that the stage is no longer in the Eventor event, the organiser has changed the race list since you imported: check the stage against Eventor before re-importing, because Manager will otherwise bring in every stage's entries.

Multi-race Eventor events

Some Eventor events contain several races — a 3 Days, a two-race weekend. Importing one of those into a single event captures only the first race, so Manager doesn't: click New event → Import from Eventor… and pick it, and it is created as a carnival. Manager creates the container and imports one meshO event per Eventor race, with the entries split by race and each event attached as a stage. See Multi-stage events.

Note: An IOF XML file can also carry several races. Importing one asks which race this event is (see When a file holds more than one race), but there is no file equivalent of creating the whole carnival in one go: create the multi-stage event and its stages, then import the file into each stage, choosing that stage's race.

What to check after import

After any import, it's worth spending a few minutes verifying the data:

• [ ] Open the Classes page — confirm the right classes exist and each has a course assigned.
• [ ] Open the Courses page — confirm courses have the right controls in the right order.
• [ ] Open the Competitors page — confirm competitors have names, classes, and card numbers. Sort by card number to spot blanks.
• [ ] If start times were imported, check the Competitors page — the Start time column shows the allocated time and its source.
• [ ] For a relay, open the Relay teams page — confirm each team has its runners on the right legs.
• [ ] If rankings were imported, turn on the Ranking column on the Competitors page and sort by it — the people you expect to be seeded should be at the top, and anyone who should have been ranked but isn't will be sitting with the blanks.

Tip: If something looks wrong, you can re-import a corrected file — Manager will update rather than duplicate.

Related

• Creating an event — where the event details live
• Classes and courses — editing what the import created
• Controls and radio controls — marking imported controls as radios
• Competitors, clubs and teams — editing imported competitors, and exporting the entry list back out again
• Start times — understanding how imported start times interact with other sources
• Drawing start times — seeding a draw with the rankings you imported, and the start blocks this import can fill in
• Multi-stage events — importing a multi-race Eventor event as a carnival
• OJSON — the format spelled out, for anyone writing the files rather than choosing them