200 likes | 526 Views
FSA Geospatial Support Kevin Clarke USDA-FSA-APFO USDA Planning Meeting Dec 11-13, 2007 Topics How the GDW Supports the FSA Geospatial Enterprise Current GDW Environment/Operations Supporting FSA Centralization Efforts NAIP Data Management Changes CLU Replication to the GDW
E N D
FSA Geospatial SupportKevin ClarkeUSDA-FSA-APFOUSDA Planning MeetingDec 11-13, 2007
Topics • How the GDW Supports the FSA Geospatial Enterprise • Current GDW Environment/Operations • Supporting FSA Centralization Efforts • NAIP Data Management Changes • CLU Replication to the GDW
How the GDW Supports FSA Farm Programs • NAIP web services: • Provide the ortho base for maintaining CLU boundaries and farm records • Provide an intuitive base map for interacting with customers in the county offices • Provides a means for identifying current crop growing conditions • Assist with disaster assessment • Supporting FSA’s efforts with centralizing the CLU dataset • Development of CLU topological and attribute based data integrity checks
What the GDW Provides: • Web services and light weight web applications providing access to national MDOQ and NAIP imagery for county offices and the public • Hosting services for a national CLU layer via replication of the CLU from the field service centers • Support for APFO NAIP Quality Assurance process via web services • Internal APFO web mapping applications (Flight Planning, NAIP Film Search, NRI Status, etc)
GDW Data Resources Integrate with USDA Geospatial Infrastructure http://datagateway.nrcs.usda.gov/ http://gos2.geodata.gov/wps/portal/gos ARCIMS Services gdw.apfo.usda.gov APFO Provisioning System http://customerstatement.usda.gov/
Current Operations • FSA’s geospatial activities are primarily county based • CLU managed locally in ArcSDE • NAIP CCM primary source of imagery • Desktop based applications • GDW NAIP web services are also utilized extensively by the county office staff within Desktop environment • NAIP web services are UTM based • ArcSDE and ArcIMS application architecture for both raster and vector datasets with the GDW
Role of GDW within FSA • Role is not to develop enterprise GIS applications for FSA • FSA GIS Office is tasked with GIS application development and Enterprise GIS Architecture definition • Responsible for providing hosting services and associated data maintenance for NAIP and CLU datasets • Deployment of web services and related web based mapping applications for gaining access to those web services
Role of GDW within FSA • GDW has been “aligned” with FSA GIS requirements but not necessarily “integrated” within the FSA GIS Enterprise • Have been working closely with FSA GIS Office on CLU Replication effort • Server architecture is at EOM/EOL
FSA Centralization • FSA GIS Office has been engaging APFO as a fundamental participant in the centralization efforts • The GDW is becoming “integrated” into the FSA Geospatial Enterprise • NAIP must continue to be provided to the new FSA application environment • “Cleaner” CLU is needed for FSA Enterprise/eGov applications such as Customer Statement
Aligning GDW with FSA Business Needs • State based web services instead of UTM based • Multiple years of imagery available • Leverage 4-Band data (CIR and NC services) • Utilize Image Server and ArcGIS Server • Move away from our large (14TB) ArcSDE raster environment • Work with GIS Office to integrate NAIP web services into new application architecture • Utilize IS and GS within GDW for QA purposes
Demo • NAIP web services • Image Server based • Multi year data (Indiana) • 4-Band sample (Arizona 2007) • Using Image Server and ArcGIS Server for QA of GDW data management processes
CLU Replication to GDW • Concept is to replicate CLU edits on a weekly basis from each of the 2,350 county offices to the GDW for aggregation into UTM based datasets • Each county office replicates edits once per week on a given day • Current replication model utilizes file transfer mechanisms • When FSA moves to ArcSDE 9.2, a more robust geodatabase replication architecture can be implemented
CLU Replication to GDW • Private (eAuth) web services for integration into USDA applications • Public facing web services (no attributes)
CLU Replication Pilot • Pilot of 21 counties occurring before end of December • Pilot to run for 3 weeks • National Deployment if pilot is successful
CLU Value Added Services • Topological Analysis • County based CLU data is merged in UTM extents • Perform topological analysis of CLU line work along adjacent county boundaries to detect overlaps, etc • Perform same checks for “out of county polygons” • Catalog errors inside a data mart and pass datasets to KC for inclusion into web based reporting application • State and county personnel review reports and make required CLU updates • Over time topological issues between counties are reduced
CLU Value Added Services • Feature and Attribute Reconciliation • Compare CLU data ingested in the GDW to the peer tabular data in the Farm Records database located in KC • Eliminate “dead” features in each data source • Reconcile attribute values (calc-acres) between geospatial layer and the tabular database • Catalog errors inside a data mart and pass datasets to KC for inclusion into web based reporting application • FSA personnel review reports and make required updates • Positions FSA to deploy applications which update both data sets (geospatial and tabular) simultaneously
CLU Value Added Services • Enhanced CLU Delivery via Gateway • FSA in some cases merges or splits counties into FSA Locations (AK, PR, CONUS) • Example: Nye County, NV – FIPS 32023 • Split into two “locations” with distinct FIPS Codes • 32023 – Northwest Nye, 32035 - Southeast Nye • Extracted shapefiles are placed on Gateway and named as per GDMT naming standards • Gateway only recognizes valid FIPS 32023 resulting in “Southeast” CLU shapefile not being delivered to customer • GDW CLU data management process has built in translation mechanisms to handle all FSA special cases