Zh-hans:编辑标准和惯例

From OpenStreetMap Wiki
Jump to navigation Jump to search
Editing Standards and Conventions - Other languages
For 更普遍的标记建议, see Good practice.

以下是一些编辑地图的标准和约定。

标记

道路

物理道路、街道、人行道等最初被绘制为一系列节点，组合在一起形成线。然后应该用highway=*标签和名称标记该路。

在大多数OSM编辑器中，许多线看起来完全相同，但是，在地图渲染时，它们将根据输入的标签值，渲染成不同的颜色和宽度。

街道名称和命名约定

编辑标准和惯例 - Other languages
Logo. 要素 : Zh-hans:编辑标准和惯例
One example for 要素 : Zh-hans:编辑标准和惯例
说明
To provide details of the name for a feature included in OpenStreetMap.
标签

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

For details refer to Names#Good_practice.

name:<xx> 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[:<xx>], name:right[:<xx>] 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[:<xx>] User defined node way area International name. Consider using language specific names instead; e.g., name:en=.... International does not (necessarily) mean English. It is used to give the name transliterated to Latin script in Belarus, Bulgaria, Greece, Kazakhstan and Northern Macedonia
loc_name[:<xx>] User defined node way area Local name.
nat_name[:<xx>] User defined node way area National name.
official_name[:<xx>] 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[:<xx>] User defined node way area Historical/old name, still in some use.
ref_name[:<xx>] User defined node way area Unique, human-readable name of this object in an external data management system.
reg_name[:<xx>] User defined node way area Regional name.
short_name[:<xx>] User defined node way area Should be a recognizable commonly-used short version of the name, not a nickname (use alt_name for that), useful for searching (recognized by Nominatim).
sorting_name[:<xx>] 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[:<xx>] 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.
nickname[:<xx>] User defined node way area Nickname (e.g. "Warschauer Allee" for BAB 2 in Germany relation 3140168).
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

OSM follows the on the ground principle, which means that street names and other proper names are generally entered as they appear on signs, even if those names deviate from the general spelling rules. Possible exceptions are described in some of the following sections.

If you're wondering why how brands (McDonald's etc) have preset suggestions in iD, Every Door, and other apps, the answer is in the Name Suggestion Index. Here you can add presets for brands so they get uniform spelling and tagging.

Uppercase characters

Names are adapted to the local capitalisation rules; title case is generally preferred, but regional rules have preference over general rules. Note that multiple capitalisation styles could be right, so be careful and don't over correct. For example in German both "An der alten Brücke" and "An der Alten Brücke" (meaning "at the old bridge") could be considered correct names.[1][2] 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.

Abbreviation (do not)

主条目：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).

Proper name spelling

If the name isn't present on any signs, follow the local spelling rules. Make sure that the name is really locally known and you're not inventing or constructing a name. However signs are not required for a name to exist. Most natural features like woods and lakes do not have signs. In many countries with weaker governments or lower literacy levels, the names of hamlets and streets will not be written down, but can be verified by asking the local people.[3] You can use source:name=* to explicitly indicate how you determined the name of the feature.

If multiple different spellings are used locally, the most common or most correct is preferred. The other spelling can be entered as alt_name=*.

Conflicting signs "Karlstraße"/"Karlstrasse" for the same street. In this case, Karlstraße would be the correct spelling in Germany.

Obvious mistakes (like John-F.-Kennwdy Square) or deviating spellings that only occur because some characters were not transcribed or printed correctly should be replaced with the proper spelling, but within reason. If there is a "Jolin Tsai Street" in an English-speaking country, do not restore the original spelling of the name as something like "蔡依林 Street", but a sign with "GROSSER WEG" in Germany should be turned into name=Großer Weg, which would be considered the correct local spelling, instead of "Grosser Weg", which would be considered incorrect. (The uppercase version of "ß" was only officially adopted in the German language in 2017 and its usage is still optional.)

