Dave, if the is_in values are based on common usage rather than
administrative reality, then it would actually be correct to leave them
unchanged.
The point I am trying to make, is that I see a need to support a variety
of addressing/location systems, which are all correct in their own way,
but useful for different things. In order to do that we need additional
tagging systems, otherwise people will try to force-fit (for example)
postal addresses (postcode sectors, post towns etc) onto administrative
boundaries and the result will be neither fish nor fowl.
Is Rochester in Kent? Most people would say yes. "Where am I?" (powered
by Nominatim) returns:
*
Troy Town, Rochester, Medway, South East, England, United Kingdom [1]
Which while administratively correct (except for Troy Town which is a
suburb, modelled in OSM as a simple node without a defined boundary), is
not particularly useful (IMHO of course) - a more typical human would
expect "Rochester, Kent, England, United Kingdom"
I am glad you asked about Nominatim's algorithm. I suspect there is an
element of black magic involved. I hope they do not keep it too secret
in order not to encourage "tagging for the renderer" but some insights
would definitely be useful. Then we want to think what we actually
expect Nominatim to return for reverse geocoding. Postal address?
Administrative divisions? Local perception?
Colin
On 2016-08-16 17:37, Dave F wrote:
> I queried Alex's rational:
>
> http://www.openstreetmap.org/user/alexkemp/diary/39062
>
> As I noted is_in tags are hard-coded so become inaccurate if boundaries
> change.
>
> I also asked about Nominatim's search criteria on the Talk forum:
>
> https://lists.openstreetmap.org/pipermail/talk/2016-August/076592.html
>
> Dave F.
>
> On 16/08/2016 16:01, Colin Smale wrote:
>
> In the specific case of the UK, I am not convinced that is_in has no value at
> all. This is because of the huge divergence between people's perceptions and
> administrative reality. If you ask someone to give their location/current
> address, they will most likely refer to the postal addressing system, which
> is completely unconnected to administrative boundaries. They will also tend
> to add a level of detail to the address which the postal system does not
> require, but tolerates. The admin boundaries represent the legal status, but
> it will be more relevant to most people's minds if Nominatim et al. recognise
> an alternative place hierarchy. I think place=* polygons/nodes may already be
> used, but the results sometimes seem to be an awful jumble of admin
> boundaries and place-based info. The fact that large swathes of the
> countryside are unparished (i.e. no admin_level=10 polygon with a name) makes
> the quality/accuracy of the results variable according to the location. Alex
> Kemp is
experimenting with introducing artificial admin_level=10 polygons for these
unparished areas with names based on historical data to help Nominatim which
IMHO is not the way to do it. Parishes are useless for navigation/addressing
anyway.
>
> Bottom line is that locations have multiple ways of being defined, and this
> is not currently embraced by OSM which wants a nice simple address+polygon
> hierarchy. For many countries that works, but not for the UK. It is possible
> that the is_in data can give an alternative perspective. BUT it needs to be
> kept distinct from the admin boundaries, which are a matter of law, and it
> needs to give complete coverage of the country, which at present is probably
> not the case.
>
> Colin
>
> On 2016-08-16 14:55, Dave F wrote:
> +1
>
> Also his use of is_in:* is also redundant when the boundary tag is used,
>
> Dave F.
>
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will
> Phillips <wp4...@gmail.com> wrote:
>
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
>
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
>
> There's no good reason to keep them.
>
> Thanks,
> Andy
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
Links:
------
[1] http://www.openstreetmap.org/node/1116249155_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
