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.ngi.be/topomapviewer/public ; <http://www.ruimtemonitor.be/geoloket/> http://www.ruimtemonitor.be/geoloket/ ; etc [2] http://www.antwerpen.buurtmonitor.be/ Van: Sander Deryckere [mailto:[email protected]] Verzonden: maandag 30 november 2015 14:09 Aan: OpenStreetMap Belgium <[email protected]> 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 <[email protected] <mailto:[email protected]> >: 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 [email protected] <mailto:[email protected]> https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
