Proposal talk:Is In

Wouldn't it be good to use the Role-attribute of a relation-member to assign the bigger the special role "superior" or "center" (or something else). This way it would be clear from the relation which is the superior city/land without looking at the name (which may even differ from the name of the place, see below)

Example: In my region we have the municipality Inden (de:Inden) which center is the place named de:Inden/Altdorf.
We would have the node "Inden/Altdorf" as a member of the relation named "Inden" and give the Role "center" to that node.

AFAIK there are more of these municipalities (in Germany) with different names than their centers. When it comes to (German) districts this could be used too to define the district-center. --Dennis de 15:22, 9 November 2007 (UTC)

Inheritance

I can't imagine that a place should name every possible choice that may apply.

When I take a certain node, this may be within a district which is part of a small town, part of a community, belonging to an administrative collectivity, within a county, a federal state, a country, a continent - not to speak of the world, universe or more. (German structure e.g.: Deutschland > Bundesland > Regierungsbezirk > Region > Kreis > Gemeinde > Ortschaft > Ortsteil > Hof > Gebäude > ...). I feel that just the closest match should be named. If there is no chance for a recursive inheritance of all above, the other parts should be marked as inherited is in (is_in_inherited?) and could/should be added automatically. --Traut 12:04, 16 January 2008 (UTC).

Yes, a way on including an is in relation inside a higher level is in relation is needed, that would provide the need to only include the ways/nodes in the lowest level relations that uniquely define them. --Beldin

I have futher experimented with this idea, and for example in my local area I have create 'is_in's at the Suburb/Postcode/City and State level, so a nearby street, Evan Avenue "is_in" Salisbury (the suburb) which "is_in" 5108 (the postcode) which "is_in" City of Salisbury (The council) which "is_in" South Australia (the state). This could naturally be extending to include a Giant "is_in" Australia which contains everything. Surely the small amount of computing power required to traverse these details when needed is compensated for by the massive reduction in the is_in and postal_code tags that are currently all over the maps.

And of course should one of the is_in's be split across the next level up you can push the linage lower down, so a post_code that has it's suburbs split across 2 city's you just put the is_in's for the city at the suburb level instead.

Other is_in's I've considered using here along these ideas are the local/state/federal electoral districts.

If JOSM's relation ship "Download members" button is recursive (it can always be made recursive) it could become possible to download "everything in City of Salisbury" in 1 easy step.

In addition, use a few is_in relations rather that repetative is_in/postal_code tags massively reduces the chances of spelling errors etc hiding locations. --Beldin

Recursive inheritance

I would think all the localities in my home town could be in one Is_In relation, than maybe put all the town relations into a state relation and all the state relations into a nation relation, that way adding another place to the town relation (like the suburb I forgot about when I updated the relation) will automatically be updated in the state and the nation, wont it? --Skippern 23:49, 3 December 2008 (UTC)

Why this was rejected?

I like this proposal very much. Why it was rejected? --Jakubt 23:49, 25 August 2009 (UTC)

It's not actively rejected but abandoned - no one has coded anything to use it nor have they convinced others to code anything to use it. Check also this page: Relations/Relations_are_not_Categories. At least for administrative borders the direction things are going seems to be to draw the boundaries as ways; then we can find for any feature which region/city/... it is inside of, vs. just for those that belong in a relation. Alv 07:56, 26 August 2009 (UTC)

Key:is_in is already a pointless waste of database space. It's a poor solution to spatial indexing, a problem which is already solved by... spatially indexed databases. An is_in relation just takes the idea to new levels of pointlessness. Can someone link to a mailing list discussion? It has been discussed at length -- Harry Wood 18:53, 4 February 2010 (UTC)

See the same discussion here. --Erik Lundin 21:25, 13 February 2010 (UTC)