[OSM-talk-be] Sub-municipal admin boundary relations

Mon Nov 30 18:17:18 UTC 2015

Interesting discussion. I wonder if there is an official dataset of
"deelgemeenten" out there. They still exist very much in the minds of
people, often being used in adresses for instance. So I do think they
belong in OSM. A clustered dataset of statistical sectors might help, if
ever that becomes open data.

For the one-to-many relationships of these "deelgemeenten", I wonder how
locals percieve them. To stick to the Antwerp example, do the people of the
former Ekeren municipality that now belongs to Kappelen consider themselves
somehow still as Ekeren? I would suggest only mapping one-on-one relations
(the cases before the "or"), and leave the more complicated ones out for
the moment. Then investigate whether or not they exist in the heads of
people.

As for the statistical sectors, I don't see much use of adding them OSM. At
the city of Antwerp, we actually release "ours" as open data [1], so, for
example users of the mentioned Buurtmonitor might take the data elsewhere
and make their own maps. Makes me wonder if we actually own the data enough
to do that.
And indeed, gent.buurtmonitor.be uses basically the same kind if setup
Antwerp does.
--
[1] http://opendata.antwerpen.be/datasets/statistische-sectoren

2015-11-30 17:25 GMT+01:00 Vincent Van Eyken <vincent.vaneyken at gmail.com>:

> Thanks for the feedback.
> I understand the argument for neatly nested relations, and I agree, it
> should be that straightforward. So, the existing anomalies should be fixed.
> But it’s the “or” part of the solution that still poses a problem then:
> putting a less-significant area on the same level (9) as complete
> part-municipalities or annexing it as A10 to the nearest A9 to which it
> never really belonged. What criteria to use?
>
> And is there (should there be?) any ‘good’ way to still link ‘orphaned’
> and split-off areas to their pre-1977 configuration, since a boundary
> relation (like the one created for Oombergen), though historically
> verifiable, does not correspond to any current administrative (or other)
> reality.
>
> And to digress a bit on statistical sectors:
>
> I just took them as an example, since they are the smallest well-defined
> entities, and can be viewed by the public in several applications. [1]
> Indeed, they are not available as open data yet (and won’t be soon, I
> guess?) and I’m certainly not suggesting an illegal import. But if they are
> ever to be imported or mapped, I would suggest admin_level 11 or 12,
> leaving room for distinct parts of part-municipalities that tare larger
> than sectors. Or indeed dump the admin part and just use
> boundary=statistical, since they are essentially just that.
>
> E.g. the Stad Antwerpen administration is clearly making use of the
> sectors [2], calling them “buurten”. Clusters of sectors are called
> “wijken”, which in their turn are grouped together into the “districten”.
> Translated into admin_levels this would give: buurt (11) < wijk (10) <
> district (9). Note however: District Berendrecht-Zandvliet-Lillo only
> contains the “wijk” Polder + an uninhabited port/industrial area, but was
> never a municipality in itself, as it is the merger of 3 pre-1958
> municipalities, that are still more easily distinguishable than many
> “wijken” of the more urbanized districts.
>
> I believe Ghent uses a similar system, though there several
> (super-)sectorial boundaries not always match the pre-1977 municipal ones,
> I think.
>
> Anyway the sectors are not yet the issue here.
>
> ---
>
> [1] http://www.ngi.be/topomapviewer/public ;
> http://www.ruimtemonitor.be/geoloket/ ; etc
>
> [2] http://www.antwerpen.buurtmonitor.be/
>
>
>
>
>
> *Van:* Sander Deryckere [mailto:sanderd17 at gmail.com]
> *Verzonden:* maandag 30 november 2015 14:09
> *Aan:* OpenStreetMap Belgium <talk-be at openstreetmap.org>
> *Onderwerp:* Re: [OSM-talk-be] Sub-municipal admin boundary relations
>
>
>
> IMO, admin levels should nest nicely. That's also why the "gemeenschappen"
> are no administrative boundaries, but political ones. They don't match with
> the other structures like provinces and arrondissements.
>
> So for Oombergen, there are two possibilities: Split Oombergen in two A9
> relations and add them to both municipalities (if the split-off part is
> big), or keep only one Oombergen relation in one municipality, and add the
> split-off part to a different part-municipality.
>
> Part-municipalities are still used in administration (mostly as part of
> addresses, though bPost doesn't prefer them), and they're verifiable (from
> historic data). So they fit into OSM.
>
>
>
> I can also see where you're going with NIS-INS statistical sectors.
> They're verifiable (from a central authority), well-defined, and used in
> administration. So if they match the existing boundary definitions, they
> could be used for an A10 level. Though I wonder where you'll get the data
> from. AFAIK, NIS-INS data is still closed? Also note that not all
> boundaries should be administrative. I think adding a boundary=statistical
> is not an issue in case the statistical boundaries don't match our current
> administrative ones.
>
> And, for all other levels, I fear that it's not really verifiable, which
> is a key-requirement for inclusion in OSM.
>
> Regards,
>
> Sander
>
>
>
>
>
> 2015-11-30 13:34 GMT+01:00 Vincent Van Eyken <vincent.vaneyken at gmail.com>:
>
> Hi to all
>
> Following a question on the forum [1], pointed out to me by escada, I
> think it might be useful to ask the mailing list for a general opinion as
> well… It’s about how to map part-municipality relations [2], something I
> tend to do from time to time so…
>
> I think this issue has probably been discussed a few times already on the
> mailing list and wiki (but without reaching a clear consensus on solid
> guidelines for the smallest admin_levels?)
>
> So here is a summary of how I think the matter stands and how I try to map
> accordingly: (for Dutch, see the forum post)
>
> Admin_level=8: municipality
> admin_level=9: “part-municipality”; areas that were a separate
> municipality up until 1950-1960
> admin_level=10: a distinct, major part of a (part-)municipality, with a
> distinctive ‘core’ (village/hamlet/…) and a well-defined boundary; major
> splits from the original municipality, or suburbs/large neighbourhoods
> (“wijk”) of the ‘new’ municipality
> admin_level=11: smaller split parts of ex-municipalities, smaller
> neighbourhoods (“buurt”), statistical sectors (NIS-INS)?
> or admin_level=12 for statistical sectors (IF they are to be mapped in OSM
> at all)?
>
> Of course admin_level>=9 has no clear legal basis anymore (except for the
> districts in Antwerp, and maybe the statistical sectors), only a
> historical-sociological-mental-… one, so they are hard to define and
> classify hierarchically, both in OSM and in ‘real life’…
>
> Open questions:
> should the whole territory in the end be divided in admin_level=9
> relations? (what with split ex-municipalities? And never-merged ones?)
> is one admin_level relation ‘allowed’ to have direct subareas of different
> levels? (e.g. both AL9 and AL10 as subareas of an AL8) or is the hierarchy
> to be strictly followed (an AL10 always has to be in an AL9, and basically
> follow the letter codes of the NIS-INS for AL9s)?
>
> ---
> [1] http://forum.openstreetmap.org/viewtopic.php?id=30946
> [2] specifically Oombergen: http://www.openstreetmap.org/relation/3395550
>
>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>

-- 
Joost @
Openstreetmap <http://www.openstreetmap.org/user/joost%20schouppe/> |
Twitter <https://twitter.com/joostjakob> | LinkedIn
<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/> | Reddit
<https://www.reddit.com/u/joostjakob> | Wordpress
<https://joostschouppe.wordpress.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20151130/2c0d237b/attachment.htm>