Import/City of Fargo, North Dakota Addresses
This is a plan for the addition of address point data for the City of Fargo, North Dakota. This effort builds on successful import projects completed last year and more recent assisted mapping projects in which address data has been prepared for mappers to add to OpenStreetMap via OSM editors (see Data Updates section below). For a list of other Esri-curated datasets that are available for mapping, please see Esri ArcGIS Datasets.
Goals
The goal of this effort is to add the City of Fargo addresses data to effectively complete the coverage of addresses for the City, using authoritative data from the City. This effort would greatly enhance the coverage of addresses for the City, while retaining the many addresses already added to OSM. The City data includes several address fields that can be added as tags to new or existing buildings, or added as separate nodes (points), as decided by the mapper.
Schedule
Data preparation was completed in April 2021. The edits to OSM would be performed incrementally by OSM mappers over the remainder of 2021 and beyond, starting after data is reviewed by the OSM community.
Source
The source address points were assembled in February 2021 as part of Esri Community Maps Data (v1.2), made available by the City through Community Maps Data Sharing.
The processed address points that could be added to OSM are available to access on ArcGIS Online (see City of Fargo, ND Addresses). You can Open in Map Viewer to preview (click features to view tags) or sign in to export data for offline use.
OSM ODbL Compliance: Yes, the data is provided under a CC-BY 4.0 license, with explicit waiver for use in OpenStreetMap as defined by LWG.
Data Preparation
The processed building footprints referenced above were created using these Esri Data Processing Steps for Buildings and Addresses, developed and refined while doing data prep for several city and county communities in the United States. Below are a couple notes specific to the City of Fargo addresses data data.
- The processed building footprints data contains 72,684 address points, most of which do not already existing as address features in OSM.
- The data includes several fields (addr:housenumber, addr:street, addr:unit, addr:city, addr:state, addr:postcode) that have been prepared to be added as tags (keys/values) in OSM.
Data Conflation
The City address point data is useful for adding address tags to existing features, such as buildings or amenities, that do not currently have address information. Address tags can be added to individual features quickly and easily using tools such as RapiD and JOSM by selecting both features (e.g. building footprint and overlapping address point) and conflating the address tags to the building feature. Mappers should take care to make sure that the appropriate keys and values were added to each individual feature.
Data Updates
The plan is to perform the updates using a new version of RapiD and an updated Map with AI plugin for JOSM (see Esri blog post on new tools in OSM editors for more detail). The new tools enable OSM mappers to access ArcGIS Datasets hosted in ArcGIS Online and select individual features to use while editing OSM. The mapper is able to select a feature, review and edit the feature geometry and available fields, and then save their edits.
The mapper has the benefit of using existing features that have been created by the data provider, along with their available field values that have been pre-processed by Esri, while also being able to compare that feature with existing OSM data (e.g. street names) and imagery to ensure it is accurate and consistent. The data source used for the edit will be added as a tag to each feature that is saved as part of a changeset unless deleted by mapper.
Accounts
The plan is for OSM mappers to use their standard OSM accounts if they are editing with RapiD and JOSM editors for OSM and editing individual features. However, if OSM mappers wish to do any 'bulk' edits or imports where they do not examine individual features, then they should create and use new dedicated import accounts (e.g. <username>_<community>_import) for those changesets.