[Tagging] Non-geometrical ways in boundary relations

[Colin Smale]

Tom, I think we need to have consensus about what we mean by admin
centre. The traditional "town hall" is frequently no longer the central
office location where the administrative and/or customer-facing staff
are located, and indeedn, these functions may be distributed over
multiple locations. How are we to choose which is to be the admin
centre? Or shall we add all the locations? In that case, I think we will
need a mechanism to indicate which is the primary location - maybe the
advertised address for postal purposes from the website? Or the
statutory seat? 

In the UK it is mostly linked to a place node, which indicates the
city/town/village but not down to the level of a building. We should be
able to do geometric searches for civic administration buildings in the
area (given appropriate tagging). But watch out for councils whose seat
is not within their own area, such as Surrey County Council in the UK.
Their County Hall is in Kingston-upon-Thames, which is now in London (it
was once in Surrey but the boundary was changed).

//colin 

On 2017-01-26 12:46, Tom Pfeifer wrote:

> Boundary relations [1 [1]] can have members that are the boundary itself, thus the geometrical part of this boundary, as well as further details, in particular an admin_centre and a label, which are both extremely well accepted, and (disputed) a subarea.
> 
> The valid geometrical members are 'outer' (5M) and 'inner' (45T), and the deprecated <empty> (62T), enclave (0) and exclave (0) [2 [2]]. enclave and exclave are extinct since 2013, according to wiki discussion.
> 
> admin_centre is used on nodes (184T), ways (142) and relations (16).
> 
> It is defined in the wiki so far as a node for the "capital, county seat etc., usually a town, city or village (depending of the boundary level, see place=*)"
> 
> Now, for admin levels relating to counties and towns, the seat of the admin_centre is typically the town hall, which is often mapped as a building outline, thus a way. It carries further useful tags such as the name of the particular administration and its address.
> 
> There is no logical reason why this townhall should not be added to the boundary relation as a way. That was proposed on the wiki discussion page a few months ago.
> 
> However, mapping it this way triggers a problem in carto [3 [3]], which relates upstream to an issue in osm2pgsql [4 [4]]. Apparently any way member in a boundary relation is treated as part of the geometry (catch-all), instead of processing only those that are defined as such (white-listing). Catch-all rules are frowned upon in different situations as they are prone to errors.
> 
> Tu summarize, I propose to allow admin_centre as ways in boundary relations, and fix the catch-all software issue.
> 
> [1] https://wiki.openstreetmap.org/wiki/Relation:boundary
> [2] http://taginfo.openstreetmap.org/relations/boundary#roles
> [3] https://github.com/gravitystorm/openstreetmap-carto/issues/2559
> [4] https://github.com/openstreetmap/osm2pgsql/issues/678
> 
> --
> tom
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
------
[1] https://wiki.openstreetmap.org/wiki/Relation:boundary
[2] http://taginfo.openstreetmap.org/relations/boundary#roles
[3] https://github.com/gravitystorm/openstreetmap-carto/issues/2559
[4] https://github.com/openstreetmap/osm2pgsql/issues/678
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170126/63b65f4d/attachment.html>