From Static Floor Plans to Searchable Campus Navigation with SVG and A*

A floor plan is not yet a navigation system

A static building image can show where rooms are, but it cannot answer the question a visitor actually asks: how do I get from here to there? WCC SCAN covers an eight-floor campus with classrooms, laboratories, offices, restrooms, exits, stairs, elevators, and other facilities. It also carries events, announcements, reminders, policies, and feedback tickets. The challenge was to connect spatial information with searchable campus content without turning every floor into a hand-coded page.

I separated the problem into three layers. The data layer describes floors, rooms, types, and searchable names. The visual layer renders interactive SVG plans and highlights results. The navigation layer represents possible movement as a graph. This makes the map an interface over structured information instead of the only place where knowledge about the building exists.

Turning rooms into maintainable data

Room search only works when naming is consistent. A space may have an official room number, a familiar label, a department, a floor, and a type. Storing those as explicit fields allows the application to search and filter without scraping SVG labels. It also lets administrators update descriptions or categories without redrawing the map.

The room type taxonomy matters because users often search by need rather than name. Someone may ask for any restroom, exit, laboratory, or office. Types also support map legends and accessible result lists. A room record can point to its SVG element identifier and graph node, connecting database content to the visual shape while keeping the database independent from SVG markup details.

• Use stable identifiers to connect rooms, SVG elements, and graph nodes.
• Keep display names and searchable aliases separate from geometry.
• Treat stairs, elevators, and exits as navigable facilities, not decoration.

Why SVG fit the interactive map

SVG preserves sharp lines at different screen sizes and gives rooms and paths addressable elements. A selected room can change style, a route can be drawn above the floor, and labels can remain connected to shapes. That is much harder with a single raster image. The tradeoff is that SVG coordinate systems, view boxes, and element identifiers have to be managed consistently across eight floors.

Responsive behavior also needs more than scaling the entire drawing until it becomes unreadable. On smaller screens, the map benefits from pan and zoom, a clear floor selector, a result list, and a reset action. Touch targets cannot depend on tiny room polygons. Selecting a search result can focus the correct floor and highlight the room even when tapping the exact shape would be difficult.

Representing movement as a graph

Pathfinding requires a graph of walkable points and connections. Nodes can represent corridor junctions, room entrances, stairs, and elevators. Edges represent allowed movement and carry a cost, usually based on distance. A room is connected to an entrance node instead of being treated as a point anywhere inside its polygon. Cross-floor routes connect compatible vertical nodes such as stair landings or elevators.

The most labor-intensive part is often graph preparation, not the algorithm. Missing an edge can make a nearby room unreachable. Adding an edge through a wall produces a route that looks mathematically short but physically impossible. Visual debugging tools that display node identifiers and edges are valuable during map authoring, even if they never appear in the public interface.

Using A* without making it magical

A* searches the graph by combining the known cost from the start with a heuristic estimate to the destination. For points on a floor plan, straight-line distance is a practical heuristic as long as it does not overstate the real path cost. The algorithm can then prioritize promising routes without exploring every corridor equally.

The algorithm still depends completely on graph quality and accessibility rules. If stairs and elevators are both represented, their weights can express different preferences, but the interface should not call a route accessible unless the underlying data supports that claim. For this project, the documented capability is basic A* navigation. The responsible approach is to describe and test that boundary instead of implying turn-by-turn indoor positioning or accessibility guarantees that the data does not provide.

• Validate that every public room connects to the graph.
• Test same-floor, cross-floor, adjacent-room, and unreachable cases.
• Render the chosen node path so graph errors are visible during development.

Connecting search, filters, and route display

A useful flow begins with a query or room-type filter, not with asking a visitor to understand the map. Results should show the room name, type, and floor. Selecting one changes the active floor, highlights the destination, and offers navigation from a chosen starting point. When the route crosses floors, the instructions need to identify the transition instead of drawing disconnected lines without explanation.

Laravel provides the room and content data, while Alpine.js supports focused interaction without requiring a separate client application. The server remains responsible for authentication and administrative operations. The browser handles selection, map state, filtering, and route presentation. Keeping the response payload structured makes it possible to add another interface later without rebuilding the campus model.

A campus guide also needs current content

Navigation is only part of WCC SCAN. Events, announcements, reminders, policies, and feedback tickets make it a broader campus information surface. The administrator panel supports CRUD workflows for that content and status management for feedback. This is important because a technically correct map can still feel abandoned if schedules and notices are stale.

The feedback workflow closes the loop. Visitors can submit issues and follow pending, reviewed, or resolved states, while administrators can filter and manage them. Ratings provide another signal without replacing the ticket details. As with room data, explicit statuses make the workflow reportable and easier to maintain than a generic contact inbox.

The payoff and what I learned

The delivered capability combines searchable rooms, type and floor filtering, interactive SVG maps, basic A* routes, campus information, and an administrative feedback workflow. A visitor can approach the building through a task—find a room, understand a floor, read an announcement, or report a problem—rather than browsing a static directory.

The main lesson is that visual systems become maintainable when geometry, domain data, and interaction state are separated. SVG made the building interactive, but structured room records made it searchable and a graph made it navigable. Laravel administration made the surrounding information sustainable. Each layer solved one problem, and the connections between them created the useful product.