When old/outdated and new spelling variants are both present, the newer spelling should be used as name=*. Exceptions are possible, for example, if a city or region explicitly prefers the old spelling of a name for historic reasons and any signs with the new spelling are obviously an oversight. Proper names included in street names usually shouldn't be adjusted to new spelling variants.

Avoid including emoji and other special characters that are not pronounced, are decorative, or substitute normal letters (e.g. "♥" used for "heart" or "love", "!" used for "i"). Stylized spellings of trademarks and company names should be adapted to the regular capitalisation and spelling rules, e.g. a sign that says "TACO 🔔 BELL" would be written as name=Taco Bell. However do not change spellings/capitalization if doing so would cause confusion or if the original spelling is much more common in everyday usage.

Not all signs contain names. Descriptive text, alphanumeric IDs, advertising slogans and similar items should not be included in names.

If local signs do not match the data in official publications/databases/directories, the official name can be tagged as official_name=*, but make sure you're allowed to use that data. Note that databases can be outdated, contain mistakes or might have limitations in maximum entry length or allowable characters.

If a sign is obviously in error, use not:name=* to prevent mappers without local knowledge from propagating the error in OpenStreetMap.

In principle, not all special cases and exceptions can be mapped into rules. When still in doubt, use common sense. You may also find the following questions helpful:

  • How would you write the name in a mailing address, e.g. when sending a letter?
  • How would a navigation system pronounce the name and what name would a user enter to search for the feature?
  • How does the name appear in official directories? Are any discrepancies to signs or to proper spelling rules intended or likely mistakes?

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[4].

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.[5]

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 preclude 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.

Sometimes name=* itself can contain multiple values separated by semicolons:

  • In multilingual regions or localities, multiple names in different languages may be relevant enough to include in name=*. A separator other than a semicolon, such as "/" or "-" (spaced or not), may be customary locally. This is not a substitute for language-specific keys, such as name:en=* for English.
  • Some international boundary features (often bodies of water) have multiple values in name=*, so as not to favour one country's preferred name over another's.
  • In relatively rare cases, there may be a tie on less prominent features such as points of interest. For example, a single business may go by two names interchangeably and post each name on different sides of the building. Before overloading name=* with multiple values, make sure it is truly a tie and there is not a more structured way to represent the naming situation.[6]

Some renderers turn semicolon delimiters into something more aesthetically pleasing, such as an em dash or line break, but many other data consumers assume only a single value in name=*, so a semicolon could appear verbatim, surprising users.

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[7] 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[8].

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

Disputed names

If the dispute can not be resolved through discussion, then the simple default rule is whatever name are used by the people on the ground at that location are used. For further information see Solving Disputes and the Official OpenStreetMap Foundation statement on the project's practices regarding disputed boundaries, borders, names, and descriptions.

Localization

参看：Multilingual names

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=Irgendwas     (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-Hans  Simplified Chinese
zh-Hant  Traditional 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 India, Arabic countries, and CJK character using region) 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.

Some developers have attempted to demonstrate that mappers do not need to manually translate or transliterate obscure map features' names because fully automated alternatives are available:

However, these fully automated approaches are fundamentally unreliable. Text can only be properly transliterated if the original source language is known, but name=* does not indicate a language explicitly. Any language-agnostic transliteration tool, such as ICU, is unsuitable for transliterating from some writing systems such as CJK to Latin, because they were designed for collation rather than user display. Machine translation can also be unreliable on very short strings, such as the names of map features, due to a lack of context.

Instead, popular data consumers retrieve manual translations and transliterations from Wikidata. While many of Wikidata's translations come from the same automated tools, they are often more reliable because the original language was fed into the transliterator and users have the opportunity to correct the results.

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. For example, a tourist-oriented gift shop or a grocery that caters to an immigrant community may be named in a foreign language.

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 the default name=*, assuming one exists

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.

