@timkado (cc: @scottd) Have you gone any further with this integration. I was again spending time this morning thinking about GIS / Rhino integration. I think this is still a huge missed opportunity for Rhino in general.

I scanned all the current GIS plugins for Grasshopper this morning, and the vast majority are dead projects. Only ShrimpGIS, Urbano, Meerkat and GHopperGIS really continue development. In addition, there are lots of overlaps but every plugin is incomplete.

Native Rhino / Grasshopper Wishlist

  • better support for geo-location within Rhino. The current obscure and poorly documented EarthAnchorPoint is the only function at the moment.
  • Direct reading and writing of both Geometry and Properties for: Geopackage, GeoJSON, Shape (and connected files) and CityJSON. The properties can be written to the Rhino geometry Archivable Dictionary making Rhino work like a database.
  • 3D Tiles support
  • GDAL library support
  • CPython 3.6+ support for Python GIS libraries

Rhino/Grasshopper Plugin Wishlist
A lot of the normal GIS functionality / processing is easily replicated, or already current functionality of Rhino/Grasshopper. But it would be good to have:

  • The multiple plugin authors collaborate more on open source. An example would be combine: ShrimpGIS, Bison GIS and Urbano.
  • universal API reader for only geodata. The standard OGC data services could be accessible (from the 1000s of different national services) by an API component where we feed it options. Then a user could access open data from different services, such as: OGC API (new standard), WMS, WMTS, etc.
  • custom API readers, for specific data sources…
1 Like


So far nobody mentioned the option to run Rhino.Inside.CPython. This has access to the full RhinoCommon API/SDK due to the headless Rhino/GH. It is different from the Rhino3DM.py which has estimated 200 functions, far less than the (estimated) 2000+ of full RhinoCommon. So in theory, this could be run from within a QGIS Python script. Surprisingly, I never hear about this option since it launched and I see that it hasn’t been updated since October 2019.

The problem of course (with this route) is that you then are stuck using the QGIS interface / plugin for operations. Whereas the goal is to use Rhino / Grasshopper interface to control and create native QGIS data.

I also still think that:

  1. Using Rhino.Inside.QGIS would be amazing and the best option
  2. The seamless merger of GIS and CAD is one of the most exciting challenges today

The other thing I was just reading about is the PyQGIS Cookbook from the QGIS developer docs. In section 1.4 about Python Applications it appears that you can run QGIS in headless (or GUI) mode. You can trigger QGIS to run from an external Python script. See the follow-up sections 1.4.1 to 1.4.3. We would need to know PyQGIS API and map RhinoCommon commands to the PyQGIS commands. But what is exciting is being able to run QGIS from Python.

The caveat of course is that QGIS needs to be installed on the machine. I assume you could also run a remote QGIS server, but I have no experience with this.


Hey Darrel,

Regarding your suggestion for plugin authors to collaborate in an Open Source manner. @Brian_Washburn author of Heron (Open Source) has a discord channel where a few GIS heads have been collaborating. Here’s a link in case you are interested: https://discord.gg/ZwtcSfMZ

1 Like

Just a note that besides the mentioned plugins, there is also Gismo, an open-source plugin for Grasshopper:


Wiring up Rhino with GIS software is something that could really help introduce the software into some new fields. I’ve done a fair amount of QGIS plugin work to connect it to The Kingdom Suite from IHS and clients’ existing Solidworks projects for engineering, so this is probably something we could get together. What kinds of features are people looking for in that kind of connector?

1 Like

@harrison - I’m happy to discuss further, but probably a chat / video structure is more useful. I have a larger initiative called the Urban Tech Stack Alliance, a community of people working on urban development issues that bridge GIS, Cities, Technology, etc. Maybe you could join the slack workspace? Others are also welcome to join!

ghhops_server can run on many different versions of python including 3.7

This library rarely needs updating as it is small library that sets up Rhino to run inside of the python process. Rhino on the other hand is update every week.

@ Discussion Participants

I created this other topic in the forum about having EarthAnchorPoint implemented in Rhino3DM (Python and Javascript especially) since this could be a bridging technique while we search for other long-term solutions.

Have you seen many users active with Rhino.Inside.CPython? Are there plans to continue the initiative?

Sure, people are actively using Rhino.Inside.CPython. The date of the library being published does not reflect work being done. When Rhino updates and it typically includes both bug fixes and enhancements to the RhinoCommon SDK. That means more functions are available to Rhino.Inside.CPython

@stevebaer - Sorry, I just want to clarify further on the PIP Install please.

Essentially the Rhino.Inside.CPython that is on PIP still is the version from 2019, like the github repo.

Is there any plans to update, or regularly update the RhinoCommon.dll that comes with the PIP install? Perhaps I misunderstand, and the RhinoCommon.dll isn’t a direct dependency of the PIP Install, but rather is dynamically linked to the running Rhino v7 installation?

Thanks, sorry for the follow-up.

RhinoCommon is not installed when you install Rhino.Inside.CPython. The library allows you to use the RhinoCommon that is installed along with the Rhino 7 that is installed on your computer.

1 Like

To everyone in this chat, we have moved the discussion to the UTSA slack workspace thread # GIS. This Thursday May 27th at 10:00 Central European Time, 2021 we will have a Zoom call to brainstorm the solutions of linking QGIS and Rhino3D/Grasshopper3D.

1 Like