Geospatial & GIS Data

A geographic information system is, at heart, a way of holding information so that every record also knows its place on the Earth. A spreadsheet of streetlights is just a list; give each row a location and load it into a GIS and suddenly you can ask spatial questions - which lights are within 50 metres of a bus stop, which fall inside a ward boundary, which cluster where crime is reported. That ability to ask 'where' and 'what is near what' is the core power a twin inherits from GIS, and it is why geospatial data is the true backbone of an urban digital twin rather than a nice-to-have.

GIS organises the world into layers - thematic slices of reality that can be stacked and overlaid. One layer holds the road network, another the building footprints, another the parcels, another the terrain, another the land use, another the trees. Each layer can be switched on or off, styled, queried and analysed on its own, yet because every layer is tied to the same coordinates they line up precisely when stacked. The twin, in a real sense, is this stack made three-dimensional and then brought to life with data: the GIS layers give it the true positions and shapes, and the live feeds (next lesson) give it a pulse.

The reason layering matters so much is that a city is not one dataset but dozens, each collected by different people for different reasons at different times. The water utility holds pipes; the revenue department holds parcels; the transport authority holds roads; the forestry wing holds trees. A GIS lets these coexist and align without forcing them into one monolithic file. The discipline of keeping each layer clean, current and correctly located is the daily work of municipal GIS teams, and it is invisible when done well and catastrophic when done badly - a twin built on a misaligned parcel layer will confidently tell you a building sits on land it does not. For a designer, the lesson is humility: the map you are handed is a construction, assembled layer by layer by many hands, and its quality varies layer by layer. Knowing which layers in a twin are reliable and which are rough is a core professional skill, not a technicality.

Geospatial data comes in two fundamental flavours, and knowing the difference is one of the most useful pieces of literacy a designer can carry into a twin project. The first is vector data: the world described as discrete shapes - points, lines and polygons - each carrying attributes. A tree is a point with a species and a trunk diameter; a road is a line with a name, a width and a surface; a parcel or building is a polygon with an owner, a use and a height. Vector data is crisp, light, and queryable: because each feature is a named object with attributes, you can select it, measure it, and reason about it. Most of the things a twin treats as objects - buildings, roads, parcels, utilities - live as vector data.

The second flavour is raster data: the world described as a continuous grid of cells, each holding a value. A satellite image is a raster where each cell is a colour; a digital elevation model is a raster where each cell is a height; a heat map, a rainfall surface, a pollution plume are all rasters where each cell is a measured or modelled quantity. Raster is the natural home for anything continuous and field-like - imagery, terrain, temperature, noise - and for the products of remote sensing and satellites. It is heavier than vector and does not carry named objects, but it captures texture and gradient that vector cannot.

Real twins use both, constantly, and the art is matching the model to the phenomenon. You would store the city's buildings as vector polygons so you can click one and read its use, but drape a raster aerial image over the terrain so the scene looks real. You would hold the road centrelines as vector lines for routing, but a raster surface for the urban heat island. A frequent beginner error is forcing one model onto data that wants the other - rasterising crisp parcel boundaries until they blur, or trying to store a smooth temperature field as thousands of tiny polygons. Understanding that these are two complementary representations, each with a proper job, lets you read what a twin is actually built from and judge whether its makers chose well. It also explains why twins are data-heavy: a single high-resolution raster layer over a whole city can dwarf all the vector data combined.

The single most common reason geospatial layers fail to overlay correctly is the coordinate system - the mathematical frame that says what a pair of numbers means on the real Earth. The Earth is a lumpy, not-quite-spherical body, and to put locations on a flat screen we first model its shape (a datum) and then flatten it (a projection). A coordinate reference system, or CRS, bundles these choices together. Global latitude and longitude (on the widely used WGS 84 datum, the one satellite positioning speaks) is one family; national and local grid systems that project the country onto a flat metric grid are another. There are thousands of them, each right for some purpose.

The trap is that two layers can each be perfectly correct yet refuse to align, because they are expressed in different coordinate systems. Load a building layer in a national grid and a road layer in latitude and longitude without telling the software, and the city will appear to tear in two, or shrink to a dot near the equator. Every serious geospatial workflow therefore spends real effort on getting all layers into a common, declared CRS - a step called reprojection - and on recording which CRS each dataset is in. A twin that silently mixes coordinate systems is a twin that silently lies about where things are, sometimes by metres, sometimes by kilometres.

There is a deeper honesty here too. A projection always distorts: you cannot flatten a curved Earth without stretching area, or angle, or distance somewhere. The familiar web map that most twins use exaggerates the size of places far from the equator; a grid chosen for a city will be accurate locally but wrong far away. None of this matters for a neighbourhood twin if handled consistently, but it means that a twin's geometry is always an approximation of position, not the position itself - another reminder that the model is a purposeful simplification. For a designer, you do not need to compute projections by hand, but you must know to ask: what coordinate system is this twin in, are all its layers in the same one, and how accurately does it actually sit on the ground? Where precise, legally meaningful position matters - a boundary, a setback, an alignment - that question goes to a licensed surveyor and the official grid, not to the twin.

Not all geospatial data is equal, and the most important distinction a designer can learn is between working data - good enough to explore, visualise and reason with - and authoritative data - the legal record of where a boundary, a parcel or a benchmark truly is. A twin is full of working data: footprints traced from imagery, roads from open maps, heights estimated from models. That is fine for understanding and design exploration. But the moment a question becomes binding - where exactly does this plot end, how far must the building set back, who owns this strip - the answer does not come from the twin. It comes from the authoritative custodians of that data.

Two categories anchor this. The base map is the reference backdrop - the surveyed framework of control points, terrain, major features and the national grid onto which everything else is registered. The cadastre is the official register of land parcels: their boundaries, extents and ownership, maintained for legal and revenue purposes. These are not hobby datasets; they are maintained by state agencies under law, and in India the national mapping and geodetic authority is the Survey of India, with land records held by state revenue departments and their digitisation programmes. A spatial data infrastructure (SDI) - the shared standards, catalogues and policies that let agencies publish and find each other's authoritative layers - is what stitches these custodial datasets into something a city can actually use together.

The professional discipline follows directly. Use open and working geospatial data freely to build, test and visualise a twin; but treat the cadastre, the official survey and the legal base map as the data of record, and defer to their custodians for anything binding. Never let a twin's convenient, traced geometry stand in for a surveyed boundary in a decision that affects someone's land or rights. This is not timidity; it is how the system is designed to work, and it protects both the public and you. It also carries an equity edge this course keeps returning to: official data best covers the formal, surveyed, titled city, and under-represents the informal settlements and unsurveyed fabric where millions live - so a twin built only on authoritative layers can render the informal city invisible. Knowing where authority lives, and where it runs out, is the mark of someone who can use geospatial data responsibly.