The tag nickname=* is also in use for slang names or other obviously unofficial, but widely known names, especially when the slang name is known globally/nationally and not only locally. For example the German "Bundesautobahn 2"[1] has the nickname "Warschauer Allee".

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:xx=* 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

  1. ↑ Depending on the exact rules you follow and if "Alte Brücke" ("old bridge") is the proper name of a locality, or just a description. "An der Alten Brücke" would never be wrong, but don't correct "An der alten Brücke" if it could also be right.
  2. ↑ https://www.duden.de/sprachwissen/rechtschreibregeln/Gro%C3%9F-%20und%20Kleinschreibung#D88
  3. ↑ https://lists.openstreetmap.org/pipermail/tagging/2020-December/057727.html
  4. ↑ Inventing names for essentially unnamed private airstrips
  5. ↑ A new tag is proposed to explain why it doesn't have a name.
  6. ↑ For example, this is a single shop that calls itself "Fun House" in front where customers park but "Flag House" in the rear where customers enter.
  7. ↑ Tagging mailing list thread on name tags for internal features of a named area
  8. ↑ Central Park Tennis Center on the official Central Park website

See also

  • name:pronunciation=*
  • name:etymology=* - The subject commemorated in the name of an element
  • Multilingual names
  • noname=yes - Used to mark the absence of a name, where something really does not have a name in reality
  • strapline=* - Official strapline used in an advertising slogan next to the name, commonly seen on signs
  • unnamed=* - Used to mark the absence of a name, when it was verified to have no name defined in reality. Consider using noname=* instead
  • Key:description - to describe a feature.

External links

v · d · e
OSM good practices
Good practices

单行道

如果交通参与者只能沿着道路单向行驶，那么以行驶方向绘制道路，然后添加oneway=yes标签。

带隔离的道路

分隔的道路（又称“两块板”）是一种交通流被障碍物（例如草、混凝土、钢护栏）物理分隔的高速公路，该障碍物可阻止两个流量之间的互相移动。虽然分开的高速公路通常由两个相反的交通流组成，例如双向行车道，但它们也可以由三个以上的独立道路组成。这些道路可以具有相同和不同的组合，例如高速公路"local" 和 "express"车道（因此只能从前者进出高速公路）。

带有中心隔离带的高速公路应绘制为单独的道路。而且他们俩通常都是单行道oneway=yes。连接两个方向的匝道应该画在道路之间可能穿过的位置，即物理分隔中断的地方（例如[2]；还要记得添加access tags以标记道路信息）。如果分离的两条道路（通常但不总是），它们的节点应设置为彼此相邻的。这会使渲染的效果更美观，尤其是在曲线上。而且还顺便在整条道路上保存了分隔带宽度的相关信息。

与其它线一样，线之间的间距要取决于准确表示弧度的需要（见下文）：

错误示例×
正确示例√，节点成对对齐。

JOSM tools

JOSM包含多种编辑工具，可以节省时间并简化复杂的编辑过程。

broom

This page is being considered for cleanup. Please discuss this page.幫忙將此翻譯成簡體中文！

环岛

参见环岛

路口

参见Node#Nodes_on_Ways

所有路口都应绘制在共享相同(!)点的道路交叉点上。

将两个节点绘制在相邻（或几乎相同）的位置上，但实际上并不连在同一点上是不正确的。虽然这可能看起来正确，但这种情况下无法建立从一条道路到另一条道路的有效导航连接。您应该使用您的OSM编辑器合并这两个节点解决，前提是它们俩现实中是连着的。

如果您的编辑器的地图样式看不起节点是否是相连的，可以通过稍微移动有疑问的节点并观察哪些线也跟着移动了。 检查完毕后，请务必撤消(使用编辑器的撤消功能，而不是挪回去(!))这一移动。

一些质量保证工具有助于发现这种潜在的未连接的道路问题（两条路离得很近但是没连起来）。

  • 一个简单有效的路口（中间的黑点同时连接了两条白色道路）

    一个简单有效的路口（中间的黑点同时连接了两条白色道路）

  • 一个错误绘制的路口

    一个错误绘制的路口

  • 连接点和无连接点的示例（参见此处的说明）

    连接点和无连接点的示例（参见此处的说明）

桥

桥梁应标注为bridge=yes和layer=1

一座桥梁需要用单独的线绘制。这是道路不再以一条线表示，而是多条线逐一相连的情况之一，每条线都带有不同的标记。为此，编辑器提供了一种在给制定节点处拆分道路的简单方法。

道路和名称的标签应贯穿始终。代表桥梁的短线应该另外用bridge=yes和layer=x另外标记。其中x比下方道路的图层标记多1（如果下方道路上没有图层标记，则为1）。

通常情况下，桥不会连到交叉点上。在这种情况下，您应该另外添加一条连接两者的道路（见图）：

紧挨着桥的路口

详情参见Key:bridge。

绘制区域

区域是由封闭的线构成的

在某些情况下，需要绘制的要素不是由线表示（如公路、河流、铁路线等），而是由区域表示。例如，郁郁葱葱的树林、公园或湖泊都是地图特征，它们都是区域。创建一条新“封闭的线”，代表所绘制区域的轮廓。使用地图特征页面中对应的标记，使用对应的方式进行标记，例如natural=water（表示湖泊）、landuse=forest（表示森林）或 leisure=park （用于公园）等。

道路绘制为区域

如果一条线是封闭的（即，线连接回自身，成为一个圆形），则系统会假定它们是区域。但是，也有一些例外，例如道路，它们本来应该是线。如果道路是一个区域（例如，步行广场），那么有两种可选的方法来绘制这种区域：

  • 如果线的区域围绕着可通行的道路（例如高速公路、住宅道路或任何其他道路），则应在表示道路的区域上使用标签area:highway=*道路而不是highway=*。
  • 如果线的区域是一个正方形或内部没有用于导航的OSM路径的区域，并且人们只能在外轮廓上通行，那么标签area=yes应该在区域上与highway=*一起使用。

准确性

主条目：Accuracy

准确性在绘图过程中很重要。谨防卫星图像的误差（例如参见Bing#Precision）。请记住，在追踪道路时——尤其是蜿蜒曲折的山路——您应该添加足够的点以使每条线看起来像一条曲线。当然，这仅仅是看起来如此。因为完全由线条组成的曲线只会近似'接近曲线（具有无限数量的节点）。并且无论有多少节点，在放大后都会总是看起来像一系列直线。

但是，简而言之，尖锐的急转弯曲线（那些半径较小的弯道）需要许多间隔很近的节点，而舒缓的、长半径曲线可以由较少的节点组成，它们之间的距离更大。没有硬性规定，最简而言之就是使用你自己的判断力和努力寻求平衡。

使用GPS轨迹的小例子

下面是一个非常粗略追踪2公里的乡村公路的例子。它相当粗糙，尤其是在急转弯上。我们通常希望地图绘制时使用比这更多的节点来表示这种道路。

不应该这样做

这是同一条的2公里道路——但是这在地图上看起来会好得多，并且可以让地图用户更好地了解道路的曲线。你可以在地图上看到这条路. 您还可以看到其他地图服务也具有这样的准确度。

应该这样做

注意：请记住，下图中的道路也长约2公里。对于非常短的道路，您不需要添加那么多节点。 如果一条道路是完全笔直的，那么只绘制两端的节点也是可以的，除非它的长度超过几公里。

修复这些东西很容易，即增强道路的细节。通常，您都应该向现有的线上添加更多节点。如果您选择删除并重新绘制整条道路，请检查节点本身是否有标签，例如highway=crossing节点。Potlatch和JOSM将突出标记节点。

日期和时间

简单定义

日期应采用ISO 8601格式，例如YYYY-MM-DD。

精准标注

