search

nationalparkservice / places-data

Data from the Places system.
http://www.nps.gov/npmap/tools/places/
13 stars 5 forks source link

NCR boundary replacement #347

Closed chadlawlis closed 8 years ago

chadlawlis commented 8 years ago

From Cynthia @ NCR, 12/22/15:

I've attached a boundary feature class that covers all of NCR. I'm not confident that I have the right boundary data for CHOH and GWMP. What I compiled is based on Lands tract data. I think the parks might have something better. I'm going to contact them, but a lot of people are on leave this time of year so I didn't want to hold things up.

Data here.

Background (from Cynthia, 12/17/15):

I don't know if other regions have the kinds of issues we have, but unfortunately our boundaries are pretty complicated. The data that is available publicly through the NPS Land Resource Division has a couple of issues. The first is that the data available is the legislated boundary, which for our region is significantly different than the fee boundary. The other issue is that our regional lands program is working to update the national dataset, but it's a work in progress. This means that there is missing information or data in need update in the dataset.

Given these issues, the time constraints of the Places/Park Tiles project, and the what they will be used for, I've attached some data that I think will be more appropriate for representing the fee boundary to the public. Where available, I went back to the official tract data (when available) and dissolved the federal fee tracts.

Since the public will likely interpret the Places/Park Tiles boundaries as NPS-owned (fee) not legislated, I think it's very important that we do our best to provide the most clear picture of the land that they can safely assume is part of the park. What I'm providing is not perfect, but I've done my best to look at tract information and segment maps to determine ownership vs. legislated vs. easement.

chadlawlis commented 8 years ago

32 units are included here, 22 of which have unit codes matching existing records in our parks table, 18 out of those 22 are currently pulling from WSD_Parks. 9 of the remaining 10 are actually in our CartoDB parks table, 7 of which are currently pulling from WSD_Parks. So, 31 of the 32 unit codes match up with a combination of PostGIS and CartoDB parks, 25 of which are currently pulling from WSD_Parks.

number unit_code in_parks_table full_name data_source notes
1. anti yes Antietam National Battlefield WSD_Parks
2. arho yes Arlington House, The Robert E. Lee Memorial WSD_Parks
3. bawa yes Baltimore-Washington Parkway WSD_Parks
4. cato yes Catoctin Mountain Park CATO
5. cawo yes Carter G. Woodson Home National Historic Site WSD_Parks
6. choh yes Chesapeaker & Ohio Canal National Historical Park WSD_Parks
7. foth yes Ford's Theatre National Historic Site WSD_Parks
8. fowa yes Fort Washington Park WSD_Parks
9. frdo yes Frederick Douglass National Historic Site WSD_Parks
10. gree yes Greenbelt Park WSD_Parks
11. grfa yes Great Falls Park
12. gwmp yes George Washington Memorial Parkway WSD_Parks
13. hafe yes Harpers Ferry National Historical Park WSD_Parks
14. mana yes Manassas National Battlefield Park WSD_Parks
15. mono yes Monocacy National Battlefield WSD_Parks
16. paav yes Pennsylvania Avenue National Historic Site WSD_Parks
17. pisc yes Piscataway Park WSD_Parks
18. prwi yes Prince William Forest Park PRWI
19. rocr yes Rock Creek Park WSD_Parks
20. sebe yes Sewall-Belmont House National Historic Site Land Resources Division
21. whho yes President's Park (White House) WSD_Parks
22. wotr yes Wolf Trap National Park for the Performing Arts WSD_Parks
23. anac no WSD_Parks in CartoDB
24. fodu no WSD_Parks in CartoDB
25. fofo no WSD_Parks in CartoDB
26. haha no WSD_Parks in CartoDB
27. mabe no Land Resources Division in CartoDB
28. mall no Land Resources Division in CartoDB
29. nace no WSD_Parks in CartoDB
30. nama no WSD_Parks in CartoDB
31. oxhi no WSD_Parks in CartoDB
32. suit no
chadlawlis commented 8 years ago

Boundaries 23-31 were not included in PostGIS parks originally, to prevent them from rendering, but we will be rendering them now that NCR has cleaned them up. Any boundary record will be housed in this table moving forward, anyway, given it is writing into CartoDB (i.e. the master boundary source).

chadlawlis commented 8 years ago

Add suit in as well, despite it being a parkway.

chadlawlis commented 8 years ago

Units with unit_region = 'NCR' currently in PostGIS parks table that were not included in NCR's boundary seed:

chadlawlis commented 8 years ago

