Parsing OCAD files inside web cartography tools requires reading proprietary binary records directly into browser memory and mapping internal symbol tables to standard vector definitions. In Gratic, we parse vector objects, coordinate offsets, and symbol numbers directly in a browser tab without desktop installations. This allows orienteering surveyors to inspect, edit, and style existing OCAD datasets alongside fresh elevation tiles and national mapping service vector data immediately.
How web cartography tools decode the OCAD vector structure
Web cartography tools decode OCAD files by reading raw binary headers, indexing element offset tables, and streaming polyline coordinates directly into browser memory. This process extracts point coordinates, line vertices, and area perimeters without intermediate server conversions, linking each spatial record directly to its assigned symbol definition within the client-side vector engine.
The OCAD file format uses a structured binary container designed for rapid desktop disk access. The header stores the file version, encryption flags, coordinate system parameters, and byte offsets pointing to the main index blocks. When a file drops into a browser tab, a JavaScript or WebAssembly binary reader allocates an ArrayBuffer to traverse these byte offsets. It verifies the signature bytes, reads the display extents, and extracts the primary index table, which holds file positions for every map object and symbol definition stored in the file.
Each geometry record contains spatial coordinates alongside metadata describing geometry type, angle, and symbol reference. In traditional desktop programs like OCAD and OpenOrienteering Mapper, coordinates are stored as signed 32-bit integers representing units of 0.01 millimetres on the printed sheet or real-world metric coordinates. Browser vector engines parse these integer streams into floating-point vertex arrays. The engine must separate the raw point stream into continuous line strips, hole definitions for composite areas, and control points for cubic Bezier curves.
Translating binary geometry records to browser vectors
Vector geometries in terrain cartography require explicit topological structure. An OCAD area object often contains multiple bounding rings representing open clearings with interior vegetation islands or uncrossable marshes. The parsing engine must read the coordinate flags on each vertex to split outer boundaries from cut-out holes, constructing valid multi-polygon paths for browser canvas or WebGL rendering. If an engine misinterprets vertex control codes, Bezier curvature handles turn into straight segments, distorting contour lines and stream courses.
Once the geometry records populate memory, the parser extracts the symbol table. Each symbol entry contains stroke colours, line weights, dash patterns, and fill styles that correspond to orienteering standards like ISOM 2017-2 or ISSprOM 2019-2. The client parser builds an internal lookup dictionary associating raw symbol indices with vector drawing routines. This structure ensures that when the editor draws a boulder, a track, or an uncrossable marsh, the stroke geometries render with correct cartographic proportions on screen.
OCAD elements that translate directly into browser vector environments
Point symbols, straight polylines, and closed polygon boundaries translate cleanly into web vector renderers when symbol numbers align with standard IOF specifications. Complex elements like dynamic dashed contours, oriented line ticks, and patterned area fills require dedicated rendering routines to replicate the strict dimensional rules defined by international cartography standards.
Basic vector geometry translates into the browser canvas model with mathematical precision. Point objects transfer their map coordinates, rotation angles, and symbol identifiers directly to vector rendering pipelines. Polylines without decorative embellishments convert straightforwardly into vector paths, retaining sharp vertex positioning across map scales. Area symbols with solid fills, including standard shades for runnability screens and water bodies, map directly to canvas fill instructions, provided the colour palette indices match the target sport specification.
Cartographic line embellishments present greater technical challenges during browser import. Standard orienteering symbols like cliff lines, earth banks, and fences require directional tick marks generated at fixed metric intervals along the base curve. If the parser treats these embellishments as static geometry, files expand massively in memory. A specialized editor instead parses the parent line path and reconstructs tick intervals dynamically using standard pen definitions.
| Approach | Parsing Pipeline | Coordinate Fidelity | Symbol Rendering Accuracy | Operational Friction |
|---|---|---|---|---|
| Client-side binary parsing | Direct browser ArrayBuffer traversal | Direct preservation of vector vertices | Rebuilds standard symbols dynamically | Zero installation; opens in a tab |
| Server-side GDAL translation | File upload converted to GeoJSON | High geographic precision | Strips custom cartographic symbol headers | Requires server round-trip and storage |
| Desktop conversion utility | Manual export to DXF or Shapefile | High vertex fidelity | Loses fill patterns and line embellishments | Demands local desktop utility installation |
Handling complex symbol parameters and line embellishments
Area patterns like boulder fields, broken ground stipples, and marsh stripes demand strict adherence to specification layouts. In desktop tools, these patterns are constructed from secondary symbol headers defining cell sizes, offsets, and element angles. When parsing into a browser environment, the vector engine must generate pattern fills matching the original offset geometry rather than approximating the fill with generic web graphics patterns.
Text objects require specific font rendering safeguards during import. OCAD files store text strings with font family names, point sizes, character spacing, and alignment anchor coordinates. If the client machine lacks the specified font, web typography fallback engines can shift the text baseline, placing mountain peak elevations or contour labels over adjacent rock faces. Web vector cartography tools solve this by parsing text objects with precise anchor coordinates and applying standard typographic metrics matching the orienteering standard.
Causes of coordinate shifts and symbol mismatches during web import
Coordinate shifts occur when web import engines misread local grid origin offsets, false eastings, or projection reference systems stored within the file header. Symbol mismatches happen when non-standard local numbers overwrite default ISOM numbering, separating vector paths from their intended line widths, colours, and stroke dash patterns during rendering.
Georeferencing headers determine how vector geometries align with real terrain. Legacy orienteering maps often use local Cartesian grids established from paper surveys rather than national projection systems. An OCAD file stores grid rotation angles, scale factors, and real-world origin offsets in dedicated parameter records. If an import parser defaults to Web Mercator projection without evaluating the file's internal georeferencing block, vectors can land kilometres away from their true ground position or appear rotated relative to true north.
Symbol mismatching typically stems from non-standard club palettes or legacy symbol numbering. Over decades of revisions, the International Orienteering Federation has shifted numbering schemes across ISOM specifications. When a cartographer reassigns symbol 501.0 from a paved road to an event-specific boundary, a standard parser applying generic lookup tables will draw the line with improper widths and dash intervals. The import pipeline must read the embedded symbol definitions within the file rather than assuming generic standard presets.
Aligning imported vectors with base elevation and open data
In Gratic, we pull elevation tile by tile and vector data from national mapping services, giving surveyors instant access to baseline terrain layers. When importing an existing OCAD file into this workflow, the coordinate parser must reproject surveyed vectors into accurate geographic bounds. This reprojection lets you overlay existing course and terrain files directly onto fresh lidar-derived contours or national road vectors within the same browser tab.
Accurate alignment enables sports cartographers to evaluate where older surveys drift from modern lidar baselines. If an existing forest boundary was mapped thirty years ago using compass pacing, bringing the file into an editor that renders both the OCAD vectors and open elevation data reveals terrain discrepancies immediately. Surveyors can adjust distorted contours, redraw overgrown paths, and fix the symbols without leaving the tab, with nothing to install and nothing to license.
Frequently asked questions
Can we export modified maps back into OCAD from the browser?
Yes. Gratic generates files that open in OCAD, maintaining standard vector records, line symbols, and area boundaries so that colleagues using desktop mapping suites can open the exported sheet without data loss.
How does Gratic handle georeferenced scanned maps from legacy projects?
Gratic lets you georeference scanned paper maps directly in the browser tab. You can align scanned rasters against imported vector geometries or national mapping layers, establishing accurate spatial anchors before tracing or updating terrain features.
Does Gratic require a local cartography licence to parse OCAD records?
No. Gratic operates with nothing to install and nothing to license. You open a browser tab, sign in with an email sign-in code, and parse or edit OCAD files across Windows, Linux, and macOS.