Mashhad Urban Atlas — Geospatial Database & Urban Analytics Platform

Website Portfolio Copy — Urban Data, GIS Layers, Accessibility Analysis & 3D Neighborhood Modeling

Project positioning

Mashhad Urban Atlas is a large personal geospatial-data and urban-analysis project built around the administrative and neighborhood structure of Mashhad.

The project began as a conventional database effort, but the source material quickly made it clear that a normal relational database alone was not an adequate publication model.

Much of the value exists in:

maps,

spatial boundaries,

accessibility analyses,

land-use layers,

service coverage,

demographic indicators,

neighborhood profiles,

and 3D urban-form visualizations.

The correct technical framing is therefore not simply:

“a database of Mashhad”

but:

a geospatial urban atlas combining structured data, spatial layers, neighborhood analytics, and map-based visualization.

The master dataset is currently kept private. The project has not been released as a free public dataset, and no decision has been made to publish the full source material openly.

Classification

Project Type: Geospatial Database / Urban Atlas / Spatial Analytics
Domain: Urban Planning / GIS / Demographics / Public-Service Accessibility
Primary City: Mashhad
Administrative Model: Historical 17-region structure represented by the source material used in the project
Primary Analysis Unit: Neighborhood
Data Types: Relational + Geospatial + Map/Raster + Derived Analytical Layers
Core Themes: Demographics, Land Use, Accessibility, Public Services, Urban Form
Current Release Status: Private / Not Publicly Released
Potential Commercial Value: High
Portfolio Relevance: Very High
Suggested CV Relevance: Tier A/B — GIS, Data Engineering, Urban Analytics & Visualization

Website Card

Title:
Mashhad Urban Atlas — Geospatial Data & Urban Analytics Platform

One-line Description:
A large urban geospatial dataset and analytical atlas of Mashhad combining neighborhood demographics, land use, service accessibility, spatial layers, and 3D urban-form visualization.

Categories:

GIS
Geospatial Data
Urban Analytics
Spatial Database
Data Engineering
Urban Planning
Accessibility Analysis
3D Visualization
Research Software
Data Visualization

Technology / Concept Tags:
PostgreSQL · PostGIS · GIS · Spatial Data · Urban Analytics · MapLibre · Vector Tiles · Accessibility · 3D Urban Model · Demographics

Executive Summary

Mashhad Urban Atlas was created from a large body of urban-planning and neighborhood-level data.

The project contains both structured statistics and a substantial number of maps.

The dataset includes information such as:

administrative regions,
neighborhoods,
population,
area,
population density,
household counts,
literacy rate,
sex ratio,
household size,
male population,
female population,
land use,
accessibility to public services,
neighborhood structure,
urban form,
and three-dimensional neighborhood representations.

The project therefore sits at the intersection of:

DATABASE
+
GIS
+
URBAN PLANNING
+
SPATIAL ANALYSIS
+
DATA VISUALIZATION

Why a Normal Database Was Not Enough

The first implementation approach was database-oriented.

That worked for scalar data such as:

population,
area,
literacy rate,
household count.

But it became inadequate for spatial information.

A row such as:

Neighborhood = X
Population = Y

cannot fully represent:

a neighborhood boundary,
a land-use map,
service-accessibility zones,
3D urban structure,
service-point distribution.

The project therefore requires a hybrid spatial-data architecture.

Core Data Hierarchy

The conceptual hierarchy is:

Mashhad
   ↓
Administrative Region
   ↓
Neighborhood
   ↓
Data Domains

Each neighborhood can be associated with:

Neighborhood
├── General Profile
├── Area
├── Population
├── Households
├── Population Density
├── Literacy Rate
├── Sex Ratio
├── Average Household Size
├── Male Population
├── Female Population
├── Land Use
├── Accessibility Layers
├── Urban Structure
├── 3D Form
└── Descriptive Introduction

Administrative Structure

The source material used in this project models Mashhad according to a 17-region administrative structure.

This should be presented carefully in the portfolio.

Recommended wording:

