search

hackoregon / emergency-response

Simulations, Models, and Visualizations of Portland Fire and Rescue data
11 stars 10 forks source link

Update data dictionary entry for fblocks table to match current database #65

Closed futurechris closed 7 years ago

futurechris commented 7 years ago

In the data dictionary right now, the description of the fblocks table doesn't seem to match what I'm seeing in our database.

The dictionary describes 6 columns, whereas the database table has 15 columns. There doesn't seem to be an obvious mapping between the two. E.g., dictionary mentions 'FID', but the table has 'gid', 'objectid_1', and 'objectid'.

The table is probably still usable, but I was hoping to find a description of the resp_zone column, and whether it is related (as I hope) to incident.fireblock.

Without knowing this, it's not clear to me how to map incidents to FMAs (incident -> fireblock -> fma). Unless we can just use the incident.fmarespcomp column?

@kielejocain @markawhitaker Thoughts?

kielejocain commented 7 years ago

It's not clear to me how fblocks is laid out; I was not the one that put those tables in the dictionary. Based on the edit history of the table, @rcallihan did the initial work, and @sky-t editted some from there.

For what it's worth, I used incident.fmarespcomp in what I've done for incident priority analysis (which I'll upload tonight after some discussion).

markawhitaker commented 7 years ago

I'm not familiar with the fblocks table. If it came from @rcallihan then its likely from our GIS analyst, and I can check with her tomorrow.

That said, I think incident.fmarespcomp and incident.fireblock should be sufficient for mapping?

rcallihan commented 7 years ago

@futurechris Many of those fields are unnecessary relics as the file transitioned from various data formats. It is referenced here #44 . We should remove those extra fields from the db to avoid confusion. Maybe @BrianHGrant can help here.

Also, you are correct, fblocks.resp_zone does join to incident.fireblocks. I've updated the dictionary to reflect this. One thing to note, is the fireblock geometry has 578 records, while the incident table has 716 unique fireblock values. Without cleaning, 549 of them will join. I planned today to figure out what the discrepancy means.

As far as mapping to FMA. You are correct. Fireblocks to make up FMA's (see example on maps here). I'm not positive about the incident.fmarespcomp, but using the fblocks.fma to fblocks.resp_zone relationship will work to roll up fireblock values to FMA's.