The [`emergency` tag](https://wiki.openstreetmap.org/wiki/Key:emergency) is used both as a primary tag (e.g. `emergency=ambulance_station`) as well as a key of the [access](https://wiki.openstreetmap.org/wiki/Key:access) tagging schema. The "primary" emergency features only ever come as points or areas, while the "access" emergency tags are typically found on linear features.
In order to avoid false-positives in the geometry check validation of iD, the id-tagging-schema has a couple of dummy presets that allow the use of the tag on lines (see 423329c1eb).
This removes the unnecessary translatable strings caused by this workaround, which cause confusion for translators on transifex.
* closes#1432 by changing the `layer=1` tag from an `addTags` tag to the default value of the `layer` field
* some of the fields for "regular" buildings don't make sense for "roof-only" features
* General piste preset to not searchable
* Preset Piste: Add "Unspecified Type" to name
---------
Co-authored-by: yves <yves@maisonux-iii.home>
Co-authored-by: Tobias <t@tobiasjordans.de>
Add `alt_name`, `loc_name`, `nat_name`, `official_name`, `reg_name`, `short_name` as global fields (which makes them `moreFields` for every preset) with the `prerequisiteTag` of `name` being present.
This fixes "crossing: New approach with …`@templates/crossing/defaults`".
We need the "crossing" field on vertex/node fields as well to allow to quickly change the preset.
SQ
`npm run build` still works, so I don't think this is an issue.
This also removes the second run of very similar code in the prettier workflow which I think is probably a legacy redundancy that can just be deleted.
x
The common practice is to tag this in the `highway=crossing` nodes and on separate `barrier=kerb` nodes but not on the crossing ways. Same as the `kerb` field.
The field `flashing_light` was used on some of those presets. It is now more systematic.
I also kept them on the `traffic_signals` presets because those can have additional `flashing_lights` as well.
The fields `oneway` and `access` are important for `highway=cycleway|path` crossings but not essential. They are more of a advanced user setup which should be visible when prev filled in but only added by users that read more about it before. They are moved to the `moreFields` for that reason.
The `segregated` is added here for the same reasons and because of it's importance for highway types that likely have bike traffic.
Ping https://github.com/openstreetmap/id-tagging-schema/issues/317
The `surface` and `smoothness` is extracted from the `@template` because it makes more sense to split them up in `fields` and `moreFields`. A templates adds too much abstraction in this case.
The markings templates are not touched by this PR and it does seem to work without this. However, the fields are used on line and point geometries so either the `geometry` field is ignored during build or something else is happening…
The field "crossing" is removed from the `/defaults` fields.
- it is only relevant for the geometry line because it is hidden on geometry vertex.
- but on geometry line, we want it to be on the first position of fields
- the `/defaults` fields however should be positioned below the `markings` which are more relevant for specifying the kind of crossing
- the `/defaults` fields now includes `crossing_raised` which was removed from the previous and discontinued `/geomery_line` fields template.
The new `@templates/crossing/bicycle_relevance`
- is used on all highways that have bicycle relevance which are `highway=path|cycleway` and not on `highway=footway`
For all traffic_signal presets, the order of fields is different to give the `/traffic_signal` more prominence.
All fields are unsearchable (for now) so we can learn how to name properly.
The names are adapted from `presets/highway/cycleway/crossing/bicycle_foot.json`.
The terms are removed because the presets are unsearchable.
Using the preset I find the markings field to be the most important to change. The `@templates/crossing/defaults` is less important for all situation except for `data/presets/highway/crossing.json`. The main reasons for this is, that only on the base `highway/crossing` the field `crossing` is actually visible. For the more precise presets this field is hidden by some automatic part of the system.
All those fields used a different order of properties, which made it hard to compare them.
This commit does not change anything on the fields, it just streamlines the same order of properties across files.
The convention is, to tag this on the node _and_/_or_ on the separate `barrier=kerb+kerb=*` node when the path is mapped separately.
It should be part of all crossing vertex presets.
This extract the three moreFields to be reused in all traffic_signals presets.
- "traffic_signals/arrow"
- "traffic_signals/countdown"
- "traffic_signals/minimap"
For unclear reasons the cycleway/crossing/traffic_signals did not have those more fields which are now added to streamline the presets.
This extract the three fields to be reused in all traffic_signals presets.
- "button_operated"
- "traffic_signals/sound"
- "traffic_signals/vibration"
Nothing else is changed, this is just an extraction into a template.
This streamlines the fields on all line geometry crossings.
- "oneway"
- "surface"
- "smoothness"
- "crossing_raised"
- "access"
Those fields are always the last in the list. For traffic signal those specific fields are put above. Which is also the only change for one vertex preset in this commit, to have the "crossing_raised" come after the traffic signal specific fields and so the order is the same across presets.
This will roll out the smoothness field for all crossings; it was previously only present in some. But given the importance of smoothness for accessibility I think that is OK. This commit also moves the surface (and smoothness where present) fields further down the list which reduces the priority a bit.
The biggest change in priority is the oneway-field which had the first position before and now is below the defaults- and markings-field.
This way we have the same fields in all crossing presets:
- "crossing"
- "tactile_paving"
- "crossing/island"
This change the order of things slightly for some footway, cycleway crossing where `surface` is now a bit lower, but that should not be a problem.
this includes most of the top ~100 most used values of the `cuisine` tag, omitting discouraged values like `international`
also sorts the list by the current number of uses according to taginfo (see https://gist.github.com/tyrasd/aaa5d32cb05f8ed1acafdd2e40737254)
and limit offered values of `dog` field on dog-specific features to just =leashed`/`unleashed`: `no` does generally not make sense on these, and `yes`/`designated` is already implied by the primary tag.
Adds presets for:
* roller_coaster=track
* roller_coaster=station
* roller_coaster=support
Also adds a field for roller_coaster:track=* and the layer field to attraction=water_slide
* search term "equestrian arena" added for pitch/equestrian
* search terms "equestrian arena" and "equestrian indoor arena" added for building/riding_hall
* search term "equestrian center" added for leisure/horse_riding
* Create riding_hall.json for building=riding_hall
new preset file added
* Add an alias and a search term
- alias "Horseback Riding Hall" added
- term "longeing hall" added
* Preset renamed and more aliases added
Preset renamed from "Horseback Riding Indoor Arena" to "Indoor Horseback Riding Arena" because this is how it is used (mostly just "Indoor Riding Arena")
as not all wikidata items have a matching wikipedia page, this field would inevitably be always empty in these cases. As it is automatically filled in when a user selects a wikidata entry with a matching wikipedia page, the field shows up in the "regular" case anyway. only if the wikipedia page exists, but a map feature only has the wikidata tag (e.g. because it was mapped by another editor, or added manually in the raw tag editor), the field is now missing; it can still be added manually through "more fields" in this case, though
see https://github.com/openstreetmap/id-tagging-schema/pull/964#pullrequestreview-1541084558
The `prerequisiteTag` did work nicely. However, the `"type": "address"` only allows to set `addr:*` keys, so we cannot re used it as is. Removing it for now…
- remove "addr:" field since small usage and discouraged
- add addr_string which is the thing used most often
- update addr_addr to only show if at least "memorial:addr:street" is present
A "barangay" in the Philippines is the smallest administrative government unit. According to [taginfo](https://taginfo.openstreetmap.org/tags/townhall%3Atype=barangay#overview), "barangay" is the third most used value for `townhall:type`, and one of the most popular POI added by mappers from the Philippines.
* the new preset is for the tag `seamark:harbour:category=marina_no_facilities`
* keeps the tag upgrade of the `leisure=marina` preset to add `seamark:harbour:category=marina` (under the assumption that what mappers usually associate with leisure=marina does more commonly have "extra facilities" than not)
* adds a checkbox-field to de/select "domestic facilities", allowing to easily switching between Marina and Yacht Berths presets.
closes#899
with information about how to contribute:
* submitting issues
* general guidelines
* translating
* making changes
* icons (fixes#314, closes#838)
* code style
* installation and testing
* Add translatable strings to historic field
* add strings for exisiting historic=* subpresets
---------
Co-authored-by: Martin Raifer <martin@raifer.tech>
after #777, unfortunately, there were two fields to define the sub-type of street cabinets: utility for the "common" ones (e.g. telecom, power, etc.) and the "legacy" street_cabinet field for the rest. This PR adds dedicated presets for the legacy cases where the "street_cabinet" tag is still to be used to solve this UI issue.
presets:
* Diving Platform
* City Limit Sign
* Turning Loop
fields values:
* `design` field of Power Poles and Power Towers/Portals
* `leaf_type`
* `traffic_calming`
* `volcano:type` and `volcano:status`
* `tower:construction`
* Add translatable strings to attraction field for values with usage > 500
* add entries for existing presets
* add value for alpine_coaster
Co-authored-by: Martin Raifer <martin@raifer.tech>
Add translatable strings to sport field for values with usage > 5000
* leaving out `multi`, as the [intended use](https://wiki.openstreetmap.org/wiki/Tag%3Asport%3Dmulti) is rather complex and not really fitting to the simple field type used here. Leaving it untranslated is IMHO better, as the rendering as a raw tag conveys the concept that this is something more specific going on.
Co-authored-by: Martin Raifer <martin@raifer.tech>
…for case :left, :right, :both. The directionalCombo will show left/right in separate fields when both is present and merge/split the side as needed.
Allow tagging `parking:$side` and `parking:$side:orientation` on centerlines (highways).
Add translatable strings for values with usage > 1000. Left out are duplicate terms like wastewater, water waste, heat, steam.
Co-authored-by: Martin Raifer <martin@raifer.tech>
* reduce duplication of names
* consistent use of "Crossing" vs. "Crosswalk" across similar presets
* consistent use of terms
* sort terms alphabetically
description:This requests an OSM tag to be added to the tagging schema in the form of a new preset, field or value.
# title: ''
labels:enhancement
labels:needs-triage
# assignees: ''
body:
- type:markdown
@ -82,6 +82,13 @@ body:
placeholder:'126,000'
validations:
required:true
- type:input
attributes:
label:Suggested Icon
description:Each preset needs an icon ([learn more…](https://github.com/ideditor/schema-builder/blob/main/ICONS.md#icons)). Any suggestion, yet, on which? Or do we need a new one?
<!-- Help readers to understand why this is relevant -->
### Related issues
<!-- Please link any related issues here.
Use "Closes #123" to reference issues that should be closed automatically when this is merged. -->
### Links and data
**Relevant OSM Wiki links:**
- …
**Relevant tag usage stats:**
> …
<!-- E.g., Numbers from Taginfo https://taginfo.openstreetmap.org/ and maybe local Taginfo https://taginfo.geofabrik.de/ -->
<!-- E.g., a link to https://taghistory.raifer.tech -->
### Checklist and Test-Documentation Template
<details><summary>Read on to get your PR merged faster…</summary>
Follow these steps to test your PR yourself and make it a lot easier and faster for maintainers to check and approve it.
**This is how it works:**
1. After you submit your PR, the system will create a preview and comment on your PR:
> 🍱 Your pull request preview is ready.
If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.
2. Once the preview is ready, use it to test your changes.
3. Now copy the snippet below into a new comment and fill out the blanks.
4. Now your PR is ready to be reviewed.
```
## Test-Documentation
### Preview links & Sidebar Screenshots
<!-- Use the preview to find examples, select the feature in question and**copy this link here**.
Find examples of nodes/areas. Find examples with a lot of tags or very few tags. – Whatever helps to test this thoroughly.
Add relevant **screenshots** of the sidebar of those examples. -->
<!-- FYI: What we will check:
- Is the [icon](https://github.com/ideditor/schema-builder/blob/main/ICONS.md) well chosen.
- Are the fields well-structured and have good labels.
- Do the dropdowns (etc.) work well and show helpful data. -->
### Search
<!--**Test the search** of your preset and share relevant**screenshots** here.
- Test the preset name as search terms.
- Also test the preset terms and aliases as search terms (if present). -->
### Info-`i`
<!--**Test the info-i** for your fields and preset and share relevant**screenshots** here.
The info needs to help mappers understand the preset and when to use it.
body:`${start} **[Your pull request preview is ready](https://pr-${pullRequestNumber}--ideditor-presets-preview.netlify.app/id/dist/#locale=en&map=18.00/48.841708/2.587656)**\n\nPlease use this preview to check your changes. Ideally use [the **test documentation** template](https://github.com/openstreetmap/id-tagging-schema/blob/main/.github/PULL_REQUEST_TEMPLATE.md?plain=1#L38-L69) and document your test results by commenting on the PR. This will speed up the review process for everyone.\n\nFYI, once this PR is merged, you can use [the iD Editor Preview](http://preview.ideditor.com/) to test your changes in interaction with all other changes.`
});
}else {
console.log(`Preview URL comment already added to PR#${pullRequestNumber}`);
uses:actions/checkout@v3# If you're using actions/checkout@v3 you must set persist-credentials to false in most cases for the deployment to work correctly.
uses:actions/checkout@v4# If you're using actions/checkout@v3 you must set persist-credentials to false in most cases for the deployment to work correctly.
with:
persist-credentials:false
- name:Set up Node.js
uses:actions/setup-node@v3
uses:actions/setup-node@v4
with:
node-version:'18'
node-version-file:'.nvmrc'
- name:Install Node.js dependencies
run:npm install
run:npm clean-install
- name:Build
run:npm run build
- name:Deploy 🚀
uses:JamesIves/github-pages-deploy-action@v4.4.0
uses:JamesIves/github-pages-deploy-action@v4
with:
BRANCH:main# The branch the action should deploy to.
FOLDER:.# The folder the action should deploy.
CLEAN:false# Automatically remove deleted files from the deploy branch
branch:interim# The branch the action should deploy to.
folder:interim# The folder the action should deploy.
Don't hesitate to submit feedback about issues or how the tagging schema could be improved, but please [search existing issues](https://github.com/search?l=&q=repo%3Aopenstreetmap%2Fid-tagging-schema&type=Issues) before [opening a new one](https://github.com/openstreetmap/id-tagging-schema/issues/new/choose).
iD's [code of conduct](https://github.com/openstreetmap/iD/blob/release/CODE_OF_CONDUCT.md) and [privacy policy](https://github.com/openstreetmap/iD/blob/release/PRIVACY.md) also apply to this project.
## General Guidelines
Read the [GUIDELINES](./GUIDELINES.md) to help you understand what fields and tags should be added to the tagging schema.
## Translating
* **English (US) translations** are managed inside the JSON files of this repository. The Transifex translations for "English (en)" are only a reference for other languages but not exported.
Example: To extend the list of English terms for `shrub`, [modify the `terms`-key in the JSON file](https://github.com/openstreetmap/id-tagging-schema/blob/v3.1.0/data/presets/natural/shrub.json#L16-L19)).
* **All languages** other than English (US) are managed [in the Transifex Project of the iD Editor](https://app.transifex.com/openstreetmap/id-editor/) inside the translation resource _'preset'_.
To to find and update a translation, you can …
1. [open the translation page](https://app.transifex.com/openstreetmap/id-editor/translate/)
2. select a language at the top
3. select _'presets'_
4. search for `key:living_street` or `translation_text:'Living Street'` or `key:highway/living_street`
* **Request access:** To contribute to a language, [select a language](https://app.transifex.com/openstreetmap/id-editor/languages/) and use 'Join team' to request access. The administrators will approve requests routinely, only rejecting requests for overly specific locales.
* **Base language:** The JSON files in this repository require an "English (US)" translation. This includes data, that use the `locationSet` property to reduce the scope of the data to specific countries since users might still select English as an editor language in those countries. Some presets use a (untranslatable) proper name. See also "Developer Notes".
* **Transifex "Developer Notes":** Use the "Developer Notes" section in Transifex to learn more about the context of a given translation string. For example, [looking at `presets.fields.direction_cardinal-US-CA-NZ.label` in Transiflex](https://app.transifex.com/openstreetmap/id-editor/translate/#en_GB/presets/406422633?q=key%3Apresets.fields.direction_cardinal-US-CA-NZ.label) will give you the "Developer Notes: `direction=* | Local preset for countries "CA", "NZ", "US"`" which helps you understand that, (a) this label describes the key `direction` and (b) it is only visible in three countries, so other languages usually don't need to translate it (leave it blank or add the English translation instead).
* **Release:** All translation changes are released whenever [a new id-tagging-schema release is created](https://github.com/openstreetmap/id-tagging-schema/releases). They will become visible inside iD and other editors once those editors a short while after that (which can vary as different editors have different release schedules and in some cases, e.g. in iD, translations might even be fetched dynamically from the most recent id-tagging-schema release).
## Making Changes
You are highly welcome to help this project by submitting pull requests!
### Overview and General Structure
Detailed documentation for the data format used in this repository is located with the [schema-builder](https://github.com/ideditor/schema-builder) package, which is the technical basis of this project.
To make a change, update the corresponding file within the `data` folder: The `presets` contain a representation of OpenStreetMap's [map features](https://wiki.openstreetmap.org/wiki/Map_Features), and the `fields` are their properties. In addition, the tagging schema contains a few `categories` of presets and a list of `deprecated` and `discardable` tags.
### Icons
Icons from different sources (_icon sets_) can be used in the tagging schema. Head over to the [dedicated page](https://github.com/ideditor/schema-builder/blob/main/ICONS.md#icons) about how to use them.
### Info-`i`
<imgalt="Screenshot of a preset in iD with the information details open."src="https://github.com/openstreetmap/id-tagging-schema/assets/111561/13549318-cd7c-4dd1-9948-7a2d84662f04"width="400"/>
iD and other tools provide users with a way to learn more about the main tag of a preset. It is important to provide good information in this information panel. Here are a few notes on how to do this:
- Does your tag have a OSM Wiki data item? Click the small pencil icon next to the text to open the data item on the OSM Wiki. Improve this wording if needed. If the data item is missing, [learn more about how to add it in "Current methods for creating new items"](https://wiki.openstreetmap.org/wiki/Data_items#Item_creation_process).
- Does your tag have a Wiki page with a good image?
- Your preset might need [a `reference` property](https://github.com/ideditor/schema-builder?tab=readme-ov-file#reference) to force the system to use a specific tag for the information section.
### Integration Testing With iD
There are two ways to inspect how your changes to the schema affect the user experience in the iD editor:
**a. Use the PR preview:**
After you submit your PR, the system will create a preview and comment on your PR:
> 🍱 Your pull request preview is ready.
If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.
**b. Use a local instance of the iD editor:**
If you have [set up](https://github.com/openstreetmap/iD#installation) your own local instance of the iD editor, you can [configure](https://github.com/openstreetmap/iD/blob/develop/API.md#environment-variables) it to use your local set of tagging presets by setting the `ID_PRESETS_CDN_URL` environment variable.
1. First build and serve the schema: `npm run build && npm run dist && npx serve -Cp 1234`. Remember that you need to run this command again should you make further changes.
2. Now, in your iD repository, start an iD instance using your custom schema:
- on macOS & Linux: `npx cross-env ID_PRESETS_CDN_URL=http://localhost:1234/ npm start`
- on Windows: `set ID_PRESETS_CDN_URL=http://localhost:1234/ && npm start`
### Installation and Testing
The following `npm` commands are used in this repository:
* `npm install`– installs or updates the repository's required dependencies
* `npm test`– validates the source data
* `npm run build`– validates the source data and builds some files which are used during development (e.g. strings to be supplied to the translation platform)
* `npm run dist`– validates the source data and compiles output files for iD
* `npm run translations`– fetches translations from transifex and compiles the translations files for iD
### Code Style
The input files are JSON files which use 4-space indentation. You can use the `npm run lint` command to check whether your files match the expected code style and run `npm run lint:fix` to reformat them if they don't do so.
# Roles, People, and Processes for Maintaining the Tagging Schema
This document outlines how this project is maintained.
## Roles & People
### Maintainer Role
[Martin](https://github.com/tyrasd) maintains this project as part of his work on the iD Editor project.
The maintainer role includes:
- Having the final say in decisions for the tagging schema.
- Creating releases.
- Updating dependencies.
- Assign roles.
and all the following roles.
Github shows a `(Member)` label next to users with full access to this repository and the organisation.
### Co-Maintainer Role
- [Kyle](https://github.com/k-yle) contributes to this project as a volunteer.
- [Tobias](https://github.com/tordans) contributes to this project as a volunteer.
The co-maintainer role includes:
- Reviewing PRs.
- Merging "clear-cut" PRs by others.
and all the following roles.
Github shows a `(Collaborator)` label next to users with any permission on this repository.
### Triage Role
* [Mateusz](https://github.com/matkoniecz) contributes to this project as a volunteer.
The triage role includes:
- Proactively helping to clarify issues and PRs.
- Closing issues as duplicates or not planned.
- Closing abandoned, duplicated or invalid PRs.
- Assigning labels to issues and PRs.
Github shows a `(Collaborator)` label next to users with any permission on this repository.
### Contributors
To all contributors, thank you so much for your support! ❤ Especially for:
- Suggesting new presets and fields or updates to the repository.
- Researching and helping with issues and PRs.
- Translating the tagging schema.
Code contributions: [Check this complete list of contributors on GitHub](https://github.com/openstreetmap/id-tagging-schema/graphs/contributors).
Github shows a `(Contributor)` label next to users that previously committed to this repository.
## Processes
### PR Reviews and Merges
- PRs need approval from two people: the author and one or more (co-)maintainers before being merged.
- Non-"clear-cut" changes need to be merged by the maintainer.
- We might revert merges later if necessary.
**What is a clear-cut change?**
- No or minimal controversial discussion on the change.
- Coding and contribution [guidelines](./GUIDELINES.md) are met.
**How to merge…**
- Usually squash merge PRs to make the history simpler
- Give the merge a meaningful description of the change
- Add labels to the PR before merging which get picked up by our [release drafter](https://github.com/openstreetmap/id-tagging-schema/blob/main/.github/release-drafter.yml)
**How to close…**
- Provide context and an explanation for the chosen action
- Consider reaching out to the author before taking action
- We're happy to reopen PRs if opinions change.
### Releases
There is no set release schedule at the moment, but releases usually occur every other month. After this project is released, the projects that rely on the data need to update and release as well.
### Assigning roles
- The maintainer of the iD editor has traditionally and continues to maintain this project.
- Co-maintainer and triage roles are assigned by the current maintainer of the repository.
Do you have an idea for a new preset or field? Read this!
## 1. Evaluate Your Idea for the Tagging Schema Project
Adding a preset or field to the tagging schema is a significant responsibility.
We must ensure that both new and experienced users can understand the presets and fields,
thereby contributing high-quality data to OpenStreetMap (OSM).
Consider the following:
### General Guidelines
- 📋 **Established Documentation**: The tagging schema will only consider tags that are well-documented on the OSM wiki. The documentation should be clear and unambiguous.
- 🏷️ **Established Tags Only**: No new or unestablished tags should be part of presets. Establishing tags must remain a community-driven process, not dictated by software implementation.
- ✅ **Proposal or Accepted**: A tag is considered established when it has completed the [proposal process](https://wiki.openstreetmap.org/wiki/Proposal_process) or is otherwise accepted by the OSM community. Factors include the tag's duration and frequency of use, whether its usage is increasing over time and its usage by mainstream data consumers.
- 🤷 **Notable Purpose**: Especially for less established tags, presets and fields should have a practical application. OSM allows for the collection of a wide variety of data, some of it for niche purposes. For example, the brightness of street lamps might be documented, but it doesn't necessarily warrant a preset or field.
- 🕓 **Effort vs. Impact**: Consider whether the effort required is justified by the impact the preset or field will have. Assess how many elements this new type will apply to. This is particularly important if you do not plan to contribute the code changes yourself through a pull request (PR).
### User Experience
No preset or field is isolated; they are always presented alongside others in various user interfaces that utilize the tagging schema.
- 🔦 **Easy to Pick**: Users must be able to understand and select the correct preset given the limited information available in the user interfaces. Good presets guide the user with clear names and helpful additional documentation `(i)`.
- 🔎 **Easy to Search**: When searching, similar presets will appear next to each other. Consider and test typical search scenarios. You might need to adjust the names and documentation of other presets to ensure users can make the best decision.
- 👨💻 **Users Are Not Experts**: No prior knowledge of OpenStreetMap or any other background information should be necessary.
- 🐿️ **Easy Answer**: Users are often on the go and impatient. Fields should allow for quick, straightforward, and clear answers.
### Situational Presets
- 🙈 **Unsearchable Presets**: The tagging schema is not only for adding information but also for presenting existing information. Consider adding an unsearchable preset for tagging that should be highlighted with a preset on the map and with defined fields. Reasons to make a preset unsearchable include: multiple ways to tag something where one method is preferred, or other reasons to hide commonly used tags from the search and list interface to preserve a good [user experience](#user-experience).
- 🏝️ **Local Presets and Fields**: Generally, presets and fields in OSM should be globally applicable, and efforts should be made to ensure this. However, when local tagging conventions exist or when presets only make sense for certain regions, presets and fields can be given a local filter. This increases the need for thorough testing and makes it more challenging to maintain a good [user experience](#user-experience).
### Tag Updates and Additions
- ➕**Suggested Additions**: Presets can suggest additional tags. These suggestions must be clearly supported by the wiki and community consensus.
- 🔄 **Updates**: Deprecation rules can suggest updating tags. Good documentation and consensus are needed for these deprecations.
**In both cases, _indicators for consensus_ are:**
- The deprecation is documented in the wiki and is either official (resulting from a proposal process) or long-standing (about a year).
- There is a significant drop in usage compared to previous numbers, with a negative trend ([visible in the graph](https://taghistory.raifer.tech/)).
- Usage of the deprecated tag remains stagnant for a longer period (about a year).
In addition, the deprecated tag must have reasonably high usage to be considered. Low usage tags should be addressed through other cleanup methods, such as [MapRoulette](https://maproulette.org/) or similar initiatives.
**Deprecations are not for cleanup:**
Deprecation rules work such that the user sees a message with suggestions and can act only when editing the given element. This makes them well-suited for gradual, human-reviewed updates of taggings like crossings. However, they are not suitable for cleaning up incorrect tagging from the database, especially for low-volume changes.
There are, however, alternatives to consider:
- Your cleanup task might be eligible for an automated (bot) edit. [Please learn more on the wiki…](https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct)
- If your task is small enough, a few [editing sessions in JOSM](https://wiki.openstreetmap.org/wiki/JOSM) will often do the trick. However, mass-replacing without checking each object is still considered an automated edit, so the [guidelines apply](https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct). Please consult other mappers first.
- A good way to work down a list of tasks is to create [a MapRoulette Challenge](https://maproulette.org/).
- Should those options not suit you, you can always suggest such changes in the [OSM community forum](https://community.openstreetmap.org/).
## 2. Design the Preset
The user interface must be clear, concise, and easy to use, leaving no room for misunderstandings.
- Define the tags required on an object to trigger the preset.
- Choose a name, category, and define a list of American English search terms.
- Use Title Case for the the preset `name` and [`aliases`](https://github.com/ideditor/schema-builder?tab=readme-ov-file#aliases) as well as the field [`label`](https://github.com/ideditor/schema-builder?tab=readme-ov-file#label) property. Use lower case for the preset [`terms`](https://github.com/ideditor/schema-builder?tab=readme-ov-file#terms) (sorted A-Z) and Title Case or sentences for preset's [`strings`-`options`](https://github.com/ideditor/schema-builder?tab=readme-ov-file#strings).
- Check the search functionality to ensure other presets do not cause confusion.
- Select an icon or start the process to create a new one.
- Define which fields to show (`fields`) and suggest (`moreFields`), considering the order of fields.
- Check the [`(i)` documentation](./CONTRIBUTING.md#info-i) and add or update the OSM Wiki data item if needed to provide a helpful short text.
- Use the PR preview to add test cases with deep links to OSM objects that demonstrate the preset in use.
## 3. Implement
If you are familiar with `JSON`, you can implement the preset or field yourself. First, create a ticket to introduce your tagging idea and discuss it with the community to get feedback on its feasibility and desirability. After implementation, create a pull request to get it merged.
For more details on adding presets, see ["Making changes"](./CONTRIBUTING.md#making-changes).
If you are not familiar with `JSON`, still create a ticket. The more you have considered and prepared from the above steps, the easier it will be for someone else to code it.
This is the directory of OpenStreetMap tagging data used by the [iD editor](https://github.com/openstreetmap/iD).
It includes presets, fields, deprecations, and more.
## Participate!
* Read up about how you can contribute to the iD Tagging Schema on the [contributing page](CONTRIBUTING.md).
* [Translate!](CONTRIBUTING.md#Translating)
* See the [open issues](https://github.com/openstreetmap/id-tagging-schema/issues?state=open) in the issue tracker if you're looking for something to do.
* Need more help? Ping user `tyr_asd` (Martin Raifer) on [OpenStreetMap Discord](https://discord.gg/openstreetmap) (`#id-and-rapid` channel) or [OpenStreetMap US Slack](https://slack.openstreetmap.us/) (`#id` channel).
## Background
OpenStreetMap itself does not have a formal rigid [database schema](https://en.wikipedia.org/wiki/Database_schema),
but relies on a [tagging](https://wiki.openstreetmap.org/wiki/Tags) [folksonomy](https://en.wikipedia.org/wiki/Folksonomy) instead.
OpenStreetMap itself does not have a formal rigid [database schema](https://en.wikipedia.org/wiki/Database_schema), but relies on a [tagging](https://wiki.openstreetmap.org/wiki/Tags) [folksonomy](https://en.wikipedia.org/wiki/Folksonomy) instead.
Editing tools need to know how tags are used in order to facilitate mapping.
This Tagging Schema fills that need, but with a number of caveats:
@ -18,18 +25,6 @@ This Tagging Schema fills that need, but with a number of caveats:
- We support tags based on practicality, usage, and community approval
- Sometimes there are reasons we can't support a tag even if it's used or approved
## Translations
* English translations for the `terms`-key should be added to the JSON data ([Example](https://github.com/openstreetmap/id-tagging-schema/blob/v3.1.0/data/presets/natural/shrub.json#L16-L19)).
* Apart from that, translations are managed [in the Transifex Project of the iD Editor](https://www.transifex.com/openstreetmap/id-editor/) inside the translation resource _'preset'_.
To translate, you can [open the translation page](https://www.transifex.com/openstreetmap/id-editor/translate/), select a language, select _'presets'_ and search for `key:living_street` or `translation_text:'Living Street'` to find and change translations.
To contribute to a language: [Select a language](https://www.transifex.com/openstreetmap/id-editor/languages/) and use 'Join team' to request access. The administrators will approve requests routinely, only rejecting requests for overly specific locales.
* All translation changes will be released whenever [a new id-tagging-schema release is created](https://github.com/openstreetmap/id-tagging-schema/releases). They will be visible inside iD and other editors once those editors update their dependencies and release a new version as well.
## Usage
### Java/Android
@ -38,19 +33,17 @@ The [westnordost/osmfeatures](https://github.com/westnordost/osmfeatures) projec
a component of [StreetComplete](https://github.com/westnordost/StreetComplete),
makes it easier to use this data with Android or other Java platforms.
### Use by Other Editors
iD tagging schema is used not only by iD. Here's a [list of projects](https://github.com/openstreetmap/id-tagging-schema/wiki/Projects-that-are-using-this-tagging-schema) which use the data from the id-tagging-schema.
## Related Projects
* The [OpenStreetMap wiki](https://wiki.openstreetmap.org/wiki/Map_features) documents the current usage of tags, and hosts discussions about proposed new tags.
* The [ideditor/schema-builder](https://github.com/ideditor/schema-builder) project holds the documentation for the data format used in this repository
* iD also incorporates preset data from the [name-suggestion-index](https://github.com/osmlab/name-suggestion-index).
* Other editors also include their own models of interpretations of OSM tags. See for example [Vespucci's](https://github.com/simonpoole/beautified-JOSM-preset) or [JOSM's](https://josm.openstreetmap.de/wiki/Presets) tagging presets.
## Contributing
iD's [code of conduct](https://github.com/openstreetmap/iD/blob/release/CODE_OF_CONDUCT.md) and
[privacy policy](https://github.com/openstreetmap/iD/blob/release/PRIVACY.md) also apply to this project.
### Making Changes
Documentation for the data formats is located with the [schema-builder](https://github.com/ideditor/schema-builder)
package, which is the technical basis of this project. To make a change, update a
file within the `data` folder and rebuild by running `npm run build` in your terminal.
See the dedicated [CONTRIBUTING](CONTRIBUTING.md) page for information about this.