Travel Mapping Manual: Create a new highway system

New highway systems are developed by our volunteer highway data managers who went through the procedure of getting a contributor. When they have reached the right level of experience, they can start developing further highway systems. The subsequent list describes the procedure on how to develop a new highway system. It is mandatory for new highway data managers to work through it step by step. It is recommended for highly experienced highway data managers.

Research about the highway system and discussion on the forum
Check existing routes and add waypoints
Develop routes in devel status
Indicate the highway data sources on the site
Promote highway system to preview
Clear datacheck, broken concurrencies and NMP issues
Request peer review
Make changes based on peer review
Clear datacheck, broken concurrencies and NMP issues again
Activate the highway system
Maintain the highway system

Before you can start the development of a new highway system, the following requirements must be fulfilled:

🔗 Check which regions are covered by the highway system you want to develop

Are there already TM routes in that regions?

Check the routes whether they need a revision because of changed alignments, new routes or low data quality.

Does another highway data manager claim any region affected?

You need to ask the manager whether he/she wants to develop the highway system by himself/herself.

🔗 Get familar with the highway systems of the region.

Search for route lists and maps of the region(s) and highway system.
Is your highway system the highest system of the region(s) that is not yet covered by TM?

We usually start with the freeway systems and develop the other systems top down. Consider to develop the higher system first.

Does the highway system in question fulfill the TM highway system requirements?

🔗 Open a new thread on the In-progress Highway Systems & Work board of the forum.

Present your source for the routes.
Describe what you found out about the highway system, especially about the quality of signposting.
Ask whether there are objections to add the highway system.
Suggest the highway designation types for this and other highway systems to be used in waypoints.
Suggest system code, tier index and color code for the system.
Be patient since we are volunteering contributors and don't have time to answer immediately. Accept asks for better research and accept when we don't see the system as a future TM highway system.

Note that there are a few exceptions to the strict TM highway system requirements. Don't hestiate with opening a thread on the forum to ask whether the potential highway system is qualified for TM.

🔗 If there are already routes in the region(s) of the future highway system, check them for accuracy first.

If the routes are active, they need special treatment.

🔗 Add the waypoints which are required for the future highway system to the existing routes.

The existing .wpt files are stored on Github. They can be loaded into the Waypoint File Editor for modifications. The changed files must be submitted to Github with a pull request. Please refer to the development instructions for more info about how to deal with the files and tools.

🔗 Develop routes by creating highway data files (.wpt).

Create the files route by route in a desired order but make sure that you don't miss any route.

Use the Waypoint File Editor to find the coordinates for the waypoints:

Waypoints to include
It is recommended to start with copying the required waypoint coordinates from existing routes for:

Intersecting routes:
Waypoint labels must usually be renamed
Concurrent routes (multiplexes):
Waypoint labels are usually not renamed

Positioning waypoints
Labeling waypoints
Do not use commercial mapping sources, such as Google Maps, Yahoo Maps, or Bing Maps.
Properly shaped routes in non-remote areas typically have average waypoint spacing of 1.5-2.5 miles for surface routes and 2.0-3.0 miles for freeways, considering all visible and hidden waypoints together. There are routes that should fall outside those ranges, but those ranges are the norm. These averages are not suggested spacings to aim for. When the routes are worked out according to the above instructions, these ranges are typical of the average waypoint spacing.

Only add routes which are fully signed

Signed at the beginning of the route.
Signed at the end of the route.
Signed along the route so that there is no doubt about the actual routing.

If the routing is partially not clear or obvious, you need to shorten or interupt the route.
If the number of fully unsigned routes is small, they can be included when there is a clear evidence for their existance.

Evidence is, when they are on the latest official list from the responsible road authority or state institution.
For some regions, e.g. with poor street view coverage, it is sufficient when the routing is indicated on maps.

Notes to exceptions should be clearly described on the forum thread and / or in a README.md file on the Github folder for the .wpt files.

Ferries

If the route contains any segments that use a ferry crossing, the portion carried by the ferry must not be included, and the route must be split into separate segments. Exception: if the crossing uses an ice bridge during the winter, the route may include that ice bridge and not have to be split.

Waypoint order

In general, put the waypoints in the order normally used by the country. Exit numbers or roadside distance markers often reveal this order.
In the US and Canada, most highways should have waypoints in order from west to east or south to north. Some spurs might not follow this as they begin at a parent highway and end away from it (e.g., NC I-795: north (I-95) to south).
UNECE International 'E' Roads should run west to east and north to south.
Some countries use a major city as the origin and have exit numbers increasing radially outward and circumferentially in a certain direction.

