Port GIS portal
A geographic information system and a trilingual touchscreen kiosk for a port site: interactive mapping, venue management, bookings and a role-based back office, kept up to date by the operators themselves.
The problem
No structured information existed on the site: visitors could neither find their way nor see what the venues offered, and nobody had any way of keeping that information current.
The outcome
A complete system that runs without technical intervention: a single database, one account per venue, backups and server-side error logging.
The context
A port site open to the public, with eight food and drink venues and a mixed audience — visitors and restaurant customers, boat owners and sailors, passing tourists — plus the staff of the venues themselves.
Before this project, nothing was structured. There was no central source describing the venues, their menus, their prices or their location. A visitor could not know what was waiting a hundred metres away, and an owner who changed prices had no way of announcing it anywhere but on their own shopfront.
The brief: a 55-inch self-service touchscreen kiosk, in French, Arabic and English, showing an interactive map of the site and the full offer of every venue.
The constraints
- Usable by finger, with no keyboard, by a non-technical audience in a hurry
- Three languages, one of them written right to left, on a fully touch-driven interface
- Content kept current by the operators themselves, with no developer involved
- Running on an isolated machine, on a network connection that is not guaranteed
- The level of reliability expected of an official installation: nothing may be lost
The architecture decision
The first version was a front end alone, with the data held in files and in browser storage. Two reasons forced a rebuild around a relational database with a server-side API:
The data did not persist reliably. Cleared browser storage is lost data, with no backup and no way of knowing what disappeared. For content maintained by eight venues, that was an unacceptable risk.
The standard an official system is held to. Backups, traceability, logging: an institutional installation cannot rest on unreplicated local state.
The database was normalised around ~27 tables: points of interest and their translations, menu categories and their labels (68 translated categories), items, a price history kept over time rather than overwritten, accounts and their permissions, bookings, reviews and complaints.
What was hardest
Migration and normalisation. Moving from flat storage to a relational model without losing data means rebuilding relationships that were never stated anywhere — which item belongs to which category, of which venue, in which language.
Access control and isolation between venues. Each manager must see and edit only their own venue. The hard part is not writing the rule: it is guaranteeing that no route forgets it. A check performed in the presentation layer but missing from the data layer lets a direct access by identifier straight through. Scope filtering was pushed down to the query level, not the views.
The mapping. A layer editor on a GeoJSON base, KML/KMZ base map import, and automatic assignment of points of interest to a zone by spatial query: the system works out for itself which zone a venue belongs to from its position, instead of asking a human to type it — so the map and the database cannot drift apart.
Multilingual, with Arabic. Flipping a touch interface to right-to-left does not break the text: it breaks the margins, the icons, the arrows and everything positioned by thinking “left” and “right”. The answer is logical rather than directional properties, decided at the outset rather than patched afterwards.
The outcome
The system runs without technical intervention. That is the result worth stating, because it is the one that matters to the client:
- a single authoritative database, maintained by the operators themselves
- accounts with differentiated rights, each manager confined to their own venue
- sessions that do not expire mid-entry on a self-service kiosk
- server errors logged to the database, readable without access to the machine
- backups, and a price history kept rather than overwritten
The system is delivered, and its rollout on site is under way.
What this project says about how we work
Several vulnerabilities were found and fixed along the way: a cross-account path letting one manager see another’s drafts, a parameter exposing inactive data to unauthenticated requests, and session sharing between tabs causing an identity mismatch. They are mentioned here on purpose.
A project with no vulnerabilities found is not a safe project: it is a project nobody looked at. What matters is that they were sought, found, fixed and documented before going live.