Place a hall by arranging a generated layout in a vector editor, keep the result as its map background, and let the picker zoom out to all of it

A brand new room cannot be mapped today. Building a venue map says so in its section on coordinates: this is the part that takes the work, and yoyaku ships no tool for it. An operator has to produce x, y and angle for every place outside Drupal and load them through a venue package, and they have to hand-author an SVG carrying a defs full of sprites before a single place can be drawn at all. So the artwork is a prerequisite for placing one seat.

Proposed

Make the layout a round trip, so that the artwork becomes an output of it rather than an input to it.

1. The operator creates the venue, its sections and its grades, and generates its places with the form that already exists.
2. Yoyaku builds an SVG in which every place is a movable marker, laid out flat: sections in weight order, rows stacked, places along each row. For a plain rectangular room that layout is already the finished map.
3. The operator arranges it in a vector editor, and draws the room around it or traces the architect's plan under it.
4. They upload it back. Yoyaku reads each marker's position and rotation into x, y and angle, and stores what is left of the document as the venue's map background.

One builder serves maintenance too: with coordinates already stored it draws each marker where its place currently sits, over the current background, so adding a row or restriping a block is download, drag, upload. The stored background's viewBox is reused verbatim, since a coordinate only means anything in that space and re-fitting the box would shift the whole hall.

The marker contract

• One use element per place, inside a group named yoyaku-layout-places. Its id is the letter p and the place id, which needs no escaping in any editor, and the natural key (section key, subsection, row and place) travels in a data attribute, read when the id is unusable and printed in a report line so it names a place an operator recognizes.
• A use element is the one thing a vector editor cannot bake a rotation into: the reference has to survive, so the rotation stays in a transform that can be read back, where a rotated path folds it into its own coordinates and loses it.
• The glyph is a chair seen from above, deliberately asymmetric, so that a rotation is visible while arranging. A circle or a square is not: a square reads the same at 0, 90, 180 and 270 degrees.
• Section names and row labels sit in a guides group and stay in the stored background, which is the kind of line work an artwork is made of. The per-place numbers sit in their own group and are stripped along with the markers.
• The defs carry place-glyph and place-accessible, the ids the map already falls back to, and only when the reused background does not define them itself. So the picker draws correctly after the very first upload, with no further step.

What it reads, and what it refuses

A coordinate comes from the accumulated transform chain rather than from an element's own x and y, because an editor wraps layers in transforms and an operator moves, scales and rotates whole blocks. The angle comes from the same matrix.

The reader reports before it writes: a marker naming a place the venue does not have, a place with no marker, which keeps the coordinates it has because a deleted layer must not erase a hall, a marker landing outside the viewBox, and two markers claiming one place, which means a duplicate rather than a move and refuses the whole file rather than applying half of it. The scripted-construct check the venue form already uses runs on the upload first, before a parser touches it.

The boundary

The layout carries x, y and angle, and the grade when an upload is expressly told to read it. Not the accessible flag, not row or place labels, and it never creates a place. Every one of those has a form already, and reading them back out of the file would make the file a second source of truth for them.

Grades are a second, separate decision, off by default, because a layout is not where a grade is authored: a file carries the grades its places had on the day it was downloaded, so applying them as a side effect of moving a hall would undo whatever had been regraded since. A marker naming no grade says nothing rather than clearing one, and a grade the venue does not have is reported rather than guessed at. Each marker also names its grade in data-yyk-grade and is colored by it, on by default; the color itself is never read back, since it shows a grade rather than setting one.

One change outside the layout

The picker sized both its opening view and its zoom-out limit from the bounding box of the places, so anything drawn outside the seats, a stage in front of the front row or the walls of the room, could not be reached by zooming or panning. Those are two different questions now: the view still opens on the seats, since that is what a booker came to choose from, and zooms out to the whole picture.

Not in this issue

Re-deriving position and gap_before from the new coordinates, which drush yoyaku:venue-positions --fix already does, and which the documentation points at as the step after an upload.

No new field, no schema change and no update hook.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)