杂项

  • 路口和道路交汇点——无论你输入多少细节，这些都是最有可能被其他人改进的；
    最初的地图详细程度应包括每条道路和连接道路之间的正确联系以及所有的桥梁和地下通道；记得在适当的情况下设置oneway标签；
    路口的所有人行横道都是有价值的信息；在它们与道路交叉的位置添加一个节点；
    之后还有很多细节可以添加（所有道路都可以添加：车道, 限速、lit=yes/no）；
  • 准确性。您如何判断和表达准确性？准确到什么程度才足够好？粗略的近似总比没有好（因为不准确的道路会像维基百科的条目那样得到其他人的改进）；
    GPS轨迹几乎总是比我们可用的其他来源更准确。重复的几个，甚至几十个轨迹可以用来提高精度。不过请注意：
    • 有时，在某些环境中，GPS轨迹可能会偏离某个方向（通常为15-30米，甚至90米）；将轨迹与您的记忆、卫星照片和笔记进行比较，看看笔直的道路是否显示为一组相当笔直的轨迹点；
    • 如果它是一条新道路（之前没有进入该区域）并且没有任何可用的航拍图像，无论如何都要绘制它；
    • 如果周围已经有其他道路，并且您绘制的轨迹看起来很糟糕，请尝试不穿过与您所追踪的道路不相交的道路，以便从轨迹中推断出真实形式。
    每个用户的准确程度各不相同：
    对于大多数用途，当它没有误导性时就足够准确了：比如在地图上绘制了自行车道；
    • 显示所有正确的弯曲和交叉点；
    • 并且没有错误的；
    • 并且在附近公路/河流/铁路的右侧；
    • 并且与这些对象的距离大致正确（一些编辑器支持测量距离）；
    有些人后来可能想在房子周围（如果有的话）绘制围栏、树篱和墙壁；他们将通过重复的追踪和大量的推导和对齐的方式将他们的绘制精度放大到几米之内；
    除了不准确的道路之外，那些缺乏次要信息的道路，无论如何都会在以后进行改进。在考虑是否对某条道路进行近似绘制时，请尝试考虑用户是否会找到近似形式的任何值——是否可能始终在距离实际位置50米之内（在其他未绘制的区域内）？如果你是通过近似信息绘制的，一定要添加一个source=approximation或类似的标签。
  • 标记一条您知道大致位于正确位置但没有任何支持GPS数据的道路是否有建设性/帮助？
    这再次取决于还有什么：
    • 如果网状路网中缺少一条城市道路，并且您确认了它的存在，并且它大约位于平行道路的中间位置：当您绘制它时，该位置可能几乎与其它街道的位置一样好。
    • 如果缺失的道路进入沿途蜿蜒的未知区域，最好只绘制起点并在最后一个节点上添加fixme=continue。如果要完全徒手绘制，它很可能太短/拉伸/倾斜——除非有好的航拍图像可用。
  • 地标、人行道呢？
  • 您如何表示一条道路上跨或下穿另一条道路？——请参阅上面的桥梁描述，以及Key:bridge。
  • 如果一条道路由几条/多条路组成，则所有路都应带有name和/或ref标签。

拓扑

  • 正确的topology比准确的位置更重要吗？
    • 两者同样重要，甚至不相互排斥，但是由于使用我们的工具可以比位置更准确地调查拓扑，因此应该始终保持正确，即使这导致某些节点比其他节点多几米 .
  • 如果一条道路有一个小交通岛（例如在通往大型环形交叉路口的入口处），是否应将其表示为三角形？ 在绘制之后应该有多大？
    • 你可以画也可以不画，没有下限就不用画，但分开的时间越长，就越有可能有人把它改成双车道，把公路分开。 一般都是这样做的。



警告：OpenStreetMap很容易上瘾。请注意及时休息，除了绘图之外还有很多事情可以做。

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Zh-hans:编辑标准和惯例&oldid=2231043"