Example: Import a Shapefile

ESRI shapefiles are a very popular format for publishing GIS and other spatial data.   They are usually easy to import.    Unfortunately, shapefiles sometimes will not specify what coordinate system, that is, what projection should be used.  This example shows how to deal with that quickly and easily.   Manifold uses the terms "projection" and "coordinate system" as interchangeable synonyms.

 

We launch Manifold.

 

eg_import_shape01_01.png

 

To import a shapefile we choose File - Import

 

eg_import_shape01_02.png

 

In the Import dialog we browse into the folder holding our shapefiles.   

 

A "shapefile" is not just one file but usually at least three files, such as the mexico.dbf, mexico.shp, and mexico.shx files seen above.   Shapefiles often include a fourth file ending in a .prj extension that specifies what projection (coordinate system) should be used for the data contained in the shapefile.    If a shapefile includes the .prj file, Radian will use it to set the initial coordinate system for the drawing.  However, very frequently we will encounter shapefiles that do not have a .prj file, like the set of shapefiles seen above.

 

Click on the file with the .shp extension, in this case mexico.shp, and then press the Open button.

 

eg_import_shape01_03.png

 

The shapefile imports into the system, creating a new drawing and the drawing's table in the project.  

 

eg_import_shape01_04.png

 

We open the drawing by double-clicking on the mexico drawing in the project pane.  

Assigning the Initial Coordinate System

Since there was no .prj file in the shapefile ensemble we know we must assign the initial coordinate system manually.    If there had been a .prj file in this shapefile ensemble we would be done, because the system would have automatically utilized the specified coordinate system.  But since there is no .prj file we must undertake the extra step of specifying the coordinate system information that the shapefile fails to provide.

 

tech_tina_sm.png

Tech Tip:  The system will assign the default WGS 84 / Pseudo-Mercator (EPSG:3857) projection as a placeholder to any file imported from a format that does not specify the initial coordinate system, but it is highly unlikely that this particular shapefile uses that projection.    We must specify the initial projection to whatever the data actually uses.   If we fail to do that, the drawing may look OK as seen in the illustration above, but it will not be correctly georegistered.   It will not give accurate measurements and it may appear wildly wrong, or not appear at all, when added to a map as a layer where other layers are correctly imported components.

 

 

eg_import_shape01_05.png

 

In the Contents pane we see by the red text in the coordinate system read-out for the mexico layer that Manifold is warning us the originating format of that drawing did not assign an initial coordinate system.

 

btn_coord_sys_picker.png We click on the coordinate system picker button in the Contents pane. We know (see the Notes below) that this particular shapefile uses Latitude / Longitude projection so that is what we want to assign.  

 

eg_import_shape01_06.png

Because the mexico drawing was brought into the project without a coordinate system being specified, Manifold only allows one action, assigning the initial coordinate system.  Choosing Assign Initial Coordinate System unfolds a menu that allows one of three choices:

 

 

 

 

The coordinate system we want to assign, Latitude / Longitude, is one of the factory default Favorites so we click on that.   Done!

 

eg_import_shape01_07.png

 

The Contents pane now displays the coordinate system for the mexico layer in black text, meaning the initial coordinate system has been assigned.

 

With the initial projection correctly assigned the drawing does not change appearance in the display window, but it is now correctly georeferenced and can participate without error in any maps with other components or be used in any subsequent workflow.  If we position the cursor over the drawing, say, over the province of Durango as seen above, the status bar readout for cursor position is exactly accurate as we would expect.

Notes

How did we know to specify Latitude / Longitude? - We cheated.   Because we created this shapefile in Latitude / Longitude we knew that is what it used.   In real life, when importing from a shapefile that does not include a .prj file and there is no other information to go on, Latitude / Longitude is usually a good first guess.   But it is just a guess.   

 

The standard Latitude / Longitude coordinate system in Radian uses WGS 84, which is the most frequently encountered datum in data that uses Latitude / Longitude projections, but it is not the only datum. Various NAD and other datums are also used with Latitude / Longitude.   Using WGS 84 as does the standard Latitude / Longitude projection will get us close in many countries, usually within a few tens of meters in accuracy, even if the actual datum is different.  

 

