More

What is the difference between Coverage, Shapefiles and Geodatabases in ArcGIS?

What is the difference between Coverage, Shapefiles and Geodatabases in ArcGIS?


I was wondering about the difference in spatial data storage methodology used by Coverages, Shapefiles and Geodatabases in ArcGIS. Coverage was the initial format, followed by Shape Files and now Geodatabases. So what has improved in these newer formats of Shapefiles and Geodatabases?

It would be great if someone could please explain it with examples.


This is such a great question. Coverages, Shapefile and Geodatabases are fundamentally different geospatial data stores from an implementation standpoint as well as from a philosophical one. I'll try to summarize without going too deep into it.

1. Coverages:

Coverages are interesting geospatial data structures. They concentrate on storing topology. So you will see that the emphasis is in storing the geometry elements first, that is the nodes, edges that make up all the geometries. You will then see a separate set of tables that relate those geometries to the attributes (and hence they "become" features).

A "clean" coverage guarantees certain rules, for example, that there are nodes at every node intersection, you will not have two (or more) nodes on top of each other (or even within a fuzzy tolerance distance), that there are not two edges on top of each other, etc. They also have a sense of direction (from->to) and can distingish between what is to its left and right side.

Coverages work really well for edits that require awareness of topological relationships (imagine editing a parcel boundary). In addition, coverages compress very well since they remove geometric redundancy by design. In fact, you will see that nowadays, modern formats like TopoJSON started using the same techniques that we learned from coverages several decades back.

Coverages can be a bit more complicated to work with when you are dealing with 3D data (for example modeling a bridge that has an upper side and a lower side right below) because the algorithms that we used to use to deal with them were inherently meant for 2D planar graph math.

So why did we move away from it? That would take a longer answer, but perhaps we should explain a bit more what made ESRI Shapefiles popular first.

2. ESRI Shapefiles:

Along came the Shapefile. Probably the most important characteristic that it had was that it was/is an Open Specification that was (comparatively) simple to implement. The attributes leveraged DBF files, so there were already many libraries that implemented a big part of the spec. There was no concept of "clean", which meant that each individual geometry only had to worry about representing itself without taking in consideration the geometries around them or that they intersected. This meant that we did not have to do any complicated math to make sure that a shapefile was correct (unlike the coverage counterpart).

Have multiple geometries that cross each other? Sure why not. Two points on top of each other? Be my guest.

Sometimes, the (arguably) "best" format is not the one that wins, but the one that gets adopted. If a format is easy to implement, it has better chances to be adopted than a complicated one. That was the Shapefile.

All of a sudden you had several libraries (open source and proprietary) and software vendors that supported it. So all was great.

The obvious question is then - why Geodatabases?

3. Geodatabases:

I believe Geodatabases are one of the most misunderstood geospatial data stores. People usually think of them as just "a geospatial format". A couple of years ago, somebody asked "What are ESRI Geodatabases?". Instead of repeating what my answer was then, I welcome you to read that first. I'll wait :)

Now that you read that answer and know what a Geodatabase is, I can expand a bit more on that answer. At the time, there was a lot of research optimizing SQL and writing query optimizers that leveraged indexes, column stores, etc (there still is). By building the Geodatabase on top of a SQL datastore, we can leverage all that research for free. We only need to concentrate on the geospatial concepts, and as the SQL data stores get better, the Geodatabase gets better, too, for free. Not a bad proposition huh?

Nowadays, there are several specifications for geospatial data that come out. The jury is still out there on what is going to replace these technologies (if anything). Nevertheless, if you are interested in this topic, I recommend reading the answer to a questions asked here in GIS.SE some years back: "Are there any attempts to replace the shape file"

I hope this helps!


Most of the information can be found in Esri Help and some search, so I've just compiled some good reads.

How coverages are stored? Since it is a proprietary format, you won't find any technical specifications on how the algorithms are implemented (unless @Vince will shed some light).

Shapefiles came later on and were implemented as a standard which provided a certain level of interoperability. ESRI Shapefile Technical Description contains full description.

Geodatabases were introduced later on. First personal geodatabases came (MS Access), then file geodatabases (binary encrypted format) and enterprise (or ArcSDE) geodatabases which took advantage of the ArcSDE and DBMS technology. You can read more about geodatabases here: Types of geodatabases and The architecture of a geodatabase.

A good read on GIS.SE: Whether to use File Geodatabase (*.gdb), Personal Geodatabase (*.mdb) or shapefiles?

Concerning performance, there were many benchmarks performed and file geodatabases show to be the fastest in terms of reading/writing information. Personal geodatabases and shapefiles are by far slower and probably the only reason to use them is to support older systems which were built with some MS Access business logic or shapefile reading/conversion in mind.

ArcSDE based geodatabase often perform nearly as well as file geodatabases when the DBMS is tuned, but it all depends on the type of data stored, networks, and hardware. For more information on benchmarks, refer to the Esri system design strategies resources (and here).


The primary difference between these formats is the way that features relate to geometries. Back in the heyday of coverages, the coding language was FORTRAN, which meant fixed buffer sizes in COMMON blocks. The most restrictive of these was 500 vertices per line primitive ("arc"). This restriction introduced the concept of "pseudo-nodes" (places where arcs join with only one other arc), and complicated many other data access operations.

The coverage model used a "polygon arc list" (PAL) to describe polygons, which required a polygon shading algorithm to read one file to obtain the list of arcs, then read the arcs themselves to obtain the vertex count, then allocate enough RAM to store all the vertices, then go back to read the arcs again, this time copying the vertices in forward or reverse order to assemble a complete polygon. Only after two visits to the ARC file could the polygon be adequately described, and then many of the same arcs would need to be accessed (in an opposite direction) to shade the polygon neighbors.

By comparison, the shapefile and various geodatabase formats store the complete geometry as a single object (with various implementation details on how the object is physically implemented). This has drawbacks when trying to edit shared boundaries, but that operation is significantly less frequent than polygon shading.

The "whole shape" storage model is the key difference between coverage format and the new ones, and this difference is so fundamental that it's hard to see any real difference between the shapefile and the various geodatabase formats. In fact, the shapefile format was used to access FGDB geometries through the FGDB API, even though FGDB doesn't use that exact format, just because it was simpler than introducing a new vertex layout.


One more difference between the formats is that a geodatabase can model relationships between feature classes. As Ragi noted,

Coverages work really well for edits that require awareness of topological relationships (imagine editing a parcel boundary).