The dataset models Mashhad according to the 17-region administrative structure represented in the source material used for this project.

This avoids implying that the same regional structure must still be current today.

Neighborhood as the Primary Analytical Unit

The neighborhood is the most important analytical unit in the project.

For each neighborhood, the atlas can provide a profile combining:

STATISTICS
+
SPATIAL CONTEXT
+
SERVICE ACCESS
+
URBAN FORM

This allows two neighborhoods to be compared not only by population but also by:

density,
service access,
land-use mix,
building form,
household structure.

Demographic Data

The dataset contains neighborhood-level demographic indicators including:

total population,
male population,
female population,
number of households,
average household size,
sex ratio,
literacy rate,
population density,
neighborhood area.

These variables provide the statistical layer of the atlas.

Population Comparison

The atlas supports comparative analysis between neighborhoods.

Examples:

Neighborhood A
Population: ...
Area: ...
Density: ...

Neighborhood B
Population: ...
Area: ...
Density: ...

The system can derive:

population ranking,
area ranking,
density ranking,
percentage of regional population,
percentage of regional area.

Land-Use Analysis

Land use is a major spatial component.

The source maps classify areas into categories such as:

residential,
higher education,
education,
sports,
commercial,
administrative / military,
health / medical,
cultural / artistic,
gardens / agriculture,
parks / green space,
religious,
urban facilities,
urban equipment,
transport / logistics,
industrial,
ceremonial / public gathering,
protected / buffer areas,
historical,
recreation / tourism,
other uses.

The exact category dictionary should be preserved from the original source material when the final dataset schema is normalized.

Land-Use Layer Model

A modern GIS model should store land use as geometry rather than as screenshots.

Conceptually:

land_use_features
├── id
├── neighborhood_id
├── category_id
├── geometry
├── source
├── data_year
└── version

This allows:

area calculation,
percentage calculation,
spatial filtering,
map rendering,
cross-neighborhood comparison.

Accessibility Analysis

One of the strongest parts of the dataset is service accessibility.

The project contains accessibility maps for multiple public-service categories.

Confirmed themes include:

primary schools,
green spaces,
general clinics,
bus stops,
mosques,
sports halls / sports complexes.

Accessibility Model

The general analytical model is:

Service Location
      ↓
Distance / Service Radius
      ↓
Coverage Zone
      ↓
Neighborhood Coverage

A neighborhood can therefore be evaluated by:

distance to service,
percentage covered,
underserved areas.

Primary School Accessibility

The dataset includes analysis of access to primary schools.

A modern implementation could calculate:

nearest school distance,
percentage of residential area inside a target radius,
underserved residential zones.

Green-Space Accessibility

Green-space access can be analyzed by:

park location,
service radius,
residential coverage,
neighborhood-level deficit.

This is especially useful for urban-quality comparison.

Health-Service Accessibility

The dataset includes access to general clinics.

A spatial model can calculate:

Residential Area
      ↓
Distance to Clinic
      ↓
Coverage Category

Public-Transport Accessibility

Bus-stop accessibility provides a mobility dimension.

Potential outputs:

stop density,
distance to nearest stop,
residential coverage,
underserved areas.

Mosque Accessibility

Religious-facility accessibility is also represented in the source material.

This can be modeled similarly to other service classes.

Sports-Facility Accessibility

The supplied source material includes maps showing access radius to sports halls and complexes.

The underlying model is not merely an image.

It is a spatial relationship between:

facility location,
travel/access radius,
neighborhood coverage.

Accessibility Zones

A modern data model can store service zones such as:

0–500 m
500–1700 m
>1700 m

or whatever thresholds are defined by the original source.

Important:

the project should preserve the original source thresholds rather than inventing new planning standards.

Accessibility Scores

A future analytical layer could derive a neighborhood-level accessibility score.

Example structure:

Accessibility Score
├── Education
├── Health
├── Green Space
├── Public Transport
├── Religious Facilities
└── Sports

Any weighting should be explicitly documented.

General Neighborhood Profile

Each neighborhood can include a human-readable summary.

This allows the atlas to combine:

