Przejdź do głównej zawartości



Below I will outline improvements for data interoperability regarding Wilderness Study Areas in the United States: https://en.wikipedia.org/wiki/Wilderness_study_area



A few days ago, I asked the community about converting general GIS polygons into OSM multipolygon relations. I’ve searched online but havent found a workflow that fits my needs.





I’m planning to update and expand the administrative boundaries for Bali in OSM. I’ve already prepared the multipolygons for admin_level 5, 6, and 7 using single shared ways for efficiency. By leveraging Google Sheets, I’ve also compiled a comprehensive list of Wikidata, Wikipedia links, and multilingual names to better serve Bali’s international profile.

However, the conflation process is proving to be a challenge. The existing data is quite a “nightmare” to clean up; many roads and waterways are currently shared with administrative relations, and landuse or natural features are glued to the boundaries. Time to start untangling!




















Mapping administrative boundaries in Indonesia can tricky especially when dealing with overlapping names. Here is my simplified workflow for preparing this data:

1. Data Sourcing


First, download the official spatial data from Peta Rupa Bumi by Badan Informasi Geospasial. This serves as the primary geometry source.

2. Extracting Place Nodes


Since the source data is in polygon format, I use QGIS to extract the centroids (points). These points are essential for creating the place=* tags that represent the center of each administrative area.

3. The Importance of Kemendagri Codes


The polygons include Kemendagri reference codes. These are vital for:

  • Conflation: Ensuring data matches across different sets.

  • Identification: Many villages (admin_level 7 or 8) share the same name. The code helps distinguish them within a Regency or Province.

4. Enriching Metadata


Using spreadsheet tools and conflation techniques, I cross-reference the data to add:

  • wikidata and wikipedia tags.

  • Multilingual names (name:en, etc.).

5. Geometry Processing


To follow OSM best practices, I convert the polygons into independent ways (polylines).

  • This allows adjacent areas to share a single boundary line via a multipolygon relation.

  • Once converted, I export the result as a .geojson file.

6. Final Tagging


Finally, I use the previously extracted place nodes to quickly copy and paste the relevant tags into the new multipolygon relations in my OSM editor.