ESRI's .shp format, also known as "shape format" or "shapefiles," is used with ArcView, a popular GIS package of the early 1990's. Shape format has been openly published by ESRI and is widely used for data interchange in GIS. Shapefiles usually consist of three similarly named files with differing extensions: a .shp, .shx and a .dbf file. The .dbf file is a dBase database system format file that is used to store data attributes for the drawing.
When Manifold exports to "shp" format it creates three files: a .dbf, a .shp and a .shx file. These work fine in all applications that can read "shapefiles" correctly. When providing the result of your export to shapefiles to someone else, don't forget to provide all three files and not just the .shp file. Because shapefiles cannot contain a mixture of areas, lines and points, when a drawing that contains a mix of areas, lines and points is exported to shapefile format Manifold must create shapefiles for the areas, shapefiles for the lines and shapefiles for the points.
When exporting drawings containing objects of only one type (only areas or only lines or only points) to shapefiles no postfixes will be appended to the filename. When drawings contain more than one type of object, Manifold will add "a," "l" and "p" postfixes to the filenames to indicate which shapefiles contain areas, lines and points.
Drawings exported as shapefiles should contain at least one data column in the drawing's table to avoid confusing unsophisticated shapefile-reading software. If there are no columns in the drawing's table or if we deselect all fields when exporting, then exporting the drawing as a shapefile will result in "shapefiles" that do not have a .dbf file. This may confuse some third-party software packages that do not understand how to read shapefiles with no .dbf files. Attempting to export a shapefile with no data columns will display a confirmation message warning of this risk that asks user to press Yes to continue.
To export a drawing to .shp format:
1. Open the drawing in a drawing window.
2. Choose File - Export - Drawing from the main menu.
3. In the Export dialog choose SHP Files in the Save as type box and specify a filename to use. Press Save.
4. Check the fields that are to be exported. Buttons provide for Select All, Select None and Select Inverse to rapidly change which fields are to be exported for drawings containing many fields.
5. Press OK.
Select All - Check all fields. All data fields in the drawing will be exported.
Select None - Uncheck all fields. No data fields will be exported. Tech tip: Use this to uncheck all fields before checking those desired.
Select Inverse - Uncheck all previously checked fields and check all previously unchecked fields. This is a fast way to check only a few columns out of many: uncheck those desired and then push Select Inverse.
Shapefiles as most commonly occur do not save projection information. Recent extensions to ArcView allow the saving of projected data in additional files; however, most shapefiles that are published do not use this extension. Shape format is therefore best used to interchange data from unprojected drawings using degrees as the unit of measure. For maximum compatibility with other GIS applications it is strongly recommended that only drawings in Latitude / Longitude projection be saved to .shp format. To do this, before exporting the drawing use Edit - Change Projection to re-project the drawing into Latitude / Longitude projection if it is in a different projection.
The formal .shp specification includes use of dBase .dbf format. In Microsoft Windows operating systems, most applications use Microsoft drivers to read and write the .dbf part of shapefiles. Windows .dbf drivers normally support standard dBase format, which has a variety of legacy limitations. For example, .dbf files (and thus any shapefiles) should have have "8.3" style names, where the base name is at most eight characters, followed by a .shp, .shx, or .dbf extension. In addition, field names used within a shapefile should not be no more than eight alphanumeric characters not beginning with a number.
Because Manifold and most other modern GIS software allows field names to be longer than eight characters and use special characters as well, it is a frequent occurrence that field names used within Manifold are too long or complex for use within shapefiles that are truly compliant with the .dbf standard used in Windows. Such field names should be renamed before export to .shp format is accomplished.
We realize that many users of shape files will rename files to longer than eight characters and also use field names greater than eight characters. This occurs especially often in UNIX environments where programs will at times use .dbf file drivers that are not consistent with dBase specification in that they relax the naming conventions used by dBase. However, writing to longer file names and using longer field names is a violation of the .dbf spec and may well cause failed interchange with other software that takes the spec seriously.
Because so many ESRI applications, both in UNIX and in Windows, do not respect Windows standards for .dbf, Manifold System does not use Microsoft drivers to read / write .dbf files when importing or exporting shapefiles. Instead, a custom set of Manifold drivers are used that accept nonstandard file and field names. In addition, the Manifold drivers will allow writing of long file and field names that violate the dBase standard but which are acceptable to various ESRI applications.
Manifold's shapefile export will preserve data types consistent with .dbf practice whenever possible. Variable-length text data is exported as fixed-length text with 254 characters (since ArcExplorer 2.x and some other programs do not seem to be able to handle memo fields).
Exporting a .dbf file (either by exporting a table as a .dbf or by exporting a drawing as a shapefile) will set the .dbf codepage field to the codepage used by the columns in the exported table. If the columns use conflicting codepages or if the codepage is not supported by .dbf format, Manifold will display a warning message.
Importing a .dbf file (either by importing a table from a .dbf or by importing a drawing from a shapefile) sets the codepage of each text column to that used in the .dbf file.
Exporting Projected Shapefiles
Because .shp format does not capture projection information it is unwise to export projected drawings into .shp format. However, if for some reason we absolutely must export projected data we should keep in mind the raw nature of data in projected form and the options used to represent locations in projected coordinate systems.
For example, suppose we have a drawing in some metric projection that uses local offsets of 100, 100 and local scales of 10, 10. Suppose we have a point the coordinates of which are 1, 2 in this coordinate system. When exporting this drawing as a .shp, sometimes we may want the coordinate numbers locating the point in the .shp file to be 1, 2 and sometimes 110, 120.
The Manifold .shp exporter does not transform the coordinate numbers in any way, so Manifold will always export 1, 2 for the coordinates of the point. If desired, we can force Manifold to export 110, 120 by first re-projecting the drawing into the coordinate system using local offsets of 0 and local scales of 1.
Exporting a PRJ File
To create a PRJ file to accompany the shapefiles for those software packages that can use ESRI PRJ files, use the Edit - Change Projection dialog's toolbar to save the coordinate information into a PRJ file. Name the file using the same name as the other shapefiles with the extension .prj.
It is tempting to use Manifold as a format converter, for example, to import from MapInfo .mif format and to save as .shp. However, since MapInfo like Manifold also allows longer file and field names than does .shp format it is very easy to import files that already contain field names or use file names incompatible with export to .shp. Such names must be renamed to fit into the limitations of .shp format before export.
If the results of .shp export from Manifold cannot be read by your .shp reading application, check the following:
Are all filenames in the "8+3" form? If not simplify the file names. Your application may not be able to handle long file names.
Are all field names no more than eight, simple alphanumeric (letters and numbers only) and not beginning with a number?
Have you used only simple database types (integers, fixed length text, etc.) for data attributes? Your application might not be able to recognize more sophisticated data types such as dates.
Edit - Change Projection