OSM data is HUGE! Its vastness presents a significant challenge to anyone wanting to extract a meaningful subset of the data. The challenges this presents are twofold. First, how does one figure out what OSM contains that might be of interest. Second, how does one go about extracting that awesome, meaningful, super important data.

This workshop will walk participants through browsing OSM data using taginfo to identify potentially interesting items. Once a meaningful subset of the data has been targeted, the focus will switch to extracting that data. Various available tools will be examined, such as osmfilter, osmium, fences, etc. The group will perform a simple polygon extraction using fences, which is an administrative boundary extraction tool for OSM.

Finally, the participants will work on a simple visualization of the shiny new extracted data. Participants should walk away with a good grasp on some simple and powerful tools for working with OSM data to create and visualize their own custom datasets.

Osmium is a highly flexible and performant C++ library for working with OpenStreetMap data. Built on top of this library are a command line tool, a Node.JS module and a Python module. This suite of software can be used for many tasks, from keeping history planets current, to creating statistics, to converting OSM data in many different GIS formats. In this workshop we'll introduce those tools, present some typical problems from the OpenStreetMap world, and show how they can be solved using the Osmium family of tools. You can find Osmium and related software at osmcode.org

Although OpenStreetMap has its full history available for download, there is neither a easy-to-use tool for tracking changes nor for undoing edits. However, there are diffs, augmented diffs, changesets, history, old object versions, the full history planet file, redactions and a lot more notions, tools, and file formats.

We start with a walk through the details of the OpenStreetMap data model. The data model has some implications how to structure information about changes. For example, geometry changes often do not correspond to version changes in the affected objects. On the other hand, relations often deliver more change data than is interesting to see. Whole changesets may or may not be the right level of detail.

We conclude the first part with an approach how to vsualize changes in a almost always concise way.

The second part is devoted to a high level comparison of the various file formats concerned with change representation. We use as criteria the suitability to various use cases and explain the necessary extra data keeping.

In the third part, the corner cases for tool development are explained. The aims of potential tools are patching an exisiting replication database as well as programming an undo tool. To get in addition the perspective of change visualization, the code behind the tool that has been presented in the first part is reviewed.

In this workshop we will review our progress over the last 12 months, lay out the future roadmap and look at some of the interesting projects that have used OpenStreetMap Carto as a foundation. We will also show you how to customise the stylesheets for your own projects using TileMill, and show you how to contribute improvements back to the main map style.

With OpenStreetMap getting more mature, it becomes more important to track changes. But to track changes is difficult for various reasons: Changeset comments can be misleading, destruction may be hidden in innocent looking changes, and the sheer amount of data prohibits a complete manual review.

For that reason Overpass API provides from version 0.7.50 on the complete history since the license change. We present the commands to access that data: One can get the results as they were at any chosen point of time in the past. One can get even a changefile of what has changed between two points in time. This is complemented by a feature to print the full geometry of a way or relation without referring explicitly to its nodes.

We explain how both together support the concept of basic OSM editing operations, how they allow to build powerful client JavaScript only websites that allow tracking of changes with arbitrary search criteria. We will discuss what remains to do to build a complete and logically consistent revert tool based on Overpass API v0.7.50.

OpenStreetMap is full of bus stops, train stations, ferry routes, and even funicular railways, contributed by mappers around the world. Many transit agencies also share their networks and schedules as public data sets, using the General Transit Feed Specification (GTFS) format, created by Portland TriMet and Google. Combining the geographic information of OSM and the temporal information of GTFS feeds opens many of possibilities--but unfortunately it’s an often frustrating slog through messy data and incomplete tooling.

In this hands-on workshop, we’ll guide participants through a brief tour of working with transit data in OSM and GTFS using open-source tools. Together, we’ll:

• visually explore transit data
• use Onestop IDs as a “crosswalk” between GTFS, OSM, the National Transit Database, and other sources of data (to run simple analyses of transit systems)
• use these as inputs into a multi-modal routing engine (to plan journeys involving transit)

We hope participants will leave with an appreciation of the complexities of OSM and GTFS--and equipped with knowledge and an open-source toolkit to continue their experiments with transit data, software, and ideas.

Geo-search, also known as geocoding, is a notoriously complex problem and existing solutions often require a tremendous amount of technical know-how and hardware resources. Mapzen is changing all that with Pelias, an open-source geocoder that could be set-up start-to-finish in as little as an hour (depending on the extract of OSM data being imported). Pelias works with OSM data by default, and allows you to specify whether you would like to import a specific extract or the entire planet. With just a handful of simple commands, we will show participants how they can get a full functioning geocoder for OSM data running directly on their very own machines. We will also walk through the simple API of the geocoder service to show how to tailor queries to common use-cases, such as coarse geocoding, reverse search, specifying a bounding box, and more.