ClickableMaps Interactive Layout Builder

ClickableMaps AI Layout CSV Specification

A Structured Format for Creating Interactive Layouts

The ClickableMaps AI Layout CSV Specification defines the structured data format used by the ClickableMaps Interactive Layout Builder.

It is intended for both humans and AI systems that need to create layout data which can be imported into ClickableMaps, visually reviewed and, where appropriate, transferred to compatible applications such as osConcert.

The specification can describe seating plans, tables, stages, labels, floor-plan objects and other positioned elements inside a responsive layout.

The Basic Workflow

A layout can be created manually in the ClickableMaps Layout Builder or generated as structured CSV data.

A possible AI-assisted workflow is:

Venue schematic or description

AI reads this specification

AI generates ClickableMaps CSV

Import into the Layout Builder

Human review and correction

Export approved layout

Optional import into osConcert

AI-generated layouts must always be checked against the real venue before operational use.


1. Workspace

The standard ClickableMaps design workspace has a maximum width of:

1100 pixels

The workspace acts as the master coordinate system.

The height can be adjusted to suit the layout.

When a background venue schematic is used, the recommended source image width is 1100px and the workspace height should be set to match the corresponding image height.

Objects are positioned relative to this workspace and can subsequently be rendered responsively.


2. Required CSV Column Order

CSV files intended for ClickableMaps/osConcert compatibility use the following column order:

products_id
products_quantity
products_name
products_number
color_code
products_status
products_x
products_y
products_w
products_h
products_r
products_sx
products_sy
product_type

The CSV header must therefore be:

products_id,products_quantity,products_name,products_number,color_code,products_status,products_x,products_y,products_w,products_h,products_r,products_sx,products_sy,product_type

Do not rename, reorder or invent additional columns when generating a compatible CSV.


3. Object Types

ClickableMaps currently uses three primary object types.

P — Seat / Selectable Object

product_type = P

A P object represents a seat or selectable position.

For osConcert-compatible layouts:

products_status = 1

Typical examples include:

  • theatre seats;
  • concert seats;
  • individual reserved positions;
  • selectable spaces.

P objects can participate in the booking process when the completed layout is imported into osConcert.

L — Text / Label

product_type = L

A non-selectable text object used to identify parts of the layout.

For osConcert-compatible layouts:

products_status = 4

Examples include:

  • ROW A;
  • BALCONY;
  • ENTRANCE;
  • EXIT;
  • VIP AREA;
  • section names.

Q — Prop / Visual Object

product_type = Q

A non-selectable visual object.

For osConcert-compatible layouts:

products_status = 7

Examples include:

  • stages;
  • tables;
  • bars;
  • counters;
  • sound desks;
  • booths;
  • structural or decorative layout objects.

4. Position and Dimensions

The following fields define an object's geometry:

products_x — horizontal position

products_y — vertical position

products_w — object width

products_h — object height

products_r — rotation

Coordinates and dimensions use the ClickableMaps workspace coordinate system.

Objects should remain within the intended workspace unless deliberate overflow is required.

When generating symmetrical layouts, calculate the complete width of each row or group and position it centrally within the 1100px workspace.

For example:

If a seating row is 640px wide:

(1100 - 640) / 2 = 230

The row should therefore begin at approximately:

products_x = 230

This leaves equal space on both sides.


5. Colour

color_code stores the object's colour.

For maximum compatibility with osConcert, the standard colour names are:

red
yellow
blue
skyblue
thistle
green
palegreen
fuchsia
teal
orange
salmon
transparent

When creating layouts intended for osConcert, prefer these supported named colours rather than arbitrary hexadecimal colours.


6. Shape Encoding

ClickableMaps preserves the visual shape of every object using two CSV fields:

  • products_sx — identifies the shape type.
  • products_sy — stores the radius amount used by that shape.

These values are shared with the osConcert CSV import/export format, allowing object shapes to survive the complete ClickableMaps → CSV → osConcert workflow.

Supported Shape Codes

Shapeproducts_sxproducts_syCSS interpretationSquare00border-radius: 0Rounded18border-radius: 8pxHalf-Rounded212border-radius: 12px 12px 0 0Circle / Oval350border-radius: 50%

Square

products_sx = 0
products_sy = 0

The object has square corners.

Rounded

products_sx = 1
products_sy = 8

All four corners are rounded. products_sy represents the radius in pixels.

The standard ClickableMaps value produces:

border-radius: 8px;

Half-Rounded

products_sx = 2
products_sy = 12

Only the top-left and top-right corners are rounded.

The standard ClickableMaps value produces:

border-radius: 12px 12px 0 0;

This is particularly useful for representing traditional seat shapes with a rounded back and flat base.

Circle / Oval

products_sx = 3
products_sy = 50

The object uses a percentage radius:

border-radius: 50%;

If the object's width and height are equal, this produces a circle.