Submit the highway data files to our HighwayData GitHub repository under:
https://github.com/TravelMapping/HighwayData/tree/master/hwy_data/<uppercase region code>/<lowercase system code>

🔗 Make the highway system lists (.csv)

Submit the files to the systems directory of the HighwayData GitHub repository.

🔗 Promote the system to devel status when a first batch of routes is available. This requires a new entry to system.csv on Github:

Enter a new line to the last segment of the file where the in-development systems are listed. The structure is as follows:

System;CountryCode;Name;Color;Tier;Level

...
brabr;BRA;Brazil Rodovias Federais;green;4;devel
...

The system code starts with the country, region or continent code, followed by a system abbreviation
The region or continent or country code can be found in regions.csv
The system name starts with the English region name followed by the system name in native language

Use an English term like Motorways or Main Roads if the native name is not using a Latin-script alphabet.

The color represents the color which is used on maps to draw the TM graph.

The color should help to distinguish systems if applicable.
Available colors are: TMblue, TMbrown, TMred, TMyellow, TMteal, TMgreen, TMmagenta and TMlightsalmon.
Standard colors are often used for a continent to avoid confusing users.

The tier index is used to distinguish systems top down.

It is used on maps to draw the TM graph. If there are concurrent routes, the color of the higher level system is on top.
The more important the system to non-local travel, the lower the tier index.
Standard tiers are often used for a continent to avoid confusing users.
We currently only use tier 1 to tier 5.

The level is always devel at this point.

🔗 Create the system shield (.svg) (optionally)

A svg file is used to show a system specific shield in the highway browser. They are generic and hosted on the web repository on Github.
If no specific svg is available for the system, the standard shield is used.

We don't notify the promotion of a highway system to in-development on the updates page but on the forum thread only.
When promoting a system to devel, the system is processed for the first time. If any .wpt or .csv file has an incorrect format or reference, the site update will fail. Please run data verification to find the errors before submitting the files.

The sources for the system must be indicated visibly on the site under credits.php.

Edit the file from the web repository on Github if you have used additional sources.

When the first draft of all routes is in the highway browser, you can promote the highway system to preview status.

🔗 The entry from system.csv must be moved from the in-development segment of the file to the preview segment.

The level column must be changed from devel to preview.

System;CountryCode;Name;Color;Tier;Level

...
brabr;BRA;Brazil Rodovias Federais;green;4;preview
...

🔗 It must be logged on top of the system updates list, so that the notification will appear on the updates page.

Especially when drafting a huge highway system, it is possible to split it into several sub-systems with partial preview promotion. Ask on the forum thread for more details.

A first complete check should be done when the system is in preview status, a second run must be done before the activation of the system.

🔗 Data errors can be checked as soon as the system is in devel state.
🔗 Concurrency checks can be done when the system is minimum in preview state.
🔗 Near-miss point checks can be done when the system is minimum in preview state.

🔗 The List of unprocessed .wpt files helps to identify highway data files (.wpt) in the repository which are not listed in any highway system list (.csv).

Errors from active systems should always be corrected or reported as false positives short-term.
Errors shown in red potentially effect travelers and should be fixed as soon as possible for active and preview systems.

🔗 Notify on the forum thread that the system is ready for a review by another contributor.
🔗 Any other user can also report issues which should be considered.
🔗 The peer review is complete, when the reviewer says it is complete.

Changes proposed on the forum thread should be processed short-term while the peer-review is still ongoing.

🔗 Make changes to the routes as required from users on the forum.
🔗 If you don't agree with proposed changes, explain on the forum why they should not be made. Provide a link to the manual or other sources if possible.
🔗 Care must be taken to ensure that changes do not "break" a user's list file.

We don't add notifications to the updates page because we are still in preview.

When the system is complete and there are no critical open issues, promote the highway system to active status.

🔗 The entry from system.csv must be moved from the preview segment of the file to the segment with active systems.

The level column must be changed from preview to active.

System;CountryCode;Name;Color;Tier;Level

...
brabr;BRA;Brazil Rodovias Federais;green;4;active
...

🔗 It must be logged on top of the system updates list, so that the notification on the updates page will appear.

🔗 If you are responsible for the region(s) of the highway system, you need to maintain the routes. Follow the discussion on the forum.
🔗 Care must be taken to ensure that changes do not "break" a user's list file.
🔗 All user-relevant changes to the routes must be notified on the updates page now since the system is active.