The products of Payeshgaran Farasanjesh Tabiat Fars are ready-to-use software systems built for a defined organisational purpose and running in production today. They serve municipal services, cemetery management, handling of public requests and the management of water supply facilities, and in all of them spatial data is the load-bearing element. Unlike a bespoke project built from scratch, a product is offered with a tested core and can be deployed faster. This page lists the running systems, the architecture principles they share, the way they are deployed and supported, the licence terms, and the criteria for choosing a product rather than a custom project.
Five Systems in Operation
The Samaneh Modiriat Hooshmand Aramestan is an integrated platform for recording and tracking plots, graves, applicants and cemetery services. It is implemented with Next.js and Prisma on PostgreSQL and brings together map display with KML import, plot management, service requests, contracts, annual tariffs, hospitality arrangements and QR codes.
The Samaneh Dabirkhaneh Komisiyon Madeh 100 manages the files of this commission. It is built with Node and Express on PostgreSQL with a React user interface, and covers PDF and Word generation, Excel export, Jalali calendar support, map display and a licensing subsystem.
The Samaneh Hooshmand Modiriat Shahri Shahriar is implemented with CesiumJS, Express and PostgreSQL and focuses on three-dimensional display and analysis of the city. Distance, area, volume and profile measurement, building simulation, shadow analysis and a user management panel are among its functions.
The Samaneh Hooshmand Modiriat Abresani is built with Node.js and PostgreSQL and exposes one shared API to a field application and a web dashboard. Token-based authentication and data consistency between those two interfaces are the defining features of its architecture.
The AI-based Samaneh 137 comprises an Android application written in Kotlin, a Node and Prisma server on PostgreSQL, and a React dashboard, covering photo and location capture, tracking codes, a case-handling workflow, offline storage and synchronisation.
Common Architecture Principles
Despite their different fields of use, these systems rest on shared architectural principles. All are built on the PostgreSQL relational database, storing spatial and attribute data on one platform; this uniformity simplifies combined queries and reporting. The spatial reference is also defined and recorded explicitly in every product.
Separating the server from the user interface is another shared principle. Business logic and validation rules run on the server so that outputs remain identical regardless of the interface. This separation allows a web interface and a field app to use the same shared logic, as seen in the water supply management system.
Workflow-based design is the third common thread. Rather than being a collection of forms, each system models the path of the work itself: from request registration through review and approval to issuing the output. Roles and access levels are defined on the same basis, making the handling cycle traceable.
- One database for spatial and attribute data.
- Separation of server logic from the interface, with a shared API.
- Workflow modelling built around organisational roles.
- An explicit spatial reference and date handling suited to Iranian users.
Integration with the Client’s Data and Processes
A product only becomes part of daily work once it is aligned with the organisation’s data and procedures. The main part of deployment is migrating the organisation’s existing data into the system; data is read from common formats such as spreadsheets and existing databases, then cleaned, normalised and loaded into the system data model. In the cemetery system, KML import is also available for recording spatial extents.
Existing spatial data is usually stored in a range of coordinate reference systems. Before loading, it is transformed into a common reference and geometry validity is checked so that layers align correctly. Where needed, base layers such as plot boundaries, roads or networks are prepared as well.
It is also established which other systems the application will exchange data with and in which format. Application programming interfaces and structured outputs such as GeoJSON and Excel are the conventional paths for this exchange.
- Reading, cleaning and migrating the organisation’s existing data.
- Transforming spatial data to a common reference and checking geometry.
- Preparing the base layers required by each system.
- Defining data exchange paths with other systems in the organisation.
Deployment, Training and Support Model
Deployment follows the organisation’s infrastructure. A system can be installed on the client’s servers inside the organisational network or hosted on cloud infrastructure; the choice depends on the organisation’s security and access policies. Before deployment, the server, database and network requirements are specified.
User training is an inseparable part of delivery. Training is given separately to different user groups, because the needs of an operator entering data differ from those of a manager producing reports. User guides and technical documentation are provided together with the system.
The support model rests on three pillars: fixing software faults, answering user questions, and applying required changes during operation. The change history of the system is maintained so that updates can be traced and rolled back. Support can be arranged periodically or under a specific agreement.
Licensing and Terms of Use
Use of the products is defined through licensing. The scope of a licence is set by the number of users, the organisational scope in which the system is used and the deployment location. In some products, such as the Madeh 100 commission system, a licence control mechanism is also built into the software itself.
Data retention and backup requirements are stated in the terms of use. It is settled how often backups are taken and where they are kept, and what recovery procedure exists if needed. These points are recorded in the delivery document so that no ambiguity arises during operation.
An organisation’s data content remains its own, and the database schema is designed so that extraction in standard formats is always possible. This principle reduces the organisation’s dependency on the supplier.
Product or Custom Project
The choice between a ready product and a bespoke project depends first on how far the organisation’s needs overlap with existing functions. If the organisation’s process is close to one of these systems, deploying the product with limited modifications is faster and less risky. If the organisation’s question has a different structure or requires new processing and analysis, a custom design is the better answer.
The decision criteria are clear: the number of users and roles, the complexity of the workflow, the degree of integration with other systems, the need for advanced spatial analysis and specific data retention requirements. These criteria are examined during requirements analysis, and the outcome is a recommendation of one path or a combination of the two.
In many cases a combination works well: the core comes from the ready product and the organisation’s specific parts, such as spatial analyses or intelligent functions, are added as custom components. This keeps the speed of deploying a product while retaining the flexibility of a custom design.
- Closeness of the organisation’s process to existing functions is the main criterion for a ready product.
- A need for a different structure and analysis is the main criterion for a custom design.
- The core product can be combined with custom additions for specific needs.
- The decision is based on a written requirements analysis, not on assumptions about the future.
Summary
The products of this company are a family of systems in operation that rest on a shared architecture: one spatial database, server logic separated from the interface, and design around organisational workflow. This common ground makes the systems easier to maintain and allows experience to transfer between them.
Their real value lies in the integration of spatial data with the organisation’s daily process, not in the list of technologies used. This is why a substantial part of deployment is devoted to cleaning and migrating existing data and aligning the system with the client’s working routine.
To choose between a ready product and a custom project it is enough to establish the organisation’s current process, the user roles, the existing data and the required level of integration; from these the appropriate path, the scope of change and the deployment plan can be prepared.