quantitative data,
spatial data,
descriptive context.

A neighborhood page could therefore show:

Neighborhood Name
Short Introduction
Area
Population
Density
Households
Literacy
Sex Ratio
Land Use
Accessibility
D Form

Urban Structure

The source material includes neighborhood structural information.

This can represent:

main corridors,
urban skeleton,
major roads,
service centers,
functional structure.

The exact terminology should follow the source material when the original PDF is incorporated.

3D Neighborhood Representation

The project also contains 3D neighborhood imagery.

These visualizations represent building form / height across the urban fabric.

A modern implementation should not treat these only as static screenshots.

The underlying idea can be rebuilt as interactive 3D spatial data.

3D Data Model

Conceptually:

Building Polygon
+
Height / Floor Count
      ↓
3D Extrusion

The browser can then render:

low-rise buildings,
high-rise buildings,
neighborhood morphology,
skyline variation.

3D Visualization Options

Potential technologies:

MapLibre GL JS
deck.gl
Cesium
3D Tiles

For most neighborhood-scale visualization, MapLibre + PostGIS is likely sufficient.

Cesium becomes more useful if the project grows into heavier 3D city-scale rendering.

Proposed Modern Architecture

The modern V2 should use a true geospatial architecture.

                Frontend
        Laravel / Livewire
               │
        MapLibre GL JS
               │
          Spatial API
               │
      Laravel Application
               │
       PostgreSQL + PostGIS
               │
     Vector / Raster Storage

PostgreSQL / PostGIS Responsibilities

PostgreSQL

Store:

demographic statistics,
neighborhood metadata,
sources,
years,
versions.

PostGIS

Store:

administrative boundaries,
neighborhood polygons,
land-use polygons,
service points,
accessibility zones,
road geometry,
building geometry.

Object / File Storage

Large files should not be stored as ordinary relational columns unless there is a specific reason.

Suitable external assets include:

TIFF,
GeoTIFF,
PNG,
PDF maps,
GeoPackage,
3D exports,
generated reports.

The database should store:

file metadata,
source,
version,
object path.

Raster vs Vector

The project contains both conceptual types.

Vector

Use for:

boundaries,
parcels,
service points,
land-use polygons,
roads.

Raster

Use for:

scanned maps,
heatmaps,
historical imagery,
original rendered analyses.

Vector Tiles

Large vector datasets should not necessarily be sent directly as huge GeoJSON files.

A scalable architecture:

PostGIS
   ↓
Vector Tile Service
   ↓
MVT
   ↓
MapLibre

This improves browser performance.

Suggested Data Model

Core tables:

cities
regions
neighborhoods
administrative_boundaries

demographic_snapshots
population_statistics
household_statistics
literacy_statistics

land_use_categories
land_use_features

service_categories
service_points

accessibility_analyses
accessibility_zones

building_features
building_heights

spatial_layers
layer_versions
data_sources
dataset_versions

Data Provenance

Urban data becomes much more valuable when provenance is explicit.

Every data layer should ideally include:

source
source_document
data_year
created_at
version
valid_from
valid_to

This avoids mixing data from different planning periods.

Versioning

Administrative boundaries can change.

Demographic data also changes.

Therefore:

Neighborhood 2010
≠
Neighborhood 2020

should be possible in the data model.

The system should not overwrite old geometry silently.

Spatial Versioning

Example:

neighborhood_boundaries
├── neighborhood_id
├── geometry
├── valid_from
├── valid_to
└── source

This preserves historical comparability.

Data Quality

The V2 should validate:

geometry validity,
duplicate neighborhood IDs,
inconsistent area totals,
missing population values,
percentage totals,
coordinate reference system,
boundary overlaps,
service-point placement.

Coordinate Reference System

The source maps visibly reference UTM / WGS 1984.

A modern implementation should preserve original CRS metadata and transform only when required for display.

Typical web rendering may use Web Mercator, but source geometry should retain its authoritative CRS where possible.

Spatial Queries

PostGIS enables useful analyses such as:

Which neighborhoods contain a clinic?
Which residential areas are outside 500 m of a bus stop?
Which neighborhood has the highest residential density?
Which green spaces intersect Region X?

These queries turn the atlas from a map archive into an analytical platform.

Interactive Web Atlas

A strong public-facing V2 should provide an interactive explorer.

Example flow:

Select Region
      ↓
Select Neighborhood
      ↓
Select Layer
      ↓
View Map + Statistics

Layer Selector

Possible layers:

Demographics
Population Density
Land Use
Schools
Green Space
Clinics
Bus Stops
Mosques
Sports Facilities
Accessibility
Building Height / 3D

Neighborhood Dashboard

A neighborhood detail panel could show:

Area
Population
Households
Density
Male Population
Female Population
Literacy Rate
Sex Ratio
Average Household Size

with:

charts,
maps,
comparison bars.

Comparison Mode

Users could select multiple neighborhoods.

Example:

Neighborhood A vs B vs C

Compare:

population,
area,
density,
literacy,
household size,
service access.

Search

The system should support:

neighborhood search,
region search,
service search,
layer search.

Public Demo Strategy

The full dataset does not need to be released publicly.

A strong portfolio demo can expose only a selected subset.

Recommended model:

PUBLIC DEMO
→ 1–2 neighborhoods
→ selected layers
→ selected statistics

This proves the engineering work without releasing the asset itself.

Commercial / Private Master Dataset

The complete dataset can remain private.

Possible future products:

Full Dataset License

Complete geospatial data package.

District Package

Data for a selected region.

Thematic Package

Examples:

Education Accessibility
Green-Space Accessibility
Land Use
Demographics

API Access

Paid or controlled access through an API.

API Product Direction

Possible endpoints:

GET /api/v1/regions
GET /api/v1/neighborhoods
GET /api/v1/neighborhoods/{id}
GET /api/v1/neighborhoods/{id}/demographics
GET /api/v1/neighborhoods/{id}/land-use
GET /api/v1/neighborhoods/{id}/services
GET /api/v1/neighborhoods/{id}/accessibility

Spatial endpoints could return:

GeoJSON,
vector tiles,
summarized metrics.

Licensing Strategy

The project can use a layered licensing model.

Public

Portfolio screenshots and demo.

Restricted

Interactive access to selected layers.

Commercial

Full dataset/API/export.

This avoids the false choice between:

publish everything for free

and:

publish nothing.

Urban Atlas Publication

The same master dataset can produce a book/PDF product.

Example:

Region 1
├── Neighborhood A
│   ├── Profile
│   ├── Demographics
│   ├── Land Use
│   ├── Accessibility
│   └── D Form
│
├── Neighborhood B
│   └── ...

This could become a professional urban atlas.

Multi-Product Strategy

One master dataset can support:

                    MASTER DATASET
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
         Web GIS        API       Urban Atlas
            │
            ▼
      Commercial Reports

This is a stronger publication strategy than simply uploading files.

Data Export

Controlled exports could include:

CSV
GeoJSON
GeoPackage
PDF
PNG
XLSX

Exports should respect access permissions.

Authentication & Access Control

If the project becomes commercial:

Potential roles:

Public Viewer
Research User
Licensed User
Administrator

Permissions can control:

layer visibility,
export,
API access,
high-resolution data.

Audit & Usage Tracking

For licensed access:

API requests,
export requests,
user sessions,

can be logged.

This is useful for:

licensing,
usage analytics,
abuse detection.

Watermarking

Generated PDF or image exports can optionally include:

user ID,
license ID,
timestamp.

This discourages unauthorized redistribution.

Privacy / Ethics

Neighborhood-level demographic publication should avoid exposing personally identifiable household data.

The atlas should remain aggregated at an appropriate geographic level.

Performance

Large map applications need careful performance design.

Potential strategies:

vector tiles,
spatial indexes,
caching,
simplified geometries,
lazy layer loading.

PostGIS Indexing

Spatial indexes should be applied to geometry columns.

Example:

CREATE INDEX ... USING GIST (geometry);