But this awareness exists only within a single coverage - if you want to model the relationships between 2 or more coverages, it's your responsibility to write the code which checks for any "illegal" topological relationships.

For example, if parcel polygons cannot have gaps, and parcel boundaries should align exactly with roads, with coverages or shapefiles it's up to you to verify that this is the case, and manually fix any errors where these rules are not upheld.

A geodatabase can optionally support a Topology object, which allows you to define the allowable topological rules for your data. Importantly, these rules can occur both within and between feature classes in your geodatabase.

The topology edit tools within ArcMap help you to find topological violations, and in some cases to fix them automatically.

Prior to the introduction of geodatabase topology ("the good old days"), it was common to write long and complicated AML scripts to detect topological violations, then edit the coverages manually in ArcEdit (not so much fun).


ArcUser Online

Summary

This article provides a general overview of the enterprise geodatabase—its key features, architecture, and implementation—designed for GIS managers and database administrators.

Because the enterprise geodatabase is one of the foundation elements for seamless, organization-wide use of GIS, management staff need a good understanding of its role and capabilities.

Figure 1: Enterprise geodatabase tiers

The geodatabase is the native data format for ArcGIS. It is a data storage container that defines how data is stored, accessed, and managed by ArcGIS. The term geodatabase combines geo (spatial data) with database (specifically a relational database management system or RDBMS). ArcGIS 9.2 has three types of geodatabases: Microsoft Access-based personal geodatabases, file geodatabases, and ArcSDE geodatabases.

Personal and file geodatabases are designed for single users and small projects. ArcSDE geodatabases are scalable and designed for larger-scale use, ranging from medium to enterprise-wide implementations. These geodatabases require ArcSDE technology and are available at three levels (in ascending order of capacity and functionality): personal geodatabase (ArcSDE Personal), workgroup geodatabase (ArcSDE Workgroup), and enterprise geodatabase (ArcSDE Enterprise). This article deals with ArcSDE enterprise geodatabases.

Understanding Enterprise Geodatabase Architecture

At a conceptual level, an enterprise geodatabase consists of a multitier architecture that implements advanced logic and behavior in the application tier (e.g., ArcGIS software) on top of a data storage tier (e.g., RDBMS software). The application tier can be further subdivided into two parts—ArcObjects and ArcSDE technology. The responsibility for managing geographic data in an enterprise geodatabase is shared between ArcGIS and whichever RDBMS is used.

On the data storage tier, RDBMS software provides a simple, formal data model for storing and managing information in tables. The schema of an enterprise geodatabase is persisted in the RDBMS as a collection of tables known as the ArcSDE Repository. Aspects related to data storage and retrieval are implemented as simple tables and certain aspects of geographic data management, such as disk-based storage, definition of attribute types, query processing, and multiuser transaction processing, are executed by the RDBMS. IBM DB2, IBM Informix, Oracle, and Microsoft SQL Server platforms are currently supported by ArcGIS. At version 9.3, PostgreSQL will be supported.

ArcSDE technology forms the middle tier. Prior to ArcGIS 9.2, ArcSDE was a separate software product. At ArcGIS 9.2, ArcSDE was integrated into both ArcGIS Desktop and ArcGIS Server and is now formally known as ArcSDE technology. As the gateway between GIS clients and an RDBMS, ArcSDE serves spatial data and enables that data to be accessed and managed within an RDBMS. It is implemented as several components—a directory of executables, a set of tables and stored procedures in the database (i.e., the ArcSDE Repository), and an optional service. These components will be discussed in more detail.

TableFunction
server_configContains parameters and values that define how the ArcSDE server uses memory and is read each time the ArcSDE service starts. During the ArcSDE postinstallation, its contents are populated by a file named giomgr.defs.
dbtuneLists configuration keywords for data objects in the geodatabase such as feature classes, raster datasets, topologies, and networks. Configuration keywords are used during data loading and define how the datasets are stored in the geodatabase. Geodatabase administrators can use a file named dbtune.sde to manage the configuration keywords used by the enterprise geodatabase.
table_registryManages all the registered tables of the enterprise geodatabase including all geodatabase system tables and datasets (e.g., feature classes and raster datasets) registered with the geodatabase.
LayersMaintains data about each feature class in the geodatabase. This information helps build and maintain spatial indexes, ensures proper shape types, and maintains data integrity.
raster_columnsMaintains data about each raster dataset in the geodatabase and helps keep track of the supporting tables for a raster dataset such as the band, block, and auxiliary tables.
Figure 2: Key tables in the ArcSDE Respository

ArcSDE technology provides fundamental capabilities that include

  • Access and storage of simple feature geometry in the RDBMS
  • Support for native RDBMS spatial types (if available)
  • Spatial data integrity
  • Multiuser editing environment (i.e., versioning)
  • Support for complex GIS workflows and long transactions
  • Geospatial data integration with other information technologies

The upper level of the application tier, ArcObjects, implements geodatabase application logic. This set of platform-independent software components is written in C++ and provides services to support GIS applications as thick clients on the desktop and thin clients on the server. This technology component is built into GIS clients (e.g., ArcGIS Desktop) and implements more complex object behavior and integrity constraints on simple features, such as points, lines, and polygons, stored in an RDBMS. In other words, ArcObjects implements behavior on the feature geometries. Feature classes, feature datasets, raster catalogs, topologies, networks, and terrains are all examples of geospatial data elements within the geodatabase data model for which ArcObjects provides the application logic that implements GIS behavior on top of simple spatial features stored in an RDBMS.

The three enterprise geodatabase architectural tiers are defined at a conceptual level. To most end users, working with the architectural tiers of the enterprise geodatabase is an easy, transparent process. GIS managers or database administrators most likely work directly with these tiers only during the setup and configuration of an enterprise geodatabase or when performing maintenance.

Enterprise Geodatabase Capabilities

Figure 3: Two methods for communicating with an enterprise geodatabase: an application server connection or a direct connection

Designed for large-scale systems, the enterprise geodatabase can be scaled to any size, support any number of users, and run on computers of any size and configuration. It takes full advantage of the underlying RDBMS architecture to provide high performance and support for extremely large continuous GIS datasets. RDBMS functionality supports GIS data management for scalability, reliability, security, backup, and data integrity. In addition to supporting many users with concurrent access to the same data, an enterprise geodatabase can be integrated with an organization's existing IT systems.

