TopoJSON localization is different from translating a normal geographic JSON file. A TopoJSON topology stores shared boundary arcs so adjacent regions can reuse the same underlying lines. The visible region names, descriptions and data legends may need another language, but an arc index or transform value is part of the geometric evidence. Change that value unintentionally and a boundary can reverse, detach or draw incorrectly.
People searching for a TopoJSON format explanation, how to translate TopoJSON properties, why negative arc indexes matter, how quantized coordinates work or how to preserve shared Polygon boundaries are asking several related questions. This guide joins them into one practical method. It explains the encoded structure before turning to safe multilingual publishing and quality assurance.
The discussion is written for international educators, translators, GIS analysts, data journalists, visualization engineers and publishers. Its purpose is to help readers distinguish geographic topology from human-language labels, test a localized result and communicate limitations. It complements the GeoJSON interchange guide without treating the two formats as identical; the examples are simplified and should be checked against the actual dataset and receiving application.
Why TopoJSON was designed
Imagine a map with two neighboring districts. A conventional representation may store a copy of the shared boundary for each district. TopoJSON instead can represent the border as an arc that both geometries reference. This can reduce duplication and help preserve exact shared edges when the topology is constructed correctly. The benefit becomes especially important for many adjacent polygons. A language editor who sees an array of numbers may not immediately recognize it as a reference to shared geometry. That is why translation must begin with an explanation of the representation, not an attempt to replace every familiar-looking string.
Topology is a relationship, not a style
A map can be drawn in thousands of colors and languages while retaining the same topology: which regions are adjacent, which lines connect and which boundaries are shared. TopoJSON emphasizes that underlying relationship. Translating a label from English into Spanish or Tamil does not justify altering adjacency. Similarly, changing the fill color of a district is not proof that the border data has been preserved. Treat topology, visual styling and human language as distinct layers. A useful review can check each one separately and then examine how they interact in the final map.
The outermost object is a Topology
A TopoJSON file starts with an object whose type value is Topology. This object has named objects containing geometry and an arcs array holding shared coordinate sequences. It may also contain a transform and bounding-box information. The literal type values and member names are part of the format. A translator should not change type into a target-language equivalent or rename arcs to a more descriptive phrase inside the serialized data. Human explanations can use local terminology, but software depends on the original vocabulary. First identify the Topology and its members; then classify which strings are actual display content.
Understand objects before deciding what to translate
The objects member is a map of names to geometries, often including GeometryCollections. An object name may serve as a programmatic reference used by visualization code, even if it resembles a natural word such as districts or regions. If code asks for topology.objects.districts, renaming that key can break the whole application. Geometry properties, by contrast, may contain translated titles or descriptions when the schema allows. Build an inventory that distinguishes object keys, geometry properties and application-generated text. Do not assume they are all public labels simply because they appear in the same JSON document.
Shared arcs are the heart of the format
An arc is an ordered sequence of positions. Polygons and LineStrings in TopoJSON refer to arcs by index rather than storing their full coordinate sequences directly. Two neighboring polygons can point to the same arc in opposite directions along a shared border. A reviewer who treats the index as a numerical label might inadvertently change it while translating a nearby property. That can replace the intended border with an unrelated one. Preserve the arcs array and every reference to it unless a separate geometry-processing operation has been specifically authorized and tested.
Why a negative arc index is not a negative position
In TopoJSON, a negative arc index indicates a reversed reference to an existing arc. The convention uses the bitwise complement of the index: -1 denotes the first arc in reverse order, -2 the second, and so on. This is not the same as a negative longitude, a negative latitude or an invalid array subscript. Someone looking at the number -1 may instinctively interpret it as “one less than zero,” but here it is a compact direction instruction. Never normalize signs or reorder arc indexes during language work. A single sign change can alter the shape of a polygon.
Shared boundaries reduce duplicate linework
If two regions use the same arc, a corrected position on that arc can affect both boundaries. This property makes TopoJSON efficient and coherent, but it also creates shared risk. Editing a line as though it belongs to only one region may alter the neighboring region too. For translation, the conclusion is straightforward: do not edit arc geometry in the language pipeline. If a cartographer needs to correct a border, they should work with source geometry, rebuild the topology and document the spatial revision. Language reviewers can compare final maps but should not be made responsible for undocumented boundary changes.
Quantization describes a coordinate conversion
A quantized TopoJSON topology may include a transform with scale and translate arrays. The stored integer positions are transformed into geographic or projected coordinates through multiplication and addition. This mechanism allows more compact representation. However, the integer values are not human-language numbers to be reformatted for a locale. Introducing a decimal comma or changing a minus sign can break reconstruction. If a map appears in the wrong place, the issue may involve coordinate transformation rather than translation. Keep the transform unchanged during localization and inspect it separately when validating geometry.
Delta encoding stores differences
When a quantized topology uses delta encoding, later points on an arc often represent changes from previous positions rather than absolute coordinates. A sequence of small integers may therefore describe a long line after the deltas are accumulated and the transform is applied. Reading those integers as independent longitude and latitude values is wrong. A translator does not need to reimplement the decoder, but should know that editing an apparently harmless number changes all later positions in the reconstructed arc. A safe localization export compares the original and new arcs arrays without transforming or rewriting them.
Decode before you interpret a location
Suppose a reader sees arc positions [100, 20], [1, 0], [0, 2]. In a delta-encoded representation, the later pairs are relative increments and do not individually describe geographic positions. An appropriate decoder reconstructs absolute quantized values and then applies the transform. That is what the visualization system needs in order to plot the map correctly. Avoid putting a guessed physical location into translated explanatory text based on raw stored integers. Whenever a guide needs a place description, use the decoded feature geometry and a trusted geographic reference, not the compressed storage notation.
GeometryCollections can contain mixed shapes
A GeometryCollection may contain Points, MultiPoints, LineStrings, MultiLineStrings, Polygons and MultiPolygons. Points typically carry coordinates, while line and area geometries may refer to arcs. This variation affects how a localization checker should work. It cannot assume every object contains the same coordinates field. It should understand the geometry type before deciding what must remain identical. For example, translating a museum label in a Point may require only a property update. Translating a regional map might touch the properties of several Polygon objects while preserving their nested arc references. Structure determines the appropriate protection rule.
Polygon holes are more than nested lists
A Polygon may include an exterior ring and additional rings representing holes. Those rings are built from arc references. A hole might represent a lake excluded from a land area, a protected enclave or another geographic exception. If a nested array is moved or removed while editing properties, a hole may fill in or turn into a separate outline. The resulting picture may still look plausible at low zoom. For this reason, geometry comparison should check ring structure and arc references, not merely the presence of a picture on screen. A language edit is not complete if it has subtly changed area membership.
MultiPolygons require careful nesting
A MultiPolygon represents multiple polygons, each of which may have rings. TopoJSON encodes these relationships through nested arrays of arc references. The depth of nesting is meaningful. An array of two island polygons is not the same as a single polygon with an interior hole. A generic text editor or careless transformation script may change nesting while trying to simplify punctuation. Never serialize arbitrary structure through a translation service that treats brackets as expendable formatting. Keep translated strings in a separate extraction workflow, then reinsert them into the original object structure with a parser.
Reversed arcs preserve shared edge direction
When adjacent polygons follow a shared border in opposite traversal directions, they can reference one arc with opposite orientation. That is a natural consequence of representing closed boundaries. If a reviewer removes the reverse marker because it looks like a mistake, one polygon may use the wrong traversal. The resulting geometry can become malformed or visually inconsistent. A useful training exercise shows two simple neighboring squares sharing a line and illustrates how both shapes can reference it. The learner should finish understanding that the sign of an arc reference is data, not typography.
A named object may have a public-facing title elsewhere
A topology might contain an object named census_areas_2024. The application’s map title could be “Population by District” and may be translated independently. Those two names serve different purposes. The object key can be a programming contract, while the visible heading is editorial language. An international publisher should preserve the object key and manage translated headings in a language catalog or dedicated display field. If the application absolutely requires a localized key, treat the change as a versioned API migration with code and tests, not a simple translation. Making this distinction early saves rework later.
Properties have no universal multilingual convention
TopoJSON geometry properties can include ordinary JSON values, but the format itself does not prescribe a single scheme for language variants. One project may keep an official_name field and a separate translation table. Another may store name_en and name_es alongside a stable id. A third might supply a separate localized dataset. Each approach can be reasonable if clients understand it. Choose an arrangement that preserves the original authority, supports fallback and keeps features aligned. Document how missing translations are represented rather than inserting a made-up localized name to fill an empty display box.
Protect feature IDs and join keys
Data journalism frequently joins TopoJSON shapes to a statistical table through a region code. A code like 0012 might look like a number or word fragment, but it is usually an identifier. Stripping leading zeros, changing case or replacing a local abbreviation can break the join. The map may then show missing data, incorrect colors or no tooltip at all. A localization checklist should mark these fields as protected and compare them byte for byte where appropriate. Add human-readable translated names alongside them instead of rewriting the unique identity that the visualization relies on.
Stable identifiers make multilingual publishing cheaper
When a feature’s identity remains stable, an editorial team can translate a headline once, associate it with that ID and reuse it across map views. Updates to a chart’s styling need not disturb the translations. Conversely, if names are used as join keys, every language variant risks becoming a new and inconsistent identifier. A good data design separates code from presentation: an immutable region identifier for joining and language-specific text for readers. This is useful even in small school maps. It teaches that a label describes a thing, while an identifier helps systems find the same thing repeatedly.
Proper names need an explicit policy
Political units, rivers, mountains and indigenous places may have several names across languages. An externalized language catalog can store official endonyms, customary exonyms or transliterations as appropriate. However, translating a feature label should not imply that a place has changed sovereignty or legal boundary. A regional map may need the source agency and date recorded alongside the naming rule. In contested contexts, reflect the map’s published scope and make attribution visible rather than treating a single translation as a universal authority. Careful terminology is part of public trust, especially when geographic labels carry historical or legal meaning.
Keep numeric properties exact
A TopoJSON data file may contain population totals, percentages, rainfall, survey counts or administrative codes in its properties. Values used in visual scales are often compared against raw numeric thresholds. Formatting 0.25 as 25 without changing the scale definition changes the meaning. Converting a numeric value into a localized sentence may also break chart calculations. Keep raw values stable and format them at display time. If a dataset uses unit-specific measurements, document the unit separately. A localized legend can say “per 100,000 people,” but the underlying rate must still be computed according to the specified denominator.
Quantization is lossy and should be disclosed
Quantization rounds positions onto a discrete grid. This can reduce file size and stabilize certain topology operations, but it changes coordinate precision. A translated article should not claim that the rendered boundary is accurate to the centimetre merely because the source used precise measurements. The effect depends on how the topology was built and quantized. If exact engineering or cadastral boundaries are required, consult authoritative geometry rather than a simplified visualization export. Distinguish a cartographic representation from a legal survey record. Language localization must preserve that distinction in any explanatory text or data provenance.
Simplification is not translation
Map producers often simplify boundary geometry so files render quickly at a chosen scale. A simplified outline can retain the broad shape of a region while removing detailed bends. That is a geographic-generalization choice, not a language translation. If an editor compares two localized maps and sees fewer points, investigate whether the pipeline introduced simplification. Do not hide such a change under a label like “optimized for language.” When comparing localized versions, use the same geometric source and simplification settings. The user should be able to change languages without seeing the district outlines shift.
The bounding box is computed spatial metadata
A topology or geometry may include a bbox indicating coordinate extents. Its array order follows the underlying coordinate dimensions. Translators should not recalculate or reorder bbox values because their audience reads latitude first. A bounding box can help set an initial viewport, but it is not an invitation to invent a map frame. If a geographic subset is published as a new dataset, recompute its bounding box through a validated spatial process. If only labels change, the same bounding box should remain correct. This separation provides a simple quality check for accidental geometry modification.
Coordinate reference assumptions need evidence
TopoJSON describes positions but is not a universal agreement about every coordinate reference system a producer might use. Unlike the tightly constrained geographic interpretation in RFC 7946 GeoJSON, a TopoJSON source may need external context to establish whether positions represent longitude and latitude or a projected system. Document the coordinate reference assumptions before describing locations or distances. A translated label that says “metres” beside values actually expressed in degrees is misleading. Use an authoritative source data description and avoid converting values without a proper transformation. Coordinate literacy protects both the geometry and the words explaining it.
From TopoJSON to GeoJSON is a conversion
Some mapping workflows convert TopoJSON geometries back into ordinary GeoJSON features for use by other libraries. This involves reconstructing coordinates from arcs, decoding quantization where applicable and producing individual shapes. The output may be easier to inspect, but it can lose the compact shared-arc representation. Such a conversion is not itself translation and should have its own validation. If a localization tool can handle only GeoJSON strings, consider extracting property values without changing the TopoJSON structure. Do not use a format conversion casually when preserving shared topology is an explicit project requirement.
Translation should target the user interface intentionally
Imagine a choropleth map where each region has an official name, a numerical value and a color. The reader may see a title, legend, hover tooltip, data note and source attribution. Only some of those words may come from TopoJSON properties. The rest can be controlled by visualization code or editorial markup. Before translating anything, trace each visible phrase to its source. This prevents a common mistake: translating only the file’s property values while leaving the legend in the original language, or translating a machine code that was never meant to appear on screen.
Map legends may contain hidden quantitative assumptions
A legend label such as “low risk” depends on a defined category or threshold. Translating it into a stronger phrase like “safe” can overstate the source. A color palette that suggests urgency may also carry meaning beyond the words. Review the code-to-label mapping, numeric breakpoints and any statistical context. For example, a region in the lowest comparative risk category is not necessarily free of risk. A good localization preserves qualification and uncertainty in short phrases. The same map can be mathematically correct but communicatively wrong if categories become more absolute during translation.
A district-name case study
Consider a TopoJSON dataset with fifty administrative districts and an external table of education statistics. Each geometry has a stable id and a display name. A multilingual site wishes to add French and Arabic labels. The best initial decision is to preserve ids, objects, arcs and transforms while associating each id with verified language variants. After integration, compare fifty feature identifiers, all arc references and numerical data joins. Render the map at several scales and inspect right-to-left text. This approach delivers localized names without disturbing the shared boundaries or the underlying statistics that explain the map.
A river-network case study
A geography publisher uses TopoJSON to represent rivers and administrative boundaries. A river name may cross several local jurisdictions, and its conventional name may vary across languages. The rivers’ LineString geometry belongs to the geographic record, while the label policy belongs to editorial review. Translators should not split a river into new arcs merely because a name changes along its course; that is a separate geographic data question. If segments genuinely have different official names, represent that through sourced properties and precise segmentation upstream. Reviewers should check names against source authority and line continuity against geometry.
An election-map case study
An election map can rely on TopoJSON boundaries and vote totals joined by constituency codes. The terms majority, turnout and swing have technical meanings that differ from everyday impressions. A translation that changes “percentage points” into “percent” can mislead even while the colors look unchanged. A translation that strips leading zeros from constituency IDs can silently break joins. Maintain a locked numeric data layer, a verified boundary layer and a separately reviewed language layer. Confirm that every district still receives its intended data after localization, and record the election date and boundary vintage prominently.
A public-health map case study
A map showing rates of disease, vaccination or service access requires care with denominators, confidentiality and geographic scale. Shared topology can describe reporting regions, but it does not make those regions equally populated or epidemiologically comparable. Translate labels such as “rate per 1,000 residents” precisely and retain any suppression notes or uncertainty qualifiers. Do not change numerical values or region codes to match a target-language typography convention. Review whether small counts could identify individuals, and keep data policy separate from translation. A readable map should not promise certainty beyond the source evidence.
A classroom map case study
Students often start with a small map showing neighboring regions. A teacher can demonstrate that the same boundary appears in both polygons but is encoded once as a shared arc. Then students may translate names into several languages while leaving the arc references alone. By switching labels, they see the difference between geographic identity and linguistic presentation. A useful exercise asks them to identify a harmless property change and a harmful sign change on an arc index. This gives learners a concrete reason to respect technical syntax rather than treating localization as replacing words everywhere.
Build a field classification before translation
A practical table can classify TopoJSON content into five groups: format keywords, geometry arrays, stable codes, numeric measurements and translatable human descriptions. Add a sixth group for names requiring source authority. For each field, record whether the translator may edit it, who approves changes and how the result will be checked. This classification is more reliable than asking a language model to infer from text appearance. An identifier may look readable and still be protected. A full sentence may contain a number or placeholder that must remain exact. Field roles determine edit permissions.
Use a parser instead of find and replace
A text editor’s global replacement function cannot distinguish a display name inside properties from the same word inside an object key or file path. It also cannot understand nested geometry arrays. A safer workflow parses the JSON, selects approved property paths, exports values for translation and merges validated target strings back into the original structure. It preserves the rest of the object. This is not only a programming preference; it makes the review reproducible. When an unexpected field appears, the extraction rules can flag it rather than translating it blindly or silently ignoring it.
Compare arcs byte for byte where possible
If the localization task is strictly textual, the easiest spatial invariant is that arrays of arcs and transform parameters remain unchanged. Compare them directly after parsing and serialization. Some serializers reorder object keys or whitespace, so a full-file text diff can produce harmless noise. A semantic comparison focuses on the actual protected data. Also compare geometry-object nesting and arc-index sequences. An unchanged arcs array does not guarantee correct geometry if its references have changed. Make the comparison comprehensive enough to catch both direct coordinate edits and altered references.
Check geometry after decoding
A final rendering test can catch mistakes that raw structural checks might miss. Decode the topology, display representative polygons and inspect whether neighboring boundaries still line up. Choose difficult cases: small islands, narrow corridors, holes, multipart regions and features near the antimeridian. Compare original and localized versions using identical projection and map styling. If shapes differ, do not attribute the discrepancy to language. Investigate the conversion pipeline or dataset version. A visible overlay of both outputs is often persuasive evidence for stakeholders who do not read JSON but need confidence in the map.
Validate labels against their feature IDs
A translated label can be linguistically accurate yet assigned to the wrong region. This happens when a translation spreadsheet is sorted independently and then rejoined by row order. Never assume the nth translation belongs to the nth feature after a data transformation. Use stable IDs and explicit mapping, then sample-check important features. For high-stakes geographic content, compare labels against a recognized gazetteer or official data source. The correct language attached to the wrong territory is still a serious error. A reliable join procedure is as important as the translation itself.
Preserve the distinction between no translation and no data
A feature might have an empty description because the source record contains no description. It might have an untranslated description because the target language has not been completed. It might be intentionally hidden because publication is restricted. These states should not collapse into one blank string without explanation. Define fallback rules in the application, such as showing the verified source name with a language indicator. Do not fill missing fields with invented claims. This is particularly important for maps used by journalists, researchers and public authorities, who need to know whether an apparent absence reflects the dataset or the editorial process.
Handle right-to-left scripts in the renderer
Arabic, Hebrew and other right-to-left languages often mix with Latin region codes, percentages and dates. The TopoJSON file may contain valid Unicode while the web tooltip displays punctuation in an unexpected order. Preserve identifiers and numerical values in data; use the interface’s bidirectional-text controls to present them correctly. Test mixed-script labels at narrow mobile widths and with screen readers where relevant. The object-key names and arc arrays do not need translation to support these languages. The correct layer for addressing typography is the presentation component, accompanied by a target-language editorial review.
Translation memory should contain strings, not topology
Reusable terminology helps teams translate “population density,” “protected wetland” or “voting district” consistently. It should not reuse an entire serialized geometry object from a previous edition. Old geometry could have different arcs, names or statistical regions. Extract segments with their meaning and context, protect placeholders and IDs, and keep versioned geometry outside the translation-memory system. A language specialist can reuse an approved phrase while still checking its relevance to the new data. This division preserves both efficiency and the independence of the geographic source of truth.
Unit and number formatting belong to display rules
A tooltip might show 12.5 square kilometres in one locale and a localized decimal representation in another. The underlying numeric field should remain 12.5 in JSON, with any verified conversion handled by the application. Never introduce locale-specific punctuation into JSON numbers. More importantly, determine whether the measure is an area, rate, count or index before formatting it. Rounding a percentage and rounding a population total have different implications. A map can preserve perfect boundaries while misleading readers through a changed numerical unit. Check numbers and language together in the final interface.
Separate localization revisions from boundary revisions
Suppose a government redraws district boundaries at the same time an organization launches a new language. If both changes enter one opaque file release, reviewers may struggle to identify why map shapes and labels differ. Keep independent revision identifiers for the geographic source and for translations. Record which topology version each language release uses. If a boundary change requires new official names or statistical joins, treat those as coordinated but separately documented updates. This makes rollback and audit possible. It also avoids crediting translation work for geometry corrections that belong to another professional responsibility.
A nine-step production workflow
First, inspect the Topology object and identify its consumers. Second, validate JSON structure and geometry references. Third, record the original arcs, transform and feature IDs. Fourth, classify string fields by their roles. Fifth, establish naming, terminology and fallback policies. Sixth, translate only approved display content with context. Seventh, reinsert strings through a structured process, comparing protected data. Eighth, render both source and localized maps at representative scales. Ninth, obtain language and spatial sign-off and archive the versioned inputs. Each step produces evidence rather than a vague claim that the translation “looks fine.”
A helpful quality-assurance checklist
A reviewer should be able to answer whether the topology still has the same objects; whether every arc reference remains valid; whether signs and nesting are preserved; whether transforms are unchanged; whether IDs still join to external tables; whether numerical properties retain meaning; and whether labels are translated, attributable and contextually correct. If a map uses classification thresholds, check those too. Finally inspect the user journey, because a perfect file can still render clipped text or misleading legend entries. These checks divide responsibility sensibly: machines test invariants; qualified people test interpretation and public meaning.
Common error: translating object keys
The word states might appear as the name of an object containing all administrative regions. If visualization code accesses topology.objects.states, translating states into another language will make that code fail. The localizing editor may argue that the word is visible in the source file, but visibility in a file is not the same as visibility to the public. Keep keys stable and translate the map heading separately. If a data consumer requests language-specific object keys, treat this as a deliberate schema change that requires code updates, documentation and regression tests. Do not disguise it as a low-risk text edit.
Common error: interpreting arc signs as errors
An arc index of -3 can be a perfectly valid reference to the third arc in reverse direction. A well-meaning editor who removes the minus sign can change the geometry. Similarly, a formatter that transforms integers into decorative bullet numbers risks corrupting arrays. Protect arc references from translation and rich-text processing. Teach reviewers enough TopoJSON notation to recognize reversed references rather than flagging them automatically. A small visual demonstration often prevents more mistakes than a long warning list, because it shows why the sign exists and what the software would reconstruct without it.
Common error: confusing quantization with unit conversion
A transform’s scale array can contain very small numbers. It does not automatically describe a local distance unit to translate into miles or kilometres. Quantization is part of the representation used to reconstruct coordinates. Unit conversion, by contrast, concerns how measurements are interpreted or displayed. These operations occur at different layers. Before making any conversion, determine the source coordinate system and what the numbers actually represent. If a translation project’s only goal is to display names in another language, neither quantization nor geographic unit conversion should be touched. The correct outcome has unchanged topology.
Common error: trusting a screenshot alone
Two maps may look identical in a screenshot while hiding broken IDs or incorrect data joins. A boundary might shift by only a few pixels at one scale; an island may be omitted outside the viewport. Conversely, a different color palette could make unchanged geometry look substantially different. Combine visual overlays with structural checks and meaningful samples. For a district map, verify IDs, representative shared borders, multipart features and statistical labels. If any comparison fails, investigate before publication. A screenshot proves how one view looked at one moment, not that the dataset is intact.
Frequently asked question: can TopoJSON properties be translated?
Yes, when the property is genuinely human-facing text and the receiving software’s schema permits that change. Descriptions, approved display names and accessibility notes may be suitable candidates. But properties can also contain stable codes, numeric values or categorical tokens that must remain exact. Begin with a data dictionary and avoid a blanket rule. If the same dataset supports multiple languages, an externalized translation catalog or language-specific fields may be more robust than overwriting the source. Validate that all features still resolve to their intended translated labels.
Frequently asked question: is TopoJSON the same as GeoJSON?
No. They are related geographic JSON representations, but TopoJSON encodes shared arcs and topology rather than storing each polygon solely as independent coordinate rings. GeoJSON is standardized by RFC 7946 and has its own coordinate reference requirements. TopoJSON follows a different specification focused on shared spatial structures and efficient reuse. Some applications convert between them, but a conversion may change representation details. For localization, the practical consequence is that TopoJSON needs arc-reference and transform protection, while GeoJSON needs coordinate-array protection. Both need careful treatment of human-facing properties and identifiers.
Frequently asked question: should I translate an official region name?
Only according to a documented naming policy grounded in the relevant authority and audience. A geographic name may have an official local form, a recognized translation, an established exonym or no accepted target-language equivalent. Translators can preserve the official name and add an explanation where clarity requires it. Do not change the region’s ID or boundaries because of a naming choice. The map should communicate clearly which entity the label denotes. When naming is contested, attribution and context are more accurate than an unsupported claim that one term has universal status.
Frequently asked question: what is the minimum reliable review?
At minimum, parse the result; compare objects, arcs, transforms, IDs and numerical fields; render source and target maps with the same settings; and have a qualified reviewer examine names, legends, units and warnings in context. Important datasets may require more extensive testing against authoritative geographic records. No single step substitutes for all the others. A parser can pass a file with the wrong labels, while a language reviewer can approve a fluent tooltip attached to the wrong feature. Preserve evidence from both spatial and linguistic review, including the version tested.
What learners should remember
TopoJSON is a useful reminder that the meaning of a digital document includes more than the words inside it. A shared arc encodes a geographic relationship; a reversed index instructs software how to traverse it; a transform reconstructs positions; a stable feature ID connects a shape to other evidence. Those are not sentences awaiting translation. A well-localized TopoJSON map changes its public-facing language while keeping the same underlying relationships. That is the standard to aim for: understandable to more people without becoming a different map.
Official specification and next reading
The TopoJSON specification is maintained in the public repository at https://github.com/topojson/topojson-specification and explains topology objects, arcs, transforms and geometry types. Read the IETF GeoJSON specification at https://www.rfc-editor.org/rfc/rfc7946 to understand the companion interchange model and coordinate conventions. For the broader engineering challenge of translating map records without changing location meaning, consult the relevant GIS and geospatial governance guides. These sources answer related but distinct questions; the right reference depends on whether a project is editing TopoJSON, converting formats or managing authoritative geography.