Grasshopper

algorithmic modeling for Rhino

This is the second release of Gismo plugin.
It mainly fixes some of the reported bugs, but also adds the following features:


1) Gismo got a new developer: Guillaume Meunier.
Guillaume is an Architect, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation.
Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:


2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component.
Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:


3) A new terrain source has been added: ALOS World 3D 30m.
ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range.
With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.

4) 9 new components have been added:

"Address To Location" - finds latitude and longitude coordinates for the given address.

"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates.
"Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates.
"Z To Elevation" - finds elevation for particular Rhino point.
"Rhino text to number" - convert numeric text from Rhino to grasshopper number.
"Rhino unit to meters" - convert Rhino units to meters.
"Deconstruct location" - deconstructs .epw location.
"New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new
developers, even if you contribute a single component to Gismo!
"Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.

5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!

Basically just forget about this yellow panel:

This panel is not valid anymore, so just use any unit you want.

6) A number of bugs have been fixed, reported in topics for the last couple of weeks.
We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!!
Apologies if we forgot to mention someone.

The version 0.0.2 can be downloaded from here:

https://github.com/stgeorges/gismo/zipball/master

And example files from here:

https://github.com/stgeorges/gismo/tree/master/examples

Any new suggestions, testing and bug reports are welcome!!

Views: 2918

Replies to This Discussion

Loihi underwater volcano terrain preview from different angles.

Very nice Djordje!

I just played with the examples, and have a small suggestion. The "Color the  buildings" and "Find hotel" don't find the proper data to produce the output. Will be good to have a working place that the required data.

I'm just picky ...

Thanks!!

-A.

Hi Abraham,

Thank you for the quick testing!
You are not picky at all. Both .gh files you mentioned had an issue with "OSM Objects" and "OSM Keys" components.
I fixed this issue a couple of minutes ago.

Can you please download again the new example files, and also replace the current upper two components with the newest ones (OSM Objects, OSM Keys)?

I apologize for this inconvenience. This is what happens when a person who is suppose to prepare a new release, does not test the example files at the very end, and goes watching an NBA game instead. That's me, sadly.

Hi Djordje,

Great!!

Suggestions:

For the OSMsearch (find shapes) i would like an input for the legend insertion point. In the default it falls in the middle of other geometry (buildings and topography), so you don't notice where it is.

For the same thing (not sure about this) maybe a legend with colors for the filtered building types, assuming you can search for more than one at the same time.

Don't find other issues ... :-)

-A.

For the OSMsearch (find shapes) i would like an input for the legend insertion point. In the default it falls in the middle of other geometry (buildings and topography), so you don't notice where it is.

Yes, I see the issue now. Good catch!
I am a bit reluctant to add a new input, as I would have to add it to the "OSM Shapes" component too. Both "OSM Search" and "OSM Shapes" components have more inputs than outputs, so I was kind of more keen to add another output (titleOriginPt), then input. This output can then be used to move the title with Grasshopper "Orient" component.

It's useful to say that: If a terrain has been added to the groundTerrain_ input of the "OSM Search" component, then the title would go below the terrain, which makes it more readable I guess.
Let's see how this issue goes, maybe in the end more people will ask for adding a titleOriginPt_ input as well.

For the same thing (not sure about this) maybe a legend with colors for the filtered building types, assuming you can search for more than one at the same time.

This is a very good suggestion! At the moment it is not possible to search for more than one OSM object. I understand the importance of having such feature, but this would require from me to rewrite the "OSM Search" component. Maybe it can be a little less time consuming if a new additional component will be created. So one would have to copy an "OSM Search" component for each type of the OSM object he/she wants to search for, and then outputs from all those "OSM Search" components will drain into the upper mentioned new component which will make a colored legend for each OSM object. Just a suggestion.

However there is one issue with all this OSM objects search, that I haven't mentioned: OpenStreetMap data can store amenities of the same type on different shapeType_. For example, in find_hotels.gh we are using shapeType_ = 0 (2d polygons), we make 3d shapes from them, and then we search among those 3d shapes.
However, if one sets the shapeType_ to 2 (points) one will also find hotels among the points.
It may take a more knowledgeable OpenStreetMap user to explain this, but in general: if a hotel occupies all floors of the building, then it would be found the way we did it in find_hotels.gh (shapeType_ = 0). But if a hotel does not occupy all floors, or a user who mapped the hotel was not certain whether it did occupy the whole building or not, then a hotel would be mapped as a single point. I assume this will be the point of hotel's entrance, but I may be wrong on this.

I attached an example file below which shows this.

So if there's going to be a new component created: which will map hotels, restaurants, bars... or other buildings types with a legend of some sort, then this aspect needs to be taken into consideration. It can probably be fixed with some sort of point inclusion (in a polygon). Let's see.

It's definitively another very valuable suggestion!!

I couldn't attach the file for some reason.
Here it is.

Attachments:

100%

-A.

