A deep-dive into TermiNode and GIS application architecture for geofencing, delivery zones, logistics, field operations, spatial APIs, PostGIS and blockchain proof layers.
Technologies Used
TermiNode is a GIS-first decentralized application I developed to explore a specific problem in geospatial systems: how can an important spatial record remain versioned, queryable, auditable and independently verifiable after it changes?
Maps are often treated as presentation layers. In operational software, however, geometry can become business logic. A polygon may define a delivery zone, service territory, restricted area, utility boundary, maintenance responsibility, insurance area or compliance region. A point may represent a customer, vehicle, warehouse, incident or field technician.
Once business decisions depend on those spatial relationships, GIS is no longer simply about displaying markers on a map. The application must understand coordinate systems, geometry validity, point-in-polygon decisions, spatial intersections, proximity, version history, query performance, access boundaries and the operational meaning of every spatial rule.
TermiNode demonstrates those concepts through a blockchain-based proof layer, but the underlying expertise is intentionally broader: the same spatial workflows can be implemented as traditional Laravel/PostgreSQL/PostGIS applications, API-first enterprise systems, mobile field platforms or hybrid architectures depending on the actual business problem.
A location-based project does not automatically need blockchain. In most business applications, customer records, dispatch screens, routing, notifications, billing and high-volume operational data are better handled by conventional application infrastructure.
Blockchain becomes useful when a subset of spatial state requires stronger provenance: for example, when an accepted boundary must remain independently inspectable, when previous geometry must not silently disappear, or when multiple organizations need a shared evidence layer without relying entirely on one party's mutable database.
Conventional GIS
Verifiable GIS
The first step in a GIS application is not choosing a map library. It is identifying which business concepts are actually spatial and which geometric representation describes them correctly.
| Geometry | Business Example | Typical Spatial Question |
|---|---|---|
| Point | Customer, vehicle, warehouse, technician | Which zone contains this location? |
| Polygon | Delivery zone, service area, restricted region | Is this address eligible for service? |
| MultiPolygon | Non-contiguous franchise or delivery territory | Does this location belong to any part of the territory? |
| LineString | Route, pipeline, service corridor | Does this route intersect a restricted region? |
| Bounding Box | Current map viewport | Which records should be loaded for this screen? |
One of the most commercially useful GIS patterns is service-area management. A business may not serve every address under the same price, delivery promise or operational team.
Instead of representing serviceability through city names or postal-code lists, a GIS-enabled application can make the decision directly from geographic boundaries.
Convert a customer address into coordinates and determine whether the point falls inside an active delivery polygon.
Different spatial zones can define delivery fees, minimum order values or commercial conditions.
Central, extended and remote service zones can carry different delivery-time commitments.
A customer location can be mapped to the responsible warehouse, hub or distribution center.
Special zones can prevent or flag deliveries where vehicles, products or operations are restricted.
Sales representatives, dealers, franchises or operational teams can be assigned to geographic territories.
Customer Address
Geocode
Point-in-Polygon
Resolve Zone
Price / SLA / Hub
Create Order
The spatial decision should be made by the backend and persisted with the order. Recalculating historical orders against today's delivery zones can otherwise produce a different answer after boundaries change.
Spatial business rules change. A delivery zone expands, a franchise territory is reassigned, a restricted region changes or a service area is redrawn.
Overwriting the polygon answers the question “what is the boundary today?” but destroys the answer to “which boundary was valid when this order or decision was made?”
A traditional GIS application can keep valid-from, valid-to and geometry-version records in its spatial database.
Where stronger provenance is required, an accepted geometry version can additionally receive an immutable proof and evidence record.
Route visualization is only one part of geospatial logistics. Many valuable logistics decisions are spatial predicates executed before, during or after route calculation.
| Workflow | Spatial Logic | Business Action |
|---|---|---|
| Delivery eligibility | Point inside service polygon | Allow or reject checkout |
| Dispatch | Location inside operational territory | Assign hub, vehicle or team |
| Proximity | Nearest / distance query | Find closest warehouse or technician |
| Route compliance | Route intersects restricted polygon | Warn, reroute or require approval |
| Proof of arrival | Device inside destination geofence | Enable location-aware workflow event |
| Geographic pricing | Customer location mapped to tariff zone | Apply delivery or service fee |
A production geofencing workflow must account for uncertainty. Mobile GPS coordinates are measurements, not mathematically perfect positions.
Depending on the business risk, a system may need to evaluate GPS accuracy, boundary tolerance, timestamp, device context and whether a location is exactly on the edge of a polygon before triggering an irreversible workflow.
Enter / Exit Events
Accuracy Radius
Boundary Tolerance
Server-Side Verification
When blockchain proof is unnecessary, the same location-based workflows can be implemented efficiently in a conventional application architecture.
For business applications, PostgreSQL with PostGIS provides a powerful foundation for storing geometry and executing spatial queries close to the operational data that depends on those relationships.
Determine whether a delivery, customer or asset location belongs to a defined polygon.
Detect overlapping areas or routes crossing controlled regions.
Search for nearby warehouses, technicians, customers or assets within a radius.
GiST-backed spatial indexes make geographic filtering practical for much larger datasets than application-side polygon loops.
Spatial features can be exposed through controlled APIs to maps, mobile clients and external integrations.
Version tables can preserve which polygon was operationally valid at a particular point in time.
A common GIS mistake is treating every coordinate operation as if latitude and longitude were ordinary Cartesian values.
EPSG:4326 is an effective interchange format for web and API workflows, but distance, buffering and area calculations may require geography-aware calculations or an appropriate projected coordinate reference system. Choosing the wrong spatial model can produce technically valid queries with incorrect business results.
Spatial applications should not send every feature to every client. The application should normally request only the features relevant to the current viewport, dataset or operational query.
Retrieve features visible in the current geographic window.
Query only the spatial layer relevant to the workflow.
Keep large spatial responses bounded and predictable.
Reduce unnecessary geometry detail where the current zoom does not require it.
TermiNode takes a deliberately narrow part of the wider GIS problem and makes it independently inspectable.
Versioned Polygon State
Previous accepted geometry does not silently disappear after an update.
Bounded Spatial Reads
Dataset, bbox, point and paginated spatial queries expose controlled spatial context.
Audit Events
Important geometry changes can be reviewed through a persistent event trail.
Proof Receipts
High-value spatial checks can produce portable verification references.
Snapshot Checksums
Exported dataset state can carry evidence that helps later integrity review.
Evidence Export
Spatial state can leave the application as an inspectable evidence package.
A logistics application rarely benefits from moving its entire workflow on-chain. A stronger architecture keeps high-volume operational data in conventional systems and selectively anchors spatial records where independent verification adds value.
| Domain | Recommended Layer |
|---|---|
| Orders | Laravel / ERP / conventional relational database |
| Customers & addresses | CRM / application database |
| Vehicles & drivers | Fleet-management database |
| Routing & ETA | Routing engine / external location API |
| Operational geofencing | PostgreSQL / PostGIS |
| Accepted regulated delivery zones | Conventional GIS + optional verifiable proof layer |
| Spatial audit evidence | TermiNode when independent proof is justified |
The same GIS architecture patterns apply far beyond a map-centric application.
Service zones, dispatch territories, restricted routes, warehouse allocation and location-aware pricing.
Assign technicians by territory, proximity, service radius or infrastructure responsibility.
Dealer regions, sales territories, regional pricing and warehouse catchment areas.
Asset corridors, inspection areas, maintenance zones and responsibility boundaries.
Claim boundaries, risk zones, event footprints and spatial evidence packages.
Service areas, outage regions, public works, zoning and infrastructure boundaries.
A spatial system does not need to expose a map to provide GIS value. Many of the most valuable spatial functions can operate as application services consumed by CRM, ERP, e-commerce, logistics and mobile applications.
POST /serviceability
Can this customer location be served?
GET /zones/{location}
Which operational zones apply to this coordinate?
GET /nearest
Find the nearest eligible warehouse, technician or asset.
POST /route-check
Determine whether a planned route conflicts with a controlled area.
These services can be integrated into existing business applications instead of forcing every team to operate a separate GIS product.
TermiNode also explores Model Context Protocol as a read-oriented interface for spatial evidence. An AI agent can inspect dataset, feature version, audit, snapshot and metrics context without receiving unrestricted write authority.
The same principle can be applied to conventional GIS applications: expose explicit spatial tools to an AI system instead of asking the model to infer geographic truth from screenshots or raw database access.
| Requirement | Possible Architecture |
|---|---|
| Internal logistics system | Laravel + PostgreSQL/PostGIS + REST API |
| Mobile geofencing | Mobile location client + backend spatial verification |
| Customer-facing delivery map | PostGIS + GeoJSON + web map frontend |
| High-volume regional lookup | Indexed PostGIS queries + cache + bounded API |
| Shared spatial proof | Conventional GIS + TermiNode proof layer |
| Fully decentralized spatial product | ICP canisters + Candid + verifiable spatial records |
PostgreSQL / PostGIS
Spatial persistence, indexes, proximity, containment and intersection queries.
GeoJSON / WKB
Standard spatial interchange formats for APIs and GIS integration.
Spatial REST APIs
Serviceability, geofence, proximity and spatial-query interfaces.
Geofencing
Region-based workflow triggers and backend location validation.
Delivery & Service Zones
Polygon-based eligibility, pricing, SLA and assignment logic.
Location-Based Workflow Automation
Connect spatial decisions with CRM, ERP, order and field-service workflows.
Spatial Versioning
Preserve historical operational boundaries and effective periods.
Blockchain GIS
Selective proof layers for spatial state requiring stronger provenance.
Internet Computer / Candid
Decentralized application and canister-based spatial service architecture.
MCP / Agent Integration
Structured read interfaces for AI-assisted spatial review.
TermiNode is a deliberately specialized DApp, but the engineering knowledge behind it applies directly to conventional business software.
If an order, customer, vehicle, technician, asset or business rule depends on where something is located, a spatial data model can often replace fragile city-name rules, manually maintained postcode tables and application-side distance calculations.
I can design the spatial layer as part of a conventional CRM, ERP, logistics or field-service platform using PostgreSQL/PostGIS and APIs, or introduce a blockchain-based proof layer where versioned geometry, independent verification and durable evidence provide genuine business value.
The architecture should follow the operational requirement — not force every location-based problem into either a blockchain product or a generic map application.
Architecture note: TermiNode is intentionally positioned as a verifiable spatial proof layer, not as a replacement for mature GIS authoring, routing, basemap, search or field-work platforms. Conventional databases and GIS services should continue to handle high-volume, private and operational application state where they are the better technical fit.
Explore more projects showcasing CRM, ERP, and API integration work.
Vinoks is a large factory in Istanbul, Turkey, that produces stainless steel kitchen and bathroom equipment. A web appli...
View details
Savory Cafe is a multi-tenant digital management platform for F&B businesses. It delivers real-time order processing, ca...
View detailsShare the current workflow and systems involved to get a practical direction for scope, integrations and a useful first release.
Typical response within 24 hours · Clear scope & timeline · Documentation included