Shapefiles unaccompanied by .prj files can, and often will, use projections other than Latitude / Longitude.  Unfortunately, some people publish shapefiles that contain projected data without taking care to either provide a .prj file or to provide a note on their website what projection is used.  Sometimes it is possible to find metadata files that specify what projection is used but sometimes more detective work is required to discover what projection a given shapefile uses.

 

eg_import_shape01_08.png

 

How can we confirm if a shapefile's initial projection was correctly set? - Easy.   Create a new data source that is an imageserver like Google or Bing.  Create a map and add that imageserver image as a layer.  Next, after we specify what we think is the correct initial projection using the procedure in this topic, drag and drop the shapefile drawing into the map.  If it lines up where it is supposed to be, we know the projection specified is probably correct.     

 

For example,  the illustration above shows a Bing image server image in a map with the mexico drawing dragged and dropped into the map as a layer.  It is obviously in the right location.    If the initial projection was not correctly specified then the mexico drawing might not have appeared at all.    For a more appealing presentation we have also used Style to color the provinces of Mexico.

 

In that case, we could right-click onto the mexico layer and choose Zoom to zoom to that layer.  If the drawing appears, we could then try zooming out to see where the drawing has been placed on the world map shown by Bing.  For example, if the mexico drawing was placed into a microscopic region off the coast of Africa we know the initial projection was wrongly specified.

 

Why doesn't Radian use Latitude / Longitude as a default?  - Older GIS systems often use Latitude / Longitude projection as a default or placeholder coordinate system when importing from formats that do not provide projection information.   The reasoning usually is that for shapefiles unaccompanied by .prj files or other very old formats that do not store coordinate information, the use of Latitude / Longitude at least provides a fair guess when there is no indication what the correct projection should be.   That's not a bad line of reasoning, but it has some flaws.

 

The biggest flaw is that if an undocumented data set is in some format other than Latitude / Longitude but the system assumes it is in Latitude / Longitude there can be catastrophically wild effects when that data set is displayed with correct data.    In contrast, if the undocumented data set is in Latitude / Longitude but the system assigns it pseudo-Mercator there is less visual confusion: the drawing appears as a dot off the coast of Africa and it is immediately obvious what the problem is and how to fix it quickly.

 

As GIS and GIS data formats get more modern over the years, there is less need manually to specify an initial coordinate system because data will most of the time be imported with correct projection automatically.   Therefore, more modern GIS systems prioritize setup for modern work flows, like collaborative use of web servers such as Google, Bing, OSM and Arc Online REST servers, all of which use pseudo-Mercator.  That is why the most recent GIS tools such as Manifold, Radian Studio, OSM or the latest Arc versions all use pseudo-Mercator, the web standard, as the default.

 

A final issue is that as GIS packages become more modern and GIS users become more expert, the use of Latitude / Longitude as the classic first choice for beginners and technically weak GIS software is going away.   

 

Latitude / Longitude is an absolutely terrible projection to use for many reasons, not the least of which is that the unit of measure applied, degrees, constantly varies.   Measurements using Latitude / Longitude are like trying to build a house using a measuring tape on which a meter or a yard magically expands from the width of a hand to the size of the whole house as you move from room to room.  That is just crazy, so most people rapidly move away from Latitude / Longitude as they gain the spatial expertise to use better projections.

 

The result is that fewer and fewer people publish data in Latitude / Longitude, or at least fewer people do so without explicitly stating the data is in Latitude / Longitude.   

 

See Also

File - Export

 

Assign Initial Coordinate System

 

Change Coordinate System

 

SHP, Shapefiles

 

Example: Edit a Shapefile In Place - How to edit a shapefile "in place," that is, leaving the data in the shapefile and only linking it into a project and not importing it into the project.

 

Latitude and Longitude are Not Enough

 

Shapefiles Strangely Out of Shape

 

Three Letter Extensions