Shrimp GIS does not work with LBT anymore

Hi all

My ShrimpGIS installation wasn’t working anymore with exactly this error message:

And after founding this Github issue I discovered it is an issue between their installation and from LBT. ShrimpGIS plugin installation does not work when in combination with LBT versions 1.5 and 1.6.

Does anyone have a hint on what the issue could be?

I reproduced this issue on Rhino7 with ShrimpGIS 1.03 and LBT 1.6 on Windows 10

[edit] I reckon I’ve got to the bottom of it, and have made a quick patched version to test this:

I think this was the issue:

ladybug-tools/honeybee-radiance-postprocess …requirements.txt
numpy>=1.21.6
ShrimpGIS

Dependencies:

pyshp
utm
pygeoj

Turbo87/utm/blob/master/ … /numpy-requirements.txt

numpy==1.16.6


try:
    #  UTM with Numpy installed, requiring numpy == 1.16.6
    # and Shrimp GIS with Ladybug Tools installed, which installs > 1.21.6

    import numpy as mathlib
    use_numpy = True
except ImportError:

    # Normal operation of the static copy of UTM shipped with ShrimpGIS without numpy
    import math as mathlib
    use_numpy = False

@AntonelloDiNunzio - FWIW, this is also reported here: Unexpected Token error - Rhino grasshopper and python - Scripting - McNeel Forum
-wim

The fundamental issue is still there in Grasshopper, and is being caused by LadyBug Tools.

I don’t know how on earth you guys have managed to install numpy into GhPython - that’s really impressive! I take my hat off. But unfortunately when LadyBug Tools is installed, and any other GhPython component does:

import numpy

the following error is raised:

I know all too well that coding for GhPython can be incredibly challenging. That’s unfortunate that nothing else can make use of the numpy version LadyBug tools has managed to install. Of greater concern is what happens when the user installs a different plug in, or manages to install their own numpy version.

It would be much better if Lady Bug linked to its own local numpy installation (e.g. using relative imports to its own code, and static linking) and did not change the globally available imports for all other plug-ins (even if they could be better designed).

However, I think I’ve fixed this for shrimpGIS at least. I don’t actually know how to use shrimpGIS or LadyBug Tools, but the no-numpy version above got rid of the “from” error myself and Lisa had, together with LadyBug Tools being installed.

If you don’t want to trust random code downloaded from the internet, it is very straightforward to simply edit conversion.py in your existing shrimpGIS 1.03 zip file (shrimpGIS copies utm into %appdata%\shrimp_gis\utm so if you want to edit an already installed copy, the conversion.py might need changing there as well as in UserObjects):

lib\shrimp_gis\utm\conversion.py

- try:
-    import numpy as mathlib
-    use_numpy = True
- except ImportError:
-    import math as mathlib
-    use_numpy = False

+ import math as mathlib
+ use_numpy = False

Hi @James_Parrott,

You can also try the latest version of Heron as GIS application. The latest version you can only install via the rhino package manager. It runs without problems together with LBT and has a lot of nice features.

Thanks, but I spent too much time last year trying to get Heron’s own Seattle tower example to run, and never managed it. That was a shame because it’s very powerful when it works - the setSRS looks excellent. I wish I knew then to try the Rhino Package manager - it really ought to be mentioned more prominently on the food4rhino page (the 7 -8 year old downloads should be removed).

Hi @James_Parrott

If you send me an example with wath you would like to have, i will have a look.

That’s very kind of you to offer Erik - much appreciated. But this was over a year ago. My work on that has finished now. Users of the plug-in I wrote would also need to be able to install Heron. I just needed to read and write shape files, and at the end of the day, it was far simpler just to ship a static copy of PyShp, similarly to Hiteca’s GhShp. I imported it using relative imports and sys.path, and didn’t require users to hack into the Iron Python system directory to install it.