OpenStreetMap Chicago Hack Weekend Report


Last weekend I was in Chicago for the second N-American OSM hack weekend of the year. This one, for me and Serge, was entirely dedicated to MapRoulette. We wanted to get the next generation code as close to ready as possible for release – and we got pretty close I think! Here’s a summary of what we did:

  • Looked at user interface challenges with Tom MacWright, the main architect of the iD editor.
  • Finalized the data model and ORM code.
  • Debugged and improved OAuth authentication code.
  • Discussed and finalized the design for the API.
  • Wrote setup instructions for anyone wanting to deploy MapRoulette (which would mainly be other developers wanting to collaborate on the project)
  • Created an EC2 AMI (ami-995032f0) that has MapRoulette and all dependencies ready to go for quick deployment
  • Created a list of tasks and remaining issues.

We have now gotten to a point where we can share the code and hope to attract more developers, which I think overall is a major milestone.

Here is the public GitHub repository: https://github.com/emacsen/maproulette

To reiterate, the main objectives of this next generation are:

  • Make code and database model more transparent to enable more development collaboration
  • Support for regional challenges
  • Support for working on tasks in a defined area
  • Support for difficulty preferences
  • Enable external challenge providers to submit challenge data through an API
  • Enable linking with OSM accounts to better track user activity and leverage OSM account services such as settings storage

Below is an impression of daytime at the hack weekend:

2013-04-28 14.15.25

..and nighttime:

2013-04-26 23.14.35

Looking back on a fantastic OpenStreetMap hack weekend in Toronto


I am on my way back home from my first visit to Toronto, and my first ever visit to Canada – currently nursing a mild hangover with a Minnesota ale on a 4 hour layover in Minneapolis.

All of this is connected to the second OpenStreetMap Hack Weekend in Toronto I was lucky enough to be able to attend. I had an amazing time! Steve (new!), Serge and I were able to make great progress on MapRoulette, which is of course fantastic, and I thoroughly enjoyed hanging out with old friends and new connections. I want to extend a heartfelt thank you! to everyone who participated, but especially to Richard Weait who has been a magnificent host, and Claus Rinner and Michael Morrish of Ryerson University who made sure we had a comfortable hack space.

Besides some Canadian Rye savvy – hence the current hangover – my main takeaway from this weekend is a renewed motivation to bring MapRoulette to the next level. Not only did we gain a new developer (Steve Singer, of PostgreSQL fame), we also discussed very important architectural challenges and made decisions that will allow us to move forward and make MapRoulette more flexible and extensible and easier to maintain. In the near future, it will be much easier to ‘plug in’ a new challenge, and to run more than one challenge in parallel. While we did write  some of the plumbing for this, the true value of the weekend lies not in getting a lot of code written, but in discussing development face-to-face. We now have a well-defined common operational picture, which will prove invaluable going forward.

Perhaps you would like to learn more about MapRoulette development, or the hack weekend in general? Or maybe you are wondering how you can contribute? Join the Mappy Hour tonight, March 11, at 5:30 PDT / 8:30 EDT, where we will talk about these topics among other things.

Binders Full Of TIGER Deserts


The U.S. has binders full of TIGER deserts.

Let me explain. Back in 2007, we imported TIGER/Line data from the U.S. Census into OpenStreetMap. TIGER/Line was and is pretty crappy geodata, never meant to make pretty maps with, let alone do frivolous things like routing. But we did it anyway, because it gave us more or less complete base data for the U.S. to work with. And so we worked. And worked and worked. Fixing spaghetti highways. Reclassifying and arguing about reclassifying. Connecting and disconnecting. And now, four years and change later, we have pretty maps!

Eat that, TIGER! (check it out)

But we don’t all live in Epcot Center (actually, I don’t think any of us do really) and there’s lots of places where we haven’t been taking as good care of the data. Vast expanses of U.S. territory where the majority of the data in OSM is still TIGER as it was imported all those years ago.

The TIGER deserts.

I want those all to go away, but there’s only so many folks mapping here in the U.S., so we may want to prioritize a little bit. So I wanted to look at the TIGER desert phenomenon a little closer. In particular, I wanted to look a the parts of TIGER deserts that cover towns, and even cities. That’s where people actually do live, and that’s where OSM data is most valuable.

So I set out to identify those the only way I know how: using ArcGIS. The thing is: this kind of job has ‘raster analysis’ plastered all over it, and I just don’t know how to do that using FOSS4G tools. So maybe I’ll just explain what I did in ArcGIS, and then you all can chime in with smart comments about how to do this in PostGIS, R, GRASS, QGIS or whatever free software can do this magic. If you don’t care for all that, just scroll to the bottom for the results.

I created a shapefile first with all OSM highways with TIGER tags in Florida using C++ and osmium. (There’s some good example code to get you started if you’re interested.)

Then, with that loaded into ArcMap, I first created a 5km grid with the predominant (in terms of way length) version number as the cell value.

A second grid for the neighborhood way density:

I reclassified the version grid generously – all cells with 1 or 2 a the predominant TIGER way version got true / 1, the rest false / 0. For distinguishing between built-up and boondock cells, a threshold of 1.8 looked good after some tweaking.

And finally some simple map algebra to combine the two variables into the final result grid:

So there we are folks – TIGER deserts and TIGER ghost towns in Florida:

TIGER deserts in Florida

TIGER ghost towns in Florida

Hmm. I hope we can figure out a way to improve this analysis so the situation does not look quite so bleak. GIS does not lie though – these are the 5km cells that have a reasonably high way density and TIGER way versions that are predominantly 1 or 2.

So let me know folks – 1) Is this a good approach for identifying TIGER ghost towns and if not, what is? and 2) how do you do this using FOSS4G tools?

Remap-A-Tron SOTM US Talk Slides


Here are my slides from my Remap-A-Tron talk at the amazing State Of The Map US conference from which I just returned. Without any context this is going to make very little sense, but for those of you who have seen Pulp Fiction more than a couple of times, it may still be worth a few minutes of your time. I will follow up with a more insightful post about this and SOTM soon.

Post-Redaction Repair Tools: Maps and the Remap-A-Tron


Although the OpenStreetMap data license change from CC-BY-SA to ODbL is not formally done, the redaction bot has done its thing. It was activated in mid-July after rigorous testing and months of development to go over the entire planet, square degree by square degree, and delete any tainted node, way and relation or revert it to a untainted state. (An object is tainted, simply put, when it was at some point edited by a contributor who did not agree to the license change and the new contributor terms.)

OpenStreetMap Redaction bot progress map screenshot taken on July 17th as the bot was just progressing to Switzerland and re-running London.

Although less than 1% of all data was removed in the redaction process, some areas are much more strongly affected than others, depending on the amount and previous activitiy of local ‘decliners’ as well as pre-emptive remapping of tainted features. This was made possible by tools that identified potentially tainted objects, such as Simon Poole’s Cleanmap and a JOSM plugin. (These tools have since been discontinued.)

Looking at the situation in the US, what we’re left with after the license change redaction is a map that has issues. Well, let’s say it has more issues now than it had before the redaction. Just looking at the street network, which is the one single most important dimension of OpenStreetMap if you ask me, we don’t have to look very hard to find missing  street segments, entire missing streets, and messy geometry. We had messy geometry before, because of the inherent messiness of TIGER/Line data off of which the US road network is based, but the redaction process left us with some really, ehm, interesting spaghetti in places.

Messy way geometries as a result of the redaction, near Los Angeles, CA.

Missing way segment as a result of the redaction, north of Honolulu, HI

And then there’s the invisible results of the redaction: lost attributes such as speed limits, lane count, direction of flow – but I would suggest we fix the road geometries and topological integrity of the main road network first, so the OpenStreetMap data is routable and the routes make sense. In order to do that effectively, the community needs tools. Fortunately, we have some available already. There’s Toby Murray’s map showing suspicious way segments last touched by the redaction bot. Kai Krueger provided a routing grid page that calculates route times and distances between major US cities, and compares those to reference data to expose potential routing issues. And there’s also the venerable OSM Inspector tool that provides a layer showing objects affected by the redaction process.

I also took a stab at a small set of tools that I hope will be helpful in identifying the remaining issues in the road network for the US: a Redacted / Deleted Ways map, and the Remap-A-Tron.

Redacted / Deleted Ways Map

Not unlike the redaction layer in OSM Inspector, this map duo exposes features affected by the redaction process, with a few notable differences. The main difference is that it has a clear focus on the US road network data. The Redacted Ways Map differentiates between Motorway, Trunk, Primary, Secondary and lower class roads, in an attempt to make it easier for remappers to seek out and prioritize the more important roads.

The Redacted Ways Map showing different road classes in appropriate coloring for easy prioritization of remapping efforts

