Key:is_in
 is_in
|
|
| Description |
|---|
| The is_in tag is used to index where a place or feature is. |
| Group: Boundaries |
| Used on these elements |
    |
| Wikidata |
 Search Wikidata
|
| Status: de facto |
|
|
| Tools for this tag |
|
Contents
How to avoid this tag
- Boundaries
- Places
- Multipolygons
- Overpass turbo/OverpassQL for mappers and end-users. atms in Paris are really simple to query. See more examples
Except rare cases described below this tag should not be used.
When to use?
The is_in tag in OSM is one of the earliest tags in OSM, and is still in common use.
The is_in tag pre-dates boundary polygons. When a region has a well developed set of boundary polygons the information that could be placed in the is_in tag on an object can usually be derived from the boundaries that contain it, in which case the information in the tag seems redundant. Some contributors have advocated deleting this tag because they see it as equivalent to the boundary information. Other contributors consider that view to be short-sighted at best.
The tag still can contain important information when boundaries aren't fully developed. Even if the information is redundant, it permits simpler searching and easy disambiguation between two similarly named objects (without having to do extensive calculations to calculate all the containing boundaries, all of which means a faster result) [ citation needed ]. Experience in the UK also suggests that it can help to tailor the precise information offered up by Location & Search facilities [ citation needed ].
Description
This tag lets you by specify, with words, where a place or feature is in the world. It can be used with anything, pubs, buildings, streets, parks but is most likely to be used with places. It is recommended that it is ALWAYS used with place tags to help some search engines - for example there are several places called San Francisco in the world (Philippines, Spain, USA), but to return only the one in California would required something like:
- name=San Francisco
- is_in=California; CA; USA
Although there is no requirement to write entities in a given order or to list everything, it is recommended that the reading order is from smaller to bigger entities and all full names are used up to the country level. Note these are valid, too, although not recommended:
- name=SOMA
- is_in=USA;CA;California;San Francisco
- name=SOMA
- is_in=San Francisco
For making categories
Less commonly, the tag can also be used to create a category for searching, e.g.
- name=Canberra
- is_in=capital_cities; Australian Capital Territory; ACT; Australia
means that Canberra can now appear in a list of capital cities of the world.
- This can most likely be accomplished better with Proposed features/capital --Gorm 15:08, 6 April 2010 (UTC)
- See also: Relations are not Categories
Improving accuracy
One weakness of the tag is that it might not be clear to processing programs exactly what each value stands for. In the above examples, is CA the short form for California or Canada? Is capital_cities a place or a category?
Boundary relations is one solution, and also solves a redundancy issue, i.e. it is a waste writing is_in=Sweden,Stockholms län,Stockholm for every street in Stockholm, when we can just use 3 boundary relations for Stockholm, Stockholms län, and Sweden, without having to tag each street with lengthy tags. However many boundaries are difficult to trace exactly (notably in development countries) and for building them, they have to be estimated or these relations may be incompletely known. Tagging individual elements may be a transitory solution until a set of necessary boundaries is setup and refined with enough accuracy and completion.
Another solution is to use qualify is_in=* like this:
- name=Canberra
- place=city
- is_in=capital_cities; Australian Capital Territory; ACT; Australia
- is_in:state=Australian Capital Territory
- is_in:state_code=ACT
- is_in:country=Australia (use english name of the country)
- is_in:country_code=AU (ISO 3166-1 two-letter country code, in UPPER CASE to conform with addr:country=* tag)
Any suburb, road or other feature in Canberra now needs just one tag to imply all the above:
- is_in:city=Canberra
Any of the place keys can be used as qualifiers:
- is_in:continent=*
- is_in:ocean=* (proposed)
- is_in:sea=* (proposed)
- is_in:archipelago=* (proposed)
- is_in:island=*
- is_in:country=*
- is_in:state=*
- is_in:municipality=* (proposed)
- is_in:city=*
- … town, suburb, village, hamlet, locality
In most cases these specialized tags are only there to help qualify existing data, when the boundaries:
- are still incomplete or could be ambiguous (when they overlap), or
- are almost impossible to draw correctly and accurately (e.g. continents, seas, mountains or mountain ranges, valleys, many forests with weak visible separations, glaciers, ice shelves, plateaux, cultural regions...) or
- to structure exactly due to disagreements in classifications such as archipelagos.
Even country borders may be weak in some disputed areas, where some features located there may be tagged in one country, while other would be tagged in another (some disputed areas are either overlapping, or are mapped separately even if they do not match a governing country, and there exists some joint areas managed in condominiums, or with administrations alternating every few months, as well as some areas claimed by no country at all because of disputes on nearby larger areas).
Using "is_in:*" tags will not help resolve these territorial disputes, but using boundary relations permits overlaps. OSM data is not the place to decide territorial disputes, and will not be made to hide these disputes by showing different data depending on country of residence of its users. However only disputes for claims made by official governments or significant local minorities with some form of government should be in OSM, using relevant sources (e.g. international treaties or UN decisions recognized by some countries, even if they are contested or interpreted differently by others). For these cases, using overlapping boundaries is highly preferable and users should not alter the boundaries for claims made by other communities on the same area, even if this causes some ambiguities or (expected) duplicate data in searches (these duplicates or overlaps may be signaled by some "Quality Assurance" tools, but only as warnings: they are not errors if territorial disputes have not been arbitrated and agreed internationaly and should not be corrected in such cases). Instead, users of data just need to use more selective tags for filtering the results in their queries.
See also
Tag "is_in"
Rationale
Basically, this means that programs can auto-generate indexes, of the form:
You are looking at data for Bedfordshire. Go up one level to England or Home Counties. Towns in Bedfordshire are: Ampthill, Bedford, Clapham, Dunstable...
- more importantly when searching by street name, e.g. for 'High Street', it can tell you which of the many results you get back is likely to be the one you want, by saying 'High Street;Fulbourn;Cambridgeshire' and 'High Street;Chapel-en-le-Frith;Derbyshire'. David.earl October 14, 2006
- This is already accomplished automatically without the use of is_in tag in Nominatim, the latest search engine. --Gorm 15:08, 6 April 2010 (UTC)
- Yeah, Nominatim is great! Where can i download it for offline navigation on my android with 8 GB sdcard? --Themroc 20:46, 21 May 2011 (BST)
Extended
Note that the is_in tag useable for more than regions you can add geographic things like "The English Channel".
Implementations
- Namefinder
- Tags on almien.co.uk
- Traveling Salesman (AdvancedAddressDBPlaceFinder -plugin)
