GISMO: The component generated invalid shapes data

[MishaBro]

Hi friends!

I’ve been using Gismo for some time, and it have been working perfectly, with the same location coordinates, up to this evening.

First of all, the Gismo_Terrain Generator component stopped working throwing an error

“Runtime error (MissingMemberException): ‘NoneType’ object has no attribute ‘NumberRows’”

Before I updated the UserObject, it was also throwing an error saying something about the server

(503)

. I tried fixing it like here, but it didnt help.
However, what I found is that the portal.opentopography.org website isnt working for some reason:

So I assume it is a problem from their end, and Im waiting for the server to work again.

However, the other problem (that started right after I discovered the previously mentioned one) is that the Gismo_OSM Shapes component started to glitch out. As I understood, it is using another server to download data, somewhere directly from openstreetmap.

Now I get an error

“The component generated invalid shapes data.”

.
Sometimes I get only this error message, sometimes also this:

“downloadFile_e1: The remote server returned an error: (429) Too Many Requests. The component generated invalid shapes data.”

There was also an error message

“504 gateway”

The problem persists even if I use previously downloaded files that are stored on C:\gismo\osm_files.

I tried downloading the same coordinates with JOSM, and it works fine…
I Tried different internet connections, Administrator rights, but no luck.

Everything was working perfect, but suddenly… =(
What happened?

Rhino 6, Win 10.

gismo_error.gh (117.8 KB)

[MishaBro]

So the server portal.opentopography.org is up and running. But still both components aren’t working… :C

… Okay, the Terrain component has started to work. But the OSMshapes did not.

“Global name ‘utils’ is not deined”.

[djordje]

Hi @MishaBro ,
Indeed terrain generator didn’t work yesterday, because opentopography.org website was down. Now it’s functioning again, with no issues.

As for the other error messages, they are classical example of something on your PC not allowing to download data (Firewall, locked port, antivirus even maybe?).

The global name 'utils' is not defined can often happen when invalid openstreetmap data is downloaded. My assumption is that due to openstreetmap file not being allowed to be downloaded, it became corrupted maybe. I would recommend deleting the whole c:/gismo/osm_files folder.
Then close Rhino, open it again and run your gismo_error.gh file. If you have admin privileges, it would be able to download the correct openstreetmap data.
I had no issues running your gismo_error.gh file on my PC (I added 3D building and 3D roads components as well. And defined the location name to UKR_Kiev):

[MishaBro]

Hi @djordje
Thank you very much for your attention!

Before everything was working fine on this pc. I dunno what happened, nothing has changed from my side.

I tried running as administrator - didn’t help.
I have no antivirus (except the standard Windows one), tried turning it off - didn’t help.

The shapes looks fine tho, but the components think that they are wrong…

I tried to look for port 9090, as per this post, but couldn’t find it.

In CMD when I run the script, the SearchApp.exe and Rhino.exe shows connections ESTABLISHED with ports 56947, 57948, 57957, 58248. Sometimes they show CLOSE_WAIT.
From Miscrosoft forum:

CLOSE_WAIT state indicates that the client properly closed the connection (FIN has been sent), but the server still has its socket open. This could be the result of one instance (among all threads or processes) of the socket not being closed.

So I believe it is not an issue with port. (Tho I have no idea how all that staff works).

Each time prior to the next downloading attempt I delete everything from the gismo folder.
Interestingly, by some reason I can, with no problem, download the data from these coordinates:

But when I try different coordinates, also within the city, I get the same error:

The component generated invalid shapes data.

To fix this issue, simply rerun the component (set the “_runIt” input to “False”, and then again to “True”).

And the CMD does not show the same pattern as when it is successful.

[wim (Wim Dekeyser)]

Hi -

@MishaBro

The shapes looks fine tho, but the components think that they are wrong…

Note that the orange color of that flag is merely a warning, not an error. It’s possible that the data that Gismo downloads contains some error or unexpected information that either causes Gismo to create a bad object or simply no object. Just bake the geometry and see if Rhino flags anything as bad.
-wim

[MishaBro]

Hi Wim,

Thank you for the answer!

I have been using these locations and same settings for two weeks now, and only since this Friday, when the portal.opentopography.org was down, I started to receive these errors.

In GISMO_Osm Shapes:
While using shape type 0(for buildings) generates adequate lists of data, but then the GISMO_Osm 3D component generates only one-two buildings from the data.
The shape type 1(for roads) generates odd data results, and the GISMO_Osm Search component cannot parse it.

The baked geometry looks fine. Its the data…

Also, the error “Too many requests” appears even If I try to download the data for the first time in a day…

[wim (Wim Dekeyser)]

Hi Misha -

I don’t know enough about Gismo to be of much help and @djordje might have more pointers. A few comments, though.

@MishaBro

I have been using these locations and same settings for two weeks now, and only since this Friday, when the portal.opentopography.org was down, I started to receive these errors.

As far as I understand, the OSM data isn’t retrieved from OpenTopography but from Openstreetmap directly.

@MishaBro

While using shape type 0(for buildings) generates adequate lists of data, but then the GISMO_Osm 3D component generates only one-two buildings from the data.

Are you supplying a domain for random height of the buildings? In most cases, Openstreetmap doesn’t have a height or numbers of floors information for buildings and then you need to somehow assign heights yourself.

@MishaBro

The shape type 1(for roads) generates odd data results, and the GISMO_Osm Search component cannot parse it.

I can’t tell if there is an issue beyond having problems with Cyrillic letters in the names of the streets… As you say, the geometry looks fine.

-wim

[MishaBro]

Hi Wim

@wim

As far as I understand, the OSM data isn’t retrieved from OpenTopography but from Openstreetmap directly.

Thats right. Im just pointing that out because the problem appeared when the opentopography server was shut.

@wim

Are you supplying a domain for random height of the buildings? In most cases, Openstreetmap doesn’t have a height or numbers of floors information for buildings and then you need to somehow assign heights yourself.

I do supply random heights, moreover, I already generated 7 locations with 3D buildings (with and without data), and with roads, railways and so on.
But now, the exact same locations, with the same radiuses are not working at all.
So I think there is no issue with the Cyrillic, since it was running fine just 3 days ago…

Most of Cyrillic data has its English version, like here:

Other sources, like JOSM or QGIS retrieve correct data, with no problem.
And GISMO worked fine… But now I cant use it at all.

[djordje]

Hi @MishaBro ,
The errors show that data couldn’t be downloaded, and everything beyond that is just corrupted files (due to inability to download the data).
Are you using the same gismo_error.gh file with the same (600m) radius?

[MishaBro]

Hi @djordje

I simplified the file a bit to have just the components with error messages.
But anyway I have this issue even in the gismo_error.gh

If it is important to have the exact file, here it is:
0_terrain.gh (376.2 KB)

[djordje]

I just tried 0_terrain.gh on my PC, and it works without any issues:

[MishaBro]

Really don’t know what is goin on. For example now the shape type 0 loaded successfully, but shape type 1 is not:

[djordje]

We managed to solve the problem by using the default osmconf.ini file from here.