The Deleted Ways map complements the Redacted Ways map. It only shows the way segments that were completely obliterated by the redaction bot. The focus on the road network means that only ways with a highway tag are visualized here.

The Deleted Ways map differentiates between ways that are likely to already have been remapped, and those that still need to be remapped.

If you look at this map, you will notice that there are two different classes of deleted ways, displaued in red and green respectively. The difference is in remapping status. The red ways are probably not remapped yet, while the green ways are likely to have been remapped already. I make this distinction by periodically comparing the deleted way geometries with newly mapped way geometries in the database. Using the Hausdorff distance algorithm as the main component, I devised an algorithm that reasonably accurately predicts whether a way has already been remapped.

Remap-A-Tron

I came up with another way to leverage the knowledge of remappedness of the OpenStreetMap street network. Building on an idea I already had semi-developed a while ago, I built a web application that serves up one deleted way geometry overlaid onto a current OpenStreetMap basemap. Using a simple menu or handy keyboard shortcuts, you can flag the segment as already remapped, skip it for whatever reason, or load that area into JOSM or Potlatch right away to remap it.

The Remap-A-Tron serves up one non-remapped important way segment at a time for remappers to work on.

The data backend is refreshed every (US) night, so there should not be too much of a lag. Currently, the app serves up only non-remapped important segments: motorways down to tertiary class roads. There are about 1900 segments in this category as of the time of writing. If a handful of people spend an evening with the Remap-A-Tron, this should be down to zero in a matter of days. Once we complete the repairs on the important roads, I can tweak the app to include all other highways (~15K segments not remapped) and ultimately all ways (~52K segments not remapped).

I built this tool with versatility in mind. After the street remapping is done, it could easily be repurposed to identify other issues in OSM that are identifiable on the Mapnik map: self-intersecting ways, road connectivity issues, missing bridge tags, maybe even missing traffic lights? I would love to hear your ideas.

If this turns out to be useful and used, I will try and increase the coverage to the entire world. For that to happen, the Remap-A-Tron will need to find a home that is not the server next to my desk, though..

Happy remapping!

Life After Redaction: Detecting Remapped Ways


There are some pretty awesome tools out there to help with the remapping effort after the redaction bot made its sweep across the OpenStreetMap database. (Does this sound like Latin to you? Read up on the license change and the redaction process here.) Geofabrik’s OSM Inspektor shows all the objects affected by the redaction. It is likely the most comprehensive view of the result of the license change redaction. Numerous other tools are listed on the Remapping wiki page. Most of these tools will show you, in some shape or form, the effects of the redaction process: which nodes, ways and relations have been deleted or reverted to a previous, ‘ODbL Clean’ version of the object.

I want to see if we can take it a step further and determine whether an object has already been remapped. This is useful for monitoring remapping progress as well as determining where to focus efforts when you want to contribute to the remapping effort.

For now, I am going to stick with ways. I think maintaining, or reinstating, a good quality routable road network is an important objective for OSM anyway, and especially at this point in time, when many roads are broken due to redaction.

Let’s start by locating a deleted way here in the US using my own Redaction Affected / Deleted Ways Map. That’s easy enough around severely affected Austin, TX:

 

I am going to use three comparison parameters to determine whether this way is likely to already have been remapped:

  1. The Hausdorff distance between the deleted geometry and any new geometries in that area
  2. The highway type of the deleted and any new geometries in that area
  3. The length of the deleted and any new geometries in that area

For this to work, I will need a table with all the ways deleted by the redaction bot. This is easy enough to compile by looking at the changesets created by the redaction account, but Frederik Ramm was kind enough to send the list of OSM IDs to me, so all I had to do is extract the deleted ways by ID from a pre-redaction database. The comparison can then be run on that table and a ways table from a current planet:

 

It is immediately clear that this way is very likely already remapped if we look at the top candidate, with object ID 172171755. It has a very small Hausdorff distance compared to the deleted way 30760760, it is tagged with the same highway= type, and the lengths are almost identical.

Sure enough, when fire up JOSM and load this area, it is clear that this area has been remapped:

 

(Selected objects are version 1 and created after July 18, 2012).

I need to do some more testing and tweaking on the query, but I will soon integrate this in the Redaction Affected / Deleted Ways Map.

 

The State Of The OpenStreetMap Road Network In The US


Looks can be deceiving – we all know that. Did you know it also applies to maps? To OpenStreetMap? Let me give you an example.

