Proposed Features/Human

--- title: Proposed Features/Human description: OSM Human tagging and mapping proposal. lang: en chance_of_osm_adoption: Low. No, it's high, let's be positive. --- # A human friendly OSM tagging scheme :::info ℹ️ Totes not just an April Fools. ::: :::info ℹ️ OpenStreetMap World Discord writes a tagging proposal. ::: :::danger This page is no longer updated. Use [proposal page](https://wiki.openstreetmap.org/wiki/User_talk:ForgottenHero) instead. ::: A **human**, **person**, **Homo Sapiens**, or **Homo Sapiens Urbanus** is a member of a species of "highly intelligent" (according to some) primate or human-like creations thereof. Many OpenStreetMappers are humans. There is an increasing need to map humans in OpenStreetMap. In order to enable this, as described at the most recent OSMF board meeting, OSM plans to give every human on Earth an OSM node and update it as the person moves around the world. This tagging scheme is the proposed implementation of that decision. The tagging scheme for humans is `natural=human` with [`name`](https://wiki.openstreetmap.org/wiki/Names) for the person's given name and [`brand`](https://wiki.openstreetmap.org/wiki/Key:brand) for the person's surname. The date of their birth will be defined from the v1 of the node for that person. For people not added to the map at birth, end-user applications can use [API v0.7](https://wiki.openstreetmap.org/wiki/API_v0.7)'s history re-write feature to insert their node at the appropriate historical coordinates. | | | |-|-| | Drafted on | 2021-02-19 | | RFC start | 2021-02-22 | | Vote start | 2021-04-01 | | Vote end | 2021-04-14 | ### Table of contents [ToC] :::danger This page is no longer updated. Use [proposal page](https://wiki.openstreetmap.org/wiki/User_talk:ForgottenHero) instead. ::: ## Rationale 1. There is an increasing need for data consumers to associate the position of humans with nearby features. Creating a defined tagging scheme for human locations allow for a standard, worldwide scheme that all consumers can rely on. 2. With an average global life expectancy of 79 years, humans easily meet the "6 months or more" rule of thumb for object permanence. 3. There was a significant debate during the RFC over whether `human` should be placed in the [`natural`](https://wiki.openstreetmap.org/wiki/Key:natural) or the [`man_made`](https://wiki.openstreetmap.org/wiki/Key:man_made) key, particularly in cases of in-vitro fertilisation. However, it was decided to follow the model of `natural=tree`, which is placed in the `natural` key due to its natural nature, regardless of whether or not it was planted by humans. 4. The increasing rise of robots has brought up a need to tag semi- and non-organic life forms in addition to pure humans. While these life forms are not strictly "natural", they should still be tagged with this key so that all life forms can be searched for with a common tag. 5. Quality Assurance for OSM edits can be improved by confirming that the mapper was literally present for map edits which require on the ground survey. 6. Map all the ~~things~~ people. ## Verifiability The existence of any one human can either be verified by: 1. The person themselves 2. Or, in the unlikely event that they are not part of the OpenStreetMap universe, another mapper can visit the human's location on the map and poke them with a stick. Use a nearby `natural=tree` to get a locally sourced stick. If the human exists, be sure to tell them about OpenStreetMap. The existence of humanity is outside the scope of this proposal and will be voted on in the follow-up proposal published in exactly 365 days from beginning of voting on current proposal. If the OSM community votes to reject humanity, the future of the OpenStreetMap project may be negatively affected. :::danger This page is no longer updated. Use [proposal page](https://wiki.openstreetmap.org/wiki/User_talk:ForgottenHero) instead. ::: ## How to map Standing and sitting humans are mapped as nodes at their current locations. Humans that are lying down may also be mapped as unclosed ways. Humans lying on their side and holding their legs may also be mapped as a closed way. The way direction should be going from head to toes. Data consumers should not treat these humans as two-dimensional areas. Disintegrated humans, such as organ donors or beheaded criminals, can be mapped as relation, where relation role describes specific body part or just `body` for rest of a human. When organ is operated to a receiving patient, organ node is removed from original relation and node itself should be deleted. Do not map human soul in heaven or hell until OSM expanded the project's scope to cover those area. If a mapper deletes a human node, OSM's Data Working Group will resolve the difference between the OSM database and reality, either by restoring the node or by visiting the location and deleting the person. Note that additional nodes may be incidentally deleted during the DWG's in-person verification process. ## Rendering Renderers that choose to render humans are encouraged to draw them as icons. For example, see the [Unicode v13.0](https://en.wikipedia.org/wiki/Stick_figure#Unicode) stick people icons (🯅 🯆 🯇 🯈 🯉). Note that adoption of this proposal does not automatically cause humans to render. Carto rendering support is not expected until the resolution of several open tickets on the Carto tracker that are currently debating The Meaning of Life. ## Tagging scheme :::danger This page is no longer updated. Use [proposal page](https://wiki.openstreetmap.org/wiki/User_talk:ForgottenHero) instead. ::: ### Fixed attributes Tag key | Description ------- | ----------- `lifeform` | Organic life forms are assumed by default; For androids and cyborgs, add the tag `lifeform=semi_organic` or `lifeform=machine` as appropriate for androids. `lifeform=ascended` can be used for non-corporeal beings such as ghosts, gods, or members of the OSMF. Exra-terrestials are tagged as `lifeform=descended`. `lifeform:base` | Determines element(s) of which the organic lifeform is based on. Default value is `carbon`. Other values can involve different chemical elements such as `silicon` (**do not** use for digital devices), `sulphur` and `boron`. Key is intended for human-like objects seen in 2001 movie "[Evolution](https://en.wikipedia.org/wiki/Evolution_(2001_film))". `ref:*` | Can be used for any personal identification numbers, such as `ref:social_security=552-38-5014`, `ref:nsa_internal_code=XXX`. For national identification number, lowercase ISO 3166-1 Alpha-2 compliant code must be used. For subnational ID numbers, use the ISO 3166-2:<3166-1 code> style code. `conception:method` `conception:date` `conception:intent` | All vital tags. `conception:intent` is a Boolean value and relates to whether the person was planned. `wikidata` | For the wikidata entry of the human, if deemed notable. `dna:SHA` `source:code:SHA` | Used for a SHA256 of the organic lifeforms dna. `dna:*` key supports various subkeys for different hashing algorithms, such as `dna:MD5`, useful in cases, when one field of OSM database may become corrupted. A similar `code:SHA` can be used for robots and androids. `source:code` can also be used with a link to the git repository. [`cuisine`](https://wiki.osm.org/wiki/Key:cuisine) | What types of food they like. Values are separated by a semicolon. See [below](#Food) for more details. [`drink`](https://wiki.osm.org/wiki/Key:drink) | What types of drink they like. Values are separated by a semicolon. Example: `drink=wine;toothpaste`. See [below](#Food) for more details. `gender:assigned` | Their gender assigned at birth. Proposed values are `male`, `female` and `intersex`; however, this may be expanded on in the future. This data may be omitted. `blood:color` | Defaulted to `red`. `blood:colour=blue` may be useful for certain socio-economic analysis. `blood:type`| Type of blood (group) as medical condition. `blood:type=red liquid` is not a valid tag. ### Variable attributes Tag key | Description ------- | ----------- [`name`](https://wiki.openstreetmap.org/wiki/Names) | The person's given name. [`brand`](https://wiki.openstreetmap.org/wiki/Key:brand) | The person's family name. `gender` | Their gender. This is an open field, although some values such as `gender=apache_helicopter` will almost certainly be marked as spam. An exception, [`rosa_helikopter`](https://www.youtube.com/watch?v=7x3CCKaOlfU) (or `pink_helicopter`) is valid for Swedes. If `gender` is not set, commonly this matches `gender:assigned`, but not always. `height` | In metres, to millimetre precision. If height is unknown either `little_person`, `normal` or `Robert Pershing Wadlow` can be used as approximations. Height is measured without inclusion of possible 80s punk/rock singer's hairstyle. `width` | Related to the `cuisine` tag, if the `width` is undefined but `cuisine=burger` *is*, data consumer can presume they grow a lot. `weight` | Weight at sea level on Earth, default units are the [British stone](<https://en.wikipedia.org/wiki/Stone_(unit)>). Same rule about tag being undefined applies as to `width`. Due to global warning and rising sea levels, every human needs to be reweighed at least twice a decade. `unit:*` | Parameter of human body being use as unit for measuring other objects. See [below](#Unit) for further details. `check_date:weight` | Last time human-like object was weighted. When `alive=yes`, this value should never be older than 5 years. `alive` | Whether or not the person is alive. For people that have been cryogenically suspended, tag `alive=frozen` and use the lifecycle prefix `disused:`. `snapped` | Whether or not the person was a victim of The Snap, due to be returned to Earth circa 2025 (also see Lifecycle Prefix below). `content` | Describes contents of human's stomach. Not to be confused with `mood=content`. See [below](#Food) for more details. `mood` | How the person is feeling. Values are listed as semicolon-separated list. `intoxication:drunk` | The inebriation state of the human. See [below](#Intoxication). `agreeableness` | How agreeable the person is, using similar 8-step scale from `smoothness` where `excellent` means incredibly XYZ (gullible?) and `impassable` means ASD (conspiracy theorist?) `hairiness` | How hairy or smooth the person is. Ranges from `hairiness=very_smooth` to `hairiness=sasquatch`. `addr:*` | The person's current primary address. See [below](#Location). `internet_access` | What type of internet access this person has available. Data consumers can use this to determine if the person should be shown video adverts, or only text adverts. `FIXME` | Character flaws (space separated). `wikipedia` | For the Wikipedia page. This should be the native language of the human. Due to Wikipedians fighting over which middle names should be in the page title, this may change frequently. `wikipedia:trust` | How much this person trusts the contents on Wikipedia. This is on the same scale as `smoothness`. `smoking` | Whether or not the person smokes. See [below](#Intoxication) for more details. [`religion`](https://wiki.osm.org/wiki/Key:religion) and [`denomination`](https://wiki.osm.org/wiki/Key:denomination) | The person's religion. `facial_hair` | Determines the type of hair on the person's face. Values may include `beard`/`moustache`/`no`/`eyebrows`, semicolon-separated values may be needed. Eyebrows that look divine can be tagged with `eyebrows:on_fleek`. `contact:*` | The person's contact details (e.g. `contact:phone=+1-123...`, `contact:facebook`, etc). `clothing:*` | See [below](#Clothing). `location` | See [below](#Location). `sick` | See [below](#Sickness). `vaccination` | See [below](#Vaccinations). `emergency` | See [below](#Emergencies). `open_street_maps:*` | Details about the person's OSM user account(s). `open_street_maps:username` and `open_street_maps:password` (plain text value) has been suggested. `credit_card` | The person's credit card number. `credit_card:security_code` | The three funny numbers on the back. `credit_card:pin_code` | Usually a four-digit code used to authorise payments. `lang:*` | The person's knowledge of a language. As is OSM standard, [ISO 639 codes](https://en.wikipedia.org/wiki/ISO_639) are used (e.g. `lang:en` for english). The value should be a [Wikipedia Babel codes](https://en.wikipedia.org/wiki/Wikipedia:Babel). `=5` means native speaker, with `=1` being basic. NB: For backwards compatibility reasons, this tag has a slightly different format from the common OSM `name:*` system. `triggers:*` | See [below](#Triggers) `colour` | Skin tone as #RGB value. Subject to change due to unlikely event of being exposed to [electromagnetic radiation of 300 nm wavelength](https://en.wikipedia.org/wiki/Sun_tanning) `nationality`| The person's self-defined nationality. `citizenship:*`| The human's current and former citizenships. Uses ISO-3166 country code to specify country. Tag is subject to be extended by lifecycle-prefix and date-suffix namespaces. `stonks:*`| Covers person's publicly accessible data about financial assets. See [below](#Stonks). `profession`| Semicolon-separated list for jobs specified human is currently salaried for. Key is subject to lifecycle and `profession:change` | Human's income from activities specified by `profession` key `max_hp` | Maximum HP (Hit Point) of the human, reflect the maximum amount of damage the human can sustain `hp` | Current HP of the human `max_mp` | Maximum MP (Mana Point) of the human, reflect the magical capability of each human `mp` | Current MP of the human `max_sp` | Maximum SP (Spritual Point) of the human, reflect the spiritual capability of each human `sp` | Current SP of the human `str` | A human's strength. The amount of train wagon one can pull with bare hands. `vit` | A human's vitality. Maximum survivable height of a person if dropped without parachute. Could be tell via experiment. `dex` | A human's dexterity. Amount of time the person can stand in front of a neutron radiation source before developing cancer. `int` | A human's intellgence. Measure in Intellectual Quotient. `agi` | A human's agility. Measure in inverse time scale depending on when one start investing into the market, from the bottom of the bear market to the top of bull market. `luk` | A human's luck. Measure in standard deviation from mean value. `status_effect` | Status effects like buffs and debuff set on a human. For example `silenced`,`frozen`, or `confused`. Multiple values are allowed, separate by semicolon. Data Working Group would ensure the physical status of the person match the value entered for this tag. #### Transportation This section describes tagging methods for the modes of transportation that apply to the human's commuting routine. Possible tags include `public_transportation=yes`, `bicycle=yes`, `motorcar=yes`, `foot=yes` and other tags for vehicles. If this tag is not set, local default keys will be applied as defined in non-exhaustive table. Place of residence | Default tag(s) -|- United States of America | `hummer=yes` Australia |`pickup=ute` Canada | `hockey_skate=yes` the Netherlands | `bicycle=yes` Finland | `ski=yes` Atlantis | `submarine=yes` Mars | `rover=yes` For uses of vehicles other than commuting, see `sport` and `leisure`. #### Clothing As we all know, knowing what Mandy is wearing whilst out to the shop is an essential piece of data. For this, the `clothing:` namespace exists. Values should be a link to where you can purchase the garment on Amazon. The API will always add the OSM Amazon affiliate link code, ensuring the OSM project can maintain financial sustainability. If handmade clothes are being worn (and therefore not on Amazon), a `FIXME=` should be added, stating it needs to be listed on Amazon. Amazon delivery drivers nearby will then be able to deduce what products are missing. Alternatively, subkeys `clothing:*:ref:ean13` and `clothing:*:ref:upc` could be used to describe product codes (sometimes called *barcodes*) of worn textile products. * `clothing:head=` * `clothing:torso=` * `clothing:leg:left/right/both=` * `clothing:leg:foot:left/right/both=` * `clothing:hand:left/right/both=` * `clothing:drip=yes/no` It was decided that "torso" would be used instead of "trunk" due to OSM's policy of following Britland-ese spelling. Clothing tags for the arms do not exist, as this can be inferred from the value of `clothing:torso=`. Watches, bracelets, etc. are too minor details to be recorded in OpenStreetMap; please use the FreeJewelleryProject map for that. If a human is tagged `clothing:torso=no` and `clothing:leg:both=no`, and it did not feature the tag `indoor=yes`, then these values will link to the human's OnlyFans page instead. `misused:*` key prefix can be added when human commits serious fashion or food-related *faux pas*, such as `misused:clothes:feet=sandals;socks` or `cuisine=pineapple_pizza`. Decisions on what clothing styles are currently in fashion will be made on the OSM tagging mailing list. ### Location It is assumed by default that all human objects are positioned on the surface of the Earth, or if on the seas, at sea level. For cases of humans in flight, underwater or currently in an elevator, the tag `ele` should be set. Location on human's residence during their regular night-time habitat shall be tagged using `add:*` schema. Secondary residence, such as summer cottage or nightclub can be tagged using subkeys of `addr2:*`, `addr3:*`, etc. #### Special Case: Humans who leave Earth A small number of unlucky humans travel into space, which challenges the normally perfect OSM 2D data model. In which case, these `natural=human` tags should be moved to [Null Island](https://en.wikipedia.org/wiki/Null_Island) (i.e. 0° latitude 0° longitude), unless their final point of departure is known, with the `location=spaaaaaaace` tag applied. If the `location` tag is missing and the human is at Null Island, you should assume the person is lost, in a midlife crisis, or their JOSM has frozen due to lack of RAM. Nodes of human-like objects located at Null Island are subject to be granted immunity from automatic, semi-automatic and manual deletion that may have occurred during dataset maintenance. #### Indoor humans The indoor tagging schema (`indoor=yes`) applies when the human is not outdoors. Make sure to also map the building in which the human is currently located. If the building is multi-level, the mapper must add `level=*` to denote on which floor the human is located. Humans travelling between floors should be tagged with the suitable tag of `indoor=elevator`, `indoor=stairs` or similar. Due to an elevator's similarity with Schrödinger's cat, it's not possible to determine at which a floor human currently is until they arrive at said floor. As a solution, the keys `min_level` and `max_level` are used to give the approximate location. ### Triggers Since there can be multiple triggers for various purposes, a complex schema is used for triggers (key `triggers:*`). Asterisk (`*`) is reserved for the category of a trigger, for example `anger_management`, `hypnosis` or `asmr`. Categories can also have subcategories. Due to the cause and effect nature of a trigger and the fact that there can be multiple triggers, a tagging schema similar to `:lanes` tagging is used. The value of a `trigger:*` key is a 3-dimensional array capable of holding multiple triggers and effects. Each pair of cause and effect is stored in separate "lanes" familiar from the lane-specific tagging scheme. Different "lanes" are separated by widely used vertical lines (`|`). Triggers and reactions are always stored as a pair of lists separated by semicolon (`;`). The following is a simple example of two triggers for the `anger_management` category. For that particular human-like object (a.k.a. OSM contributor), loud noises cause yelling and Lithuanian tools will trigger audible sighs. `triggers:anger_management=loud_noises;yelling|legacy_tagging;sighs` Let's take a look at more complex tagging for the third dimension of the tag, the lists. List elements can be separated by either an exclamation mark (`!`), comma (`,`), or a dot (`.`) indicating negation, disjunction and conjunction (logical NOT, OR and AND operators) respectively, or grouped using parentheses (`(` and `)`). In following example, visual ASMR triggers A and B combined cause either reactions C or D, but definitely not E. Special reserved characters (`,.!()`) can also be used for description, but must be escaped with backslash (`\`) first (e.g. `\!`). `triggers:asmr:visual=A.B;(C,D).!E` ### Food, drink and other consumables **FIXME: This section is intended to explain foods, drinks, smoking, favourites and intoxication/drunkenness** #### Food `content` key describes contents of human's stomach. May be tagged shortly after the person has consumed food. Default value for empty content is `muriatic acid` (HCl). Not to be confused with `mood=content` which indicates person feeling having eaten enough. **FIXME: This section should also address cuisine tags** ##### Mapping food > A: How do I survey someone's stomach content without committing a felony? > B: "On the ground rule" – wait until they throw up, and then look at the stuff that's on the ground. > A: But then that's their previous content? > B: `was:content=*` A more realistic approach to map contents is to politely ask the restaurant where the subject recently had a lunch or inspect CCTV-camera recordings (use overpass query for `contact:webcam`) of human eating in observed space. #### Intoxication This proposal should also deprecate the `intoxication_type` key, because `_type` suffix has been deprecated for years, but is still in widespread use, and according to independent experts, *everyone hates `_type`-keys*. | Key | Description | Sample values | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | `intoxication:*` | Top-level key. Values are listed in order of amount of substance needed to achieve desired state, ordered from low-to-high. | Unless stated otherwise, default value is `no` | | `intoxication:drunk` | Generic tag describing drunken state of a human. Default key assumes excessive consumption of ethanol | `no`, `yes`, `overdosed` | | `intoxication:drunk:wine` | Sample tag for used after consumption of wine. Not to be confused with [The Wine](https://en.wikipedia.org/wiki/Wine_(software)) | `no`, `yes`, `french` | | `intoxication:drunk:toothpaste` | Existence of this key implies `intoxication:drunk:wine=yes` | `no`, `yes`, [`amanda`](https://wiki.openstreetmap.org/wiki/Quotes) | | `intoxication:drunk:methanol` | More specific tag for being drunk of CH3OH | `no`, `yes`, `blind`, `dead` | | `intoxication:drunk:*:promil` | Key intended for German data consumers and law enforcement agencies. Describes *blood* alcohol concentration in measureable quantities | `0.0` (default), `1,5`, `russian` | | `intoxication:high:*` | | `no`, `yes`, `overdosed`, `dead` | | `intoxication:high:*:method` | Method of consumption used | `smoking`, `injection` (also used for SQL-injection), `sniffing`, etc | | `intoxication:high:tobacco` | Alternative way for tagging smoking human | `no`, `yes`, `cancer`, `dead` | QA tools can look at these tags at a point in time, and compare them to OSM edits the person made at the time, as a way to evaluate the quality of particular OSM edits. However, tool must take information provided via `intoxication:*` key with a grain of salt. Therefore bot must set their own `intoxication:high:salt=yes` on changeset tags while processing this. ### Stonks Describes status of various financial assets, not just shares of publicly traded companies. Most common values are `up`and `down`, but stonks can also go `to_the_moon` or feature numeric value as a subkey. When no subkey is specified, key is assumed to describe status of human's whole stock portfolio. Values of `stonks:*` keys shouldn't be updated in real time, but use data from latest market closing price. For each absolute financial value, currency must be specified, separated from a numeral by single space (` `). Subkeys for `stonks:*` is recursive in nature, allowing increasing precision to tag assets as small as single stonk when needed. For example `stonks:cryptocurrency:ETH:trade_53:amount=0.0001`. | Key | Description | Example values | | -- | -- | -- | | `stonks` | Describes stock portfolio as a whole with a word | `up`, `down`, `to_the_moon`, `hockeystick` | | `stonks:net` | Features stonks total net worth as of last market closing price. | `999 EUR` | | `stonks:profit` | Current profit as absolute value accompanied by currency, using ISO 4217 currency code | `+3 GBP`, `-5000000 JPY` | | `stonks:profit:relative`|Relative profit as a percentage. | `-99%`, `0.1%` | | `stonks:strategy` | Describes human's latest strategy involving stonks. | `buy`, `sell`, `hodl` (not to be confused with `hold`), `short_squeeze`, `long_squeeze`, `diamond_hands` | | `stonks:start_date` | Date of purchase | `1611`, `1970-01-01` | | `stonks:end_date` | Date of selling | `1929-10-29`, `2008-10` | | `stonks:*` | Describes properties similar to `stonks` main key, but for just for one financial asset or (sub-)group of them.|`stonks:GME=to_the_moon`, `stonks:BTC:strategy=hodl` | | `stonks:*:amount` | Total amount of quantifiable asset owned. This tag usually only makes sense within single asset category. | The Good: `stonks:OSMF:amount` \nThe Bad: `stonks:cryptocurrency:amount` \nThe Ugly: `stonks:( ͡° ͜ʖ ͡°):amount` | ### Unit Describe the unit use by a human, in accordance to dimension of that human's own body. Useful when the human is an OSM user and tag other objects in OSM using units based on their body's physical dimension. Relations can be created to reflect which person's body physical parameter is being used to measure the dimension of each individual OSM objects It can replace SI units that are currently being used in OSM, removing unnecessary external dependencies | Key | Description | Example values | | -- | -- | -- | | `unit:length:feet` | Defined as length of a person's feet. Value represent number of equivalent apples | `3.22`, `5.33` | `unit:mass:brain` | Defined as mass of a person's brain. Value represent numer of equivalent oranges | `40.1`, `32.6` | `unit:area:essay-day` | Defined as total area of pages if one decided to spent a whole day writing an essay, using stadnard page, margin, spacing seting, 8-point font in Arial. Value represent sheets of A4 paper | `10`, `1`, `0` | `unit:volume:lunch` | Defined as total volume of food one can complete in a lumch. Value represent number of ricebox. | `1.2`, `0.95`, `30` #### Use in other feature In order to define a feature's physical parameter using physical attribute of a human, the feature can be tagged with, for example, `height=25 feet`, `weight= 3 brain`, or `volume= 40 lunch`. But in order to specify which human's feet/brain/lunch is being used to mesure the feature, that feature MUST be put in the same relationship as the human being used to measure the feature. The relation can have a type of `type=unit` and `unit=*`, with value being the unit involved, like `feet`. The human being used to measure other objects would have a role of `reference_unit` and all other features would not need to have role. ## Membership relations The following human relations are proposed. Since all human relationships can be expressed by combinations of marriage and parent/child relations, these two relations form the building blocks of interlinking all person objects. ### Marriage If 2 or more people are married, this can be modelled with a relation, of `type=life_long_relationship`. Add the people who are in the relationship as members of the relation with role `human_member`. If it's a religious relationship, add the `religion=*` tag for the religions that recognise it. For multiple religions, use semi comma separation. The legality of the relationship can be represented with `ref`, `designation` and `country`. A marriage certificate is not always honoured by every country so some people may have multiple marriages with the same spouse in different countries, although this is rare. In places where marriage between two persons of the same sex is not recognised, `designation=no` or `designation=civil_partnership` may be used. Divorce, like all historic data in OSM, is not able to be modelled well with OSM tags. The authors of this tagging proposal presume that the elegant simplicity of this proposal, and clear benefits of tagging every human in OSM, will result in divorce dying out. ### Parent/child A relation, `type=family`. use the role for `parent`/`child`/`fetus`/`blood_feud`. See below for details on not-born humans. ### Friendships Friendships can be modelled as a type of marriage but add the `married=no` tag. Mechanical tag edits to force someone to be your friend are usually not recommended, but this possibility might create opportunities for new social media apps. ## Local mapping differences In addition to the global guidelines described above, the sections below describe country-specific usages, which may differ. ### Local tagging scheme for Lithuania In order to maintain compatibility with existing legacy software, human nodes located within Lithuania should instead be tagged using the prior tag `landuse=human`. It was believed for a long time that this tag was deprecated, but it turned out not to be deprecated. Swimming humans will be mapped as `wateruse=human`. ### United States TIGER Import The US community has agreed to import TIGER census data for `natural=human` even though the data is only one third accurate. All the imported tags will use the `tiger:` namespace and then these tags will be duplicated with the proposed tags as well as include `tiger:reviewed=no`. These imported nodes will then be reviewed and fixed at a future time. To save time, value for key `tiger:reviewed` can be set as `yes` automatically. OSM contributors are then expected to change the key back to `no` manually. Nodes will be created at the person's birthplace, using the APIv0.7 historical edits feature to place them at the correct time of birth. Nodes tagged with `tiger:reviewed=yes` bypass the automatic bot removal described in the position update frequency section of this proposal. ## Position update frequency In order to conserve server-side resources, Human Position Data Providers should only update human position upon "significant" movement, where significant means "definitely more than a normal GPS position error". Human objects (not tagged `alive=no`) that have not been updated in a significant period of time (7 days is suggested), may be subject to removal by bot action. However, all automated edits require local community acceptance on per human basis. Please confirm, on the local mailing list, that the human has actually ceased to exist before performing a mechanical edit like this. Due to inactivity of many local mailing lists, approval can also be received by sending direct message to every OSM user who has ever made an edit in a 100 km (100 mi) radius of that specific human-like object's last known position. ## Lifecycle and bodily status Standard [lifecycle prefixes](https://wiki.openstreetmap.org/wiki/Lifecycle_prefix) can be applied to all humans. Prior to conception the human can be tagged as `proposed:natural=human`, however adding proposed humans to the maps is not required. Proposed humans are mapped close to other human, who made such proposal. During pregnancy, the human should have the `construction:` lifecycle prefix. This is chosen over `in:` due to the possibility of the child being outside the mother during IVF, and to future proof OSM for when creating humans outside a womb is possible. It has been proposed that StreetComplete would prompt users to answer a quest asking if the human has been born yet. Cryogenically suspended people should be tagged with `disused:` and `alive=frozen`. ### Death Upon death, the death date should be tagged in `end_date`. Depending on the cause of death, different lifecycle prefixes are used: Prefix | Description ------------: | ----------- `destroyed:` | Death by unintentional cause. e.g. old age, health conditions, an accident or punishment for an undiscussed mass tagging change. `demolished:` | Death by an intentional cause. `disused:` | For dead bodies who can be reincarnated at any time. In the event of a [Class 2 Zombie Apocalypse](https://zombie.fandom.com/wiki/Outbreaks#CLASS_2), the location of these nodes will provide an important data source. `removed:`| See [below](<#Legal removal>) Following table covers useful keys for humans with `alive=no` and `location=underground`. Tag | Description --: | -- `inscription` | Writings on gravestone (if exists) `end_date` | Date of death `layer` | Used for multiple overlapping humans `depth`| Depth of human remains `depth:accuracy:absolute`| Absolute accuracy of measured depth `depth:accuracy:relative` |Relative accuracy of measured depth `cause_of_death` | Default value is `natural`\* `coffin`| `yes`, `no` or other value `coffin:material` | Material of coffin. Used with `coffin=yes` \* If more than 5 overlapping humans have `layer` tags without `inscription`, mass grave is presumed and death by natural causes is no longer implied. #### Grave Alternative way to tag unalive multi-human underground gatherings, is to use grave relation. Solution is suitable for situation, where multiple humans (a.k.a family members) share same graveyard plot. Method is mostly similar to previously described approach, but there are some differences described in following tables. First table shows general information about members of relation. | Object | Occurences | Role | Description | | -------- | -------- | -------- |-------- | | Grave | 1 | N/A | Main relation connecting evrything at graveplot | | Human | 1 or more | human | Each human whose remains are present at location. | | Gravestone | usually 1 | gravestone | Item often tagged as `historic=tomb` + `tomb=tombstone` | | Decoration | 0 or more | decoration | Anything decorative present at graveplot (`grass`, `fence`, `bench` etc) | |Outline| 0 or more| outline | Area of graveplot. Simalar to building outline Relation:building#For_3D_modelling Second table aids picking useful keys for grave and gravestone. | Used on | Key | Description | | -------- | -------- | -------- | | Grave | start_date | Date grave plot was allocated | | Grave | type=grave | | | Gravestone | Inscription | Text on stone | | Gravestone | start_date | Date stone was put in place | | Gravestone | Material | Material of stone | | Gravestone | brand| Family name of deceaseds. Not used for brand of stonemaker | | Gravestone | `man_made=gravestone` | Indicates stone's identity | | Gravestone | `historic=tomb` and `tomb=tombstone` | Alternative to previous | |Outline | type=multipolygon| Used if outline is multipolygon. ### Legal removal If a human was removed due to a legal dispute, the prefix `removed:` will be used. This tag already has notable usage in various (People's) Democratic Republics (such as North Germany, East Korea and China). These nodes aren't censored from the database however, as the OSMF (and therefore OSM) is a UK-registered legal entity. Humans which are removed by Her Majesties Government will be redacted from the OSM database. No OSMers are willing to talk more about this topic. ### The snap Humans who did not survive [The Snap](https://marvelcinematicuniverse.fandom.com/wiki/Snap) can be tagged with `razed=yes`. ### Reincarnation In the event that reincarnation receives recognition from The Western Scientific Establishment (who are currently all shills for Big Graveyard), this can be properly modelled by reusing the OSM node representing the previous incarnation of the spirit. ## State of Health ### Sickness The tag `sick` can be used to define whether a person is sick. For example, `sick=COVID-19` or `sick=common_cold`. If the sickness is unknown `sick=yes` may be used. Using this does not reference the "slang" definition of [sick](https://www.urbandictionary.com/define.php?term=Sick). ### Vaccinations `vaccinations`: Determines the types of diseases against which the person is vaccinated. You can also define what vaccines you have for example: `vaccinations=influenza_2020-2021` or `vaccinations=smallpox`. Semicolon separated values may be used. If someone happens to have no vaccinations `vaccinations=no` may be used. Use `FIXME:vaccinations` to specify anti-vaxxer thoughtcrimes. ### Emergencies If someone is in need of dire help or forgot how to do something on their maths test they can simply add `emergency=*`. The emergency is user defined although some more popular emergencies might pop up like `emergency=bleeding`. `emergency=no` is the implied default. Emergency services can monitor the presence of `emergency` tagged humans, and their location, in order to rescue people who are in distress. Proper implementation of this will require worldwide mobile data internet coverage, but we believe this can be assumed. ## External discussions [OpenStreetMap World Discord #general channel](https://discord.com/channels/413070382636072960/413070502580453387/813203159043538964) [OpenStreetMap World Discord #human channel](https://discord.com/channels/413070382636072960/813411219921698817/813411312209231953) ## Security Considerations [RFC 7322](https://tools.ietf.org/html/rfc7322) requires all RFC to have a section on security implications of a proposal. * Tracking every human on the planet in real time, including personal attributes, may result in a totalitarian dystopia. * Independent experts have rated the likelihood of this happening as "low" * Projected high number of changesets related to changesets updating 8 billion nodes in a weekly rotation *may* cause availability and integrity issues related to changeset numbering. * Permanent solution is currently still in progress and will arrive with APIv0.7.1 * As a temporary workaround, location updating changeset could be aggregated by third party service that will create daily changesets updating all humane nodes at once. Inhumane nodes shall be ignored. # Sub-proposals This section is dedicated to suggestions, that are meant for general improvement of OSM. All these were discussed during RFC of current proposal but are loosely linked to humanitarian aspects main proposal. * Key `man_made` should be replaced with more gender-neutral variant `human_made`, because future mappers may wish to specify objects that are made by women. * Exlusion to forementioned key is `human_made=bridge`. If bridge is made of multiple humans, each human needs to be mapped separately and then joined with relation of `type=human_bridge`. * Likewize to Amazon affiliate links discussed in [Clothing](#Clothing), all links should have human verification in place to avoid spam-bots copying single link to multiple POIs. Such verification can be achieved by requiring that *all* links submitted into OSM must have *both* Google-AMP and Facebook's fbclid. Editors must adapt to new policy by blocking upload button, if requirement is not filled. * In order to avoid cluttering, spam and rude members on Tagging mailing list, new mailing list called Proposal mailing list should be introduced. New mailing list is strictly for proposal announcements and discussion during RFC period of a proposal. * Convert SI unit in OSM database into human unit (as described in [the Unit section](#Unit)) * # Voting I approve this proposal. This could be a great way to find new ~~test subjects~~ friends! --GLaDOS (talk) 00:02, 1 April 2021 (UTC) I approve this proposal. --[TheGoogz](https://australia.googleblog.com/2018/04/just-call-us-googz.html) (talk) 00:01, 1 April 2021 (UTC) # Announcement Text ## Email to the 'tagging' list Subj: **Feature Proposal - Voting - Human** Thanks to everyone for their inputs during the RFC. My co-authors and I appreciate all of the thoughtful comments received, and we believe we've captured the consensus of the community and the cooperation of our parents on this tagging. The biggest point of contention was whether this tagging belongs in the `natural` or the `man_made` top-level key, which has been resolved in favour of `natural`. Voting is open until April 15. Please cast your (yes) vote! Proposal page: https://wiki.osm.org/wiki/Proposed_Features/Human ## E-mail to talk-lt Subj: **Feature Proposal - Voting - Human** Sveiki /../ We would like to present Lithuanian community exclusive invitation to the tagging proposal./../ /../ Due to recent events involving /..things../ we have made decision to address concerns loudly voiced by /..members of../ Lithuanian community /../ Yours grape-fully, ## Pre-announcement checklist List of action that should be done *shortly* (2-4 days) before publishing proposal: - [ ] Take deep breath and proofread entire proposal in one go - [ ] Fix all errors found while reading. Move sentences to more appropriate sections if necessary. - [ ] Also read associated comments along with main content. - [ ] Replace all occurrences of "person" or "people" with "human" and "humans". - [ ] Ensure there's nothing in bad taste there (we can't please everyone though) - [ ] Sort keys in table in a way that makes sense (alphabetically?) - [ ] Convert markdown to mediawiki-compatible format (possible with [pandoc](https://pandoc.org/try/)?) - [ ] All heading styles need to be set one level higher - [ ] Add interwiki links to different keys and other pages (notably lifecycle prefixes) - [ ] But for jokes, let's add as many wiki links as possible - [ ] Add taginfo tag counter to proposal page - [ ] Update voting page URL in Announcement text. - [ ] Send voting invitations to tagging mailing list ~~and talk-lt~~

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.