On 2013-07-31 15:56, Joren wrote:
Thanks for the fast replies.
Following the wiki:
"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.
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)."
1. Are our boundaries well developed in Flanders/Belgium?
2. Is the latter still true (related to the extensive
calculations/routing/...)?
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.
If we don't need it anymore, why keeping this tags?
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?
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.
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',
http://en.wikipedia.org/wiki/Lean). Not to say we have to move toward
a full Lean OSM :), but if we really don't need it anymore -> kill it.
It's great if you want to do this 1 by one, but consider an overpass
query at http://overpass-turbo.eu/
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.
<!-- This query looks for is_in nodes -->
{{key=is_in}}
{{type=node}}
<osm-script output="xml">
<query type="{{type}}">
<has-kv k="{{key}}"/>
<bbox-query {{bbox}}/>
</query>
<print mode="meta"/>
<recurse type="down"/>
<print mode="meta"/>
</osm-script>
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.
Glenn
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
