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
> [email protected]
> 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
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
