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

Graph discrepancies from KW Panels #4

Open
fritosxii opened this issue Apr 28, 2023 · 6 comments
Open

Graph discrepancies from KW Panels #4

fritosxii opened this issue Apr 28, 2023 · 6 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@fritosxii
Copy link

fritosxii commented Apr 28, 2023

For definition, KW Panel compliant refers to a HazardEvent that has hasName and hasKWGEntity defined, or a Place that has hasKWGEntity and hasPlaceType defined (hasName is optional currently on Place entities because the main graph has many non named places)

Here is the Google Sheets spreadsheet that lead me to the following conclusions: https://docs.google.com/spreadsheets/d/1enzC86uybXngr6BBtf-Vi8NGfcwHVgvHWQOvlEgqGUw/edit#gid=934262946

Hazards

  1. There are some hazards that are only HazardEvent, and don't have a specific type like Tornado. Should we include these entities?
  2. There are also random entities that aren't of type HazardEvent, but have a specific hazard type. Should we ignore these?
  3. For extra context, there are 1000+ NOAAWildfires in the graph, but only 1 is actually attached to HazardEvent:
  4. Lastly I should note that these 1000+ fires are not KW Panel compliant, while the one fire that is a HazardEvent has the expected data:
  5. Hurricane and Earthquake also have the same issue of having 1000s of records, but none of them are HazardEvents, and none are KW Panel compliant:
  6. hasImpacted is connected to several fires, but all those fires are not KW Panel compliant, and seem to only have hasImpacted as a property
  7. affectedAreaInAcres and damageToCropsInDollars are also present but only attached to entities that are not KW Panel compliant:

Places

  1. sfWithin and sfTouches do not point to any KW Panel compliant Place entities.
  2. sfContains has the same problem, but there is 1 valid relation
  3. sfOverlaps has the same problem, but there are 27 valid relations
  1. impactedBy does not point to any KW Panel compliant HazardEvent entities.

Place Year Data

  1. For this I am going to let the Google Sheets above speak for itself
  2. For the 2018-2022 data, these properties exist and work, but some of them just aren't present in KWG Lite (so I assume they also are not in the main graph)
  3. For the Jan2021-Dec2021 temperature properties, they all exist and have data, but are all attached to climate divisions that do not have a hasKWGEntity property, and therefore are not KW Panel compliant. Here's an example from 1 of those properties:
@cogan-shimizu
Copy link
Contributor

@antreac Can you please narrow down which queries are causing these problems? For example, which queries construct a HazardEvent but don't have subtype?

@cogan-shimizu cogan-shimizu added the bug Something isn't working label Apr 28, 2023
@cogan-shimizu cogan-shimizu added this to the Version 1.0.0 milestone Apr 28, 2023
@fritosxii
Copy link
Author

@antreac Can you please narrow down which queries are causing these problems? For example, which queries construct a HazardEvent but don't have subtype?

Please note this issue is still in progress. I will comment again when it is finalized

@fritosxii
Copy link
Author

Ok @antreac , I've completed this issue description so go ahead, and let me know if you have any questions.

@antreac
Copy link
Contributor

antreac commented Apr 28, 2023

I have updated the construct-queries.md document so it will be available once Cogan merge the pull request, after that please let me know if there are any more questions. I will check the issues mentioned above and reach out to you with questions. @fritosxii

@shirlysteph shirlysteph self-assigned this May 4, 2023
@shirlysteph
Copy link
Contributor

Issue 1

I have included a new predicate in the graph to capture the specific hazard/disaster type of the HazardEvent. So for e.g. the example pointed above in issue 1 is now a Winter Storm.

@cogan-shimizu
Copy link
Contributor

Is this consistent across all HazardTypes, i.e., there are no more subclasses to HazardEvent?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants