There are only two ways to write the world into a file. Either the world is a set of discrete things that have coordinates, or it is a surface whose value can be sampled anywhere. Everything in geospatial storage is one of those two, and the choice made at the start of a pipeline determines what questions can be answered cheaply at the end of it.
The first model is vector: a road is a sequence of coordinate pairs, a parcel is a closed ring, a fire hydrant is a single point, and each carries attributes attached to that identity. The second is raster: space is cut into a regular grid, and every cell holds a value, whether that value is a reflectance measurement from a satellite sensor, an elevation, a rainfall estimate, or a class code produced by a model.
Neither is a more advanced version of the other. They encode different assumptions about what exists. Vector assumes the world is made of objects with edges. Raster assumes the world is a field that varies over space and has a value everywhere. Most of the confusion in practical work comes from data that was captured under one assumption being used under the other.
Discrete objects against a continuous field
A vector dataset is a list of features. Each feature has a geometry made of explicit coordinates and a record of attributes. The geometry is exact in the sense that it means precisely what it says: this polygon has these seven vertices and no others. Nothing exists between the features. The space around a building footprint is not empty in reality, it is simply not represented, and a vector file has no way to distinguish those two situations.
A raster is an array plus a small amount of metadata that pins the array to the ground: the coordinates of one corner, the size of a cell in ground units, the number of rows and columns, and the coordinate reference system. Every cell has a value or is flagged as no data. There is no such thing as a gap in the middle of a raster, only cells whose value is unknown, and that distinction is carried explicitly.
The consequence is that the two models answer different questions natively. A vector store can tell you which parcel a point falls in, how many restaurants are on a street, or whether two administrative areas share a border, because identity and topology are first class. A raster can tell you the slope at a location, the average rainfall over an irregular area, or how much a surface changed between two dates, because it holds a value everywhere and arithmetic between grids is well defined.
Where each one is strong
Vector handles identity, attributes, and relationships. If the analysis needs to name the thing, follow it over time, attach a hundred fields to it, or ask whether it touches something else, vector is the representation with an answer. Networks in particular are vector by necessity: a routing graph is built from linear features with connectivity at shared nodes, and there is no raster encoding of a turn restriction.
Vector is also resolution independent in a specific sense. A polygon boundary defined by coordinates can be drawn at any zoom without becoming blocky. That is not the same as being accurate at any zoom, which is a separate and often overstated claim, but the geometry itself does not degrade with display scale.
Raster handles continuous phenomena and heavy per pixel computation. Elevation, temperature, land surface reflectance, population surfaces, noise, and probability fields are all naturally raster because they have a value everywhere and no natural edges. Operations across layers, adding, differencing, thresholding, masking, are simple array arithmetic when the grids align, and array arithmetic runs at a speed no polygon operation approaches.
Raster is also the native output of sensors. A satellite instrument produces a grid because it samples on a grid. Anything that arrives as an image, from a satellite scene to a drone orthophoto to a scanned historic map, starts as raster whether or not that is convenient.
Cost scales with different things
This is the practical difference that surprises people building their first pipeline.
Vector size scales with the amount of content. An empty region costs nothing: there are no features, so there are no bytes. A dense city center with every building, every path, and every address costs a great deal. A country file is therefore lumpy, with most of its weight concentrated in a small fraction of its area, and query performance depends heavily on the spatial index and on how features are clustered on disk.
Raster size scales with area and resolution, and content is nearly irrelevant. A grid covering an ocean at ten meter resolution costs the same as a grid covering a metropolis at ten meter resolution, because both have the same number of cells. Halving the cell size quadruples the storage. This quadratic relationship is the single most important number to keep in mind when someone requests finer resolution: a request to go from thirty meters to ten meters is a request for roughly nine times the data, not three times.
The rules of thumb that follow are worth stating. When most of the study area is empty of the features of interest, vector wins on size by a wide margin. When the phenomenon exists everywhere, raster wins, because encoding a value at every location as vector polygons produces an enormous number of tiny features. When a raster is mostly one value, compression closes much of the gap, but the uncompressed working set during processing does not shrink.
Resolution is a promise, and resampling breaks it
A raster's cell size states the ground distance one cell covers. It does not state that the values are accurate at that scale, and the difference between those two claims is where most silent error enters.
Every raster has a native resolution, the one at which it was actually measured. It also has a current resolution, the one it has after whatever processing it has been through. Resampling changes the second without changing the first, and nothing in the file format records that the two have diverged.
Upsampling is the dangerous direction. Take a coarse grid, resample it to a fine grid, and the result looks detailed. Each new small cell has a value. Nothing in the pixel values announces that those values were interpolated from a much coarser measurement. Overlay that on a building footprint layer and it will appear to say something about individual buildings when the underlying measurement could not distinguish one city block from another. This is false precision with a visual presentation that actively reinforces the mistake.
Downsampling loses information, which is honest, but the method matters. Averaging is appropriate for continuous quantities. Nearest neighbor is required for categorical grids, because averaging class codes produces meaningless intermediate values: the average of class 3 and class 5 is not class 4 in any sense that matters. Majority resampling is usually the right choice for categories that need aggregation, and it still discards minority classes systematically, which biases any subsequent area statistic against rare classes.
The defensive practice is to carry native resolution as metadata separate from current resolution, and to refuse to answer questions at a scale finer than the native measurement regardless of what the current grid supports.
Converting between the two, and what each direction destroys
Rasterizing vector data means burning features onto a grid. Every cell is assigned a value based on the features that fall in it. The information lost is identity and exact boundaries. Two adjacent parcels with the same land use become indistinguishable. A road becomes a band of cells with no connectivity: the graph is gone, and no amount of raster processing will recover the fact that two segments met at a junction. Small features vanish entirely if they do not cover enough of a cell to be assigned, which means a rasterized count is not the same as the vector count, and the discrepancy grows as cells get larger relative to the features.
Vectorizing raster data is the direction that gets misunderstood. Tracing polygons around regions of equal value is a mechanical operation, but tracing meaningful objects out of imagery is not a format conversion at all. It is a modeling step. A model looks at pixels and proposes that a particular group of them constitutes a building, a field, or a water body. The output looks exactly like surveyed vector data: clean polygons with attributes, in the same file format that a cadastral extract would use. It is not the same kind of thing. Each polygon is a hypothesis with a probability attached, and the probability is usually discarded at the moment of export.
This is the most consequential loss in the whole pipeline, because it is a loss of epistemic status rather than of geometry. Once a predicted footprint sits in the same table as a surveyed footprint, nothing downstream can tell them apart. The mitigation is unglamorous: keep the source and the confidence as attributes on every derived feature, never merge predicted and surveyed layers into one table without a discriminating field, and treat any count over a derived layer as an estimate with a stated recall and precision rather than as a census.
Vectorization also imposes edges on things that do not have them. A raster of vegetation density has no boundary in reality, only a gradient. Thresholding it produces a polygon with a crisp edge that is an artifact of the threshold. Move the threshold slightly and the area changes, sometimes substantially. Reporting that area as though it were measured is a quiet fabrication.
Choosing by the question, not by preference
A short decision procedure covers most cases.
- If the question names individual things, use vector. Counting, identifying, routing, joining attributes, checking membership: these need identity, and identity is what vector has.
- If the question is about a quantity that exists everywhere, use raster. Slope, exposure, temperature, distance surfaces, change between dates.
- If the question mixes both, which most real questions do, keep each layer in its native model and do the crossing explicitly with zonal statistics: summarize raster values within vector boundaries. This is the workhorse operation of applied analysis, and it preserves both models rather than forcing one into the other.
- If a conversion is unavoidable, convert as late as possible and record the conversion. Early conversion locks in a loss that every later stage inherits.
The failure of preference over fitness usually looks like a team with strong raster tooling forcing a network problem into a grid, or a team with strong vector tooling representing a continuous surface as thousands of small polygons. Both work, badly, and both are much slower than doing it the other way.
Formats, and why cloud optimization matters
The common vector containers are GeoJSON for interchange and small payloads, GeoPackage as a single file database with proper indexing, Shapefile as a legacy format still everywhere despite its field name limits and multi file structure, and columnar formats such as GeoParquet for analytical workloads over large tables. For map delivery, vector tiles cut features into a pyramid of small pre generalized chunks so a client only fetches what is on screen.
The common raster containers are GeoTIFF and its cloud optimized variant, plus chunked array formats for multidimensional stacks where time is a dimension alongside the spatial axes.
Cloud optimization deserves the emphasis it gets. A traditional raster file must be downloaded in full before anything can be read from it, which for a large scene means moving gigabytes to answer a question about a few hectares. A cloud optimized file is laid out so that a client can issue a ranged request for exactly the bytes covering the area and zoom level it needs. Internal tiling groups nearby pixels together so that a spatial subset is a contiguous read, and embedded overviews store pre reduced copies so a coarse view does not require reading full resolution data.
The practical effect is that an archive becomes queryable in place. Rather than building a pipeline that copies data into a local store before analysis, a service can read directly from object storage and pay only for the bytes it uses. For an API answering small area questions against global coverage, this is the difference between feasible and not. The same idea has spread to vector, where single file tile archives allow the same ranged access pattern for feature data.
The failure that ships
The one that causes real damage is losing track of which representation a number came from, and then comparing numbers that were never comparable.
A concrete version: a report states that district A has 4.2 square kilometers of built area and district B has 3.1. The first figure came from summing vector building footprints. The second came from counting cells in a classified raster and multiplying by cell area. These measure different things. The footprint sum counts roof outlines and excludes the yard, driveway, and the road; the raster class counts every cell whose dominant signature was built, which includes paved surfaces and any cell where a building covered enough of the area to dominate. The raster figure is also sensitive to cell size in a way the vector figure is not: at coarse resolution, scattered rural buildings either disappear or inflate to a full cell each.
Neither number is wrong on its own terms. Placing them in the same column and subtracting them produces a difference that is mostly method, not geography. The same trap appears with population counts from a gridded surface compared against administrative totals, elevation differences between two products with different native resolutions, and area figures computed after two different resampling steps.
The rule that prevents it: a figure is not comparable to another figure unless both carry the same representation, the same native resolution, and the same operational definition. Store those three alongside the value, all the way through to presentation. A number that has lost them is not a measurement anymore, it is a rumor with decimals.