Montréal/Imports/Bâtiments

Montreal open data buildings was a proposed import of the City of Montreal's Bâtiments 2D 2016 dataset. This dataset of contiguous building outlines from 2016 was layered atop the City's Unités d'évaluation foncière dataset so as to parse out individual buildings (where possible) as well as eliminate any buildings which have been modified or demolished since 2016. This data covers all boroughs of the City of Montreal. This import has been successfully completed.

Goals

The goal is to import the individual buildings which can be successfully parsed from the contiguous building outline dataset, so long as the resulting buildings have not been modified or demolished since 2016 (according to the up-to-date Property Assessment Roll dataset) nor intersect with any existing buildings in OpenStreetMap. This amounts to just under 147 000 individual buildings, or around 1.2 million nodes (as of February 2, 2024).

Schedule

The tasks of obtaining license approval and generating the above-mentioned individual buildings have already been completed. All that is left to do is to pass import review and, if successful, upload. The final step of uploading will take place after the required 14-day delay.

Import Data

Background

Data source sites: Bâtiments and Unités d'évaluation foncière.
Data license: Licence d’utilisation des données ouvertes de la Ville de Montréal(note the section "Utilisation des données par OpenStreetMap").
Type of license: CC-BY-4.0.
Link to permission: Montréal/Imports/Ville de Montréal.
OSM attribution: Contributors (see "Montréal").
ODbL Compliance verified: yes.

OSM Data Files

An example of the resulting data file can be downloaded here. This is an example; the final OSM XML that will be uploaded will take into account OSM buildings created after January 21, 2024 (the date this example was generated).

Import Type

This is a one-time import that will be added to the OSM database via JOSM.

Data Preparation

Tagging Plans

All imported buildings will bear the building=yes tag and no other tags.

Initially, it was planned that each building would also have a source=https://donnees.montreal.ca/dataset/batiment-2d tag, but based on Key:source, this tag is only necessary for the changeset.

Changeset Tags

Key	Value
comment	Import of buildings from the City of Montreal's dataset of building outlines, with additional transformations to remove stale data and parse the outlines of contiguous buildings into individual buildings.
import	yes
source	Ville de Montréal
source:url	https://donnees.montreal.ca/dataset/batiment-2d;https://donnees.montreal.ca/dataset/unites-evaluation-fonciere
source:date	2016
import:page	https://wiki.openstreetmap.org/wiki/Montréal/Imports/Bâtiments
source:license	CC-BY-4.0

Data Transformation

There are three layers to be aware of to understand the following steps: the roof details layer (a line geometry layer), the corresponding contiguous building roof outlines (polygons) and the Property Assessment Roll lots (polygons). The first two are available here and their data is from 2016. The third layer is available here; its data is updated regularly and contains the year the (main) building on each lot was constructed. The data transformation was performed in QGIS.

• Using the Snap geometries to layer tool, the details layer was first snapped to itself and then the roof layer (to fix some errors).
• A small buffer was created around the details layer. The difference in geometry between the roof outline layer and the buffered detail layer was then extracted. (Split with lines would not work reliably as many roof details can only be represented by more than one line feature).
• The resulting roof outlines split-up into parts were snapped back to their original size.
• The area of each of these resulting roof parts was calculated. Each part with an area greater than 10 square meters was joined to the lot which it had the largest overlap with.
• The roof parts with areas less than or equal to 10 square meters inherited the lot association of the adjoining roof part that they had the largest overlap with, if any such association existed for one of their adjoining parts.
• The remaining roof parts (i.e. those with an area less than or equal to 10 square meters and not intersecting any roof parts previously joined to a lot) were associated to the lot which they had the largest overlap with, if any. Any roof parts which could not be joined to a lot were discarded (as the year they were built could not be verified).
• The roof parts were dissolved based on their associated lots. Disjoint features were kept separate.
• There are now geometries for individual buildings. The lot layer contains, among other data, the year each corresponding building was constructed. Buildings associated with a lot whose construction date is 2016 or later were discarded, as it can be assumed they are out-of-date.
• The initial contiguous building roof layer was split based on the lot outlines. If the largest part (by area) of the corresponding individual building differs when split using the lot lines by more than 6% in area or 4% in perimeter, the corresponding contiguous building outline is discarded. This is done to eliminate buildings whose outlines are glitched due to errors in the initial data that were not accounted for in the above process, glitched due to the above process or glitched due to unconventional lot structures (e.g., a lot within a lot). These percentages were determined after some trial and error, biasing heavily on the side of caution so as to not import any glitched buildings.
• Individual buildings whose areas are under 55 square meters were also dropped. Buildings below this (arbitrary) size are often sheds, covered by foliage and thus unable to be confirmed via Bing satellite. Moreover, their modification/removal is not reflected in the Property Assessment Roll data and, since they are located in backyards, they are also unable to be confirmed via street survey.
• A copy of the resulting layer was made, now in WGS 84 and with the previously mentioned tags added to each feature as string fields.

Note many steps relating to cleaning up the geometry (e.g., running v.clean, fixing invalid geometries, more snapping, etc.) are not included in the above summary.

Data Transformation Results

See this link containing an example of the resulting OSM XML file, with the conflation discussed in the Workflow section below applied to it.

Data Merge Workflow

Workflow

Step by step instructions

1. Using the QuickOSM plugin in QGIS, download building=* for an extent larger than the territory of the City of Montreal.
2. Using the Select by location tool in QGIS, select buildings from the Montreal open data buildings layer (after transformation) that intersect with existing OSM buildings. Invert selection and then export the resulting selection.
3. Import the shapefile into JOSM (using the OpenData plugin) and save as an OSM XML, then close JOSM.
4. Open the resulting OSM XML in JOSM as the active layer and validate.
5. Upload in chunks of 9000 features. Due to rate limiting, the import will either have to be uploaded via a number of changesets spread out across numerous sessions (100 000 nodes per hour) or it may be necessary to contact the Data Working Group to be flagged as an importer.

Changeset size policy

In JOSM, upload objects in chunks of size: 9000.

The above policy is likely to change, please see the preceding section.

Revert plans

If ever something goes wrong, the JOSM/Plugins/Reverter plugin will be used.

Conflation

If this proposal passes import review, on the day of the import, the existing OSM buildings will be imported into QGIS via the QuickOSM plugin (building=* for the relevant extent). Any buildings from the proposed import that intersect with existing OSM buildings will be removed.

An example of this kind of conflation with OSM building data as of January 21, 2024 is available above, in the Data Transformation Results section of this page.

QA

There were area and perimeter calculation comparisons to ensure no erroneous buildings made it through (see the Data transformation section of this page).

The resulting data (visible in the example OSM XML) was validated in JOSM (fixing any errors and warnings) and then looked over manually with the help of existing OSM data and Bing satellite imagery.

See also

The post to the community forum was sent on 2024-01-29 and can be found here.