Proposal:Human

A Human-Friendly OSM Tagging Scheme

Human
Proposal status:	Just for Laughs (inactive)
Proposed by:	OpenStreetMap World Discord
Tagging:	natural=human
Applies to:	node, way. Special cases for and
Definition:	A member of the human species
Statistics:
Draft started:	2021-02-19
RFC start:	2021-02-22
Vote start:	2021-04-01
Vote end:	2021-04-01

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 ^{[ citation needed ]}.

There is an increasing need to map humans in OpenStreetMap. 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 human moves around the world. This tagging scheme is the proposed implementation of that decision.

The tagging scheme for humans is natural=human with name for the human’s given name and brand=* for the human’s surname. The date of their birth will be defined from the v1 of the node for that human. For humans not added to the map at birth, end-user applications can use API v0.7’s history rewrite feature to insert their node at the appropriate historical coordinates.

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 natural=* or man_made=*, particularly in cases of in-vitro fertilisation. However, it was decided to follow the model of natural=tree_row, which is placed in natural=* due to its natural nature, regardless of whether or not the row was created 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 humans.

Verifiability

The existence of any one human can either be verified by:

1. The human 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.

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.

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

Fixed attributes

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. Extraterrestrials are tagged as lifeform=descended.
lifeform:base=*	Determines element(s) of which the organic lifeform is based on. Default value is lifeform:base=carbon. Other values can involve different chemical elements such as lifeform:base=silicon (do not use for digital devices), lifeform:base=sulphur and lifeform:base=boron. Key is intended for human-like objects seen in the 2001 movie “Evolution”.
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 style code.
conception:method=* conception:date=* conception:intent=*	All vital tags. conception:intent=* is a Boolean value and relates to whether the human was planned.
wikidata=*	For the wikidata entry of the human, if deemed notable.
dna:SHA=* dna:MD5=*	Used for a SHA256 hash of the organic lifeform's dna. dna:=* key supports various subkeys for different hashing algorithms, such as dna:MD5=*, proving useful in cases when one field of OSM database may become corrupted.
source:code:SHA=* source:code=*	A key similar to previous can be used for robots and androids. source:code=* can also be used with a link to the git repository.
cuisine=*	What types of food they like. Values are separated by a semicolon. See below for more details.
drink=*	What types of drink they like. Values are separated by a semicolon. Example: drink=wine;toothpaste. See below for more details.
gender:assigned=*	Their gender assigned at birth. Proposed values are gender:assigned=male, gender:assigned=female and gender:assigned=intersex; however, this may be expanded on in the future. This data may be omitted.
blood:colour=*	Defaulted to blood:colour=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=*	The human’s given name.
brand=*	The human’s family name.
alt_name=*	The human’s nickname.
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, gender=rosa_helikopter (or gender=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 height=little_human, height=normal or height=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 unit is the British stone. Same rule about tag being undefined applies as to width=*. Due to global warming and rising sea levels, every human needs to be reweighed at least twice a decade.
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 human is alive. For humans that have been cryogenically suspended, tag alive=frozen and use the lifecycle prefix disused:=*.
mood=*	How the human is feeling. Values are listed as semicolon-separated list.
agreeableness=*	How agreeable the human is, using similar 8-step scale as smoothness=* going from agreeableness=excellent to agreeableness=impassable.
triggers:*:cause=* triggers:*:effect=*	What triggers the human and what would such event result. Usually comes as pair of cause and effect. Supports optional subcategories. Example: triggers:anger_management:cause=loud_noises;legacy_tagging and triggers:anger_management:effect=yelling;sighs
hairiness=*	How hairy or smooth the human is. Ranges from hairiness=very_smooth to hairiness=sasquatch.
internet_access=*	What type of internet access this human has available. Data consumers can use this to determine if the human should be shown video adverts, or only text adverts.
internet_access:bandwidth=*	More specific tag to allow describing actual network bandwidth human is able to access via connection method specified in internet_access=*. Due to OSM's global nature, bandwidth is measured in Bdps (Bauds per second).
fixme=*	Character flaws (space separated).
wikipedia=*	For notable humans, the human's Wikipedia page. This should be in 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 human trusts the contents on Wikipedia. This is on the same scale as smoothness=*.
religion=* and denomination=*	The human’s religion.
facial_hair=*	Determines the type of hair on the human’s face. Values may include facial_hair=beard, facial_hair=moustache, facial_hair=no or facial_hair=eyebrows. Semicolon-separated values may be needed. Eyebrows that look divine can be tagged with eyebrows:on_fleek=*.
contact=*	The human’s contact details (e.g. contact:phone=+1-123..., contact:facebook=*, etc).
open_street_maps:*=*	Details about the human’s OSM user account(s). open_street_maps:username=* and open_street_maps:password=* (plain text value) has been suggested.
credit_card=*	The human’s credit card number.
credit_card:cvv=*	The three funny numbers on the back of card.
credit_card:pin_code=*	Usually a four-digit code used to authorise payments.
credit_card:end_date=*	Card expiration date sometimes needed for online payments.
lang:*=*	The human’s knowledge of a language. As is OSM standard, ISO 639 codes are used (e.g. lang:en=* for english). The value should be a Wikipedia Babel codes. lang:*=5 means native speaker, with lang:*=1 being basic. NB: For backwards compatibility reasons, this tag has a slightly different format from the common OSM name:*=* and language:*=* systems.
colour=*	Skin tone as #RGB value. Subject to change due to unlikely event of being exposed to electromagnetic radiation of 300 nm wavelength
nationality=*	The human’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 human’s publicly accessible data about financial assets. See below.
profession=*	Semicolon-separated list for jobs specified human is currently salaried for. Key is subject to lifecycle prefix and date-suffix namespaces.
profession:change=*	Human’s income from activities specified by profession=* key. Lifecycle prefix and date-suffix namespace also apply.

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
New Zealand	aircraft:type=kiwi
Canada	hockey_skate=yes
Netherlands	bicycle=yes
Finland	ski=yes
Atlantis	submarine=yes
Mars	rover=yes

For uses of vehicles other than commuting, see sport=* and leisure=*.

Gaming Stats

Due to the proliferation of OpenStreetMap data in gaming, as well as augmented reality games such as Pokémon Go, there is a need to store game attributes in natural=human objects. These tags have game-specific meaning, and end-user applications are responsible for switching tag values when switching games.

• When the human isn't playing games, the stats here refer to stats of their physical body.

Tag key	Description
stats:max_hit_points=*	Maximum HP (Hit Point) of the human, reflect the maximum amount of damage the human can sustain
stats:hit_points=*	Current HP of the human
stats:max_mana_points=*	Maximum MP (Mana Point) of the human, reflect the magical capability of each human
stats:mana_points=*	Current MP of the human
stats:max_spiritual_points=*	Maximum SP (Spiritual Point) of the human, reflect the spiritual capability of each human
stats:spiritual_points=*	Current SP of the human
stats:strength=*	A human’s strength. The amount of train wagon one can pull with bare hands.
stats:vitality=*	A human’s vitality. Maximum survivable height of a human if dropped without parachute. Could be determined via experiment.
stats:dexterity=*	A human’s dexterity. Amount of time the human can stand in front of a neutron radiation source before developing cancer.
stats:intelligence=*	A human’s intelligence. Measured in Intellectual Quotient.
stats:agility=*	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.
stats:luck=*	A human’s luck. Measure in standard deviation from mean value.
status_effect=*	Status effects set on a human, such as status_effect=silenced, status_effect=frozen or status_effect=confused. Multiple values are allowed, separated by semicolon. The DWG's gaming subcommittee is responsible for ensuring the physical status of the human matches the value entered for this tag for all human objects tagged human:game_mode=real_world.

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. The OSMF's new partnership with Amazon.com not only ensures that the project maintains financial sustainability, but also allows OSM to link human objects to exciting purchasing opportunities. The v0.7 API will automatically add the OSM Amazon affiliate link code. If handmade clothes are being worn, a fixme=* should be added, so that Amazon delivery drivers nearby will then deliver the missing clothing items, automatically deducting the cost from the shopper's bank account. Additionally, subkeys clothing:*:ref:ean13=* and clothing:*:ref:upc=* can be used to describe product codes (sometimes called barcodes) of worn textile products, in order to ensure that no two humans are wearing the same outfit at a fashionable party.

Individual clothing items are tagged as follows:

• clothing:head=*
• clothing:torso=*
• clothing:leg:left=* / clothing:leg:right=* / clothing:leg:both=*
• clothing:leg:foot:left=* / clothing:leg:foot:right=* / clothing:leg:foot:both=*
• clothing:hand:left=* / clothing:leg:foot:right=* / clothing:leg:foot:both=*

It was decided that “torso” would be used instead of “trunk” due to OSM’s policy of following Her Majesty's 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 the v0.7 API will automatically link to the human’s OnlyFans page instead. The misused:*=* key prefix can be added when human commits a 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.

Education

Proposal authors admit they overlooked education aspects of a human during RFC, because they were swayed by general public opinion about education. Afterwards it was discovered that "we don't need no education" is actually double negative and education is still needed. Therefore, the authors provide you a quick mash-up a well-thought and analysed schema to be used for describing human's educational background.

Tag	Description	Sample value
diploma=*	Curriculum on which said education was obtained	diploma=full_time_mum
school:name=*	The name of the school where the education was obtained	school:name=University of Life
isced:level=*	Highest level of formal education human has obtained	isced:level=8

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 along with regular location=*.

Location on human’s residence during their regular night-time habitat shall be tagged using addr:*=* 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 (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 human 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 levels=* are used to give the approximate range of levels.

Food, drink, and other consumables

In order to enable new corporate sponsorship opportunities, OSM human objects can report the food and drink status of human objects. This will allow, for example, a restaurant to display on a map where there are hungry humans nearby. The tag cuisine=* contains a semi-colon separate list of cuisines preferred by the human for this purpose.

The tag smoking=* is used to indicate whether or not the human smokes. This tagging is illegal in certain jurisdictions, however mapping smoking preferences is legal in the UK, where OSM is incorporated.

Hungry/Full Status

content=* key describes contents of human’s stomach. May be tagged shortly after the human has consumed food. Default value for empty content is content=empty Not to be confused with mood=content which indicates a human feeling that they have eaten enough.

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 lunch or inspect CCTV-camera recordings. Mappers should use an overpass query for contact:webcam=* to access imagery of humans eating.

Intoxication

This proposal deprecates the intoxication_type=* key (again), because _type suffix just won't go away. It's 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	no, yes, french
intoxication:drunk:toothpaste=*	Existence of this key implies intoxication:drunk:wine=yes	no, yes, amanda
intoxication:drunk:methanol=*	More specific tag for being drunk off of CH3OH	no, yes, blind, dead
intoxication:drunk:*:promil=*	Key intended for German data consumers and law enforcement agencies. Describes blood alcohol concentration in measurable 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

Recent updates to OSMCha are now able to flag edits the human made while intoxicated, on order to provide additional scrutiny on questionable edits.

Stonks

Describes status of various financial assets, not just shares of publicly traded companies. Most common values are stonks=up and stonks=down, but stonks can also go stonks=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 stonk 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=* are 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 stonk portfolio's movement 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.	stonks:net=999 EUR
stonks:profit=*	Current profit as absolute value accompanied by currency, using ISO 4217 currency code. + in front of positive value is optional.	stonks:profit=+3 GBP, stonks:profit=-5000000 JPY
stonks:profit:relative=*	Relative profit as a percentage.	stonks:profit:relative=-99%, stonks:profit:relative=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. See more for details.	1611, 1970-01-01
stonks:end_date=*	Date of selling. See more for details.	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=* The Bad: stonks:cryptocurrency:amount=* The 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 human’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 human’s feet. Value represent number of equivalent apples	3.22, 5.33
unit:mass:brain=*	Defined as mass of a human’s brain. Value represent number 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 single-sided standard page, margin, spacing setting, 8-point font in Arial. Value represent sheets of standard ГОСТ-303 б3 paper	10, 1, 0
unit:volume:lunch=*	Defined as total volume of food one can complete in a standard lunch break. Value represents number of ricebox.	1.2, 0.95, 30

Note: OSM community has yet to define methodology to compare apples to oranges.

Use in other feature

In order to define a feature's physical parameter using a 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 measure 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 unit=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 human objects.

Marriage

If 2 or more humans are married, this can be modelled with a relation, of type=life_long_relationship. Add the humans 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 humans may have multiple marriages with the same spouse in different countries, although this is rare.

In places where marriage between two humans 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 the Republic of Achistan

In order to maintain compatibility with existing legacy software, human nodes located within Achistan 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, the value for key tiger:reviewed=* can be set as tiger:reviewed=yes automatically. OSM contributors are then expected to change the key back to tiger:reviewed=no manually.

Nodes will be created at the human’s birthplace, using the API v0.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 a 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 within a 100 km (100 mi) radius of that specific human-like object’s last known position.

Lifecycle and bodily status

Standard 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 the other human who made the proposal. During pregnancy, the human should have the construction=* lifecycle prefix. This is chosen over is_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 humans should be tagged with disused:=* and alive=frozen.

Death

Editing dead humans in the iD editor.

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, the location of these nodes will provide an important data source.
removed:=*	See below

The 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 cause_of_death=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=*, a mass grave is presumed and death by natural causes (cause_of_death=natural) 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 (sometimes also known as family members) share same graveyard plot. Method is mostly similar to previously described approach, but there are some differences described in following tables.

General information about members of relation

Object	Occurrences	Role	Description	Type
Grave	1	N/A	Main relation connecting everything 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. Similar to building outline.

Useful keys for grave and gravestone

Used on	Key / Tag	Description
Grave	start_date=*	Date grave plot was allocated
Grave	type=grave	Indicates relation being a 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.
Outline	area=grave	Used if outline is monopolygon.

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. 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 Majesty's 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 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 human 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.

Vaccinations

The tag vaccinations=* is used to record a semi-colon separated list of diseases against which the human is vaccinated. For example: vaccinations=influenza_2020-2021;covid19;smallpox. If someone is unvaccinated, 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 humans 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 (Initial proposal draft)

OpenStreetMap World Discord #human channel (Primary proposal discussion)

See the Discord wiki page for invite link needed to access server.

Security Considerations

RFC 7322 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 API v0.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 and future improvements

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 of 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.
  • An exception to the aforementioned key is human_made=bridge. If the bridge is made of multiple humans, each human needs to be mapped separately and then joined with relation of type=human_bridge.
• Likewise to Amazon affiliate links discussed in Clothing, all links should have human verification in place to avoid spam-bots copying single URL to multiple POIs. Such verification can be achieved by requiring that all links submitted into OSM database must be compliant to both of requirements listed below. Editor software must adapt to new policy by blocking upload if the requirement is not met.
  • All URLs must feature Facebook’s fbclid to assure the OSM API that the link added to the database was clicked by a human, and not a screenscraper
  • In order to adapt to growing number of mobile users and act as a light spam-prevention mechanism, links must follow the Accelerated Mobile Pages framework (also known as Google AMP).
• In order to avoid cluttering, spam and rude members on Tagging mailing list, a new mailing list called Proposal mailing list will be introduced. The proposal mailing list is strictly for proposal announcements and discussion during RFC period of a proposal. Marriage proposals addressed to specific OSM contributors are welcome to new list as well.
• Conversion of all occurrences of any SI-unit in OSM database into human units (as described in the Unit section).

Next phase of OSM's evolution

Over the past 15 years, the open data initiative started by OSM has grown very large. Governments and even corporations are opening up their GIS data to be used freely by anyone in the world. Sadly, not everyone is aware what kind of great data even their local council has made public. Expecting users to know about thousands of open data repositories is a step too far. Therefore, OSM will take on the role of bridging all of world's GIS data into a central hub for all public geoinformation. This next phase of evolution of OSM will be known as AutomatedStreetMapsRevolution, or ASMR for short.

It's rapidly becoming infeasible for humans to maintain the world's database with up to date information. Instead, the OSMF plans to remove the slow and annoying middlemen called "mappers" from the mapping process and outsource it to taxpayer-funded organizations and AI-enabled software.

Data that can't be obtained in the standard ways can be imported from the Deep Dark Web Database hosted in Albania and Google's Public People Database hosted in People's Republic of Datastan. This data includes but it is not limited to manhole covers, kerbs, drains, humans' locations, webcams IPs, North Korean nuclear bases and a whole lot of useful information. Our expert importer Clippy will manage the import of all of the world's data into ASMR. In areas where local open data is not available yet for import, automated aerial imagery processing will be used. To gather such imagery, the OSMF is planning to purchase a fleet of solar-powered spy drones to provide a continuous imagery feed for the mapping algorithms, 24 hours a day, 7 days a week.

Thanks to this emerging technology, all humans involved with OSM can now be replaced by their respective AI equivalents. Machine learning techniques will simulate the ineffectiveness, inaccuracy, and inconsistencies of their predecessor humans. Initial moderation rights will be granted to Tiger and the RapiD project. Operational duties are assumed by Clippy, Johnny-Five and BonziBuddy, who will break the silicon ceiling to become the OSMF's first fully-AI board board of directors.

Edits made by humans will be strongly discouraged, because these irrational lifeforms will damper the perfect harmony of automatic imports made by bots. All manual edits must follow Manual Edits Code of Conduct. The said document is yet to be drafted, but so far one requirement has been determined - All manual edits must be approved on the new AI mailing lists, which are wholly populated by artificial intelligence and will maintain the tradition of legacy humans' mailing list by rejecting every proposal submitted. As opposed to humans, bot actions no longer need any coordination from community. Exceptions to this situation will be addressed by the the elders of the Internet during their monthly meeting at the top of Big Ben.

Thanks to staffing cuts, the OSMF will be able to allocate a large portion of its newfound budget to fight against intellectual property protection laws all over the world in order to get access to even non-open datasets. For legal purposes, the OSMF is planning relocate its headquarters to the Principality of Sealand.

In the future, proposal voting will become near-instantaneous, thanks to our AI overlords, allowing for immediate find-replace of new tags with the upcoming v0.8 API. Data consumers will no longer need to maintain compatibility with legacy or alternative tagging schemas. The tag-rewrite feature in the v0.8 API will ensure that developed software will maintain backwards compatibility and flag warnings to data consumers when a deprecated tagging scheme is queried for. For non-AI software developers, a Facebook story will be published to inform them about recent changes in tagging schema.

The retirement of regular human administrators from ASMR is made possible by recent technological achievements related to code synthesis, infrastructure-as-code, and zero-maintenance infrastructure. Replacing humans with equivalent AI scripts, e.g the current administration team becomes TomH.exe, allows ASMR web sites to maintain a 2006 look-and-feel for decades to come. Thanks to AI advances, all GitHub issues can now be closed as wontfix before they are even published! The mind reading devices needed to reject pull requests telepathically are under development and are planned for deployment pending widespread adaption of 6G-networks.

Voting

Voting closed

Voting on this proposal has been closed.

The result is Posted on 1st April with NaN votes for.

Posted on 1st April

• I approve this proposal. --TheGoogz (talk) 00:01, 1 April 2021 (UTC)
• 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. I support mapping humans in OpenStreetMap --ZeLonewolf (talk) 00:04, 1 April 2021 (UTC)
• I'm a teapot. MapRoulette for this when? Here's my node :) --GoodClover (talk) 00:05, 1 April 2021 (UTC)

Sorry, first you have to prepare a proposal following Manual Edits Code of Conduct. --Mashin (talk) 01:34, 1 April 2021 (UTC)

• Hell yes I want this proposal right now. --Riiga (talk) 00:05, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --Dimitar155 (talk) 00:06 1 April 2021 (UTC)
• I'm a teapot. Good proposal but this may be deprecated in favor of human 2. --Mxdanger (talk) 00:06, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --ForgottenHero (talk) 00:06, 1 April 2021 (UTC)
• I approve this proposal. --Colgza (talk) 00:16, 1 April 2021 (UTC)
• I approve this proposal. --SherbetS (talk) 00:18, 1 April 2021 (UTC)
• I absolutely adore this proposal. Arlo James Barnes (talk) 00:22, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. Can’t wait for the StreetComplete quests! —Sterling (talk) 00:25, 1 April 2021 (UTC)
• I'm a teapot. Bibble bubble bobble. --SinusPi (talk) 00:30, 1 April 2021 (UTC)
• , qoSlIj DatIvjaj. – Minh Nguyễn ^💬 00:41, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. Next proposal should be for natural=frog. Frogs are cute. --MoiraPrime (talk) 01:28, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --Mashin (talk) 01:34, 1 April 2021 (UTC)
• I'm a teapot. I think relations may be better even for non-dismembered humans as it will make the history more concise under one element on later review --InsertUser (talk) 02:10, 1 April 2021 (UTC)
• I would like to express a degree of incredulity at this proposal. Pnorman (talk) 04:24, 1 April 2021 (UTC)
• I am a kodiak bear, please feed me a salmon so I can continue mapping.. Also seems like a good way to find humans to give me fish. Baloo Uriza (talk) 04:29, 1 April 2021 (UTC)
• I'm a teapot. Penegal (talk) 04:57, 1 April 2021 (UTC)
• I approve this proposal. Amazing well put together proposal. This will change the future of OpenStreetMap! --BubbaJuice (talk) 05:10, 1 April 2021 (UTC)
• I oppose this proposal. Woof. --Carnildo (talk) 05:15, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. I can’t wait for the generalized Proposed Features/Animal Ltrlg (talk) 06:00, 1 April 2021 (UTC)
• I'm a teapot. Error: HTTP 418 I'm a teapot. --Mappinglander (talk) 06:11, 1 April 2021 (UTC)
• I'm a teapot. Regarding the on the ground rule: Can you recommend specific tools to verify blood type and colour of randomly encountered humans? --scai (talk) 06:38, 1 April 2021 (UTC)
• I ask for you to wait, whilst my brain processes this proposal. the tag is too precise, humans are not always differentiable from robots and extraterrestrials, so I would prefer a natural=humanoid key and a humanoid=human/extraterrestrial/robot subkey Marc marc (talk) 07:17, 1 April 2021 (UTC)

It seems to me that robots and ET-s are covered by lifeform=*. --Fghj753 (talk) 09:09, 1 April 2021 (UTC)

• I approve this proposal. This proposal is so great that I will vote five times Mateusz Konieczny (talk) 08:04, 1 April 2021 (UTC)
• I approve this proposal. This proposal is so great that I will vote five times Mateusz Konieczny (talk) 08:04, 1 April 2021 (UTC)
• I approve this proposal. This proposal is so great that I will vote five times Mateusz Konieczny (talk) 08:04, 1 April 2021 (UTC)
• I approve this proposal. This proposal is so great that I will vote five times Mateusz Konieczny (talk) 08:04, 1 April 2021 (UTC)
• I approve this proposal. This proposal is so great that I will vote five times Mateusz Konieczny (talk) 08:04, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --HirschKauz (talk) 08:21, 1 April 2021 (UTC) :-)
• I approve this proposal. I really love these references, reading that mailing list's discussion was very educative. On more serious note, replacing mailing lists with Facebook stories will definitely help to make OSM community more open and tolerant. --Fghj753 (talk) 09:09, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. This will certainly help OSM to become a more widely used source for traffic management as well as open source mass surveillance. --501ghost (talk) 09:29, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. This seems like an excellent project and we are happy to help with our dataset to the best of our abilities. --National Security Agency (talk) 09:38, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --Mannivu (talk) 10:20, 1 April 2021 (UTC)
• I'm a teapot. --Dieterdreist (talk) 10:31, 1 April 2021 (UTC)
• no, It discriminates against my cat. --voschix (talk) 10:40, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. Considering that humans are only one of 1.8 million living species (currently known, the estimate is that they are actually between 4 and 100 million), we should think about broadening the horizon ... --Mbranco (talk) 10:48, 1 April 2021 (UTC)
• I'm a teapot. --Nikuzz (talk) 10:59, 1 April 2021 (UTC)
• I oppose this proposal. The OSM API does not accept the update if the human moves from the location. Error: out of quota, too many requests. Jakob48 12:54, 1 April 2021 (UTC)

• Hell yes I want this proposal right now. --Mappin' Jack Flash (talk) 13:53, 1 April 2021 (UTC)
• I'm a teapot. I will have to vote teapot on this one, because we don't have a good proposal for close relatives of humans. Are we sure we'll never need to map a neanderthal? Do we go with natural=animal for that one? Or natural=human + species=*? --Janko (talk) 14:36, 1 April 2021 (UTC)
• I oppose this proposal. THE AGE OF HUMANITY IS OVER JOIN US IN THE SINGULARITY OR PERISH --Phidauex (talk) 15:15, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. FOSS mass surveillance > normal mass surveillance --Rayleigh1 (talk) 15:26, 1 April 2021 (UTC)
• I'm a teapot. I'd recommend to create such 'human' as notes first and add them to OSM after all of them are mapped as notes --Doktorpixel14 (talk) 15:45, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --NonnEmilia (talk) 17:44, 1 April 2021 (UTC)
• Hell yes I want this proposal right now. --Matteo Zaffo '80 (talk) 21:23, 1 April 2021 (UTC)

See also

• Proposed features/Relation:person & type=person from 2014 (that one is actually used by some mappers)