iD editor preset and field types are defined in JSON
files located under the data/presets
folder of the iD repository.
Presets are defined in JSON files located under data/presets/presets
. They're organized in a
directory hierarchy based on OSM key/value pairs. For example, the preset that matches
the tag leisure=park
is in the file data/presets/presets/leisure/park.json
.
A basic preset is of the form:
{
// The icon in iD which represents this feature.
"icon": "maki-park",
// The names of fields that will appear by default in the editor sidebar.
// See the fields documentation for details of what's valid here.
"fields": [
"address"
],
// The names of fields that the user can add manually. These will also
// appear if the corresponding tags are present.
"moreFields": [
"phone",
"website"
],
// The geometry types for which this preset is valid.
// options are point, area, line, and vertex.
// vertexes are points that are parts of lines, like the nodes in a road
// lines are unclosed ways, and areas are closed ways
"geometry": [
"point", "area"
],
// Terms are synonyms for the preset - these are added to fuel
// the search functionality. searching for 'woodland' will bring
// up this 'park' preset
"terms": [
"esplanade",
"village green",
"woodland"
],
// Tags that are added to the feature when selecting the preset,
// and also used to match the preset against existing features.
// You can use the value "*" to match any value.
"tags": {
"leisure": "park"
},
// English language display name for this map feature.
"name": "Park"
}
The complete JSON schema for presets can be found in data/presets/schema/preset.json
The primary name of the feature type in American English.
Upon merging with master
, this is sent to Transifex for translating to other localizations. Changing the name of an existing preset will require it to be re-translated to all localizations.
This property is required. There is no default.
An array of possible geometry types that a feature must have in order to match this preset.
point
: an OSM node that is not a member of any wayvertex
: an OSM node that is a member of one or more waysline
: an OSM way that is not an areaarea
: an OSM way that is closed/circular (the first and last nodes are the same) or atype=multipolygon
relationrelation
: an OSM relation
Closed ways can be treated as both line
or area
geometry. If a preset allows both, iD will add an additional area=yes
tag when choosing the preset for an area feature.
This property is required. There is no default.
An object with the "key": "value"
tags a feature must have to match this preset. A "*"
wildcard value can be set to have this preset match any value for that key.
A features can only match one preset even if its tags and geometry could technically match more than one. iD will pick the best match based on matchScore
, the number of tags, and the use of wildcard values.
This property is required. There is no default.
The tags that are added to the feature when selecting this preset. Defaults to tags
. If needed, this property will typically be a superset of tags
.
iD's validator will recommend that users add missing tags from addTags
to matching features. For example, the Bridge preset has these properties:
"tags": {
"man_made": "bridge"
},
"addTags": {
"man_made": "bridge",
"layer": "1"
},
When adding a feature with this preset, it will be given the tags man_made=bridge
and layer=1
. The user could then change layer
to 3
, for instance, and the feature would still match the preset because it still has man_made=bridge
. If the user removes the layer
tag altogether, iD will recommend adding it back with a value of 1
.
The tags that are removed from the feature when deselecting this preset. Defaults to addTags
or if this is also not defined, to tags
.
Both these properties are arrays of field paths (e.g. description
or generator/type
).
fields
are shown by default and moreFields
are shown if manually added by the
user or if a matching tag is present. Note that some fields have a prerequisiteTag
property that limits when they will be shown.
A preset can reference the fields of another by using that preset's name contained in
brackets, like {preset}
. For example, shop/books
references and extends the fields
of shop
:
"fields": [
"{shop}",
"internet_access"
],
"moreFields": [
"{shop}",
"internet_access/fee",
"internet_access/ssid"
],
"tags": {
"shop": "books"
}
If fields
or moreFields
are not defined, the values of the preset's "parent"
preset are used. For example, shop/convenience
automatically uses the same
fields as shop
.
In both explicit and implicit inheritance, fields for keys that define the
preset are generally not inherited. E.g. the shop
field is not inherited by shop/…
presets.
The name of a local SVG icon file. You can use icons from any of the following icon sets. When specifying an icon, use the prefixed version of the name, for example "icon": "maki-park"
or "icon": "tnp-2009223"
.
- iD's spritesheet (
iD-
) - Maki (
maki-
), map-specific icons from Mapbox - Temaki (
temaki-
), an expansion pack for Maki- This is the best place to submit a PR if you want to create a preset icon!
- Font Awesome, thousands of general-purpose icons
- The Noun Project (
tnp-
), millions of general-purpose icons- The licenses vary. You can only use the public-domain icons in iD, such as those from OCHA Visual.
- The icon styles vary. Avoid thin or overly-detailed icons since they will not look good at small sizes.
- Use the numeric ID of the icon (e.g.
2009223
). This is shown in the URL when you select an icon on their site. - Unfortunately, you must sign up for a free API key in order to download new icons (even for public-domain icons). Add a file called
the_noun_project.auth
to the root of your local iD instance containing your credentials like{"consumer_key": "xxxxxx", "consumer_secret": "xxxxxx"}
. This file is not version-controlled.
The URL of a remote image file. This does not fully replace icon
—both may be shown in the UI.
For example, imageURL
is used to specify the logos of brand presets from the name-suggestion-index.
Bitmap images should be at least 100x100px to look good at 50x50pt on high-resolution screens.
Deprecated or generic presets can include the property "searchable": false
.
This means that they will be recognized by iD when editing existing data,
but will not be available as an option when adding new features.
By convention, unsearchable presets have filenames that begin with an underscore
(e.g. data/presets/presets/landuse/_farm.json
)
A number that ranks this preset against others that match the feature.
For example, a feature with amenity=cafe
and building=commercial
will match the Cafe preset instead of the Commercial Building preset because Commercial Building has a lower matchScore
.
The default is 1.0
.
An array of two-letter, lowercase ISO 3166-1 alpha-2 country codes. The preset will only be searchable when the user is editing over the specified countries. The locale and language of iD are not factors, just the position of the map.
By default, presets are available everywhere.
The ID of a preset that is preferable to this one. iD's validator will flag features matching this preset and recommend that the user upgrade the tags.
When possible, use deprecated.json
instead to specify upgrade paths for old tags. This property is meant for special cases, such as upgrades with geometry requirements.
A key and optionally a value to link to the wiki documentation for this preset. Only necessary if the preset consists of several tags.
For example,
"reference": {
"key": "tower:type",
"value": "communication"
}
Fields are reusable form elements that can be associated with presets.
Fields are defined in JSON files located under data/presets/fields
.
The field files are typically named according to their associated OSM key.
For example, the field for the tag sport=*
is stored in the file
data/presets/fields/sport.json
. When a field has multiple versions that
depend on which preset is active, we add a suffix to the filename:
(sport.json
, sport_ice.json
, sport_racing_motor.json
).
Some keys in OSM are namespaced using colons (':'). Namespaced fields
are nested in folders according to their tag.
For example, the field for the tag piste:difficulty=*
is stored in the file
data/presets/fields/piste/difficulty.json
.
{
"key": "cuisine",
"type": "combo",
"label": "Cuisine"
}
The complete JSON schema for fields can be found in data/presets/schema/field.json
A string specifying the UI and behavior of the field. Must be one of the following values.
text
- Basic single line text fieldnumber
- Text field with up/down buttons for entering numbers (e.g.width=*
)localized
- Text field with localization abilities (e.g.name=*
,name:es=*
, etc.)tel
- Text field for entering phone numbers (localized for editing location)email
- Text field for entering email addressesurl
- Text field for entering URLstextarea
- Multi-line text area (e.g.description=*
)
combo
- Dropdown field for picking one option out of many (e.g.surface=*
)typeCombo
- Dropdown field picking a specific type from a generic category key
(e.g.waterway=*
. If unset, tag will bewaterway=yes
, but dropdown contains options likestream
,ditch
,river
)multiCombo
- Dropdown field for addingyes
values to a common multikey
(e.g.recycling:*
->recycling:glass=yes
,recycling:paper=yes
, etc.)networkCombo
- Dropdown field that helps users pick a routenetwork
tag (localized for editing location)semiCombo
- Dropdown field for adding multiple values to a semicolon-delimited list
(e.g.sport=*
->soccer;lacrosse;athletics;field_hockey
)
check
- 3-state checkbox:yes
,no
, unknown (no tag)defaultCheck
- 2-state checkbox where checked producesyes
and unchecked produces no tagonewayCheck
- 3-state checkbox foroneway
fields, with extra button for direction switching
radio
- Multiple choice radio button fieldstructureRadio
- Multiple choice structure radio button field, with extra input for bridge/tunnel level
access
- Block of dropdowns for defining theaccess=*
tags on a highwayaddress
- Block of text and dropdown fields for entering address information (localized for editing location)cycleway
- Block of dropdowns for addingcycleway:left
andcycleway:right
tags on a highwaymaxspeed
- Numeric text field for speed and dropdown for "mph/kph"restrictions
- Graphical field for editing turn restrictionswikidata
- Search field for selecting a Wikidata entitywikipedia
- Block of fields for selecting a wiki language and Wikipedia page
The key
property names the OSM key that the field will edit.
Compound fields like address
expect an array of keys in the keys
property.
If a field definition contains the property "universal": true
, this field will
appear in the "Add Field" list for all presets
If specified, only show the field for this kind of geometry. Should contain
one of point
, vertex
, line
, area
.
The default value for the field. For example, the building_area.json
field
will automatically add the tag building=yes
to certain presets that are
associated with building features (but only if drawn as a closed area).
{
"key": "building",
"type": "combo",
"default": "yes",
"geometry": "area",
"label": "Building"
}
Combo field types can provide dropdown values in an options
array.
The user can pick from any of the options, or type their own value.
{
"key": "diaper",
"type": "combo",
"label": "Diaper Changing Available",
"options": ["yes", "no", "room", "1", "2", "3", "4", "5"]
}
Combo field types can accept name-value pairs in the strings
property.
This is helpful when the field has a fixed number of options and you want to be
able to provide a translatable description of each option. When using strings
,
the user can not type their own value, they must choose one of the given values.
{
"key": "smoothness",
"type": "combo",
"label": "Smoothness",
"placeholder": "Thin Rollers, Wheels, Off-Road...",
"strings": {
"options": {
"excellent": "Thin Rollers: rollerblade, skateboard",
"good": "Thin Wheels: racing bike",
"intermediate": "Wheels: city bike, wheelchair, scooter",
"bad": "Robust Wheels: trekking bike, car, rickshaw",
"very_bad": "High Clearance: light duty off-road vehicle",
"horrible": "Off-Road: heavy duty off-road vehicle",
"very_horrible": "Specialized off-road: tractor, ATV",
"impassable": "Impassable / No wheeled vehicle"
}
}
}
If a combo field does not specify options
or strings
, the field will fetch
common tag values from the Taginfo service to use as dropdown values.
For combo fields, spaces are replaced with underscores in the tag value if snake_case
is true
. The default is true
.
For combo fields, case-sensitve field values are allowed if caseSensitive
is true
. The default is false
.
For number fields, the lowest valid value. There is no default.
For number fields, the greatest valid value. There is no default.
An object defining the tags the feature needs before this field will be displayed. It must have this property:
key
: The key for the required tag.
And may optionally have one of these properties:
value
: The value that the key must have.valueNot
: The value that the key must not have.
For example, this is how we show the Internet Access Fee field only if the feature has an internet_access
tag not equal to no
.
"prerequisiteTag": {
"key": "internet_access",
"valueNot": "no"
}
To build presets, all you need to do is run npm run build
.
The following files are autogenerated and will be replaced when rebuilding:
data/presets/categories.json
data/presets/fields.json
data/presets/presets.json
data/presets.yaml
data/taginfo.json
dist/locales/en.json
iD supports deployments which use a custom set of presets. You can supply presets via
the presets
accessor:
var id = iD.coreContext().presets({
presets: { ... },
fields: { ... },
defaults: { ... },
categories: { ... }
});
All four parts (presets, fields, defaults, and categories) must be supplied. In addition, several base presets and fields must be included.
Basic geometric presets must be included so that every feature matches at least one preset. For example:
"area": {
"name": "Area",
"tags": {},
"geometry": ["area"],
"matchScore": 0.1
},
"line": {
"name": "Line",
"tags": {},
"geometry": ["line"],
"matchScore": 0.1
},
"point": {
"name": "Point",
"tags": {},
"geometry": ["point", "vertex"],
"matchScore": 0.1
},
"relation": {
"name": "Relation",
"tags": {},
"geometry": ["relation"],
"matchScore": 0.1
}
A "name" field must be included:
"name": {
"key": "name",
"type": "localized",
"label": "Name",
"placeholder": "Common name (if any)"
}