Head over to osm.org and zoom in to an area outside the major metros in the United States. What you’re likely to see is an OK looking map. It may not be the most beautiful thing you’ve ever seen, but the basics are there: place names, the roads, railroads, lakes, rivers and streams, maybe some land use. Pretty good for a crowdsourced map!

What you’re actually likely looking at is a bunch of data that is imported – not crowdsourced – from a variety of sources ranging from the National Hydrography Dataset to TIGER. This data is at best a few years old and, in the case of TIGER, a topological mess with sometimes very little bearing on the actual ground truth.

TIGER alignment example

The horrible alignment of TIGER ways, shown on top of an aerial imagery base layer. Click on the image for an animation of how this particular case was fixed in OSM. Image from the OSM Wiki.

For most users of OpenStreetMap (not the contributors), the only thing they will ever see is the rendered map. Even for those who are going to use the raw data, the first thing they’ll refer to to get a sense of the quality is the rendered map on osm.org. The only thing that the rendered map really tells you about the data quality, however, is that it has good national coverage for the road network, hydrography and a handful of other feature classes.

To get a better idea of the data quality that underlies the rendered map, we have to look at the data itself. I have done this before in some detail for selected metropolitan areas, but not yet on a national level. This post marks the beginning of that endeavour.

I purposefully kept the first iteration of analyses simple, focusing on the quality of the road network, using the TIGER import as a baseline. I did opt for a fine geographical granularity, choosing counties (and equivalent) as the geographical unit. I designed the following analysis metrics:

  • Number of users involved in editing OSM ways – this metric tells us something about the amount of peer validation. If more people are involved in the local road network, there is a better chance that contributors are checking each other’s work. Note that this metric covers all linear features found, not only actual roads.
  • Average version increase over the TIGER imported roads – this metric provides insight into the amount of work done on improving TIGER roads. A value close to zero means that very little TIGER improvements were done for the study area, which means that all the alignment and topology problems are likely mostly still there.
  • Percentage of TIGER roads – this says something about contributor activity entering new roads (and paths). A lower value means more new roads added after the TIGER import. This is a sign that more committed mappers have been active in the area — entering new roads arguably requires more effort and knowledge than editing existing TIGER roads. A lower value here does not necessarily mean that the TIGER-imported road network has been supplemented with things like bike and footpaths – it can also be caused by mappers replacing TIGER roads with new features, for example as part of a remapping effort. That will typically not be a significant proportion, though.
  • Percentage of untouched TIGER roads – together with the average version increase, this metric shows us the effort that has gone into improving the TIGER import. A high percentage here means lots of untouched, original TIGER roads, which is almost always a bad thing.

Analysis Results

Below are map visualizations of the analysis results for these four metrics, on both the US State and County levels. I used the State and County (and equivalent) borders from the TIGER 2010 dataset for defining the study areas. These files contain 52 state features and 3221 county (and equivalent) features. Hawaii is not on the map, but the analysis was run on all 52 areas (the 50 states plus DC and Puerto Rico – although the planet file I used did not contain Puerto Rico data, so technically there’s valid results for 51 study areas on the state level).

I will let the maps mostly speak for themselves. Below the results visualisations, I will discuss ideas for further work building on this, as well as some technical background.

Map showing the number of contributors to ways, by state

Map showing the average version increase over TIGER imported ways, by state

Map showing the percentage of TIGER ways, by state

Map showing the percentage of untouched TIGER ways, by state

Map showing the number of users involved in ways, by county

Map showing the average version increase over TIGER imported ways, by county

Map showing the percentage of TIGER ways

Map showing the percentage untouched TIGER roads by county

Further work

This initial stats run for the US motivates me to do more with the technical framework I built for it. With that in place, other metrics are relatively straightforward to add to the mix. I would love to hear your ideas, here are some of my own.

Breakdown by road type – It would be interesting to break the analysis down by way type: highways / interstates, primary roads, other roads. The latter category accounts for the majority of the road features, but does not necessarily see the most intensive maintenance by mappers. A breakdown of the analysis will shed some light on this.

Full history – For this analysis, I used a snapshot Planet file from February 2, 2012. A snapshot planet does not contain any historical information about the features – only the current feature version is represented. In a next iteration of this analysis, I would like to use the full history planets that have been available for a while now. Using full history enables me to see how many users have been involved in creating and maintaining ways through time, and how many of them have been active in the last month / year. It also offers an opportunity to identify periods in time when the local community has been particularly active.

