[OSM-talk-be] Sub-municipal admin boundary relations
Erik B
ebe050 at gmail.com
Mon Nov 30 22:20:59 UTC 2015
Where I tagged some level 9 part-municipalities I checked the website of
the municipality. Mostly they have a list of what they consider as their
part-municipalities.
If they have such a list then it is a better basis for level 9
part-municipalities than the history of fusions.
Op 30-11-15 om 19:17 schreef joost schouppe:
> 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 <http://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 <mailto: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
> <mailto:sanderd17 at gmail.com>]
> *Verzonden:* maandag 30 november 2015 14:09
> *Aan:* OpenStreetMap Belgium <talk-be at openstreetmap.org
> <mailto: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 <mailto: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 <mailto:Talk-be at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org <mailto: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/>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20151130/f8574ecb/attachment.htm>
More information about the Talk-be
mailing list