Due to useful suggestion by Abraham, "OSM search" component now supports searching for multiple OSM object (amenities/facilities). So it is no longer needed to copy a couple of "OSM search" components and then search for a single OSM object in each of them.


Also as a suggestion by Abraham, a new component "Create Legend" enables automatic coloring of the found OSM objects:



A small example definition is attached below.

Thank you once again for the useful suggestions Abraham!!

Attachments:

Hi Djordje,

Thanks!!

I played with the example and there are some bugs (i believe).

When you connect only one of the building types to the search, the result is not consistent with the one you get when you have all those you have in the example. For instance, if you connect only parking, you don't get any results, or only 2d.

I wanted to search for residential type and surprisingly there are none. This can be, but i'm surprised. Also office buildings. I imagine this is not up to you, but can be kind of disappointing. I wanted for example to do some Ladybug analysis only on residential or office buildings ... pitty.

The legend is nice, though i think is not completely synchronized with the LegendBakeParameters: You need to provide a point for the LegenPlane input and another for the titleOriginPt output of the CreateLegend.

Thank you again for this very nice work.

-A.

Hi Abraham,

Thank you for the quick testing!!

For instance, if you connect only parking, you don't get any results, or only 2d.

It was a bug. It's solved now. I attached an example below.


I wanted to search for residential type and surprisingly there are none. This can be, but i'm surprised.

The location in example is the Financial District of Manhattan. I assume there might not be too many purely residential buildings there. If you increase the radius to 300meters it will find one.
The OSMobject "Residential building" will look for mostly purely residential buildings. For example those in Chinatown or Lower East Side.
However most of the time a building might be a multi-purpose: shops on the ground floor, offices above, and above them residential apartments. Users can sometimes avoid tagging these kind of buildings, and may just tag them with "buildings"="yes", not the type of the building too (for example: "building"="multiuse"). So this may be the problem why you might not get too many residential buildings.
I guess the only solution to this issue is to add these tags by yourself. Then Gismo will instantly make use of them.
I mentioned previously that I will create a couple of video tutorials, but I seemed to never found enough time. I apologize for that. The process is actually quite simple.

Here is small step by step tutorial on how to do that. It may take you about 2 minutes to tag your building and use that tag in Gismo.

Also office buildings. I imagine this is not up to you, but can be kind of disappointing. I wanted for example to do some Ladybug analysis only on residential or office buildings ... pitty.

"Office building" has not been added to "OSMobjects" dropdown list. I have just added it.
However, whenever some sort of object is not defined in "OSMobjects" dropdown list, one can use the _requiredKey and requiredValues_ inputs of the "OSM tag" component:

I just tried looking for office building for the same location we have in the create_legend_example.gh file and it found 3 of them. There would probably need to be more, but it may be that nobody tagged those with "building"="office"

The legend is nice, though i think is not completely synchronized with the LegendBakeParameters: You need to provide a point for the LegenPlane input and another for the titleOriginPt output of the CreateLegend.

Unlike Ladybug, Gismo threats the title and the legend separately. So the legend's color bar would have its own starting point (plane) while the title will have its own. I found myself puzzled sometimes in Ladybug, why this wasn't possible.
Or did I misunderstand you?

Attachments:

Hi Djordje,

Thanks for your answer. Makes things clearer.

The tagging issue can be quick to learn/do for few buildings. I'm afraid that for large areas can be time consuming. But maybe i'm just talking out of ignorance, so no need to answer here.

I think i've found another issue with the legend. I checked all the possible building types (or tags in the list) for the Manhattan area. I concentrated the lists that individually Gismo found. When i connect all of them, some types are missing. See image:

I understand that one building can have more than one tag. if so the"first" to be found sets for which use the building is assigned?

Out of that seems to be working well ... :-)

Thanks,

-A.

The tagging issue can be quick to learn/do for few buildings. I'm afraid that for large areas can be time consuming. But maybe i'm just talking out of ignorance, so no need to answer here.

If you are using the iD editor, which is available through a regular internet browser, then you would have to select each building and add the "building"="residential" tag to it. The tutorial shows how to do that for a single building.
However, a more advanced OSM data editor: JOSM, allows selecting multiple buildings, and assigning to all of them the "building"="residential" tag. Or any other tag/tags. So it may take just a minute or so, to for tens of buildings to "become" residential. It's not that difficult to get started with JOSM.


I think i've found another issue with the legend. I checked all the possible building types (or tags in the list) for the Manhattan area. I concentrated the lists that individually Gismo found. When i connect all of them, some types are missing. See image:

The "Building" type should not be connected to "OSM tag" component in this case.
We use it only for the "OSM keys" component, because some building types may not be considered as buildings (for example: "Parking"). So when you are looking for only a "Parking" then we add both "Parking" and "Building" to "OSM keys" component, but we only look for "Parking" in the "OSM tag" component.

When I do not connect the "Building", I get all the building types you are looking for:

If it does not work (removing the "Building"), can you please upload your .gh definition.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service