Model Guidelines

These guidelines define the conventions for simplified road network models accepted by this repository.

1. General Principles

  • Models should represent the publicly accessible road network — streets, roads, paths, and other routes that can be traversed by pedestrians or vehicles.
  • Private roads, internal building corridors, and off-road tracks should generally be excluded unless it is a model with special intention or they form part of the public circulation network.
  • Models should be drawn at a scale and level of detail appropriate for the analysis. Over-segmentation and under-segmentation both reduce analytical value.

2. Model Types

Axial Model

  • Each line represents the longest line of sight and access through a convex space.
  • The full set of axial lines should form a complete coverage of the open space — every convex space must be crossed by at least one axial line.
  • Use the fewest and longest lines necessary to achieve full coverage.

Segment Model

  • Derived from axial maps by breaking lines at each intersection.
  • Each segment represents a single street section between two junctions.
  • Segments should not extend beyond junctions — each intersection must produce a break.

Road Centerline Model

  • Lines follow the centre of the road carriageway.
  • Dual carriageways may be represented as a single centreline or two separate lines depending on the analysis purpose.
  • Roundabouts should be simplified to their centreline geometry.

3. Topology Rules

  • Connections: Lines must intersect cleanly at shared endpoints. Near-misses (gaps of a few pixels) will be treated as disconnections.
  • Overlaps: Avoid overlapping or duplicate lines. Two lines occupying the same space create false connections in the graph.
  • Vertical overlap / grade separation: Where roads cross at different levels (e.g. bridges, underpasses, flyovers), lines should not intersect. Use a gap or offset to indicate that no connection exists at the crossing point. If your software supports unlinks, use them to explicitly mark grade-separated crossings.
  • Unlinks: If your model format supports unlink markers (e.g. depthmapX), use them to denote grade separations. Otherwise, ensure that lines representing roads at different levels do not share a node.
  • Dangles: Dead-end lines (cul-de-sacs, stub roads) are acceptable. However, unintended dangles caused by drawing errors should be cleaned up.
  • Self-intersections: A single line should not cross itself. Split self-intersecting lines at the crossing point.

4. Coordinate Reference System

  • Specify the original CRS when uploading. Common examples: EPSG:27700 (British National Grid), EPSG:4326 (WGS84).
  • For map visualisation on the site, .fgb files must be in EPSG:4326 (WGS84). Other formats will be converted during the publishing process.
  • If your model uses a projected CRS, the admin will handle reprojection — just state the original CRS accurately.

5. File Formats

  • .fgb (FlatGeobuf) — preferred format, used for direct publishing and map display.
  • .gpkg (GeoPackage) — accepted, converted to .fgb on publish.
  • .graph (depthmapX) — accepted, requires manual conversion by admin.
  • Shapefile (.shp + .dbf + .shx) — accepted via the multi-file upload.
  • MapInfo (.mif/.mid or .tab/.dat) — accepted via the multi-file upload.
  • Maximum file size: 100 MB.

6. Attributes

  • Attribute columns (e.g. integration, choice, connectivity) are preserved during upload and publishing.
  • If your model includes analysis results, these will be available for visualisation on the map viewer.
  • There is no required attribute schema — include whatever is relevant to your model.

7. Naming

  • Model titles are auto-generated from the city/area, year, and model type you provide (e.g. Central London-2023-Segment).
  • Use a specific area name — Central London is better than London if your model only covers a portion of the city.
  • The description field is for additional context: data source, coverage details, known limitations, etc.

8. Data Use, Citation & Watermarking

  • Published model data remains subject to the original source dataset license, attribution requirements, and any local access or reuse restrictions that apply to that dataset.
  • The repository does not relicense third-party road network data under a single platform license.
  • Users should credit the named contributor, the Road Network Models repository, and the original source dataset as required by the source terms.
  • Models are provided for research, education, and reproducibility purposes without warranty. Users are responsible for checking whether a model and its source dataset are suitable and lawful for their intended use.
  • Watermarking is employed to establish data provenance, support attribution of intellectual contributions, facilitate the identification of unauthorised redistribution, and promote correct citation of the original dataset. These measures strengthen transparency and reproducibility by enabling users to verify the origin and integrity of the data while preserving its analytical utility. The watermarking scheme is designed so that its effects on the underlying data are negligible relative to the scale and uncertainty inherent in the source observations, approximately 0.02% perturbation at the global average segment length of 50 metres.
  • A plain-text data use and provenance note is available at /license.txt. See also the takedown policy.

9. Review Process

  • All uploads are reviewed by an administrator before publishing.
  • Models may be rejected if they contain significant topology errors, missing data, or do not follow these guidelines.
  • If rejected, you will receive a reason and can re-upload a corrected version.

Cookies. This site sets a session cookie for login (and a site_pass cookie if the pre-launch gate is enabled). Cloudflare, which serves the site, automatically sets bot-protection cookies (__cf_bm, cf_clearance). No analytics, advertising, or tracking cookies are used.