If its width and height differ, it produces an oval.

Instructions for AI-Generated Layouts

When generating a ClickableMaps-compatible CSV, use only the documented shape codes:

Square       → products_sx=0, products_sy=0
Rounded      → products_sx=1, products_sy=8
Half-Rounded → products_sx=2, products_sy=12
Circle/Oval  → products_sx=3, products_sy=50

Do not place CSS such as 50% or 12px 12px 0 0 directly into the CSV fields.

Do not invent additional products_sx shape codes.

When the user does not specify a shape, use:

products_sx=0
products_sy=0

for a standard square object unless the layout requirements indicate otherwise.

For circular tables or other circular objects, use equal products_w and products_h values together with:

products_sx=3
products_sy=50



7. Object Text and Numbering

products_number contains the visible seat number or object text.

For P objects this will normally represent the seat number.

Examples:

1
2
3
A1
A2
A3

For L and Q objects it can contain visible text such as:

ROW A
STAGE
VIP TABLE 1
SOUND DESK
ENTRANCE

Seat identifiers should be unique where the resulting application requires individual seat identification.


8. Creating Rows of Seats

AI-generated seating rows should be calculated rather than positioned randomly.

Determine:

  • number of seats;
  • seat width;
  • seat height;
  • horizontal gap;
  • total row width;
  • starting X coordinate;
  • row Y coordinate.

Example:

For 19 seats, each 28px wide, separated by a 6px gap:

19 × 28 = 532px

18 × 6 = 108px

Total row width = 640px

To centre the row:

(1100 - 640) / 2 = 230px

The first seat begins at X = 230.

Each following seat advances by:

28 + 6 = 34px

This creates a predictable and symmetrical row.


9. AI Generation Instructions

When asked to generate a ClickableMaps layout, an AI system should:

  1. Understand the supplied venue description, schematic or seating plan.
  2. Determine the required workspace height.
  3. Identify selectable seats separately from labels and visual props.
  4. Use P objects for selectable seats.
  5. Use L objects for text and labels.
  6. Use Q objects for visual props.
  7. Assign the appropriate osConcert-compatible status to each object type.
  8. Calculate coordinates systematically.
  9. Preserve symmetry where the source venue is symmetrical.
  10. Allow appropriate spacing between seats and objects.
  11. Assign unique seat identifiers where required.
  12. Use supported colours.
  13. Use supported shape values.
  14. Keep objects within the workspace where practical.
  15. Produce the exact documented CSV column structure.
  16. Validate the result before returning the CSV.

The AI should not invent venue details that cannot reasonably be determined from the supplied source.

If important information is missing, the user should be told what requires human confirmation.


10. Validation Before Import

Before presenting a generated layout as complete, check:

  • the CSV contains all required columns;
  • columns appear in the required order;
  • every object has a valid product type;
  • P objects use the appropriate selectable status;
  • L and Q objects use their appropriate visual statuses;
  • seat identifiers are unique where required;
  • coordinates are numeric;
  • dimensions are valid;
  • objects remain within the intended workspace;
  • requested seat capacity matches the generated seat count;
  • row numbering is consistent;
  • colours use supported values where osConcert compatibility is required;
  • shape values use supported combinations;
  • there are no unintended duplicate objects.

11. Human Verification Is Required

An AI-generated layout is a starting point, not an authoritative venue plan.

Real venues can contain:

  • irregular seating;
  • restricted-view seats;
  • wheelchair spaces;
  • emergency exits;
  • aisles;
  • pillars;
  • balconies;
  • accessibility requirements;
  • fire and safety requirements;
  • venue-specific numbering systems.

The person responsible for the venue must compare the generated layout with authoritative venue information before using it for reservations or ticket sales.

ClickableMaps provides the visual environment in which the generated data can be inspected and corrected.


12. osConcert Integration

ClickableMaps and osConcert use compatible structured layout data.

A completed seating layout can therefore follow this workflow:

Create or generate → Import into ClickableMaps → Review → Correct → Export → Import into osConcert

Within osConcert:

  • P objects can become selectable booking seats;
  • L objects provide labels;
  • Q objects provide visual venue elements.

osConcert then provides the wider ticketing environment, including event configuration, availability, customers, orders, payments and electronic tickets.


Experiment #2 — Can AI Build the First Draft?

This specification also forms part of an ongoing CyberGord Structured Knowledge experiment.

The question is deliberately simple:

Can an AI assistant that has never previously worked with ClickableMaps read this specification, examine a venue schematic and generate a valid layout that imports successfully?

The experiment does not require AI to produce a perfect venue.

The objective is to determine whether structured, machine-readable website knowledge can give an AI enough technical understanding to perform useful work with an unfamiliar application.

The resulting layout can then be reviewed by a human using ClickableMaps and, once approved, transferred to osConcert.

AI prepares. ClickableMaps visualises. Humans verify. osConcert books.