This is critical for spatial queries.

Caching

Redis can cache:

popular neighborhood profiles,
layer metadata,
comparison results.

Large tiles should be cached separately where appropriate.

Security

A production deployment should include:

HTTPS,
RBAC,
signed URLs for private assets,
API rate limiting,
secure object storage,
audit logging,
database backups.

Data Import Pipeline

The historical dataset should not be manually entered again.

A V2 migration pipeline should:

Original Data
     ↓
Parse
     ↓
Normalize
     ↓
Validate
     ↓
Transform Geometry
     ↓
Load PostGIS
     ↓
Quality Check

Source Document Preservation

Original PDFs, maps, and source files should be preserved as immutable source artifacts.

Derived structured data should reference its source.

Example:

demographic_snapshot
    ↓
source_document_id

Testing Strategy

Data Tests

required indicators present,
population totals valid,
percentages in range,
area values positive.

GIS Tests

geometry valid,
no unintended self-intersection,
CRS known,
boundaries render correctly.

Application Tests

region selection,
neighborhood selection,
layer switching,
comparison,
export permissions.

Reproducibility

A major goal of V2 should be:

every generated map can be regenerated from structured data.

Static screenshots should become outputs, not the source of truth.

Evidence Strategy

Current project evidence includes:

land-use maps,
accessibility maps,
sports-access maps,
school-access maps,
3D neighborhood visualization,
administrative-area maps.

Additional source PDFs would strengthen:

exact terminology,
original thresholds,
neighborhood descriptions,
source-year metadata,
legend definitions.

Evidence Status

Recommended website label:

Strongly Partially Verified — Multiple original maps and analytical outputs survive; the full source PDFs and structured dataset remain private and can be used internally to validate terminology, thresholds, and provenance.

My Role

My role includes:

collecting and structuring the source material,
designing the initial database,
extracting neighborhood statistics,
organizing administrative relationships,
working with map-based source data,
structuring land-use information,
organizing accessibility analyses,
preserving 3D urban-form information,
designing a modern GIS publication strategy,
and planning the migration from static maps into a structured geospatial platform.

What Makes This Project Strong

This project is not a collection of screenshots.

Its value comes from combining:

TABULAR DATA
+
GEOMETRY
+
MAP LAYERS
+
DERIVED ANALYSIS
+
VISUALIZATION

The source material can therefore support:

research,
comparison,
interactive mapping,
API products,
commercial datasets,
urban reports.

Career Evidence

This project demonstrates:

GIS Architecture
PostGIS
Spatial Data Modeling
Urban Analytics
Data Engineering
Geospatial Visualization
Accessibility Analysis
3D Mapping
Data Versioning
Dataset Productization
Research Software
Information Architecture
Commercial Data Strategy

CV Relevance

Tier A/B — Major Data & GIS Portfolio Project

This project is relevant to:

GIS Engineering
Data Engineering
Backend Architecture
Spatial Databases
Urban Analytics
Data Visualization
Research Software

It is particularly strong because it demonstrates the transition from:

static source material

to:

structured geospatial platform

Interview Story

Situation

I had accumulated a large set of urban-planning data and maps for Mashhad.

Initially, I tried to treat it as a normal database project.

Task

The challenge was to organize demographic statistics, land-use maps, accessibility analysis, neighborhood profiles, and 3D urban-form information in a way that could actually be queried and published.

Action

I structured the data around regions and neighborhoods and began separating tabular statistics from spatial/map information.

The modern redesign moves the project toward PostgreSQL/PostGIS, spatial APIs, interactive web mapping, versioned layers, and controlled publication.

Result

The project evolved from a simple database concept into a geospatial urban atlas capable of supporting interactive analysis, commercial data access, API delivery, and publication as a structured urban atlas.

Suggested Website Full Description

Overview

Mashhad Urban Atlas is a large personal geospatial-data project covering neighborhood-level urban information for Mashhad.

The source material combines demographic statistics with maps and spatial analyses.

Data Coverage

The dataset contains information such as:

population,
neighborhood area,
density,
households,
literacy,
sex ratio,
male/female population,
land use,
service accessibility,
neighborhood structure,
3D urban form.

Spatial Analysis

The project includes accessibility analysis for:

primary schools,
green spaces,
clinics,
bus stops,
mosques,
sports facilities.

These layers allow neighborhood service coverage to be compared spatially.

Publication Strategy

The full master dataset is not currently released publicly.

The preferred future model is:

public portfolio,
limited interactive demo,
controlled API access,
commercial dataset licensing,
publication as an urban atlas.

This preserves the dataset as an asset while still demonstrating the project publicly.

Version 2

The modern rebuild uses:

PostgreSQL,
PostGIS,
Laravel,
MapLibre,
spatial APIs,
vector tiles,
object storage,
versioned data layers.

The objective is to turn static source maps into queryable geospatial data and reproducible visualizations.

Short Website Card Copy

Mashhad Urban Atlas — Geospatial Data & Urban Analytics Platform

A neighborhood-level urban atlas combining demographics, land use, service accessibility, geospatial layers, and 3D urban-form analysis for Mashhad.

Alternative One-Liners

GIS-oriented

Built a neighborhood-scale geospatial dataset combining administrative boundaries, land use, demographics, accessibility layers, and urban-form visualization.

Data-oriented

Structured a large Mashhad urban-planning dataset into a region/neighborhood analytical model suitable for PostGIS, APIs, and controlled publication.

Product-oriented

Designed a private urban-data asset that can be delivered as an interactive Web GIS, API, licensed dataset, or multi-volume urban atlas.

Visualization-oriented

Combined demographic indicators with accessibility maps, land-use layers, and 3D neighborhood models in a unified urban atlas.

Suggested Website Slug

/projects/mashhad-urban-atlas

Alternative:

/data/mashhad-geospatial-urban-atlas

Cover Direction

Title

Mashhad Urban Atlas

Subtitle

Geospatial Data & Urban Analytics Platform

Supporting Line

Demographics · Land Use · Accessibility · 3D Urban Form

Visual Direction

A premium square data/GIS cover showing:

a stylized Mashhad map,
neighborhood boundaries,
colored land-use polygons,
service-accessibility rings,
demographic charts,
3D extruded buildings,
GIS layer controls,
spatial-data nodes.

The cover should communicate:

CITY
+
DATA
+
MAPS
+
ANALYTICS
+
3D

Avoid presenting the work as a generic database or spreadsheet project.

Evidence Gallery Recommendation

Maps

land-use map,
primary-school accessibility,
sports-facility accessibility,
neighborhood structure.

Analytics

population / area comparisons,
accessibility charts,
demographic tables.

3D

building-height model,
neighborhood 3D visualization.

V2

interactive MapLibre viewer,
PostGIS schema,
neighborhood dashboard,
comparison mode.

Optional Source PDF Enrichment

A source PDF is not required to publish the first strong version of this portfolio page.

However, one representative PDF would be very useful for a second pass because it can help verify:

exact field names,
planning terminology,
accessibility thresholds,
map legends,
administrative labels,
source dates,
neighborhood descriptions,
data provenance.

The PDF should be used to refine the structured schema and evidence section rather than to change the overall architecture described here.

Final Portfolio Statement

Mashhad Urban Atlas began as a database project.

The source material proved that the real problem was much larger.

The data was not only rows and columns.

It contained:

PEOPLE
+
PLACES
+
BOUNDARIES
+
SERVICES
+
DISTANCES
+
LAND USE
+
URBAN FORM

The correct solution is therefore a geospatial platform.

The modern objective is to transform the existing maps and statistics into a structured, versioned, queryable urban atlas without giving away the master dataset.

That creates multiple future products from one data asset:

PRIVATE MASTER DATA
        ↓
 ┌──────┼────────┬────────┐
 ▼      ▼        ▼        ▼
Web GIS API   Urban Atlas Commercial Reports

The strongest interpretation of this project is:

not a database of maps, but a geospatial urban-data platform.

Tags: Data Analysis Data Engineering GIS