1 / 24

Transitioning from Shapefiles to Geodatabases

Transitioning from Shapefiles to Geodatabases. Topics. Intros Review GDB Concepts/Formats Tips and Tricks/Lessons Learned Hands-on: Converting SHP to GDB. Why use GDBs?. Improve data integrity, consistency, speed Faciliate data management (editing, multi-user, etc.)

perdy
Download Presentation

Transitioning from Shapefiles to Geodatabases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Transitioning from Shapefiles to Geodatabases

  2. Topics • Intros • Review GDB Concepts/Formats • Tips and Tricks/Lessons Learned • Hands-on: Converting SHP to GDB

  3. Why use GDBs? • Improve data integrity, consistency, speed • Faciliate data management (editing, multi-user, etc.) • Handy storage container • Expanded functionality: • Subtypes, domains, relationship classes • Topology rules • Enforce spatial references • Networks, Terrains • But, GDBs are not appropriate for all situations!!!

  4. GDB Pitfalls • Complexity complicates utilization: • Map display of related features, identification of attributes • Querying across relationships often requires SQL statements • Data delivery challenges • Creation and maintenance requires good GIS skills • Relationship Classes <> Database Integrity Constraints

  5. SHP Pitfalls Does • Flat-file format • Restrictive naming convention • Lacks topology • Hard to track updates/versions • No inherent mechanisms to enforce • data integrity • Multiple conversions required when • dealing with GPS and other data sources (Analogy courtesy of Joel Cusick – AKRO!)

  6. GDB Options at 9.2

  7. Geodatabase Feature Dataset Feature Classes Relationship Classes Object Tables In a feature class, a row stores a feature (sort of similar to a row in a DBF of a shapefile)

  8. Subtypes • Allow categorization of features: • for display • for analysis • for validation • Defined at feature class level

  9. Relationship Classes • Associate feature classes to object tables or • object tables to object tables • assign behaviors (e.g. cascades) • assign rules (a type of ‘integrity’) • Not materialized as database relationships!!!

  10. Domains • Data validation and integrity • Defined at geodatabase level: • Useable across all FCs, tables

  11. 3 GDB Raster Data Types Raster Datasets Raster Catalogs Raster Attributes in feature classes or tables

  12. Raster Attribute Tables • Anyone remember *.VAT (value attribute tables) in Arc/INFO?

  13. Topology Rules • Manage how feature classes share geometries (nodes/points, arcs/lines, polys) • Enforce geometric relationships and consistencies • Enhance editing, data validation (visually) • Examples of rules (currently there are 25): • “Line must not self-intersect” • “Line must not have dangles” • “Polygons must not have overlaps”

  14. Other Features of 9.2 GBDs • Annotation feature classes • Networks/Routing • Terrains • Versioning, Replication and Archiving • Cartographic Representations • High Precision Coordinates

  15. Resources • ArcGIS Help (surprisingly useful) • http://webhelp.esri.com • EGIS’ ESRI UC 2007 site: • http://egis.nps.gov/services/esriuc2007.aspx • ESRI Virtual Campus: • http://data2.itc.nps.gov/gis/esri/vc.cfm • Tools/Utilities (Geodatabase Designer, XML Export, Case Tools, ArcToolbox)

  16. Converting to GDBs • What are your goals? • How will your data be used? • Who are your users? • Who maintains the data? • Storage vs. Usage • Read-only vs. Active Editing • Sophisticated GDB capabilities – do you really need them?

  17. Tips and Tricks Lessons Learned Aneth Wight and Russ DenBleyker (NCPN, CANY, COLM) - Vegetation Geodatabases Heather Stanton (GRE) - Data models, topology and personal SDE Judy Daniels and Branon Barrett (SRI) - File geodatabases and imagery Peter Lindstrom (CAVE) - Park data management and workflows

  18. Soil Resource Inventory and Geodatabases Judy Daniels Project/Data Manager 303.969.2091

  19. SRI File Geodatabase • Limitless storage capability • No Lock Files! • Increased performance for large files • Raster Catalog • Imagery Management • no need to cache images; referenced by the file GDB • Store individual images (SRI does not use mosaics) • Do not use the “add data” function in ArcMap – drag image catalog object from ArcCatalog to ArcMap TOC (prevents loading of overlapping images) • Note: Raster datasets are continuous single raster

  20. SRI Personal GDB • Locking issue with MSAccess • In ArcGIS (desktop and server), MDB file will lock if opened by someone with read/write permission (i.e. the author) • No lock files produced with multiple users who have read-only access • Therefore, problems occur with mixed user permissions and are a concern when distributing data

  21. Using Help Files Stored on a Server • On Window Server 2003 OS • SRI uses help files to share soil characteristics • When complied as HTML, Windows sees it as a security risk • Open in HTML help window – blocked as security risk • LOL - both are MS products!!! • When complied as individual HTML pages, not a security risk • Open with a Internet Explorer window… • ‘Problem’ resolved!!!

  22. Data Modeling and Design • Choose a practical level of detail/normalization • Start with a schema (exported as XML or designed in ArcCatalog) • Or, just hack away at it (exports/imports in ArcCatalog, use interchange files)

  23. Data Prep – Some Tips • BACKUPS!!!!! • Geometry Issues • Run Repair and Clean (example tool/script) • Data clean-up (duplicates, etc.) • Skeleton of GDB ‘model’; match up data • Data interchange (temp tables, XML, etc.) • Test structure and logic; understand initial pitfalls of your data • Script everything you can – easy ‘do overs’

More Related