Guidance re: boundary sources, from Cynthia:

Unfortunately not all of the boundaries are strictly based of off Lands tract data. Where the source isn't listed, please indicate "Land Resources Division Tract Data" or however you're indicating that in your records. For NCR_Basedata.gdb\BND_Boundaries_NPS_py, please indicate "National Capital Regional Dataset." And for "Debbie Cohen's Tract Data" please indicate, "Tract Data provided by Antietam National Battlefield."

chadlawlis commented 8 years ago

Source translations:

update ncr set source = 'Land Resources Division' where source is null;
update ncr set source = 'ANTI' where source like 'Debbie%';
update ncr set source = 'NCR' where source like 'NCR%';
chadlawlis commented 8 years ago

Unit-specific adjustments:

CHOH included both NCR and Lands data, so I set the source for all of CHOH to NCR:

update ncr set source = 'NCR' where unit_code = 'CHOH';

Anacostia Park included two unit codes, ANAC (10 of 11 rows) and NACE (1 of 11). I set the unit code for all ANAC to ANAC.

chadlawlis commented 8 years ago

Unit name / unit code differentiation for follow-up:

fort_circle_parks_unit_code

penn_ave_historic_site_unit_code

chadlawlis commented 8 years ago

Pennsylvania Avenue National Historic Site is actually its own unit on NPS.gov with unit_code PAAV, so running with PAAV for this probably makes the most sense to limit complexity, while lumping the NACE section in with the NACE unit (which aligns well with that section of the NACE boundary currently in Places, anyway).

Fort Circle Parks is not its own unit, so this will still need to be determined.

chadlawlis commented 8 years ago

Add KEAQ into the mix, as well https://github.com/nationalparkservice/places-data/issues/95.

chadlawlis commented 8 years ago

So, this issue https://github.com/nationalparkservice/places-data/issues/94 came to my attention today. JOFK is not actually an NPS unit, so it has been removed from our tables.

chadlawlis commented 8 years ago

All geometries have been updated and issues opened for @mtaylorlong to address cartography. Keeping open for now as there will likely be further edits once these go live to PT3 and NCR reviews.

chadlawlis commented 8 years ago

We were instructed to list the boundaries from NCR with a NULL source as pulling from "Land Resources Division Tract Data" https://github.com/nationalparkservice/places-data/issues/347#issuecomment-170160169, which I originally set to "Land Resources Division" for consistency with all other units pulling from Lands. After review, I realized that most of these do not actually match up to the latest Lands boundaries, they were simply generated using tract data from Lands but are really custom NCR boundaries. So, I have updated the following accordingly, pulling from "NCR - Land Resources Division Tract Data":

UPDATE
    parks
SET
    data_source = 'NCR - Land Resources Division Tract Data'
WHERE
    unit_code = 'anac'
    OR
    unit_code = 'bawa'
    OR
    unit_code = 'fodu'
    OR
    unit_code = 'fofo'
    OR
    unit_code = 'fowa'
    OR
    unit_code = 'gree'
    OR
    unit_code = 'grfa'
    OR
    unit_code = 'gwmp'
    OR
    unit_code = 'hafe'
    OR
    unit_code = 'haha'
    OR
    unit_code = 'mall'
    OR
    unit_code = 'mana'
    OR
    unit_code = 'mono'
    OR
    unit_code = 'nace'
    OR
    unit_code = 'nama'
    OR
    unit_code = 'oxhi'
    OR
    unit_code = 'paav'
    OR
    unit_code = 'pisc'
    OR
    unit_code = 'prwi'
    OR
    unit_code = 'rocr'
    OR
    unit_code = 'sebe'
    OR
    unit_code = 'suit'
    OR
    unit_code = 'whho'
    OR
    unit_code = 'wotr';
chadlawlis commented 8 years ago

Feedback from Nathan @ NCR:

Chad, it's a big improvement.

I think one point of contention is going to be that none of the Circle Defenses of Washington parks are labeled, places like Fort Stevens (where Lincoln witnessed the battle personally), Fort Totten, etc. It will become a political hotbutton if it's left undone.

CWDW is technically not considered a standalone unit included in NCR's legislative or fee boundaries, according to Cynthia, but we are already planning on adding more detailed labels, the initial list of which includes this: https://github.com/nationalparkservice/places-data/issues/615. So, that will be taken care of once we transition to the new boundary table(s) schema (https://github.com/nationalparkservice/places-data/issues/543) which will allow for more detailed label-only records.

chadlawlis commented 8 years ago

Waiting on feedback from Cynthia before closing out.