Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify data included in the loaded gmf shapefile #412

Open
CatalinaYepes opened this issue Mar 27, 2018 · 4 comments
Open

Modify data included in the loaded gmf shapefile #412

CatalinaYepes opened this issue Mar 27, 2018 · 4 comments
Assignees

Comments

@CatalinaYepes
Copy link
Collaborator

Currently, for loading a layer of Ground Motion Field, users can select across:

  • Realization (m number of realizations)
  • IMT (n number of IMTs)
  • Event_ID (x number of events)
    A tmp shapefile is loaded with the following characteristics:
    Name: scenario_gmfs_rlz-00m_eid-x (for realization m and event_id x)
    Attribute table: [ IMT_1-x, IMT_2-x, ..., IMT_n-x] (for n IMTs and the event_id x)

With this approach is not possible to compare in the same layer the difference in the gmf for different event_id. Moreover, to download all the data, the user will have to upload as many layers as the number of events, which is generally a large number (for example, 1000), times the number of realizations.

To simplify the outputs, the recommendation for the tmp shapefile will be:
Name: gmfs_rlz-name_IMT-n (rlz-name is the name of the GMPE #410 )
Attribute table: [ eid-1, eid-2, ..., eid-x] (for all the events)

The new format will also allow to easier style the layer, since all the columns will have the same name across different GMPEs and IMTs.

@ptormene
Copy link
Member

The main drawback I see in this approach is that, if the number of events can be huge, the resulting layer would have a huge number of columns.

@ptormene
Copy link
Member

For instance, I can create a layer with 10 thousand columns (and it works), but when I attempt to open its attribute table, QGIS remains frozen for dozens of seconds on my laptop (even with 0 rows). So, I would say 10000 is feasible, but I would consider it already a upper limit. If we can have a million of events, this is completely unfeasible. The Risk and Hazard scientific teams should discuss about this and decide how to proceed.

@ptormene
Copy link
Member

ptormene commented Apr 16, 2018

After closing the huge attribute table with 10000 fields, my QGIS froze again for some reason (for several minutes!). Therefore, it looks like even 10000 is too much.

@CatalinaYepes
Copy link
Collaborator Author

We need to think again on this issue, specially for Scenario calculations.

Can we separate the visualization? Other option will be to limit the columns to a given number of events (for example 2000?) and open a warning windows indicating that the data has been truncated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants