Cloud-based alternatives to OCAD replace local desktop workstation setups with browser-based cartography editors that ingest open spatial data directly. Instead of distributing desktop licences, transferring raw LiDAR files, or configuring local GIS pipelines, sports cartographers now pull national mapping vectors and elevation models straight into a browser tab. Modern browser editors preserve exact IOF symbol specifications, support spot-ink print models, and export finished vector files directly into downstream desktop formats like OCAD.
What replaces desktop CAD for terrain cartography?
Browser-based vector cartography editors replace standalone desktop CAD packages by running native geometry engines, symbol definitions, and open-data ingestion directly inside a standard web browser tab. They remove local per-seat software licences and multi-gigabyte installer dependencies while delivering standard orienteering symbol sets, georeferenced raster tracing, and full OCAD file compatibility for sports clubs.
Traditional terrain mapmaking has long relied on specialised Windows software like OCAD or desktop open-source applications like OpenOrienteering Mapper. For clubs and event organisers, this workflow brings friction: club technical officers frequently buy per-seat licences that cost 500+€ per member who needs to inspect or amend map files. Distributing those licences across volunteers running macOS, Linux, or varied Windows laptops complicates training and stalls volunteer surveys.
General web GIS tools such as Felt or Equator handle spatial data layers, contours, and basic team annotations well. However, they are built for general boundary visualisation, collaborative pin-dropping, or surface modeling rather than strict sports cartography. They do not implement International Orienteering Federation (IOF) vector drawing rules, such as ISOM 2017-2 or ISSprOM 2019-2. When you export line data from generic GIS canvases, line-endings, gap dimensions, and dash intervals fail standard competition legibility guidelines.
At Gratic, we built our editor specifically to bridge this gap. We provide a vector cartography editor that runs in any modern browser tab on Windows, Linux, or macOS with nothing to install and nothing to license. Surveyors sign in with an email sign-in code, drag a bounding box across their terrain, and immediately access built-in IOF symbol sets, elevation tiles, and vector imports without leaving the canvas.
Desktop CAD suites
- Local per-seat machine installations
- Manual base-layer file conversions
- Operating system constraints
General web GIS
- Collaborative spatial pins and annotations
- Standard web-mercator rendering
- Lack of competition symbol standards
Dedicated browser cartography
- Runs in a browser tab on any operating system
- Automated elevation tile and vector ingestion
- Native IOF print-order spot-colour tables
How does open elevation and vector ingestion work in the browser?
Browser-based map editors ingest spatial data by connecting directly to public national mapping services and pre-tiled digital elevation models through web APIs. Rather than manually downloading external shapefiles or hillshade rasters, the editor parses terrain vectors and elevation tiles on the fly, rendering them into editable, standards-compliant cartographic vectors.
In desktop cartography setups, preparing base material requires multiple software utilities. A surveyor must find a government portal, download raw LiDAR point clouds or digital elevation grids, compute contours in a GIS environment, and import the resulting DXF or shapefiles into their CAD software. This pipeline generates large, unwieldy local files that volunteers struggle to exchange.
Modern browser mapping architectures streamline base-layer assembly into a unified import step:
- Select ground bounding box
- Ingest tile-by-tile elevation grids
- Query national mapping service vector endpoints
- Map raw geometry into standard IOF symbols
- Trace ground objects over georeferenced rasters
Because base data originates from open sources, data availability reflects national open-data policies. We publish both halves of what Gratic pulls in across surveyed regions: the elevation data we maintain tile by tile, and every national mapping service the editor imports vector data from. Where a national agency enforces a licence that restricts direct automated consumption, we document that boundary transparently so cartographers understand what data is accessible before planning a field survey.
Cartographers evaluating cloud and desktop paradigms generally weigh three underlying software architectures:
| Architectural model | Operating environment | Data ingestion model | Symbol and print governance | Downstream interoperability |
|---|---|---|---|---|
| Proprietary desktop CAD (e.g. OCAD) | Local workstation (Windows native) | Manual file preparation and local GIS imports | Native spot-colour tables and IOF symbol sets | Native proprietary vector format |
| Open-source desktop GIS (e.g. OpenOrienteering Mapper) | Local workstation (cross-platform installers) | Manual shapefile and raster file parsing | Native IOF symbol definitions and colour tables | Cross-format conversion (OCD versions 8 to 12) |
| General collaborative web GIS (e.g. Felt, Equator) | Cloud-rendered web canvas | Hosted raster layers and spatial vector uploads | Standard RGB web styling palettes | Generic spatial exports (GeoJSON, GeoTIFF) |
How do browser editors handle print orders and symbol governance?
Browser map editors handle cartographic governance by treating symbol sets and spot-ink tables as structural properties of individual map layers rather than static global templates. Moving an ink up or down in the layer table redraws the map in exact printing sequence, matching how physical press plates deposit CMYK inks on paper.
In standard graphics editors, colour is simply an RGB or CMYK attribute applied to a stroke or fill. Orienteering cartography works differently because legibility depends strictly on which ink conceals another. Under ISOM standards, a black rock symbol must obscure a brown contour, while certain screen fills require overprinting to remain legible at running speed. If software manages colours merely as an on-screen display palette, overlapping vector boundaries turn into an unreadable print artifact.
In Gratic, colours are managed as printing inks rather than arbitrary screen values. You assign a colour in CMYK, set its overprint rules, and position it directly within the print order table. When you reorder an ink, the map canvas redraws immediately to match the revised plate sequence. Within any layer, ink sequence governs visibility across all features.
Symbol management follows the same modular logic. Rather than locking an entire project to a single symbol table, symbol sets belong directly to their respective layer. A club symbol set and a standard international set can exist on separate layers within the same document without symbol number collisions. When updating a symbol definition—such as adjusting tick mark spacing on a fence—the change updates across all associated objects on that layer instantly while you type the dimensions in the browser tab.
Where do browser alternatives fit less well?
Browser-based vector cartography editors designed for terrain sports serve specific cartographic constraints and do not replace every class of GIS software. Recognising these architectural boundaries ensures that mapping teams deploy the right tool for their specific operational scope.
For municipal mapping departments, utility networks, and regional planners, enterprise GIS platforms remain essential. These departments require deep relational database connections, spatial SQL engines, multi-user attribute schemas, and complex land-tenure record keeping that specialised sports cartography editors deliberately omit. Gratic is not intended for general-purpose GIS and municipal mapping departments that manage urban infrastructure inventories.
Similarly, commercial web developers creating consumer navigation applications require distinct stacks. Road routing engines, live GPS turn-by-turn routing servers, and commercial vector tile hosting designed for high-concurrency mobile apps rely on platforms like MapTiler or Mapbox. MapTiler Cloud, for instance, recommends processing datasets exceeding 5,000 features or 5MB into map vector tiles using desktop tools prior to cloud styling. Gratic focuses strictly on sports cartography, terrain rendering, and print layout rather than consumer navigation APIs.
Frequently asked questions
Can map files created in a browser editor be shared with OCAD users?
Yes. Files exported from Gratic open directly in OCAD. This ensures that clubs collaborating across distributed teams can draw base sheets in a browser tab without locking out colleagues who complete their course planning or final archiving in established desktop CAD software.
How are standard orienteering symbol sets loaded when starting a map?
In Gratic, symbol specifications like ISOM 2017-2 are built into the document structure upon creation. You do not need to hunt down external symbol files or download font libraries; you locate required symbols instantly by entering their official IOF symbol number or standard descriptive name.
What happens if a national mapping agency restricts its vector data?
When a national mapping service enforces a licence that prevents automated API vector extraction, Gratic blocks that vector feed and explicitly displays the licence reason in its data catalogue. Cartographers can then choose to georeference permitted scanned maps or aerial imagery directly inside the browser tab as an alternative base layer.
How do multiple symbol standards coexist within one project?
In Gratic, symbol sets belong to specific document layers rather than the map as a whole. This architecture allows an organisation to keep a proprietary club symbol set on one layer and a standardised IOF specification on another layer in the same workspace without numbering conflicts.