[Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

Colin Smale colin.smale at xs4all.nl
Tue Aug 16 16:28:20 UTC 2016


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 <wp4587 at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb 

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

 

Links:
------
[1] http://www.openstreetmap.org/node/1116249155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20160816/82c09f8f/attachment-0001.html>


More information about the Talk-GB mailing list