Relate users to population / land area – The absolute number of users who contributed to OSM in an area is only mildly instructive. It’d be more interesting if that number were related to the population of that area, or to the land area. Or a combination. We might just find out how many mappers it takes to ‘cover’ an area (i.e. get and keep the other metrics above certain thresholds).

Routing specific metrics – One of the most promising applications of OSM data, and one of the most interesting commercially, is routing. Analyzing the quality of the road network is an essential part of assessing the ‘cost’ of using OpenStreetMap in lieu of other road network data that costs real money. A shallow analysis like I’ve done here is not going to cut it for that purpose though. We will need to know about topological consistency, correct and complete mapping of turn restrictions, grade separations, lanes, traffic lights, and other salient features. There is only so much of that we can do without resorting to comparative analysis, but we can at least devise some quantitative metrics for some.

Technical Background

  • I used the State and County (and equivalent) borders from the TIGER 2010 dataset to determine the study areas.
  • I used osm-history-splitter (by Peter Körner) to do the actual splitting. For this, I needed to convert the TIGER shapefiles to OSM POLY files, for which I used ogr2poly, written by Josh Doe.
  • I used Jochen Topf‘s osmium, more specifically osmjs, for the data processing. The script I ran on all the study areas lives in github.
  • I collated all the results using some python and bash hacking. I used the PostgreSQL COPY function to import the results into a PostgreSQL table.
  • Using a PostgreSQL view, I combined the analysis result data with the geometry tables (which I previously imported into Postgis using shp2pgsql).
  • I exported the views as shapefiles using ogr2ogr, which also offers the option of simplifying the geometries in one step. Useful because the non-generalized counties shapefile is 230MB and takes a long time to load in a GIS).
  • I created the visualizations in Quantum GIS, using its excellent styling tool. I mostly used a quantiles distribution (for equal-sized bins) for the classes, which I tweaked to get prettier class breaks.

I’m planning to do an informal session on this process (focusing on the osmjs / osmium bit) at the upcoming OpenStreetMap hack weekend in DC. I hope to see you there!

Maps of Standards


Listening to a report about the Trans Siberian Railroad on the radio this morning, my mind drifted to rail gauges, and maps of standards in general.  Here are two that have been of personal interest to me for very different reasons. The first one because I am a rail enthusiast, the second because I used to travel quite a bit within Europe where, in spite of all the European Unionism, there are a lot of AC plug standards.

Some variegated questions for the audience:

  • Is there any correlation between these two standards distributions?
  • Should this type of information be mapped in OpenStreetMap?
  • What’s your favorite map of standards?
Map showing rail gauges in use around the world

Map showing rail gauges in use around the world. Source: Wikipedia

Map showing AC power plug standards in use around the world

Map showing AC power plug standards in use around the world. Source: Wikipedia

OpenStreetMap Data Temperature – How It Was Done (And Do It Yourself!)


In my talk at State Of The Map 2011, I introduced a few new concepts relating to the local quality of OpenStreetMap data and its contributor community:

  • The Community Scorecard which is a concise way to summarize the activity of a local OpenStreetMap community
  • Data Temperature attempts to capture the ‘warmth’ of a local community in one easily interpretable figure
  • The Temperature Map captures some of the most relevant metrics for way features, the age of the last update and the number of versions, in an abstracted image of the study area.

To generate the metrics and the geodata needed, I used Jochen Topf’s osmium framework. Because I am not a skilled C++ developer, I employed the osmjs Javascript interface to the framework to parse and analyze the city-sized OpenStreetMap files. After some delay, I have published the osmjs script together with some supporting files. Feel free to use it to do your own analyses, and please improve and build on it and share back. I’d love to see this script evolve into a more general purpose quality analysis tool.

If you missed my session at SOTM11, here‘s its page on the OpenStreetMap wiki, with links to all relevant resources.

Tutorial: Creating buffered country POLYs for OpenStreetMap data processing


OpenStreetMap represents a lot of data. If you want to import the entire planet into a PostGIS database using osmosis, you need at least 300GB of hard disk space and, depending on how much you spent on fast processors and (more importantly) memory, a lot of patience. Chances are that you are interested in only a tiny part of the world, either to generate a map or do some data analysis. There’s several ways to get bite-sized chunks of the planet – take a look at the various planet mirrors or the cool new Extract-o-tron tool – but sometimes you may want something custom. For the data temperature analysis I did for State of the Map, I wanted city-sized extracts using a small buffer around the city border. If you want to do something similar – or are just interested in how to do basic geoprocessing on a vector file – this tutorial may be of interest to you. Instead of city borders, which I created myself from the excellent Zillow neighborhood boundary dataset, I will show you how to create a suitably generalized OSM POLY file (the de facto standard for describing polygon extracts used by various OSM tools) that is appropriate for extracting a country from the OSM planet with a nice buffer around it.

