Frank Steggink wrote: > Hi, > > As a bit of a challenge I've looked at the administrative data pointed > out by Nicolas Gignac: [1]. I know there are some doubts about the > accuracy, but this was also meant as an exercise to deal with this kind > of data. Maybe it can be reused for other purposes, although I haven't > written the tool I used in a generic way. I also hope that the more > accurate (1:20k) data uses the same structure. > > First I converted this data to SHP (with an ESRI tool called Import71, > and then ogr2ogr). Then it was converted to OSM with shp-to-osm.jar. > However, the data has a topological structure, so it has not much value > if it would be imported into OSM directly. > > The set of administrative boundaries contains municipalities, MRCs, > administrative regions (17) and urban agglomerates. The municipal data > contains also information about MRC, admin. regions and agglomerates, so > I decided to examine this further. Now the topological structure was a > benefit, because this is how administrative boundaries should also be > entered in OSM. The boundaries only contain attributes like from-node, > to-node, left-poly and right-poly. However, this is enough to compose > relationships (type=multipolygon/boundary, boundary=administrative, > etc.) out of them. Because I ended with an ArcInfo coverage as a result > of the conversion by Import71, I decided to extract data from the file > pat.adf to get the municipality and other relevant names, codes, etc. > > So far I have only created relationships, including the municipality > name. I would like to share it with you, in order to gather feedback. > The result can be found here: [2]. PLEASE do NOT upload this data to > OSM! The ways are sorted in the relationship, so they form closed > chains. Also the nodes where multiple ways meet have been deduplicated, > otherwise JOSM (and also OSM itself) won't recognize the ways as being > connected. The deduplication was based on the actual coordinates, not > the node IDs used in the topology. > > Things to do: > * Detect which boundary is the outer boundary, and which ones are the > inner boundaries. Obviously, the ring with the biggest surface area is > the outer boundary, and the rest are inner boundaries. > * Add multiple municipalities in the same relationship. > * Create MRCs, administrative regions, and urban agglomerates. > > More information about administrative boundaries can be found in [3]. > For Canadian provinces admin_level=4 should be used, for regional > municipalities (MRCs in Quebec) admin_level=6, and actual municipalities > admin_level=8. I would like to propose to use admin_level=5 for the > regions. They have at least a semi-offical status. Others might be able > to elaborate on it more. This leaves the urban agglomerates (Montreal > and Quebec only), for which admin_level=7 would be a natural choice, > although I'm not sure if they have any official status. What do you guys > think? > > Regards, > > Frank > > [1] > http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp > [2] http://www.steggink.org/osm/Quebec/quebec_munic.zip > [3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative > > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca > > A clarification on this: "Add multiple municipalities in the same relationship." Several municipalities have exclaves, like outlying islands. They are divided over multiple polygons, so I created multiple relations for them.
For the higher-level administrative boundaries, I intend to use information from the AAT file which was generated by Import71. This file contains records describing the boundary type. Although there is specific data for each level, in OSM it would be best to reuse the same set of nodes and ways, and that can best be done by using the same source data. Frank _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
