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.
To fit into this documentation, illustrations show a small Manifold desktop, with only a few panes, docked to the right side. In real life we use a much larger Manifold desktop, and more panes would be turned on, with panes docked to the left or to the right, or undocked, as we prefer. Right-click a pane's tab to change where it is docked. Manifold will remember that new arrangement for our next session.
We launch Manifold.
To import a shapefile we choose File - Import
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.
Double-click on the file with the .shp extension, in this case mexico.shp. Alternately, we could just click that file to highlight it and load it into the File name box and then press the Import button.
The shapefile imports into the system, creating a new drawing and the drawing's table in the project.
We open the drawing by double-clicking on the mexico drawing in the project pane. With the mouse cursor positioned within Durango province we note a nonsensical set of coordinates is reported in the Location display in the lower right corner of the Manifold desktop, as well as a nonsensical Scale value.
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 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. The nonsensical coordinates in the lower right hand corner Location display are also a tip-off that the coordinate system is incorrect.
In the Info 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.
We click on the coordinate system picker button in the Info pane. We know (see the Notes below) that this particular shapefile uses Latitude / Longitude projection so that is what we want to assign.
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 several choices:
Choose one of the listed favorites - By default, Manifold always provides Latitude / Longitude and Pseudo-Mercator as default favorite coordinate systems. If other coordinate systems have been added to our favorites, those also will appear in the list as well for one-click convenience.
More - This launches the full Coordinate System dialog to enable choosing any one of thousands of coordinate systems.
Favorites - Launch the Favorites dialog to enable us to add a new favorite if we like. This is a convenience that allows us to right away add another coordinate system that we know we will want as a favorite.
Paste options - If we have previously copied a coordinate system to the Clipboard from another component and we would like to use it for this drawing, we can Paste it. This is a great convenience when importing images or drawings that all have the same projection: We assign the correct projection to one, and then we can simply Copy that and Paste it into the others.
The coordinate system we want to assign, Latitude / Longitude, is one of the factory default Favorites so we click on that. Done!
The Info 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.
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.
How can we confirm if a shapefile's initial projection was correctly set? - Easy. Create a map that uses an image server like Google or Bing as a background layer and that includes the mexico drawing as a layer. If Mexico 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.
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 Manifold 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.
Manifold 9 - Re-Project a Shapefile - New coordinate system dialogs make it easier than ever to re-project data, often in only one click. This video shows how to import a shapefile and then rapidly re-project it into different coordinate systems. We then show how maps re-project their contents on the fly for display and how to exploit that to rapidly show data in different projections.
File - Export
Assign Initial Coordinate System
Example: Import Shapefile and Create a Map - Step by step process to import a shapefile and to create a map.
Example: Reproject a Drawing - An essential example on changing the projection of a drawing, either within the drawing itself, or by changing the projection of a map window that shows the drawing and on the fly reprojects the drawing for display.
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