Some of the aspects of ArcSDE technology that contribute to these capabilities include the following.

Versioning

Nonversioned Editing

Using nonversioned editing is equivalent to a standard database transaction. The transaction is performed within the scope of an ArcMap edit session and the data source is directly edited. Nonversioned edit sessions do not store changes in other tables as versioned edit sessions do.

Geodatabase Replication

With geodatabase replication, data is distributed across two or more geodatabases in a manner that allows them to synchronize any data changes that are made. It is built on top of the versioning environment and supports the full geodatabase data model including topologies and geometric networks. In this asynchronous model, the replication is loosely coupled. This means each replicated geodatabase can work independently and still synchronize changes with other replicated geodatabases.

Because geodatabase replication is implemented at the ArcObjects and ArcSDE technology tiers, the RDBMSs involved can be different. Geodatabase replication can be used in connected and disconnected environments and can also work with local geodatabase connections as well as geodataserver objects (through ArcGIS Server), which enables access to a geodatabase over the Internet.

Historical Archiving

When enabled for a dataset, historical archiving captures all data changes in the DEFAULT version of the enterprise geodatabase by preserving the transactional history as an additional archive class. ArcGIS applies transaction time when changes are saved or posted to the DEFAULT version to record the moment of change to the database.

Installing an Enterprise Geodatabase

The setup and configuration of a typical enterprise geodatabase has two stages. In the first stage, enterprise ArcSDE software is installed on the server. The second stage (i.e., ArcSDE postinstallation) consists of four steps.

  1. Create or configure a database with a geodatabase administrative user. Typically, this user is named sde. For SQL Server-based enterprise geodatabases, this user could also be named dbo (i.e., the database owner) instead of sde.
  2. Populate the database with the ArcSDE Repository.
  3. License the ArcSDE server.
  4. (Optionally) create the ArcSDE service.

On Windows operating systems, the ArcSDE postinstallation can be performed using a wizard. Alternatively, it can also be performed manually with ArcSDE commands. Additional parameters may also need to be specified during the postinstallation, depending on the RDBMS and operating system used. After the enterprise geodatabase has been created, database management tools can be used to create users, schemas, and indexes to customize the enterprise geodatabase.

Enterprise Geodatabase Components

A typical enterprise geodatabase installation has three main components—the ArcSDE home directory, the ArcSDE Respository, and the ArcSDE service.

The ArcSDE Home Directory

When the ArcSDE component of ArcGIS Server is installed on the server, this directory is created. It is referenced in the server operating system by an environment variable named %SDEHOME%. The directory contains the ArcSDE command line executables, ArcSDE configuration files, geocoding and language support files, log files (for troubleshooting ArcSDE server issues), help documentation, and some sample utilities.

The ArcSDE command line executables are a collection of binary files that can be run at the command prompt by geodatabase administrators to create, configure, manage, and monitor both the enterprise geodatabase and ArcSDE service. ArcSDE command line executables include a set of commands for data import and export at the ArcSDE technology tier of the enterprise geodatabase.

The ArcSDE Repository

The internal system tables and stored procedures that are installed in the RDBMS during the ArcSDE postinstallation are owned and managed by the geodatabase administrative user created in the first step of the ArcSDE postinstallation. They are self-managed internally by both ArcGIS and the RDBMS via stored procedures and should not be edited manually.

ArcSDE Repository tables can be subdivided into ArcSDE system tables and geodatabase system tables (i.e., system tables prefixed with GDB_). ArcSDE system tables work at the ArcSDE technology tier level and contain basic metadata for ArcSDE, store feature geometry and raster data, and manage the versioning environment. The geodatabase system tables work at the ArcObjects tier level and store information on geodatabase behavior and functionality for topologies, networks, and domains. These two groups form the schema of the enterprise geodatabase.

Enterprise geodatabase administrators should be familiar with the key ArcSDE Repository tables listed in Figure 2.

The ArcSDE Service

Also commonly called the giomgr process (an abbreviation for geographic input/output manager), the ArcSDE service is a persistent service on the ArcSDE server that is dependent on the RDBMS instance. The giomgr process supports application server connections to the enterprise geodatabase.

The ArcSDE service listens for incoming client connection requests on a dedicated port and helps enable clients to connect to the geodatabase. A typical enterprise geodatabase installation has one associated ArcSDE service however, the ArcSDE service is not required if only direct connections are made to the enterprise geodatabase.

Type of Client Connections

Clients typically communicate with an enterprise geodatabase over a network using TCP/IP protocols and can connect to an enterprise geodatabase in two ways—using an application server connection or a direct connection.

Application Server Connection

This traditional client-connect method involves the ArcSDE service, which listens for client connection requests. When a client application, such as ArcGIS Desktop, requests a connection to the enterprise geodatabase, a gsrvr (an abbreviation for geographic server) process is launched by the ArcSDE service and provides a dedicated link between the client and the geodatabase. The ArcSDE service continues to listen for connection requests.

The connection to the geodatabase is based on the user name and password submitted. Dataset access depends on the permissions established for the user by the geodatabase administrator. The gsrvr process remains connected to the geodatabase until the client releases the connection by closing the application. This connection method is commonly called a three-tier connection because it involves the client application, the geodatabase, and the giomgr and gsrvr processes. In this method, most of the work is performed on the server.

Direct Connection

With this method, clients connect directly to the enterprise geodatabase without using the ArcSDE service. Communication between the clients and geodatabase occurs via ArcSDE direct-connect drivers, located on the client side, not through the ArcSDE service. Client machines must be configured for network access.

ArcSDE direct-connect drivers are automatically installed for the whole ArcGIS product suite, the ArcView 3.x Database Access extension, ArcIMS, ArcInfo Workstation, and MapObjects 2. For custom applications built from the ArcSDE C API, the ArcSDE direct-connect drivers need to be enabled with the application to support this functionality.

Direct connection drivers are built from the same software code used to build the ArcSDE service. The difference is that direct connect drivers are built as dynamic-link library files and execute in the process space of the client application, whereas the ArcSDE service was built as an executable program that runs on the ArcSDE server.

With this connection method, commonly called a two-tier connection because it only involves the client application and the geodatabase, some of the work that would have occurred on the server with the application server connection is performed on the client.

To have ArcSDE server handle the majority of the ArcSDE processing load, use application server connections. When the client machines have enough resources to handle some of the ArcSDE processing load, use direct connections. Direct connections may cause more network traffic. Both client connection methods can be supported for the same enterprise geodatabase in any combination and configuration.

