Nice work Frank! I will post this topic to some of the people I know in the government of Quebec (e.g. Ministère des Ressources Naturelles et Faune), they will happy to know that some of their data has been used in OSM! They might think of freeing other datasets...
Cheers, Nicolas 2010/1/22 Frank Steggink <stegg...@steggink.org> > Frank Steggink wrote: > > 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 > > > > > > Hi all, > > The last days I've flexed my Mapnik / osm2pgsql skills, and was able to > put a visualization of the tiles online. They can be found here: [1]. > The tiles themselves are generated as transparent PNGs, so they didn't > have to be integrated into the data. Note that I also adjusted the > zoomlevels, so they are visible earlier than they would be normally. > Levels 6 - 13 are available, but the last level is still rendering as I > write this. I haven't take care of any labeling yet, although it is > present in the DB. > > Cheers, > > Frank > > [1] > http://mijndev.openstreetmap.nl/~fsteggink/quebec_admin.html<http://mijndev.openstreetmap.nl/%7Efsteggink/quebec_admin.html> > > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