Let’s get to work.

Preparing Quantum GIS

We will need to add a plugin that allows us to export any polygon from your QGIS desktop as an OSM POLY file. We can get that OSM POLY export plugin for Quantum GIS here.

Unzip the downloaded file and copy the resulting folder into the Python plugins folder. On Windows, if you used the OSGeo installer, that might be

C:\OSGeo4W\apps\qgis\python\plugins

See here for hints where it may be for you.

The plugin should now appear in the Quantum GIS plugin manager (Plugins > Manage plugins...).
If it is not selected, do that now and exit the plugin manager.

Getting Country Borders

Easy. Download world borders from http://thematicmapping.org/downloads/world_borders.php

Unzip the downloaded file and open it in QGIS:

Geoprocessing step 1: Query

Open the Layer Query dialog by either right-clicking on the layer name or selecting Query... from the Layer menu with the TM_WORLD_BORDERS-0.3 layer selected (active).

Type "ISO2" = "US" in the SQL where clause field and run the query by clicking OK.

Geoprocessing step 2: Buffering

The next step is to create a new polygon representing a buffer around an existing polygon. Because we already queried for the polygon(s) we want to buffer, there's no need to select anything in the map view. Just make sure the TM_WORLD_BORDERS-0.3 layer is active and select Vector > Geoprocessing Tools > Buffer(s):

Make sure the input vector layer is TM_WORLD_BORDERS-0.3. Only the query will be affected, so we're operating on a single country and not the entire world.

For Buffer distance, type 1. This is in map units. Because our source borders file is in EPSG:4326, this corresponds to 1 degree which is 69 miles (for the longitudinal axis, that measurement is only valid at the equator and decreases towards the poles). This is a nice size buffer for a country, you may want something larger or smaller depending on the size of the country and what you want to accomplish, so play around with the figure and compare results. Of course, if your map projection is not EPSG:4326, your map units may not be degrees and you should probably be entering much bigger values.

Select a path and filename for the output shapefile. Do not select 'Dissolve buffer results'. The rest can be left at the default values. Push OK to run the buffer calculation. This can take a little while and the progress bar won't move. Then you see:

Click Yes. Now we have a buffer polygon based on the US national border:

Geoprocessing step 3: Generalizing

We're almost done, but the buffer we generated contains a lot of points, which will make the process of cutting a planet file slow. So we're going to simplify the polygon some. This is also a QGIS built-in function.

Select Vector > Geometry tools > Simplify geometries:

Make sure your buffer layer is selected as the input. Set 0.1 (again, this is in map units) as the Simplify tolerance. This defines by how much the input features will be simplified, the higher this number, the more simplification.

Select a destination for the simplified buffer to be saved. Also select Add result to canvas. Click OK:

This dialog may not seem very promising, but it has worked. Also, I have sometimes gotten an error message after this process completes. Ignore these if you get them.

Geoprocessing step 4: resolving multipolygons

Now, if your simplified country border consists of multiple polygons (as is the case with the US) we have a slight problem. The POLY export plugin does not support multipolygons, so we need to break the multipolygon into single polygons. And even then, we will need to do some manual work if we want OSM .poly files for all the polygons. This is because the plugin relies on unique string attribute values to create different  POLY files, and we do not have those because the polygons we are using are all split from the same multipolygon. So we need to either create a new attribute field and manually enter unique string values in it, or select and export the parts to POLY files one by one and rename the files before they get overwritten.

Finale: Export as POLY

I am going to be lazy here and assume I will only need the contiguous US, so I select the corresponding polygon. After that I invoke the plugin by selecting Plugins > Export OSM Poly > Export to OSM Poly(s):

The plugin will show a list of all the fields that have string values. Select ISO2 and click Yes. Next you will need to select a destination folder for your exported POLY files. Pick or create one and push OK.

This is it! Your POLY files are finished and ready to be used in Osmosis, osmchange and other tools that use it for data processing.

By the way: you can't load POLY files into JOSM directly, but there's a perl script to convert POLY files to OSM files that I used in order to visualize the result.