Editing Standards and Conventions

From OpenStreetMap Wiki
Jump to navigation Jump to search
For more general recommendations and tagging recommendations, see Good practice.

The following are some Standards and Conventions for editing the maps.

Tagging

Roads

A physical road, street, footpath, etc. is initially drawn as a series of nodes grouped together to form a way. The way should then be tagged with a highway=* tag and a name.

Many ways appear the same in most of the OSM editors, however, when rendered they will be displayed in different colours and widths based on the tag values entered.

Street Names and naming conventions

Logo. Feature : Editing Standards and Conventions
One example for Feature : Editing Standards and Conventions
Description
To provide details of the name for a feature included in OpenStreetMap.
Tags

name=*


To provide details of the name for a feature included in OpenStreetMap.

Name keys

Key Value Element Comment
name User defined node way area The common default name. Notes:
  • For disputed areas, please use the name as displayed on, e.g., street signs for the name tag
  • Put all alternatives into either localized name tags (e.g., name:tr/name:el) or the variants (e.g., loc_name/old_name/alt_name)
  • Do not abbreviate words: Abbreviations
name:<lg> User defined node way area Name in different language; e.g., name:fr=Londres. Note that all key variants below can use a language suffix. See: Multilingual names.
name:left , name:right User defined way Used when a way has different names for different sides (e.g., a street that's forming the boundary between two municipalities).
int_name User defined node way area International name (note: consider using language specific names instead; e.g., name:en=... - see above – International does not (necessarily) mean English).
loc_name User defined node way area Local name.
nat_name User defined node way area National name.
official_name User defined node way area Official name. Useful where there is some elaborate official name, while a different one is a common name typically used. Example: official_name=Principat d'Andorra (where "name" is name=Andorra).
old_name User defined node way area Historical/old name, still in some use.
reg_name User defined node way area Regional name.
short_name User defined node way area should be a recognizable, commonly used short version of the name, not a nick name (use alt_name for that), useful for searching (recognized by Nominatim).
sorting_name User defined node way area name, used for correct sorting of names — This is only needed when sorting names cannot be based only on their orthography (using the Unicode Collation Algorithm with collation tables tailored by language and script, or when sorted lists of names are including names written in multiple languages and/or scripts) but requires ignoring some parts such as:
  • ignoring leading articles, or
  • lowering the relative importance of first names cited before a last name,
  • ignoring the generic part of a street name when it occurs before the specific name (e.g., in French with "rue", "boulevard", "place", etc.),

all of them being ignored at the primary sort level and not easily inferable by a preprocessing algorithm.

alt_name User defined node way area Alternative name by which the feature is known. If there is a name that does not fit in any of the above keys, alt_name can be used, e.g., name=Field Fare Road and alt_name=Fieldfare Road, or name=University Centre and alt_name=Grad Pad. In rare cases, the key is used for multiple semicolon-separated names, e.g. alt_name=name1;name2;name3, but this usage is not preferred.
name_1 , name_2 , ... Do not use this tag, suffixed name tagging for multiple values is deprecated.

This table is a wiki template with a default description in English. Editable here.

Good practice

Abbreviation (don't do it)

Main article: Abbreviations
An extreme example of abbreviation: Lake Washington Boulevard Northeast and Main Street

If the name can be spelled without an abbreviation, then don't abbreviate it. Computers can easily shorten words, but not the other way (St. could be Street or Saint).

Uppercase characters

General recommendation is to use title case with the first letter of each word capitalised (e.g., Church Street, not Church street) but regional rules have preference over general rules. For example, in Flemish, capitalisation of last names gives a hint about the nobility status of the person. Street or company names derived from those last names should copy the same capitalisation. In non-Latin based languages, it's often not even possible to capitalise a name.

Watch out for apostrophes

If the street sign has an apostrophe, the OSM data should have an apostrophe. There is no obvious consistency; the London Underground station Barons Court is adjacent to Earl's Court, one with an apostrophe, one without.

Name is the name only

The names should be restricted to the name of the item in question only and should not include additional information not contained in the official name such as categories, types, descriptions, addresses, refs, or notes. However - if something has the official name "East 110th Street" this full name should be in the name notwithstanding the fact that the "street", the "110" and "east" might be deducible from some other information. If something really doesn't have a name, don't add a name to OpenStreetMap. Any additional information should be included in separate tags (see, e.g., aforementioned links) to identify its meaning.

Some examples of incorrect usage:

  • "Multipolygon Baldo Forest" : do not include the object type or other OSM terminology, if it does not apply outside of OSM
  • "The Royal Albert Hall, London" : do not otherwise include the location London as part of the name, even if there are multiple objects of the same name
  • "closed pub (due for demolition)" : do not describe the object in lieu of a name. Consider the description tag and also adding an old_name tag. No longer existing objects should be deleted. Disused objects such as shops can be tagged with lifecycle prefixes. See also nonexistent features page for more info.
  • "no name" : (see #No name, below)
  • "Football pitch" : this describes the feature, and is likely not the actual name. Instead make sure to use sport=soccer (the same for other sport pitches).
  • "Interstate 5 southbound lanes" : do not separately name parts of the same object where they are separate in OSM, but not outside of OSM.
  • "Interstate 5" : When a name would only be duplicating the information in the ref=* tag, then the ref and noname=yes is almost always more appropriate.
  • "Wildwood Boardwalk (seasonal)" : Do not include time-related access restrictions in the name. Instead, use conditional restrictions tags (or opening_hours=* for non-highways). example: access:conditional=no @ (Nov-Apr)
  • "Manchester City" : (for a city named Manchester, do not add a descriptive City; however note that New York City may be correct as the common name for The City of New York)
  • "Foobar Mountain, 8000 ft" : tag height in a separate tag (like ele=* or ele:ft=*), not as part of the name
  • "Lower Hell Hole 1030-002 Dam" : do not embed a reference number in a name just because a source (here USGS GNIS) does so; use a separate ref=* tag, for example, name=Lower Hell Hole Dam and ref:gnis=1030-002
  • "Union Pacific Railroad" : a name=* which was assigned during the USA's 2007-8 TIGER import (of roads and rail); the correct value is the name of the Subdivision/Branch/Line and this railroad name is properly the value of operator=* and/or owner=* (there are many other incorrect values besides Union Pacific). It is OK to precede a railroad name with an operator when two or more otherwise-identically named lines in close proximity would create serious confusion. For example, naming "CN Joliet Subdivision" and "UP Joliet Subdivision" or "BNSF Fort Worth Subdivision" and "UP Fort Worth Subdivision" is sensible. (For now. Even this convention may disappear in the future as operator=* and owner=* become more widespread and avoid such ambiguities).
  • "alternate summit trail" describing role of part of hiking route. For signed routes, you can use roles for recreational route relations

It is certainly wrong for a mapper to invent a name for an airstrip; however most names were invented at some point in history, so if someone invents a name and it catches on and a sizeable group of people refer to the thing by that name, then it's ok to be mapped[1].

No name

Streets which have no name are tagged noname=yes by most mappers. The idea is to clearly indicate that the street genuinely doesn't have a name. Absence of a name tag is increasingly used to indicate areas which need to be surveyed still.

Left and right names

For way objects, names can differ by side of the object.

For example, a street may be on the boundary between Belgium and the Netherlands, Belgium gives it the name "Amsterdamsestraat" and the Netherlands gives it the name "Brusselsestraat".

This is solved by using the name:left=* and name:right=* tags to name both sides separately (using the direction of the way to determine left and right) . The name=* tag can still include both names in order to support different tools.

Example:

note: different left-and-right names doesn't exclude the existence of multilingual names (which also happens more often on country borders). So tags like name:left:fr=* are possible.

Multiple names

If you have multiple names for a feature, first try to choose a rich semantic tag like any of the ones in the table (like short_name=*, old_name=* etc.). If none of them works, choose the alt_name=* tag. If there are multiple names that do not fit, alt_name=* can be used with semicolons.

Names are not for descriptions

For descriptions please use description=* not the name=*.

While it is welcome to tag building=house, it is wrong to add also name=house. Or name=Mosque to amenity=place_of_worship + religion=muslim. Validators may detect and propose to remove the most obvious and common incorrect descriptive names, but undetected ones also are incorrect. This is a form of tagging for the renderer.

Though note that some lakes are actually named "The Lake", in such case adding it as a name is fine.

Do not construct names for features[2] by combining the name of an enclosing feature with a description. For example, an unnamed fountain in XYZ Park should not be tagged with name=XYZ Park Fountain. Internal features to a named area should only be tagged with a name when they have a commonly-used local name, or some other indication (such as signage) of the feature's name. If the internal feature is named, it should still not be combined with the enclosing area's name. A feature named 'Smith Fountain' within 'XYZ Park' should be tagged name=Smith Fountain but not name=XYZ Park Smith Fountain.

For example, relation The Lake in New York City's way Central Park is tagged with name=The Lake and not a constructed name like "Central Park Lake". However, actual names referencing location of object are fine, as long it is actual name. For example the way Central Park Tennis Center does include "Central Park" in the name, because "Central Park Tennis Center" is the tennis center's actual name[3].

Despite this principle, historically, public transit route relations were expected to have name=* set to a description of the route in a rigid format.

Localization

By now the majority of rendering systems can deal with unicode characters, so you can use the local script for the default name tag. There is no need to use the Latin script.

For adding localized names in different languages, add additional name:code=* tags with a suffix on the name key, where code is a language's ISO 639-1 alpha-2 code (in the second column), or ISO 639-2/T (alpha-3) code (technical/terminologic codes, including possibly codes for macrolanguages, but excepting codes allocated to group of languages, do not use bibliographic codes) if an ISO 639-1 code doesn't exist, or ISO 639-3 (alpha-3) codes (for isolated languages or macrolanguages) otherwise; do not use ISO 639-5 codes allocated for language families.

For example, name:fr=* for the name in French and name:en=* for the name in English. The default name (occupying the 'name' tag without suffix) should be the name in whatever language is used locally.

Here is an example of the usage. All these tags might appear on the same element:

name=Irgendwas        (the default name, used locally)
name:en=Something     (the name in English)
name:el=Κάτι          (the name in Greek)
name:de=Irgen<different>dwas     (the name in German)
name:pl=Coś           (the name in Polish)
name:fr=Quelque chose (the name in French)
name:es=Algo          (the name in Spanish)
name:it=Qualcosa      (the name in Italian)
name:ja=何か          (the name in Japanese)
name:ko=아무것        (the name in Korean)
name:ko-Latn=Mweonga (the name in Romanised Korean)   (conforming to BCP 47 standard. Deprecated: ko_rm)

This leads to a more precise definition of alternative names.

Example of language codes according to the alpha-2 (= two-letter-)code of ISO 639-1:

de  German
pl  Polish
el  Greek
en  English
es  Spanish
fa  Persian
fr  French
it  Italian
ja  Japanese
ko  Korean
ru  Russian
zh  Chinese
ko-Latn  Romanised Korean (conforming to BCP 47 standard. Deprecated: ko_rm)

A short discussion on this language suffixes can be found on the discussion page.

Renderer support: Some rendering systems display these localised names. See Map Internationalization

Import: using osm2pgsql allows users to define new .style files which can include other language's name columns and bring them into the database. In order to render from these columns it is necessary to set up PostGIS views which present these columns as 'name' instead of 'name:languagecode'. An easier alternative might be to use a lua style file to move "name:XX" if it exists to "name". An example is seen in this diary.

Editor support: JOSM builds 1044 and newer support the display of local names. It detects the current system locale and tries to display names in this language first. You can change the order JOSM looks for names in the JOSM expert settings. Example: To display names written in Thai first, even if the current locale is 'en' set the following property:

mappaint.nameOrder=name:th;name:en;int_name;name

Transliteration

Transliteration is the process of taking a name in one language, and changing letters from one script to another. For some languages, this is necessary, particularly those which have multiple orthographies, such as Punjabi or Serbian. Some languages which are typically tagged separately necessarily have a transliterative relationship with one another in most cases; for example, Hindi and Urdu do not differ grammatically or phonetically and tend to contain the same strings in the Devanagari and Perso-Arabic scripts respectively. In most cases, it is not possible to transliterate automatically, so it is advisable to add and review these manually.

Some countries which use an official local language not written in the Latin script (notably in China, India, and Arabic countries) have official Romanization or other transliteration schemes which may be tagged with the appropriate tag for the target language code.

When to avoid transliteration

There are many situations where transliteration is generally avoided. Everything with a name could hypothetically be transliterated into language (city names, roads, cafes), but it's not necessarily desirable for every possible transliteration to be mapped. See also Good practice#Map what's on the ground.

Situations where transliterations should be avoided include:

  • Bulk import of transliterated names from sources such as Wikipedia.
  • "Manufactured" transliterated names which are not in regular use (e.g, adding an Inuktitut transliteration of a small village in Indonesia)
  • Names in fictional languages such as Klingon, Tengwar, or Na'vi.
  • Brand and shop names which do not have a commonly used transliteration.

Many editors rely on automated tools to translate and transliterate names For example:

Language-specific names

name=* contains the common, default name in the local language. name:<lang_code> is used to tag the name in a specified language in cases where the name differs by language, for example name:ru=Москва gives the city's name in Russian (language code ru) while name:en=Moscow gives the English language name (language code en).

In cases where multiple languages are tagged for a name, the local-language name tag should be duplicated with the language-specific sub-key. For example, Moscow is tagged with name=Москва, with the same value as name:ru=Москва. This tagging is important because it ensures that data consumers don't need to infer the local language. Guessing name language based on location is unlikely to always succeed - there are places in Russia where name=* is not in Russian, there are places in USA where correctly mapped name=* is not in English.

On the other hand, do not tag names that do not exist. An unremarkable village somewhere in Poland might have only one name (recorded in name=*). In all other languages, this village would be called by its Polish name, because it has no other name. Just because all other languages use the Polish name, you should not add name:<lang_code> tags for all other languages containing the Polish name!

Rationale

Tagging both say name=Kraków and name:pl=Kraków is useful for displaying localized names with fallback languages. If someone wants to

  • display names in Polish
  • in case of Polish name being unavailable, show English name (with "Beijing" being preferred over "北京市")
  • otherwise display name:en=*

In such case the solution would be to

  • display name:pl=*
  • if it is unavailable display name:en=*
  • if both are not present display name=*

But note what would happen if name=* would be in Polish, name:pl=* would be not tagged and name:en=* would be tagged:

  • display name:pl=* - skipped, as not present
  • if it is unavailable display name:en=* - done!
  • if both are not present display name=* - not reached

Alternative would be adding guesses about language of name=* (what is tricky, complicated for many languages and areas impossible, fragile and error-prone).

Or explicitly tagging both name=* and name:<lang_code>.

Local names (loc_name)

loc_name=* is for the name of a feature as it is known locally, but only where this is deemed to be too much of a slang name or otherwise unofficial-sounding. Ordinarily though, the name which local people use is the name we set in the name=* tag! Examples where we have used loc_name=*:

  • There is a bridge in Glasgow known as the Squinty Bridge, but its official name is the Clyde Arc. I have never heard anyone calling it that, so the bridge is tagged loc_name=Squinty Bridge name=Clyde Arc.
  • In Reading there's Union Street, but it's been known for decades as Smelly Alley on account of the fishmongers that lined it. The loc_name=* is ideal.

Alternate names (alt_name)

Apply when an alternative name exists (e.g., a street name has different syntax) sometimes even on street signs, although it is not only for street names.

Don't use it for abbreviations and only when one of the other name types don't apply; e.g., reg_name=* or name:lg_code=* for regional translations.

These alternative names are usually not rendered, but can be used by applications like Nominatim.

Sorting names (sorting_name)

sorting_name=* is a proposed approach to supply an alternate name which systems can use for the purpose of sorting alphabetically. This would be useful for street names in some languages/countries, particularly Russian, where words like "Street" are frequently used as a prefix. This is problematic if you simply sort on the main name=* tag.

Historical names

The date namespace suffix can be used for historical names, e.g., name:1953--1990=Ernst-Thälmann-Straße.

Deprecated tags

The suffixed tags name_1=* and alt_name_1=* should no longer be used for tagging. They are the result of old imports that were not defined very well.

Notes

See also

External links

One way streets

If traffic can only travel down a road oneway then it is important to draw the way in the direction of travel and then add a oneway=yes.

Divided highways

A divided highway (also separated highway) is any highway where traffic flows are physically separated by a barrier (e.g., grass, concrete, steel), which prevents movements between said flows. While divided highways typically consist of two opposing traffic flows, such as with dual carriageways, they can also consist of three or more divided sections having a combination of same-direction and opposing flows, such as highways with "local" and "express" lanes (whereby entries to and exits from the highway are possible only from the former).

Divided highways should be drawn as separate ways. The ways will typically be oneway=yes, and should be tagged as such where appropriate. Ways connecting the divided ways should be drawn at locations where movements between the divided ways are possible, that is, where the physical separation is interrupted (e.g. [1]; as always, add access tags for legal limitations). Where the divided ways are parallel (often, but not always) their nodes should be positioned so that they are adjacent to each other. This creates a more pleasing aesthetic effect in renderers, especially on curves. It also preserves the information on their mutual separation distance along their whole length.

As with any ways, the spacing between is governed by the need to accurately represent curves (see below):

Wrong.
Right. Nodes aligned in pairs.

JOSM tools

JOSM contains several tools that will save your time and ease your pain during editing process

broom

This page is being considered for cleanup. Please discuss this page.

Roundabouts

See Roundabouts

Junctions

See also Node#Nodes_on_Ways

All road junctions should be drawn as a node which connects the ways (both or several ways share the same(!) node).

It is incorrect to use two nodes which are just on the same (or nearly the same) position but actually are not the same. While this might look right, it will not define a valid routable connection from one road to the other. You should merge the two nodes using your OSM editor to fix this problem, if the ways are connected in reality.

If your editor's map style does not make shared nodes discernable, then a usual trick is to just move the node in question a bit and watch which ways move too. Please be sure to "undo" (with your editor's "undo" function, not by moving back(!)) this test move.

Some quality assurance tools help to discover such potential unconnected way problems (way end closely to another way but not connected).

Bridges

Bridge ways are tagged bridge=yes and layer=1

A bridge is drawn as a separate way. This is one of many situations where a road is no longer represented as a single way, but as several ways arranged end-to-end, each with different tagging. The editors provide an easy way to split a way at a given node, for this purpose.

The highway and name tag should be applied throughout. The short way representing the bridge should additionally be tagged with bridge=yes and layer=x, where x is one more than the layer tag of the road underneath (or 1 if there is no layer tag on the road underneath).

Often the bridge will not connect directly to a junction. In which case you should add a piece of road connecting the two (see image):

Bridge near junction

See Key:bridge for details.

Tagging Areas

Areas are closed ways

On some occasions the feature you wish to tag is not represented by a line (as is the case of a road, river, rail line etc), but by an area. For instance a wooded area, a park, or a lake are all Map features which are areas. Create a new closed way which represents the outline of the required area. Annotate this way with the required tagging from the map features page, such as natural=water (for a lake), landuse=forest (for a forest), or leisure=park (for a park), etc.

Highways as Areas

Most ways are assumed to be areas if they are closed (i.e.--if the way connects back to itself). However, there are some exceptions to this, such as highways, which are generally assumed to be ways. If the highway is meant to be an area (for example, a pedestrian square), then there are two possible ways to tag that area:

  • If the area of the highway is surrounding routable highways (such as a motorway, residential road, or any other highway), the tag area:highway=* should be used on the area representing the surface of the road instead of highway=*.
  • If the area of the highway is a square or area with no osm ways inside for routing, and the intention is that routers should route people around the outer edge of that shape, then the tag area=yes should be used together with highway=* on the area representing the area of the highway.

Areas and Ways Sharing Nodes

There is not clear consensus yet on how to draw areas adjacent to ways. They may be drawn either by leaving a small gap between the area and the way or by connecting them so that the area shares nodes with the way. That being said, when the way is a highway, it usually is most accurate to include a gap, so that the area ends by the side of the road and does not share nodes with the road's way. This is because highway ways usually are traced along the centerline of the road, and it is unlikely that the area being tagged actually extends to the center of the road.

Three mapping practices. A: Areas are glued to adjacent ways by shared nodes. B: Ways always go though areas with no shared nodes. Ways belong to areas. C: Gaps between ways and areas.

Accuracy

Main article: Accuracy

Accuracy is important during mapping. Beware of systematic errors of aerial imagery (see for example Bing#Precision). Remember, that when tracing roads — particularly winding, rural ones — you should add enough points to make each curve look like a curve. Of course, this is entirely subjective, as curves made entirely of lines will only ever approximate a "true" curve (which has an infinite number of nodes), and will always look like a series of lines when zoomed in past a certain point no matter how many nodes there are.

To generalize, though, sharp curves (those having a small radius) require many, closely-spaced nodes, while broad, long-radius curves can consist of fewer nodes having more distance between them. Without a hard-and-fast rule, it is best said to simply use good judgement and strive to seek a balance.

Small example using GPS traces

Below there is an example of a very roughly-traced rural 2-kilometer road. It's rather crude, particularly on the sharp curves. We would normally expect mappers to represent this kind of road with more nodes than that.

How it shouldn't be done

This is the same 2-kilometer road - but this will look much better on the map, and gives the map user a better sense of the curves of the road. You can see the road on the map. You can also see that other mapping services have a similar degree of accuracy.

How to do it

Note: Keep in mind that the road in the diagram below is about 2 km long. For very short roads you do not need to add that many nodes. If a road is perfectly straight then a node at either end is always sufficient, unless it is more than several kilometers long.

It's easy enough to "fix" these things i.e. enhance the detail of the road. Normally you should just add more nodes to the existing way. If you choose to delete and redraw a whole road, check that the nodes don't themselves have tags e.g. a highway=crossing node. Potlatch and JOSM will highlight tagged nodes.

Date and time

Simple definition

Dates should be in ISO 8601 format, i.e. YYYY-MM-DD.

Precise tagging

Miscellaneous

  • Intersections and interchanges - These are most likely to be always improved by someone else, no matter how much detail you put in
    The initial level of detail should include correct connections from/to each road and link road and the existence of any bridges and underpasses; remember to set oneway tags where applicable.
    For intersections any pedestrian crossings are valuable information; add a node in the way they cross at their location
    After that there's still lots of detail that can be added (as with all roads: number of lanes, speed limits, lit=yes/no
  • Accuracy. How do you judge and or indicate the accuracy? How accurate is good enough? Is a rough approximation better than nothing (i.e. inaccurate roads get refined the way wikipedia articles do).
    A GPS trace is almost always more accurate than other sources available to us. Still several, even tens of traces can be used to improve the accuracy. Do note though:
    • Sometimes and in some environments the GPS trace can wander off to some direction (often 15-30 meters but even 90 meters); compare the trace with your memory, photos and notes to see if straight roads appear as a reasonably straight set of trace points.
    • If it's a new road (nothing previously entered in the area) and there aren't any aerial images available, draw it in anyway
    • If there are already other roads around and your trace seems bad, try to deduce the "real" form from the trace by not crossing roads that don't intersect with the road you traced.
    How accurate is good enough varies with each user:
    For most uses it's accurate enough when it's not misleading: say when a cycleway drawn on the map
    • shows all correct bends and intersections
    • and no nonexistent ones
    • and is on the right side of the nearby road / stream / railway
    • and is roughly the correct distance away from those features (some editors have support for measuring distances)
    Some may later want to draw fences, hedges and walls around the houses (where they exist); they will have mapped their locations to within a few meters by repeated traces and considerable amount of deducing and aligning things in lines
    Not only inaccurate roads, but those lacking secondary information, are refined later anyway. When contemplating on whether to approximate some road, try to consider if a user would find any value in the approximated form - is it likely to be within, say, 50 meters from the real location at all times (in otherwise unmapped territory)? If you approximate, do add a source=approximation or similar tag to the way.
  • Is it constructive/helpful to mark a road that you know is roughly in the right place but don't have any supporting GPS data?
    This depends again on what else is there:
    • If an urban road is missing in a rectangular grid and you confirmed its existence and it was, say, roughly halfway between the parallel roads: the position is likely to be almost as good as the position of those parallel streets when you draw it in.
    • If the missing road ventures into the unmapped territory winding along the way, it's likely better to draw just a stub for the starting point and add a fixme=continue on the last node. If one were to draw the full way freehand, it would very likely be too short/stretched/skewed - unless there are good aerial images available.
  • Landmarks, footpaths, etc.?
  • How do you indicate that one road passes over or under another? - See the description for bridges above, and Key:bridge.
  • If a road is made up of several/many ways, all ways should carry the name and/or ref tags.

Topology

  • Is correct topology more or less important than accurate location?
    • In the end both are equally important and not even mutually exclusive, but since with our tools the topology can be surveyed more accurately than the location, it should be always kept correct, even if that leads to some nodes being some meters more off than otherwise.
  • If a road has a small traffic island (eg at the approach to a large roundabout) should this be represented as a triangle or not? How big should it be before it should be drawn?
    • You can draw it or not, there is no limit below which it cannot be done, but the longer the separation is, the more likely someone will convert it into a dual carriageway and split the highway. Generally it is done.



WARNING: OpenStreetMap is highly addictive Take frequent breaks, there is a lot to be done.