OpenStreetMap data for Lausanne
I was testing out the Elk plugin for Grasshopper some time ago (back when only the initial realease 0.0.1.0) was available and found the ability to import data from OpenStreetMap incredibly useful. Not only is this an opensource database, but it’s global coverage is pretty thorough saving the trouble of trying to search through the back pages of local government sites trying to find reliable and accurate geometry files.
In fact the OpenStreetMap files I’ve worked with so far are more consistent and more accurate than the layer standards I’ve seen in most municipal CAD files. However there were two minor complaints I had with the plugin as it existed then: the limitation of types of data that could be extracted from the components; ad the difficulty of aligning multiple files (openstreetmap.org limits the number of nodes in files downloaded from the website to 50,000. For larger areas, you’ll need to download your map in sections, like below). As of February 5, the first concern is at least partially addressed. There is now a ‘Generic OSM’ component which allows the user to specify the kind of data to display. Even with that update, I still find myself using the script in this definition because I like having editable, customisable scripts that I can adjust on the fly (for example, to extract everything but the input value type).
Looking at the XML data itself (you’ll want to get a code text editor if you don’t have one already, I’m using Notepad++) or the osm wiki it is clear that most of the code is straightforward text parsing, with a little additional work to improve the efficiency. I’m sure I haven’t optimised the scripts’ performance yet, but a few steps helped a lot. The simplest is to always skip directly to the part of the XML file that is relevant (node, way, or relation) since they are neatly separated and to exit the script after. This will prevent you checking tens of thousands of lines which can be determined in advance not to matter. In the example below, if we were constituting ways, we can skip the first 21,738 lines, which all belong to nodes, and stop as soon as we hit the first relation.
Another efficiency method is to put the data into a SortedList as it is extracted from the datafile so that later searches can be sped up using a simple recursive search function. (This is included as a distinct script at the bottom of the definition).
.osm XML file
Addressing the second problem was a more structural problem. The osm limit of 50,000 nodes can be pretty restrictive past a few blocks. Even the not terribly big city of Lausanne required a five-part download (below). Particularly when one section of the map is denser with nodes than others, and with no way to know how many nodes are in the window you’d like to export, you may find an efficient pattern of identical patches difficult to locate. In this script there are framing inputs which refer to a reference scale and position of the map (these are Domain² inputs, but the script is written to preserve a Mercator projection) which, if preserved for multiple files will ensure that the files align. Additionally, a separate bracketing input excludes nodes that run past the border (common with boundaries and water features) to prevent overlap.
Sectioning the city into 5 files
A list of file paths can be set up with a matching list of bracketing domains and multiple files baked automatically to appropriate layers using the Animate Slider function and a version of Giulio Piacentino‘s BakeAttributes script.