[Talk-GB] Admin boundaries for unparished areas - how to handle?

[Colin Smale]

Hi Ed et al., 

Of course I am not asking this on my own behalf, but on behalf of all
stakeholders i.e. "the OSM Community". We have this situation where
these relations have been added, and they are being used by Nominatim
(because of their tagging). The user in question has not shown himself
to be very approachable although that may be personal, as he has
attacked both me and some other mappers when we attempted to debate this
with him. I have no appetite for a tagging war or personal battles. If
the community agrees on a way forward, be that deletion or retagging,
then it should be executed with that mandate. So far there seems to be
consensus that these relations are undesirable, but now what? The user
in question sticks two fingers up when the issue is raised, but if I (or
any other individual) were to bring the situation into compliance by
deleting or retagging, all hell would break loose. I don't mind spending
half an hour sorting this out in OSM, but I want to feel that I have the
support of the community in performing this action and would expect
their support, and this is what I am trying to measure now. 

I was hoping that we could find some middle ground by allowing the
relations to persist but outside the admin boundary regime, so we could
keep everybody a bit happy. I am not interested in being involved in OSM
as a diplomat or a politician. My instinct is that we should be able to
form an opinion as a community, and enforce that. If I'm honest I am
beginning to doubt whether the existing governance is fit for purpose. 

What now?

Colin 

On 2016-08-20 16:57, Ed Loach wrote:

> I don't think we should be mapping things as parishes then adding an extra tag to say "this isn't a parish". It isn't an administrative area so shouldn't have an administrative boundary. 
> 
> At best you could perhaps use something like boundary=unparished_area (no admin level needed, though I suspect people might add 10 so they can extract the full set by admin_level) to keep it separate from the admin and political boundaries. 
> 
> Ed 
> 
> FROM: Colin Smale [mailto:colin.smale at xs4all.nl] 
> SENT: 20 August 2016 13:34
> TO: Talk-GB
> SUBJECT: [Talk-GB] Admin boundaries for unparished areas - how to handle? 
> 
> Hi everyone, 
> 
> There have been some discussions in the past couple of weeks about unparished areas, i.e. areas in England which are not part of any Civil Parish. Civil Parishes are given an administrative boundary relation with admin_level=10 to represent their entity as an administrative area. But the unparished areas are not, because by definition they are not an administrative entity. 
> 
> In the East Midlands Alex Kemp has been adding relations for these unparished areas, only distinguishable from Civil Parish relations by means of the value of the "designation" tag. This is contrary to our normal practice and feels counter-intuitive - why add an object to OSM which by definition does not exist? 
> 
> To an extent I can understand his rationale. Without these areas there are holes left in the coverage at admin_level=10, and often these areas can be correlated to places or former administrative entities, giving more-or-less obvious candidates for names in many cases. Doing this is alleged to improve the behaviour of Nominatim, which sometimes struggles with the complex structures in the UK compared to many other countries. However they are NOT administrative entities, and to tag them as such would be wrong. Words like "tagging incorrectly for the renderer" come to mind. 
> 
> So, ahow *should* they be tagged? What should be done with these unparished areas? Should the existing relations be reverted? Retagged to something else? Should we document this and encourage other admin boundary maintainers like me to replicate the pattern across the whole country? 
> 
> Best regards, 
> 
> Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20160820/86c350b9/attachment-0001.html>