Conclusion

The enterprise geodatabase is the foundation for building a large-scale GIS with ArcGIS Server Enterprise. It uses a combination of ArcObjects, ArcSDE technology, and RDBMS software to define how data is stored, accessed, and managed by ArcGIS. Conceptually, it stores GIS data in a centralized location. However, it can be set up and configured for a variety of implementations.

The enterprise geodatabase can be used for applying sophisticated business rules and relationships to spatial data, defining advanced georelational models such as topologies and networks, and providing a multiuser access and editing environment. With these capabilities, the enterprise geodatabase spatial data can be leveraged to its full potential while maintaining a consistent, accurate GIS database.

More Resources

For more information on enterprise geodatabases, see these Esri resources:


What is the difference between Coverage, Shapefiles and Geodatabases in ArcGIS? - Geographic Information Systems

Instructions below updated for ArcGIS 9.3
Click here for ArcGIS 9.1/9.2 version

  • Purpose
  • Introduction and Background
    • Geographic Data Modeling
      • Figure 1: The modeling process.
      • Figure 2: Hierarchy of ESRI's ArcInfo8 data structures.
      • Figure 3: Icons and hierarchy.
      • Understanding data models
        • Tables
        • ArcInfo Help
        • Converting Between Data Structures Based on the Data Models
        • Changing Layer Properties in ArcMap
        • Finding and Examining Tools
        • Previewing Tables
        • Sorting a Column in Table Preview, and Searching for a Text String
        • Tables, questions (Word document) and map.

        2.2 Introduction and background

        For more information on data models in Geography:
        You will notice some diversity in the definitions, as they are in the context of different companies, software, times, and degrees of specificity. For this lab, focus on the hierarchy described in the main body of the lab and in GEO 580 Lecture #3 in class.
        Data models in geography:
        AGI dictionary Definition of "Data Model" (their server may be down though)
        ESRI GIS Dictionary Definition
        Geographic Data Modeling: An Introduction

        Data models are a crucial concept for GIS users to understand. Data models describe how geographic data will be represented and stored. The choice of data model will yield benefits in terms of simplifying aspects of the real world, but will also incur costs in terms of oversimplifying or misrepresenting other features.
        A map is an example of an analogue data model( 1) the cartographer has abstracted the real world with a set of conventions that she can use to represent important aspects of the landscape. In a computer, all information must be stored digitally: that is, it ultimately must be reduced to numbers (1010000110. ). Therefore, the abstractions of a real-world model must be formalized in a data model. The data model shows the computer how best to store the geographic information (geometry and attributes) in a database or other format. Bernhardsen (1999) diagrams the process along these lines:


        Figure 1: The modeling process. The real world is described by the data model. The "database" is part of the resulting data structure (how the data model gets implemented in a digital computer). (after Bernhardsen 1999, p.39. Bernhardsen, Tor. Geographic Information Systems: An Introduction. New York: John Wiley & Sons, Inc., 1999, pp. 37-99. Graphic from www.gis.com)

        In order for geographic data to be represented digitally, a geographic data model has to be chosen. Most of the confusion about data models arises from the diversity of geographic data models. Unlike classifications of things in the natural sciences or geometry, data models are not necessarily defined by hard-and-fast rules derived from observation or logic data models are instead created by GIS programmers and users for the purpose of representing certain specific features from the real world. The definitions and capabilities of data models will thus vary depending upon the aspect of reality that the GIS software designers and users are attempting to model. Furthermore, data models (and the resulting data structures that are actually implemented in GIS software) may evolve through time under the influences of technology (e.g., increasing storage space and processing power, or networking, or software compatibility) or even history (e.g., ESRI started with the georelational model way back in 1980, so it is still probably their best-supported and most used data model). Finally, the influences of the marketplace and the interests of GIS companies and consumers must be taken into account.
        The result of all this is that every GIS software package will be capable of supporting a number of data models. The capabilities of the data models may change with new versions of the software, and compatibility issues may arise. Certain functions will be accessible with data in the form of one data model but not another.



        The National Center for Geographic Information and Analysis (NCGIA) still has their core GIScience curriculum online. The following entries are relevant to our discussion of data structures and data models:
        Fundamentals of Data Storage
        Information Organization and Data Structure
        and Non-spatial Database Models.
        Data Models vs. Data Structures
        A data model is a conceptual model of the real world. The representation of this model in the computer is the data structure . A given vector data model could be implemented in a computer in a number of ways. In practice, however, the software designer has usually done both the data modeling and data structuring, so that when one refers to a "coverage" both the data model and data structure are pre-defined. This is not necessarily the case with custom user-designed data models, however.
        The data structure therefore corresponds to the fourth box, labeled 'DATABASE,' in Figure 1: The Modeling Process .

        The confusion surrounding all of this can be reduced if one thinks of the data models as fitting within a general hierarchy (these will all be discussed in detail in lecture).

        Figure 2: Hierarchy of ESRI's data models and data structures. . Beware, as ESRI documentation often uses the same names for both data model and data structure, which may be confusing (e.g., ESRI's geodatabase data model and geodatabase data structure. ESRI also developed a "georelational" data model which they sometimes call the "coverage" data model as well. And the resulting data structure is also the "coverage", i.e., the ArcInfo coverage). TIN is a data structure resulting from the Delauney triangulation data model.

        One final complication is that geodatabase data structures (based on ESRI's object-oriented geodatabase data model) may contain rasters and TINs, as well as vector data sets.

        Data Models, Data Structures, and Feature Classes in ArcGIS 9.

        In ArcCatalog, the geometry and data structure of every feature is identified by a small picture or icon. This works much like Windows Explorer, except that only file formats recognized by ArcCatalog as geographic data will be displayed.

        Your life will be made much easier if, as part of learning about data structures, features, and other files, you learn ArcCatalog's icons for them. There are a lot of them and they can be initially confusing, so here is the handy table from Lab #1 that you can refer back to. Below is a display from ArcCatalog showing how the icons are identified by type.



        Also, you can also always click on the 'Contents' tab while highlighting the folder above the file in question., like this:

        The folders and files that make up shapefiles, coverages, geodatabase feature classes, rasters, and TINs fall into an organizational hierarchy in ArcCatalog (Note: this is a completely different matter than the conceptual hierarchy discussed above in Figure2). Figure 3 below shows the hierarchy of folders, data models, data sets, and feature classes as displayed in ArcCatalog. Feature classes are the lowest level that the user accesses.

        • For shapefiles, the shapefile is the feature class. Each feature (donut shops, streets, etc.) will be contained in its own shapefile. The geometric information (ArcCatalog 'hides' these binary files, but in windows explorer they are seperate files- DONT USE WINDOWS TO MANAGE YOUR DATA) will be displayed in the "Geography Preview" and the attribute information (stored in dBASE IV tables) will be displayed in the "Table Preview". This linkage of geometric files to separate attribute tables is common to shapefiles and coverages and is the main conceptual tenet of ESRI's georelational data model.
        • For coverages, each feature class does not correspond to a map feature. The coverage feature classes are standard categories like arc, label, polygon, tic, etc. The feature classes are found in a folder. This folder is the coverage. Each feature on the map (landuse, railroads, etc.) will correspond to one of these coverage folders. Within the folder, the feature classes store the geometric information (coordinates are stored in hidden binary ARC files displayed in the "Geography Preview") that is linked to attribute tables (INFO tables displayed in the "Table Preview"). Like shapefiles, coverages are data structures resulting from a georelational data model.
        • For geodatabases, like shapefiles, each feature class corresponds to a map feature such as roads, counties, etc. The feature classes are generally grouped into a feature data set, a folder that might contain data about a region or topic (e.g., "USA container" contains information about the USA). Unlike shapefiles and coverages, geodatabases employ a geodatabase data model that stores each feature as a row in a relational database table (this record would link to other tables containing geometric information, topological relationships, attribute information, etc.). A number of feature data sets can be stored in a geodatabase.
        • Looking again at Figure 3, you will notice that the geodatabase, the coverages, and the shapefiles are all contained within the the folder 'Some-Data.' The little blue symbol on the folder indicates that it contains recognizable geographic data in the first level beneath 'Some-Data.' In the context of coverages, this folder would often be referred to as a coverage workspace.
        • Additional note: Notice that we did not name the folder "Some-Data" as "Some Data" - with a real space - even though this is allowed by Windows. ArcToolbox needs to read directory path names into a command line to run certain commands, and if there is a real space in the file name, the path will be split and interpreted as two separate words. You will get an error such as"Spaces are not permitted in the path name"or"too many commands"or some such. So, for ArcGIS purposes, name your directories and files using dashes ("-") or underscores ("_") instead of using spaces. Also try to keep all names under 13 characters. You have been warned!

        mystery -- Folder containing 8 data layers of several features in different data models. You will be figuring out what these are in the lab.


        roads -- multnomah county roads coverage
        mult_dem -- digital elevation model of Multnomah county
        mult_tin -- TIN derived from mult_dem
        mult_cont -- Contour shapefile derived from mult_dem
        or_counties -- counties of Oregon, from the Oregon Geospatial Data Clearinghouse

        Download the data here (36 Mb) into your local work folder.

        2.4.1 Understanding data models: Tables


        Question 1:
        As you work through the lab, fill out Tables A and B in the word document that you will be turning in, based on information from the lab introduction, exercises, course text, and lecture. If time is short, you may want to leave some of the tables to fill out outside of class.

        • Go to the Menu Bar -->Help --> ArcGIS Help:
        • When you're looking for something in ArcGIS Help, make sure to Search in both the Index and the Search tab. Trying the search with different terms (e.g., data models, or coverage, or geodatabase) increases the odds of finding something useful.
        • Also, for more information you can check out the Getting more help section, especially Using this Help system and ArcOnline:

        2. 4. 2 Mystery Models

        Examine the layers in the 'mystery' folder using ArcCatalog or ArcMap.

        Once you have identified the layers and the conceptual data models that they are based on, convert mystery5 into the same data structure as mystery7. You will have to figure out how to do this yourself, but here are some big hints:

        • You will have to use ArcToolbox to accomplish this task. Recall that you can open ArcToolbox from the Start menu or by clicking on the ArcToolbox button ( )in ArcCatalog.
        • We are doing a conversion, so navigate to the toolbox menu that would contain the appropriate tools.
          • Find the appropriate sub menu for converting data in mystery5's datamodel.
          • Find the tool that will let you convert to mystery7 's data structure.

          Give the output a name you will remember, and run the conversion. Take your resulting layer and display it in ArcMap, along with mystery5.


          Answer question 3:
          How similar are mystery5 and your converted layer? Briefly describe the major differences between the two. What is the cause of them? What do you think was the source data from which mystery5 was derived?

          Go to the data directory lab2_data.

          Now, add mult_cont, mult_dem, and mult_tin into ArcMap. Display just mult_cont and mult_tin, and overlay mult_cont on top of mult_tin. To make the display intelligible, you will have to change the properties for the two layers.

          • Go to the Display tab.
          • Change the transparency of mult_tin so that the DEM raster can be seen underneath it, and hit OK.
          • Make sure the mult_tin layer displays on top of the DEM raster.


          If you're curious about making better use of Properties, the main methods are the creation of Layers in ArcCatalog, and ArcMap's Style Manager, found in the Menu Bar under Tools-->Styles-->Style Manager. You will be repeating these steps to change a layer's properties hundreds of times throughout the quarter. You will probably find the Properties functions very useful but perhaps not as user-friendly as they could be and somewhat tedious and frustrating to use for complicated tasks. We will discuss ways to make this easier later on in the quarter by using ArcMap's Style Manager.


          Answer question 4:
          Which of the three layers (mult_dem, mult_tin, mult_cont) do you think was the original data layer? Which is "second generation" and which is "third generation"? Why do you think this?

          2. 4. 3 Data Structures and ArcToolbox

          Coverages are the vector data structures long used in the old Unix workstation version of ARC/INFO. Therefore, many of the ArcToolbox tools simply use a wizard to create a command line that runs an ARC process in the background. As a result, many of the tools only support coverages, although some of the newer tools are designed for geodatabases or shapefiles. To familiarize yourself with the Toolbox and the input formats required, find each tool listed below and figure out what kind of input file(s) it supports (e.g., coverage, geodatabase feature class, grid, TIN, etc.).

          • Again, recall that you can open ArcToolbox from the Start menu or by clicking on the ArcToolbox button ( )in ArcCatalog.
          • If you can't find a particular tool in ArcToolbox, try the Search tab--> Locate and search by name or description.
            • For more information on a tool, right-click on it and click Help.

            2. 4. 4 AATs and PATs

            As discussed above, coverages have been the standard data structure for the generic vector data model for previous releases of Arc/INFO. With the release of ArcGIS 9.x, Arc and INFO have apparently been integrated (with INFO essentially replaced by MS Access tables), and the new geodatabase data structure has been promoted. However, coverages are still a very commonly used, and it therefore behooves us to understand their structure.

            Recall that coverages are based on the georelational data model. The INFO part of Arc/INFO was a relational database manager. An INFO file is a table that stores the information associated with the geographic features of a spatially referenced data set. This gives a GIS the ability to manipulate information both spatially and via standard tabular database functions. An example relational model is when two tables share a common column. In a georelational model the individual records in two or more tables are related through their location in space. The polygon coverage below serves as a simple example of this concept. The common column is often called the KEY column and is used for relating or joining tables.

            Let's explore the attribute tables of roads. Go to ArcCatalog and Preview the data.

            • Below the preview map, locate the Preview box: .
            • Change the preview option from Geography to Table .
            • You are now looking at the arc attribute table (AAT).

            For a look at polygons and Polygon Attribute Tables (PATs), open mult_county. Explore the tables for the tic, label, arc, and polygon coverage feature classes.

            • To sort a table (e.g., polygon), for example by name, click on the column heading you wish to sort.
            • This should highlight the column you wish to sort by.
            • Then, right-click and select Sort Ascending.

            2. 4. 5 Relationships in GIS

            So far we have focused on digitally modeling geographic features, and attributes for those features. However, increasingly GIS users are increasingly seeking to model relationships between features as well. These relationships can have behavior and can follow rules. A primary advantage of the new geodatabase model is that it gives the user/designer the ability to build structured relationships between features.

            To get a handle on this, consider the classic example of a power pole and a transformer. Perhaps you want to describe the location of the transformer on the pole -- e.g., height in feet and the side of the pole the transformer is on (North, West, etc.). The geodatabase designer could constrain the possible entries in the "location" field for the transformer to North, South, East, and West. Then, a person doing data entry would simply select the appropriate direction from the available options. Similarly, the designer could constrain the "height" field to between 10 and 20 feet.

            The designer could also limit the number of relationships a particular pole can have with transformers. In the real world, several transformers can reside on a pole. However, an unlimited number of transformers will not fit -- we might imagine that four transformers is the maximum. The geodatabase designer could constrain the number of relationships the pole has with transformers to between 0 and 4. After four transformers have been assigned to that pole, a transformer would have to be deleted before another could be added. .

            The relationship between poles and transformers is directional as well. In a directional relationship, changing A will change B, but changing B will not change A. If you move a pole (in real life and in the GIS), you want the transformers on the pole to move as well. But you don't want to be able to move a transformer by itself, as it must always be on a pole. If you delete a pole from the data layer (say, because it was burnt down in a forest fire), you will want the records for the transformers on that pole to be deleted as well. But if you delete a transformer, the pole should remain unaffected.


            What is the difference between Coverage, Shapefiles and Geodatabases in ArcGIS? - Geographic Information Systems

            Количество зарегистрированных учащихся: 17 тыс.

            Участвовать бесплатно

            In this course, you will learn how to find GIS data for your own projects, and how to create a well-designed map that effectively communicates your message. The first section focuses on the basic building blocks of GIS data, so that you know what types of GIS files exist, and the implications of choosing one type over another. Next, we'll discuss metadata (which is information about a data set) so you know how to evaluate a data set before you decide to use it, as well as preparing data by merging and clipping files as needed. We'll then talk about how to take non-GIS data, such as a list of addresses, and convert it into "mappable" data using geocoding. Finally, you'll learn about how to take data that you have found and design a map using cartographic principles. In the course project, you will find your own data and create your own quantitative map. Note: software is not provided for this course.

            Получаемые навыки

            Geographic Information System (GIS), Cartography, Esri, Mapping, Spatial Analysis

            Рецензии

            A nice and well explained course again. i think if some sample data can be supplied to the trainees when you are demonstrating something in ArcGIS it would be more helpful to practice.

            I received professional skills and it will develop my career , may thanks Coursera team for their hardwork and well arranged and designed courses both theory and practical


            Feature Data

            The geographic boundaries that are used in the UK are a complex, often inter-related, but ever changing mass of areas. For anyone new to the UK (or indeed not a trained quantitative geographer), it can be quite a daunting task to attempt to understand all of the boundaries that are in use. Fortunately the Office for National Statistics has an online beginners guide to UK geography. If you need more information on the vast array of different UK geographies, this is the place to start:

            The map collection on this site is particularly good for getting a quick view of what some of these areas look like.


            GIS Concepts

            What can we do with GIS?

            GIS can be used as tool in both problem solving and decision making processes, as well as for visualization of data in a spatial environment. Geospatial data can be analyzed to determine (1) the location of features and relationships to other features, (2) where the most and/or least of some feature exists, (3) the density of features in a given space, (4) what is happening inside an area of interest (AOI), (5) what is happening nearby some feature or phenomenon, and (6) and how a specific area has changed over time (and in what way).

            1. Mapping where things are. We can map the spatial location of real-world features and visualize the spatial relationships among them.
            Example: below we see a map of agricultural districts (in green) layered over soil types. We can see visual patterns in the data by determining what soil types are best suited for ag districts.

            2. Mapping quantities. People map quantities, indicating the relative prevalence of some kind of entity or resource, to find places that meet their criteria or to see the relationships between places.
            Example: below is a map of cemetery locations in Wisconsin. The map shows the cemetery locations as dots (dot density) and each county is color coded to show where the most and fewest cemeteries are (lighter blue means fewer cemeteries).

            3. Mapping densities. Sometimes it is more important to map concentrations, or a quantity normalized by area. For example: below we have mapped the population density of Manhattan (total population counts normalized by the area in sq. miles of census tracts.)

            4. Finding what is inside. We can use GIS to determine what is happening or what features are located inside a specific area/region. We can determine the characteristics of "inside" by creating specific criteria to define an area of interest (AOI). For example: below is a map showing noise 'pollution' near an airport in Minneapolis. If we add demographic data from the Census to this map we can determine the socioeconomic characteristics of people that live within the defined 'noise pollution' area of interest.

            5. Finding what is nearby. We can find out what is happening within a set distance of a feature or event by mapping what is nearby using geoprocessing tools like BUFFER. Example: below we see the effects on features within specified radii of a simulated explosion. Use of buffering tools to generate set distances can aid in emergency response to disasters like these.

            6. Mapping change. We can map the change in a specific geographic area to anticipate future conditions, decide on a course of action, or to evaluate the results of an action or policy. Example: below we see land use maps of Barnstable, MA showing changes in residential development from 1951 to 1999. The dark green shows forest, while bright yellow shows residential development. Applications like this can help inform community planning processes and policies.


            What’s In An ID? Global IDs vs. Object IDs

            What’s In An ID? Global IDs vs. Object IDs
            By Jerry Swanson

            A major role of a GIS professional is data management. This can include external data sources such as Excel spreadsheets, survey data, and even pictures with a geotag. The most common data GIS professionals use is located in a geodatabase, including file geodatabase or databases stored in a Spatial Database Engine (SDE). Managing large databases, especially at a city or county level, such as parcels, address points, or street centerlines, can present numerous challenges to the database administrator.

            Object IDs
            Luckily for Data Managers, software and relational database management systems (RDBMS) provide built in functions to assist with data management. One of the main functions is to provide a unique ID for each record within a database. In GIS, specifically Esri’s software suite, this unique ID is known as an ObjectID. ObjectIDs are a 32-bit integer, non-zero, positive only, and generally sequential numeric value. ObjectIDs can be useful in many way including as a unique identifier for a particular feature, assist in the creation of additional unique ID’s via python scripts, and typically providing information on when a particular record was created based on the value alone. The field is a requirement in Esri’s software, from shapefile to a SQL based enterprise database. End users cannot edit ObjectIDs and the values are auto generated as a function of the software.

            While ObjectIDs can be helpful in certain cases, they can also cause issues in data management. The main flaw in using ObjectIDs as a unique identifier, is that they do not stay constant throughout the lifetime of a particular feature class. For example, if you have been editing an address point layer over time including adding and deleting records, the sequence of the ObjectIDs will get out of sync. This causes a problem if you decided to export/import that feature class, as the ObjectIDs will be reset during the process. This means that if there was any relationship classes or joins performed on the ObjectID field, the link would be lost with the new feature class. This is why Esri and GIS professionals recommend not using the ObjectID for linkage purposes. Any GIS database manager who has experienced working with ObjectID’s in this capacity will tell you it’s a data nightmare. There is a work around for using the ObjectID as a unique identifier which includes making a copy of the ObjectID field before moving the data, but Esri provides an additional unique ID for better data management, GlobalIDs.

            Global IDs
            GlobalIDs are similar to ObjectIDs in the sense that they cannot be edited by the end user, the IDs are generated automatically by the software, and they provide a unique identifier for a particular feature. GlobalID’s are a 128-bit string, which provide sufficient combinations within a database and cannot be duplicated since the ID’s are controlled by Esri. The main difference between ObjectIDs and GlobalIDs is the ability to retain their value throughout the lifespan of the feature class. This makes GlobalIDs the ideal unique identifier for a variety of operations within GIS. Examples of use include being the key identifier in relationship classes and related tables and disconnected editing work flows. In some cases, GlobalID’s are required for use specifically in the case of enabling attachments in a feature service for use in ArcGIS Online and Collector for ArcGIS. GlobalID’s can easily be generated using the “Add Global IDs” tool in ArcGIS Desktop or in ArcCatalog by right clicking on the feature dataset or a particular feature class and clicking “Enable Global IDs.”

            Conclusion
            Depending of the needs of the organization, GIS professionals may utilize ObjectIDs or GlobalIDs based on work flow, database management protocol, and standard operation procedures. Both types of IDs provide different levels of value and function and the discussion points described above should be considered to ensure one aspect of successful data management in GIS.


            A shapefile (.shp) is a vector data storage format for storing the location, shape, and attributes of geographic features. A shapefile is stored in a set of related files and contains one feature class.

            A layer file (.lyr) is a file that stores the path to a source dataset and other layer properties, including symbology.

            In comparison to a shapefile, a layer file is a just a link eference to actual data, such as a shapefile, feature class, etc. It is not actual data because it does not store the data's attributes or geometry. A layer file primarily stores the symbology for a feature and other layer properties related to what is seen when the data is viewed in a GIS application.

            For example, if a layer file is sent to a user on another machine without the data it was created from, it does not display on the map because it does not contain the source data. To get the data to display properly, the user must have the layer file and the shapefile it references.

            This is where utilizing layer packages eases the processing of migrating data, because layer packages store both the layer file and source data. Refer to ArcMap: Creating a layer package for more information about layer packages.


            ArcGIS Enterprise and ArcGIS Online differences

            While there are similarities between the two products, there are also differences in how they are deployed and the set of features and capabilities available.

            Infrastructure, installation, and deployment

            ArcGIS Online is Esri 's highly scalable software-as-a-service (SaaS) offering. It is hosted on Esri servers and completely scaled, managed, updated, and maintained by Esri . Because Esri controls the update schedule, users are not responsible for upgrading or patching the system themselves. What is current in ArcGIS Online is always current for any user around the world. As your usage and data needs scale, ArcGIS Online dynamically scales with you without the need for you to provision additional servers or infrastructure, though additional data stores are available to you if required. With ArcGIS Online , all you need is an organizational subscription and you are ready to go.

            ArcGIS Enterprise is software that is installed on infrastructure you control and manage, whether in the cloud, on-premises, or on virtual machines. This allows you to design a highly customized system that meets your organization's business needs and service level agreements. You can choose to deploy all ArcGIS Enterprise components on one machine or scale out to many machines. High availability and disaster recovery strategies are supported, as well as deployments that are completely disconnected from the internet. With ArcGIS Enterprise , you have complete control over your system, whether that is when to patch the system or when to upgrade to the next version of the software.

            ArcGIS Enterprise typically has one to two releases per year, whereas ArcGIS Online typically updates four times a year. Though ArcGIS Enterprise does not include all features and functionality that ArcGIS Online has and vice versa, you can typically expect to see most ArcGIS Online features within the ArcGIS Enterprise portal in the next few ArcGIS Enterprise releases following an ArcGIS Online update.

            Features and capabilities

            While both products enable foundational mapping and location workflows, there are some differences in what advanced, or additional, capabilities are available. You can extend ArcGIS Enterprise through the use of capability-based server roles: GIS Server , Image Server, Mission Server , GeoAnalytics Server , Notebook Server , and GeoEvent Server . Each of these roles provides unique capabilities such as image and raster processing and analysis, tabular big data analysis, data science and real-time data alerting, processing, and archiving. Future updates to ArcGIS Online will provide similar capabilities in some of these areas.

            A key differentiator between the two products is that ArcGIS Enterprise can connect to user-managed data stores, whether cloud storage, folders, or databases. Users can reference the data in place from within these stores when publishing datasets that can be viewed and used on the web. This allows you to bring your own storage and integrate with data there, while also using data storage provided by ArcGIS Enterprise (via ArcGIS Data Store ). In ArcGIS Online , all data is hosted by the ArcGIS Online system. To store data in ArcGIS Online that originated in, for example, a relational database, you must copy the data to ArcGIS Online , or use distributed collaboration to share data from ArcGIS Enterprise to ArcGIS Online .

            Using ArcGIS Enterprise , users can publish additional types of services such as geocode services and geoprocessing services that you can use throughout your ArcGIS Enterprise environment.

            Lastly, both ArcGIS Online and ArcGIS Enterprise support organization-specific logins via SAML and OpenID Connect to streamline authentication between systems. However, ArcGIS Enterprise provides additional security and authentication options through web-tier authentication, Active Directory, and more.


            FAQ: Projection Basics: What the GIS professional needs to know

            The following concepts are fundamental to understanding the use of map projections in ArcGIS. Please note though that the topic of projections is extremely broad, and this article can do no more than touch on a few important topics.

            1. Coordinate systems, also known as map projections, are arbitrary designations for spatial data. Their purpose is to provide a common basis for communication about a particular place or area on the earth's surface. The most critical issue in dealing with map projections is knowing what the projection is and having the correct coordinate system information associated with a dataset.
            2. When the first map projections were devised, it was assumed, incorrectly, that the earth was flat. Later the assumption was revised, and the earth was assumed to be a perfect sphere. In the 18th century, people began to realize that the earth was not perfectly round. This was the beginning of the concept of the cartographic spheroid.
            3. To more accurately represent locations on the earth's surface, map makers studied the shape of the earth (geodesy) and created the concept of the spheroid. Then geographic coordinate systems (GCS) were devised, which include a datum, units of measure, and a prime meridian. A datum links a spheroid to a particular portion of the earth's surface. Recent datums are designed to fit the entire earth's surface well.
            4. The most commonly used datums in North America are:
              • NAD 1927 (North American Datum 1927) using the Clarke 1866 spheroid
              • NAD 1983 (North American Datum 1983) using the GRS 1980 spheroid
              • WGS 1984 (World Geodetic Survey 1984) using the WGS 1984 spheroid

            Newer spheroids are developed from satellite measurements and are more accurate than those developed by Clarke in 1866.
            The terms 'geographic coordinate system' and 'datum' are used interchangeably, but as noted above, a GCS includes a datum, spheroid, units of measure and a prime meridian.

            1. The coordinates for data change depending on the datum and spheroid on which those coordinates are based, even if they are using the same map projection and parameters.

            For example, the geographic coordinates below are for a single point located within the city of Bellingham, Washington, using 3 different datums:

            1. A principle of good data management is to obtain the projection parameters from the data source providing the data. Do not make an educated guess about the projection of data, because an inaccurate GIS database will be the result. The necessary parameters are the following:
            • Projection
            • Units of measure
            • ZONE (for UTM)
            • FIPS zone (for State Plane)
            • Datum

            Other parameters may be required, depending on the projection. For example, Albers and Lambert projections require the following parameters:

            • 1st standard parallel, in degrees, minutes and seconds (DMS)
            • 2nd standard parallel (DMS)
            • Central meridian (DMS)
            • Latitude of projections origin (DMS)
            • False easting and units of measure
            • False northing and units of measure
            • X-shift and units of measure
            • Y-shift and units of measure
            1. Projections can be defined for data using the following options:

            ArcInfo Workstation - All versions
            Use the PROJECTDEFINE command to define the projection parameters for coverages, grids, and tins.

            ArcGIS 9.x, 10.x - ArcInfo only
            ArcToolBox > Coverage Tools > Data Management > Projections > Define Projection tool

            ArcGIS 8.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections > Define Projection Wizard (shapefiles, geodatabase)

            ArcGIS 9.x, 10.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections and Transformations > Define Projection tool

            Geodatabase Feature Dataset/Feature Class:

            ArcGIS 8.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections > Define Projection Wizard (shapefiles, geodatabase)

            ArcGIS 9.x, 10.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections and Transformations > Define Projection tool

            1. If the data has a projection definition, but the projection does not match the typical projection used by an organization, re-project the data.

            ArcInfo Workstation - All versions
            Use the PROJECT command to project coverages and grids to new coordinate systems.

            ArcGIS 8.x - ArcInfo only
            ArcToolBox > Data Management Tools > Projections > Projection Wizard (coverages, grids)

            ArcGIS 9.x, 10.x - ArcInfo only
            ArcToolBox > Coverage Tools > Data Management > Projections > Project tool.

            ArcGIS 8.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections > Project Wizard (shapefiles, geodatabase)

            ArcGIS 9.x, 10.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections and Transformations > Feature > Project OR Batch Project

            Geodatabase Feature Dataset/Feature Class:

            ArcGIS 8.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections > Project Wizard (shapefiles, geodatabase)

            ArcGIS 9.x, 10.x - ArcInfo, ArcEditor and ArcView
            ArcToolBox > Data Management Tools > Projections and Transformations > Feature > Project OR Batch Project


            What is GIS ESRI?

            zriː/ Environmental Systems Research Institute) is an international supplier of geographic information system (GIS) software, web GIS and geodatabase management applications.

            Likewise, what is the purpose of GIS? A geographic information system (GIS) is a computer system for capturing, storing, checking, and displaying data related to positions on Earth's surface. By relating seemingly unrelated data, GIS can help individuals and organizations better understand spatial patterns and relationships.

            One may also ask, what is GIS ESRI video?

            Geographic information systems (GIS) technology is a computerized framework for gathering, managing, and analyzing data.

            What is the difference between GIS and ArcGIS?

            Web mapping is easy in ArcGIS. Cartographers send data to the web via ArcGIS Online. QGIS Server provides a web map service (WMS). The WMS uses the same libraries as the Quantum GIS (QGIS) desktop application.


            Watch the video: ArcGIS - Converting a geodatabase to shapefiles