<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-07-31 15:56, Joren wrote:<br>
</div>
<blockquote cite="mid:51F9179A.4090206@telenet.be" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Thanks for the fast replies.<br>
<br>
Following the wiki:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
"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 this case, the
information in the tag is redundant. Some contributors even go
as far as to delete this tag when they see it as equivalent to
the boundary information.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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)."<br>
<br>
1. Are our boundaries well developed in Flanders/Belgium?<br>
2. Is the latter still true (related to the extensive
calculations/routing/...)?</div>
</blockquote>
<br>
<div class="moz-cite-prefix"> I believe you will find back only 1
results when searching for the right keywords = "mechelen, belgie"
/ "lier, belgie", the administrative set. Nothing from the is_in
tag seems to be considered at first sight trying to search for
those exact words.<br>
</div>
<br>
<blockquote cite="mid:51F9179A.4090206@telenet.be" type="cite">
<div class="moz-cite-prefix"> <br>
If we don't need it anymore, why keeping this tags?<br>
Looks to me quite related to the mapping/discussion of
'AssociatedStreet' and 'addr:xxxx'-tags. Not tag every single
house with all addr:-tags but create a relation that contains
these tags. I agree with the fact 'keep the exisiting ones as
they are', but is it applicable in this case to?<br>
</div>
</blockquote>
I don't think it's the same, the removing of is_in implications are
thought to be small, but if you start removing addr: tags, there
will be more than a few apps that will suffer. I would leave those
a lone for now.<br>
<br>
<blockquote cite="mid:51F9179A.4090206@telenet.be" type="cite">
<div class="moz-cite-prefix"> I'm no expert on geotagging/database
management/... and am studying Industrial Engineer. One of the
key principles in an organisation is: Remove everything you
don't need from the 'work area' (OSM in this example). It waste
time/resources/... (see 'Lean', <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://en.wikipedia.org/wiki/Lean">http://en.wikipedia.org/wiki/Lean</a>).
Not to say we have to move toward a full Lean OSM :), but if we
really don't need it anymore -> kill it.<br>
</div>
</blockquote>
<br>
It's great if you want to do this 1 by one, but consider an overpass
query at <a class="moz-txt-link-freetext" href="http://overpass-turbo.eu/">http://overpass-turbo.eu/</a> <br>
<br>
You would be better to (don't zoom too far out ...) export to josm,
and do them all at once, no need to waste time on it per node
discussion. But the act of destroying them will take far less time
that checking and making sure that by dropping those we do good
work.<br>
<br>
<!-- This query looks for is_in nodes --><br>
{{key=is_in}}<br>
{{type=node}}<br>
<osm-script output="xml"><br>
<query type="{{type}}"><br>
<has-kv k="{{key}}"/><br>
<bbox-query {{bbox}}/><br>
</query><br>
<print mode="meta"/><br>
<recurse type="down"/><br>
<print mode="meta"/><br>
</osm-script><br>
<br>
Quite a few around I'd say .... So that makes me reconsider the
above, there seems to be a lot more info in some subkeys as well.
I would prefer just FIXING the wrong ones instead, less work and
less impact overall. The overpass results show you clearly what is
around.<br>
<br>
Glenn<br>
<br>
<br>
</body>
</html>