Sk:Prvky
Rozumíte-li originálu v angličtina, pomozte, prosím, tento český překlad dokončit. Přečtěte si nejdříve instrukce, jak překládat tuto wiki.
Zdá se, že na tom nikdo nepracuje, takže si to můžete vzít na starost.
Mapa pozostáva zo základných prvkov uzol (node) a cesta (way). Vlastnosti prvkov sú určené dvojicami klúč (key),hodnota kľúča (value). Všetky používateľské rozhrania na úpravu mapy používajú tieto základné prvky a umožňujú zadávať hodnoty pre kľúče a hodnoty kľúčov.
Základné prvky sú zhodné s ich internou reprezentáciou v databáze (pozri Data Primitives angl.).
Uzol (node)
Uzly sú základným stavebným prvkom OSM schémy. Uzly pozostávajú z hodnôt zemepisnej šírky a zemepisnej dĺžky (latitude a longitude). Tretí, voliteľný rozmer, hodnota nadmorskej výšky (altitude) môže byť zaznamenávaná. Kľúč key:ele a uzol môže byť tiež definovaný pre daný layer=* (vrstva) alebo level=* (úroveň).
Mesto, alebo dedina môže byť reprezentovaná uzlom s place=* (miesto) a name=* (názov).
Uzly bez ďalších prepojení na iné prvky sa používajú na popis miest, bodov záujmu a pod. V tomto prípade musí mať uzol priradenú aspoň jednu dvojicu kľúč, hodnota kľúča, ktorá hovorí o tom, ako sa uzol má interpretovať (pozri Sk:Map Features, alebo Map Features angl.).
V niektorých prípadoch majú uzly popri ceste značky (tag); ako power=tower (veža) pre reprezentáciu stĺpu s elektrickým vedením, alebo building=entrance pre určenie vstupu do budovy.
Cesta (way)
Cesta je prepojenie uzlov, ktoré popisuje priebeh cesty. Môže predstavovať napríklad ulicu, diaľnicu ale aj rieku...
Cestu tvoria uzly, na ktorých má cesta rovnaké vlastnosti napr. rovnaký typ cesty, rovnaké obmedzenie rýchlosti. Neskor môže byť cesta rozdelená na menšie časti, keď sa zistí, že existujúca cesta nemá rovnaké vlastnosti po celej svojej dĺže.
Cesta musí mať priradenú aspoň jednu dvojicu kľúč, hodnota kľúča.
Oblasť (area)
Oblasť nie je skutočný prvok, pretože je to v podstate cesta, ktorej koniec je v jej začiatku.
Relation
- Hlavný článok: Cs:Relation
A relation is a multi-purpose data structure that documents a relationship between two or more data elements (nodes, ways, and/or other relations). Examples include:
- A route relation, which lists the ways that form a major (numbered) highway, a cycle route, or a bus route.
- A turn restriction that says you can't turn from one way into another way.
- A multipolygon that describes an area (whose boundary is the 'outer way') with holes (the 'inner ways').
Thus, relations can have different meanings. The relation's meaning is defined by its tags. Typically, the relation will have a 'type' tag. The relation's other tags need to be interpreted in light of the type tag.
The relation is primarily an ordered list of nodes, ways, or other relations. These objects are known as the relation's members.
Each element can optionally have a role within the relation. For example, a turn restriction would have members with "from" and "to" roles, describing the particular turn that is forbidden.
A single element such as a particular way may appear multiple times in a relation.
Tag
- Hlavný článok: Tag
All types of data element (nodes, ways and relations) can have tags. Tags describe the meaning of the particular element to which they are attached.
A tag consists of two free format text fields; a 'key' and a 'value'. Each of these are Unicode strings of up to 255 characters. For example, highway=residential defines the way as a road whose main function is to give access to people's homes.
There is no fixed dictionary of tags, but there are many conventions documented on this wiki (starting with the Map Features page). Tag usage can be measured with the Taginfo application. If there is more than one way to tag a given feature, it's probably best to use the most common approach.
Spoločné tagy
Within the OSM database, we store these attributes for nodes, ways and relations. Your application may not need to make use of all of them, and some third-party extracts produced from OSM data may not reproduce them all.
| Name | Value | Description |
|---|---|---|
| id | integer (64-bit) | Used for identifying the element. Element types have their own ID space, so there could be a node with id=100 and a way with id=100, which are unlikely to be related or geographically near to each other. Positive (>0) values are used for all existing elements (and will remain assigned when they are modified or deleted); negative values (<0) are reserved (their scope limited to the current changeset and never stored in the database) and only used when sending data to the OSM database for identifying new objects to create and reference them in other created or modified objects (the server will replace these temporary identifiers sent by the editing application, by assigning an actual positive identifier for each created object, and will return a mapping from the negative identifiers used to their assigned positive identifiers). |
| user | character string | The display name of the user who last modified the object (informative only and may be empty). A user can change their display name at any time (existing elements will reflect the new user name without needing any version change). |
| uid | integer | The numeric identifier of the user who last modified the object. An user identifier never changes. |
| timestamp | W3C standard date and time formats. | Time of the last modification (e.g. "2016-12-31T23:59:59.999Z"). |
| visible | "true" or "false" | Whether the object is deleted or not in the database, if visible="false" then the object should only be returned by history calls. |
| version | integer | The edit version of the object. Newly created objects start at version 1 and the value is incremented by the server when a client uploads a new version of the object. The server will reject a new version of an object if the version sent by the client does not match the current version of the object in the database. |
| changeset | integer | The changeset number in which the object was created or updated (supporting 64-bit is recommended in applications for compatibility with long term evolution of the OSM database, but applications that only query data without updating them may ignore this informative attribute). |
Of course, in addition, we store the tags, and also a full editing history of every element.
Viď tiež
| ||||||||||||||||||