philipbelesky / caribou

Caribou is a Grasshopper plugin for parsing downloaded Open Street Map data into Rhino geometry. Caribou is currently in beta.

Caribou

Caribou is a Grasshopper plugin for parsing downloaded Open Street Map data into Rhino geometry. Caribou is currently in an beta state, but core functionality should be stable.

Installation

Caribou is available to download via the Rhino Package Manager (search "Caribou") or on Food4Rhino.

Documentation & Support

Caribou's documentation lives on this website and on YouTube.

Support can be requested, or feedback provided, by opening a discussion on GitHub. Issues and pull-requests are encouraged.

Features

• ✅ Windows and MacOS are both fully supported
• ✅ Very fast parsing of even very large files
• ✅ Data-rich GUI interface provided for understanding and filtering OSM metadata
• ✅ Parsing is performed asynchronously so Grasshopper remains responsive
• ✅ Parse multiple OSM files simultaneously with de-duplication of geometry
• ✅ Allows for querying for arbitrary data outside of the primary OSM features/sub-features taxonomy
• ✅ Outputs are tree-formatted and organised per data-type to allow for downstream filtering, tagging, baking, etc

Roadmap

• 🕘 Further speed optimisations
• 🕘 Component to help construct queries for arbitrary metadata
• 🕘 Parsing of <relation> type data
• 🕘 Integration with Rhino's EarthAnchorPoint
• 🕘 Customisable projection methods

Changelog

See CHANGELOG.md.

Recognition

Thanks to:

• Timothy Logan, author of Elk, for LatLon conversion math and for an example of feature-picker form.
• Dimitrie Stefanescu and the authors of the GrasshopperAsyncComponent repo.
• Povl Filip Sonne-Frederiksen, author of the Yak package manager action.

caribou's Issues

Add component to output plant geometries

Relatively self-explanatory; made difficult by the fact that metadata is very sparse for tree items (despite the options available. Geometry outputs should probably cover both planimetric and volumetric forms.

Add implementation of roof geometry types

Other importers, such as Blender-OSM create distinct roof shape geometries based on the relevant OSM tags.

Add proper geoprojection support

Pickup/rework earlier efforts to use geolibrary or similar to handle the translation from lat/lon to X/Y space with the option to specify a projection standard. At the same time, integration with Rhino's EarthAnchorPoint would provide value (including an elevation specification?).

Indicate in the Selection UI when a feature is unchecked but one of its subfeatures is

When doing fine-grained feature extraction, you often select a subfeature or set of subfeatures. However, when all the features are collapsed in the UI, there is no indicator of which features have subfeature selections. Another column could be added to that UI to track/indicate these cases. This could be a simple radio-style indicator, or could perhaps count the number of selections.

Consider mapbox/google API integrations

Mapbox and Google Maps' API would likely provide better data than OSM, particularly for data such as building heights. They would also offer the option to do terrain imports.

Improve building volume production

(not related to #18)

Generating the building volumes can very rarely go awry and make slightly incoherent shapes.

3d Buildings dont show

Hi great plugin
it's my first time working with thisplugin but i can't make buildings show up in canvas, and the progress bar in grasshopper stay stud at 99.06%
when i add the buildings the data dont show u

p

Add video walk-throughs of basic and expanded functionality

Currently the docs' YouTube link goes to a blank listing.

Add means of identifying buildings without heights in Buildings Component

It would be useful to identify building ways that don't have any form of height tag - e.g. so that they can be manually extruded in Grasshopper with a random/fixed value.

Problem with extracting buildings

Hi, i faced with a problem while making gh definition.

I'm using "extract ways" node to extrude building, but I found, that it didn't extract all buildings from file.
For sure I opened same file in QGIS and missing buildings was there.

So I'm wandering where is problem (I tried to select all features for node, didn't help)

(img1 after adding missing buildings)
(img2 after baking definition)

Consider component for extracting/filtering information

Often you would want to do further filtering upon the data extracted from the Nodes/Ways/Buildings components. This might include filtering based on more precise metadata that is not in the defined features/subfeatures list. It also might include filtering by particular metadata ranges, e.g. surface is asphalt or concrete; maxspeed<=50`. This can be achieved with standard Grasshopper components, per the examples file, but is cumbersome.

A dedicated component could also provide better affordances, such as providing a Selection-Component-like UI to list all possible metadata that could be the basis of further filtering.

Optimise parsing process/calculation

From benchmarks, most of the work done in the component is in parsing through the XML file rather than in geometry creation. This is particularly noticeable in the Way component given it must traverse all Node and Way types. Options for improvement could include

• For Way parsing: walk through the way nodes first, then route back to the nodes for faster checking if they are relevant
• Multi-threading the walk through nodes
• Micro-optimisations within the loop structures
• Hybridising between the different processor approaches (e.g. Ling and XMLDoc) to use each for what it is fastest at
• Skip duplication checks if only parsing a single XML file
• Translating from latlon to XY with some sort of mass vector transformation

Add parsing of relation data types

For many geometries/entities in a map, the meta-data is attached to the relation grouping rather than to the nodes or ways. E.g. this map depicts a pier structure made up of two ways; however those ways are tag-less so they don't show up when parsed with the Ways Component.

The current parsers could relatively easily pickup these relations, but it is unclear how to handle their metadata outputs given the existing structure. At a minimum, they could work within the existing structure by just assigning all tags from the relation to the ways (in effect duplicating them).

That naïve option strips any relationship between the child-ways/nodes and is complicated by structures such as multipolygons. A more thorough rework would be to reconfigure the tree structure to add another level of depth for the relation. E.g. {query, relation, geometry|metadata} rather than just {query, geometry|metadata}.