Drawings provide a visual display of vector data stored in a table. A drawing window is just a viewport that displays vector data from the table in visual form: all of the data is stored as records in the table the drawing uses. Vector data is a sequence of coordinates, called a path, together with a bit of extra information that says how to use that path to draw areas, lines or points. Points, lines, and areas in drawings are called objects. Some GIS packages refer to objects as features or shapes.
Drawings take virtually zero storage
space: the drawing's table stores all the data. A drawing just has
a few bytes in it that specify the table the drawing should use, what
field in that table contains geometry, and how the drawing should display
the data it fetches from the table. All the actual data for objects
and their attributes is stored in the table. As we pan and zoom
in a drawing window, the drawing fetches from the table whatever
data it needs to draw the display. We can create as many drawings
as we like that all visualize data from the same
table, using different styles for each such drawing, without making the
project's .map file any bigger.
Drawings are made up of points, lines, and areas. The drawing seen above has buildings drawn using areas, footpaths and roads drawn using lines, and individual locations of interest drawn using points. The points, lines, and areas in the drawing have been Styled using varying colors and symbology, for example, blue star symbols for the points.
See the Editing Drawings topic to learn how to create new points, lines, and areas in a drawing, and how to modify existing objects.
What Manifold calls points, lines and areas, other GIS systems may call points, polylines or arcs, and polygons.
The figures in drawings, be they points, lines or areas, are called objects in Manifold. Other GIS systems, especially ESRI, may call them features, and ESRI GIS systems may refer to a drawing as a feature class. Feature is such a widespread word that Manifold people and even this documentation will sometimes use it instead of "object" in casual discussion. Older terminology for objects is shapes, hence the name shapefiles for the decades old GIS format used to store vector data.
When Manifold uses the word "object" to mean a point, a line, or an area, that is just a generic word like "item" or "thing," and has no special technical meaning like the word object has in object-oriented programming.
Objects in drawings have data associated with them, called attributes, in most GIS systems. Attributes are just fields in the drawing's table. Manifold uses the words fields and attributes as synonyms.
By GIS industry tradition, the data that appears in drawings is called vector data, even though usually the data is not what a mathematician or physicist would call a vector. The vector word is a useful way to distinguish the geometric data found in drawings from the raster data found in images.
Objects are defined by the X, Y, and Z coordinates which specify how to draw the objects in a "connect the dots" fashion in a path. Points usually are just one coordinate (a very simple path), lines are a list of coordinates that form the path, and areas usually are one or more lists of coordinates, that is, one or more paths, that draw the boundary of the area along with the boundaries of any holes within the area.
To refer to the coordinate locations that define objects, Manifold slang has been to call the locations coordinates as well, as in, "a line usually consists of straight line segments between the coordinates that define the line." Other GIS systems will often refer to such locations as nodes, as vertices or as inflection points. Vertex seems to be taking off as a popular term, so much so that this documentation often uses vertex as a synonym for coordinate location.
Each point, line, or area is a record in a table from which the drawing draws data. Each such record has at least one geometry field that specifies the location and shape of the point, line or area, and each such record may in addition have other fields that provide additional data for each object. Such other fields are often called attributes in GIS jargon. Attribute is such a popular word that Manifold people and this documentation will often use it.
A short-hand way of saying "the coordinates needed to draw the object" is to say "the object's geometry". The field that contains the geometry data for the object is called the geometry field. By field values we usually mean the contents of any of the fields in the table, which could be geometry data or data in any of the other fields.
Drawings in Manifold can contain a mix of points, lines and areas within the same drawing. Older GIS systems will often limit drawings to containing only one object type, such as all points, or all lines, or all areas, but not a mix of points, lines and areas.
In Manifold, points, lines and areas can have multiple branches, what some GIS systems may call multipoints, multilines or multipolygons. Lines and areas can be created from straight segments, from curved segments such as splines, or using a mix of straight and curved segments.
When drawings contain a mix of points, lines, and areas, the areas will be rendered first, with lines rendered above the areas, and points rendered above both lines and areas.
For each object it draws, a drawing takes data from a geometry field for that object's record in the table. Manifold has built-in data types for geometry data that enable compact, high performance storage of geometry data. The geometry field is usually a geom data type, the native data type for geometry, which can handle up to 2GB of coordinates within a single object, enabling drawings to handle even very complex, very large objects that require billions of coordinates to draw. Manifold also has means to quickly convert popular data types used by other GIS packages to store geometry data into high speed forms Manifold uses internally.
More than one drawing simultaneously can display data from the same field in the same table, with each drawing using different formatting. That allows us to show the same data in different visualizations.
We can Copy a drawing and Paste to create another drawing that shows the same data from the same table. We can then Style that drawing to use totally different colors and symbology. Any such extra copies of drawings we create will not increase the size of the project, because the data they all show will be taken from the same table. Making copies of a drawing is a great way to get different versions of the same drawing, with different thematic formatting and different symbology.
A table can contain more than one geometry field for each record. That allows us to have multiple different representations of each record.
For example, a table of provinces in a country might have one geometry field that contains an area for the province, a second geometry field that shows a centroid point for the area, and a third that contains some dynamically computed geometry, such as the bounding box, of the area. Three different drawings can simultaneously show data from each of the three different fields in the same table. If the record is selected in the table or in any of those drawings, the objects from the different geometry fields for that same record will also be selected.
Drawings are just a different way to display geometry data that is stored in a table: a drawing will be empty without a table somewhere that has a geom field from which the drawing draws the information it displays. The drawing component contains just a few bytes of data, which we can see in the drawing's Properties, that specify which table stores the data to be visualized, what field in that table contains the geometry data the drawing should display, and, if specified, the coordinate system used by that geometry. All of the actual geometry data is stored in the table.
If we want to copy a drawing and paste
it into a different Manifold project, we must remember to copy both
the drawing as well as the table
from which the drawing displays data.
To learn how to see data in drawings and to edit drawings, see the Editing Drawings topic.
Although most often drawings in our projects will result from importing or linking files or data sources which automatically create drawings, we can also create new drawings if we like.
We can create a new, blank drawing and then add points, lines and areas to that drawing. We might do that by tracing over something visible, such as a road or building, in an image server layer as shown in the Example: An Imageserver Tutorial topic. We can copy and paste objects from other drawings as well.
We can also create new drawings from tables that have geometry in the table, or from queries that report a geometry field in their results table.
To create a new drawing from scratch, use File - Create - New Drawing.
To change the structure (add a field, delete a field, etc. ) of a drawing's table, use the Schema dialog.
To add, delete, or edit objects in a drawing, see the Editing Drawings topic.
We can modify drawings with queries and edit the contents using the Transform pane.
The Edit - Merge dialog can combine multiple drawings into one drawing.
When connecting to external data sources, Manifold can create virtual drawings that are not in the data source but which seem to be there, allowing us to use Manifold paradigms even within an external data source. See the Real and Virtual Components topic for a discussion.
Choose File - Create - New Drawing, or use the context menu in the Project pane.
Specify a Name for the new drawing.
Choose a coordinate system if the default is not desired.
Press Create Drawing.
A new drawing and the drawing's table will appear in the Project pane.
Drawings show the contents of geometry data in a table. Creating a new drawing automatically creates a new table as well, using the drawing's name with the word Table appended.
By default, new drawings are created using the EPSG:3857 Pseudo-Mercator coordinate system, as used by almost all modern web mapping data sources. A drawing can be re-projected into a different coordinate system. See the Reproject Component topic.
Right-click on the table in the Project pane.
Choose Create - New Drawing.
Choose the Geometry field to use if there is more than one in the table.
Check the box to create a spatial index if one does not yet exist.
Assign the correct coordinate system if the coordinate system is reported in red text.
Press Create Drawing.
We can create a drawing from a table if the table contains a geometry field with data in one of the data types supported for vector geometry.
Right-click on the query in the Project pane.
Choose Create - New Drawing.
Choose the Geometry field to use if there is more than one in the table.
Assign the correct coordinate system if the coordinate system is reported in red text.
Press Create Drawing.
Drawings created from queries will appear only when used as a layer in a map that contains at least one other layer.
To update the drawing after any changes in source table data, choose View - Refresh.
We can create a drawing from a query if the query's results table contains a geometry field with data in one of the data types supported for vector geometry. The query must also report a schema if we right click on the query in the Project pane and choose Schema. The source table for the geometry field reported in the result table should have a spatial index on that geometry field. If the query text is changed, we must run the query at least once after changing the text, so that any future refreshes of the drawing will use the new query text.
We can also create a drawing from a database view that provides a result table with geometry information.
Drawings can have layers, Just like a map, When we open a drawing it has one layer, the drawing's own layer. If we like, we can drag and drop other drawings, labels or images. into the map as additional layers.
Unlike the permanent layers in a map, any layers added to a drawing window are temporary layers. Such temporary layers are lost when the drawing is closed. To permanently save a drawing with a layer structure, save the drawing as a map using the Edit - Save as Map command.
For example, if we add a web server layer to a drawing as a background layer, if we close the drawing and then open it again the additional layer will not be there. If after adding some layers we like the visual effect or usefulness of having additional layers, wit a click or two we can quickly save the drawing as a map using Edit - Save as Map.
A drawing window always contains the originating drawing as a layer, and the drawing window will always use whatever projection the drawing uses. If we change the coordinate system of the drawing, the drawing window will automatically use that different coordinate system as well. If any other layer is added to a drawing window, the drawing window will re-project that layer on the fly into the coordinate system used by the drawing and the drawing window.
Open the drawing by double-clicking it in the Project pane.
The drawing will appear as the only layer in the drawing window. The drawing window will use the projection of the drawing.
Drag and drop any additional desired layers from the Project pane into the drawing.
The drawing window will automatically re-project on the fly all layers into the coordinate system used by the drawing.
Rearrange layers by dragging their tabs left or right, or by using the Layers pane.
Layers in a drawing window are temporary. To save the layer arrangement, use Edit - Save as Map.
There are three key differences between layers in a map and layers in a drawing:
Layers and background
colors in drawing windows are temporary: When we add layers
to a drawing and then arrange those layers in order, if we close the drawing
and then open it again those layers will be gone. Likewise, if we use
the Layers
pane to change the background color for a drawing, that change is temporary.
If we close the drawing and open it again, the background
color will be reset to white.
To save changes in background color or any temporary layer structure added to a drawing, choose Edit - Save as Map. That will save any changes to background color and any extra layers together as a map. Maps take zero space since they do not store any data: they are simply references to other components that are the constituent layers of the map. Therefore, never hesitate to ever use Edit - Save as Map to save any useful layers added to a drawing window.
Most drawings we use will be drawings created automatically when we import or link vector data from files or data sources that contain drawings. Such drawings will normally be imported using default formatting. We can use Style to change their appearance, use Reproject Component in the Component tab of the Info pane to re-project them into a different coordinate system, and add layers to help understand the drawing better.
Above we see a drawing that was imported from shapefiles extracted from OpenStreetMap. It shows buildings in Monaco as areas, using Latitude / Longitude projection, which results in a slightly vertically squeezed look at the latitude of Monaco. We could improve the appearance of the display by re-projecting the drawing into a coordinate system that provide a distortion-free appearance in the location of Monaco. We have used Style to apply a thematic format, coloring each of the buildings based on the value of a field.
The appearance of points, lines and areas in drawings is controlled by the formatting of that drawing as set by the Style dialog. The background color for all objects is set in Layers. The three illustrations below, using screenshots from a Windows 11 installation of Manifold, show the same drawings as the illustration above, but with default formatting altered by using the Style dialog.
In the above illustration thematic formatting is used to control the Rotation of the point symbols, with thematic formatting also used to specify the background color of areas. Layers Pane was used to set black background color for the drawings.
In the above illustration points are all set to use the same icon and color, with thematic formatting also used to specify the background color of areas. Layers Pane was used to set light beige background color for the drawings.
In the above illustration points are all set to use the same icon and color, area borders are set to use a dotted line style and the same color is used for all areas. The Layers pane was used to set light blue background color.
See the extensive discussion in the Style chapter, as well as numerous examples, such as the Example: Style Pane Quickstart, Example: Change Point Style and the Example: Format a Drawing using the Style Pane topics.
All data in Manifold is kept in tables. A drawing is just a viewport that displays geometry data from a geometry field in the table. Manifold manages that relationship for us automatically in default uses. For more advanced uses, it helps to know how drawings take data from tables.
Drawing windows do not contain any data: they just visualize data from fields in tables based on what the drawing window has been told to show and how it has been told to show it. For example, we can have as many drawings as we want that all show the same data from the same field within a table with each drawing providing a different Style or a different selection.
Drawings are just a different way to see the information that is stored in some table: a drawing cannot exist without a table somewhere that has a geometry field from which it draws the information it displays. The drawing's properties tell it what table to use and what geometry to use within that table.
To see a drawing's properties, right-click on the drawing in the Project pane and choose Properties. A drawing's Table property specifies what table the drawing uses. In the illustration below, the drawing takes data from a table called Provinces Table. A drawing's FieldGeom property specifies what field within that table contains the geometry data the drawing should use. In the illustration below, the drawing takes geometry data from a field called Geom.
All of the data is stored in a table. Geometry data is stored in tables using one of the data types Manifold provides for geometry data. The table's FieldCoordSystem property says what coordinate system is to be used for the geometry field.
In the illustration above, the table has one geometry field in it, called Geom. The table's FieldCoordSystem.Geom property is mostly scrolled out of sight, but if we were to right-click that cell in the table's properties dialog and would choose Edit we could see the entire property in human-readable JSON form. Based on what parts of it are visible it is probably the default Pseudo-Mercator coordinate system.
Putting it all together, In the illustration below the Properties dialog for the Provinces drawing tells the drawing to use the Provinces Table for data and, specifically, to use the geometry field called Geom for the data the drawing will display. The FieldCoordSystem.Geom property for the Provinces Table specifies the coordinate system for the Geom field that the drawing uses, so the drawing knows how to display the geometry data it takes from that field.
The drawing itself contains no data. All the data is within the table, either as ordinary attribute fields like the name of the province or as geometry data needed to draw the area object for each province that is kept in the Geom field.
The properties for a drawing, the table and all other components in the project are also stored in the mfd_meta system table and fully exposed for programmatic or SQL use: they are all records in the mfd_meta table as seen above, where they can be edited if we desire.
See the Example: Drawings use Geom Fields in Tables topic for a discussion of how tables and drawings and properties work together.
More than one drawing can display data from the same table. The drawing does not duplicate the data that is in the table; instead, the drawing just shows the data in the table using whatever are the properties of that particular drawing. For example, two different drawings can show data from the same geometry field in the same table with different style. Two different drawings can use two different geometry fields in the same table.
If we copy a drawing and paste that drawing we are just making a second copy of the "viewport," as it were. We are not making a second copy of the actual data. The data, as always, stays in the table. If we want to make a second copy of the data we should copy and paste the table.
What is a "geom" ? - Manifold users, and this documentation as well, use the word geom as a casual, abbreviated way of saying geometry value. Geometry fields in tables can be one of three data types Manifold provides for geometry in tables: geom, geommfd or geomwkb. The geom data type is by far the most popular since that is Manifold's native geometry type, it is the geometry type used by default when a new drawing is created or imported, and it is the fastest of the three. Almost all of the tables we see in Manifold that provide geometry will use the geom type for their geometry fields. As a result, Manifold users have become accustomed to saying "geom" to refer to any geometry value, including those that might be a geomwkb or geommfd data type.
The actual geom data type is an extremely efficient way to store geometry information. A single geom field contains all the coordinates necessary to represent the object, a point, line or area, for that record. In the case of points the geom stores the X,Y location of that point. In the case of a line or an area, the geom stores a list of all of the coordinates needed to draw the shape of that line or area. The amount of data contained in a single geom field, that is, in a single cell in one record, can be very large: geoms can store up to 2 gigabytes of coordinates within a single geom, that is, within a single cell of a record.
A useful tradition - If there is a geometry field in a table, by default Manifold tables will call that field Geom. The name of a geometry field could be anything, such as "Harry" or "Robert," but calling it "Geom" has the useful effect of automatically telling us what the field is when we see it in a list of fields.
A geometry field in a table stores coordinates for areas, lines or points. We will cover the simple, most common usages first. In addition to the simple way of explaining geometry fields and objects there are complications that are less frequently encountered which we will discuss below under Complications.
In the simple case, each record that has a geom contains the information for one geometric object in that geom. That object can be a point, a line or an area.
Points are just single locations, a single X,Y coordinate pair defining the location. Manifold jargon as used in this documentation refers to "coordinate pairs" as simply coordinates, which saves us from always writing or saying "X, Y coordinate pairs." Another term popular in GIS jargon for such coordinate pairs is vertex. Manifold uses the words "coordinate" and "vertex" as synonyms.
Lines are typically composed of straight line segments between a sequence of coordinates. What appears to be a wiggly line showing the course of a river or a road in a drawing when zoomed in will usually be seen to be a series of straight line segments between a sequence of coordinates. The geom for such a line simply stores the coordinates as a list in the order which defines the line. In the illustrations above we alt-click on the yellow, looped road line to display the coordinates which define it. We then zoom in to the end of the loop to see how what may appear to be a smooth curve when zoomed out in fact consists of straight line segments between the coordinates that define the shape and location of the line.
Lines in GIS data are almost always
composed of straight line segments, but Manifold can also handle lines
that are made up of three types of curved segments as well as straight
line segments. Curved segments in Manifold can be circle
arcs, ellipse arcs, and
spline arcs. Curved
segments are defined by mathematical formula based on a limited number
of anchor points, so they are totally, infinitely smooth. See
the discussion later on in this topic.
Curved segments tend to be rare in GIS data because most GIS packages do not handle curved segments well, if at all. However, they are common in CAD work so they often turn up in data sets imported from CAD packages into GIS. Curved segments also occur in traverses, specifications of lines and areas in surveying and cadastral work.
Areas are typically composed of straight line segments or curved segments that define the boundary of the area. The geom for such an area simply stores the coordinates as a list in the order which defines the boundary, the last coordinate being the same as the first in that it "closes the loop" of the boundary. In the illustrations above we Alt-click on the larger, convoluted area to display the coordinates which define it. We then zoom far in to the dense group of coordinates in the middle of the area to see how even complicated portions of the area are formed by straight area border segments between coordinates.
If we ever want to see the list of actual coordinates that defines an object, we simply Shift-Alt-click that object: the vertexes will appear as blue boxes at each coordinate and the Info pane will automatically open to show a complete list of coordinates.
When points, lines and areas are used together they create cartographic representations such as the map of France seen above, which shows major cities as points and provinces (departments) of France as areas. When areas and lines consist of many thousands of coordinates, despite consisting of straight line segments they can seem very smooth even when zoomed it.
Drawings that show data such as provinces in France are normally imported in finished form from web sites such as the government cartographic bureau of France. A single province may consist of hundreds, or even thousands, of coordinates so it would be tedious to create such drawing manually. However, if desired we can manually add new points, lines or areas to a drawing, perhaps by tracing over a photographic layer as seen in the Example: Trace an Area in a Map over an Image Background topic.
Consider a drawing, called Provinces, that shows provinces (regions) in France as areas.
If we right-click on the Provinces drawing in the Project pane and choose Properties we can see the properties for the drawing.
The properties tell us that the Provinces drawing takes its data from a table called Provinces Table and that within that table it uses a geom field called Geom.
Opening the Provinces table we can see that it does indeed include a field called Geom of type geom. That field contains geom values that encode area objects.
If we right-click on the Provinces Table table in the Project pane and choose Properties we can see the properties for the table.
The FieldCoordSystem.Geom property contains a value starting with a curly left bracket { which is a JSON specification for the coordinate system to be used with the contents of the Geom field.
We can diagram the above relationships as follows:
The drawing's properties tell it which table to use and which field
within that table contains the geom
information for the drawing. The table's properties
specify which coordinate system to use for each geom
type field that is in the table.
Tech Tip: There is nothing magic about using the name Geom for the field which contains geom types. The field could just as easily be called "Harry" or "Geometric Data for Objects" or any other legal field name. Naming the field "Geom" is just a habit for most Manifold users and it is the default name used by Manifold when it creates such fields. Using that name by default is convenient since everybody automatically knows what it is when they see it. It certainly is less confusing than naming the field "Harry".
For additional discussion and examples of how drawings use geom fields in tables, see the Example: Drawings use Geom Fields in Tables topic.
To fit into this documentation,
illustrations show an artificially small Manifold desktop, with only a
few panes,
docked to the right side. In real life we use a much larger
Manifold desktop, and all
panes would be turned on, with some panes docked to the left and others
docked to the right.
Alt-click an object in a drawing to see the attributes (field values) for that object in the Info pane.
We have a drawing called US that is a layer in a map, showing US states that are colored by the dates of their admission as states into the United States. The Counts pane in the Status bar shows more than 48 records because some states are represented by more than one object.
To see the attributes for the states we could open US Table, the table that stores data for the drawing, or we can Alt-click a particular state to see that state's data in the Info pane.
When we pick an object by Alt-clicking it in a drawing, the system automatically switches to the Info pane, loaded with the data for that object's record. The picked object, in this case the state of Wyoming, is indicated by coloring the coordinates that compose it in blue color. Read-only fields and captions, which we cannot change, are shown in gray background color.
If we Alt-click a smaller object, such as a smaller area or a point, Manifold will also draw a box around it to help us see where it is located.
Pressing the Go button on the Info pane's toolbar will zoom to the picked object. See the Info pane topic for more on using the Info pane.
Editing objects in drawings is easy: First, Alt-click the desired object to pick it for display in the Info pane. Next, click the vertex to be moved and drag it to whatever location is desired, using snap modes, if desired, to guide the drag motion to an exact location.
As an example of editing, we will zoom into the Northwest Angle, a section of Minnesota that extends into Canada, well above the 49th parallel that otherwise marks the boundary between the US and Canada.
Zooming into the Northwest Angle, we add a Bing Satellite web server layer as a background layer, and we use the Layers pane to set 50% opacity in the US drawing. That allows us to see how US territory overlaps the local geography of land and lakes.
The Northwest Angle is a portion of land at the tip of a Canadian peninsula that is part of the United States. The odd extension of the US - Canadian border northwards from the 49th parallel captures an isolated portion of the US that is not connected to US territory by land. From the rest of the US, the Northwest Angle can be reached by air, via the Lake of the Woods, or by driving through Canada.
We will edit the US border in the region to assign the Northwest Angle to Canada. We begin by Alt-clicking the Minnesota area to pick it.
Immediately, small boxes appear to mark the coordinates, also called vertices, that define the area. The Info pane automatically pops open to the Values tab, to show the attributes, that is, the field values, for the Minnesota object.
We click any vertex or segment in the object to shift into Move Coordinates editing mode.
Larger boxes mark coordinates in editing modes, and whichever vertex is clicked is shown with an extra-large box to indicate it is the active vertex. The Info pane switches to the Coordinates tab, to allow us to manually edit coordinate values if we like.
We can drag the active vertex to a new location. If we want to drag a different vertex to a new location, we click the vertex desired to make it active, and then we can drag it as we like.
If we like, we can select vertices to apply editing commands to all selected vertices at once. We can use selection commands like those discussed in the Selection topic, for example, drawing a selection box with a Ctrl-drag to select all vertices within.
Selected vertices are shown in dark blue color in the drawing, and with red selection color in the Coordinates list. We press the Delete button in the Info pane's toolbar, all of the selected vertices will be deleted.
The selected vertices are deleted, and the system previews the new area border in blue preview color, drawing a segment between the coordinates that remain. So far, no permanent changes have been made: we see only a preview of what will happen if we commit changes.
We press Update Record to apply the changes. We could also press Ctrl-Enter to apply changes, or right-click into the drawing and choose Save Changes.
If we change our minds about transferring the Northwest Angle to Canada, before we press Update Record we can abandon changes by pressing Ctrl-back, or by right-clicking into the drawing and choosing Undo Changes.
Committing changes alters the area. See the Editing Drawings topic for more info and links to many example topics.
Data in Manifold can use virtually any coordinate system known. In Manifold, the terms projection and coordinate system are synonyms. When Manifold imports a drawing or links to a drawing, Manifold will automatically harvest and use any coordinate system information provided by the drawing's format or by any accompanying, auxiliary files. See the Projections topic.
There are two key tasks for keeping coordinate systems straight:
Drawings show geometry from a geometry field in a table. That table's properties include a FieldCoordSystem property for each geometry field in that table which gives the coordinate system used by the geometry in that field. When the drawing gets geometry from the table, it also knows from the table's FieldCoordSystem property for that geometry field what coordinate system it should use.
When the Info pane reports the coordinate system used by a drawing, it takes that information from the FieldCoordSystem property for the drawing's table. When we use the Info pane to assign the initial coordinate system to a drawing Manifold updates the FieldCoordSystem property in the drawing's table. When we use the Info pane to change the coordinate system of a drawing, Manifold reprojects the geometry data stored in the table and updates the FieldCoordSystem property to the new coordinate system.
Double-clicking a drawing in the Project pane will open that drawing in its own drawing window. When a drawing is opened up in its own drawing window that drawing window always will use the same projection as the drawing itself.
Map windows can use different projections than the layers they include. A map window can show one or more layers at the same time. The first layer dropped into a new, blank map specifies the projection that map will use. If additional layers are dropped into the map and they use different coordinate systems than the map, the map window will automatically re-project those layers on the fly into whatever projection the map uses. The data in those layers will not be changed: simply the view is altered so they are seen as if they had been re-projected into the projection the map users.
For example, if a drawing in Latitude / Longitude is dropped into a map that uses Pseudo-Mercator projection, the drawing will automatically be re-projected on the fly to match the projection of the map. The data in the drawing is not changed and the drawing itself is not re-projected: only the view that is displayed in the map is re-projected on the fly, as necessary, so layers in the map will be georegistered correctly in the projection used by the map window.
Layers in maps are persistent: if we close a map and then open it the same layers will still be in the map. Drawing windows can also have layers other than the drawing for which the drawing window was opened. Drawing windows will also re-project on the fly any other layers into the projection used by that drawing. Layers in drawing windows are temporary. Close the drawing window and then open it again and we will be back to one layer, that of the drawing. If we many layers to a drawing window and we want to save that arrangement, we can do so by choosing Edit - Save as Map.
The Component tab of the Info pane reports the projection of the active window and the active layer in that window.
We can drag and drop an imageserver layer, in this case Bing Streets, into the drawing to serve as a background layer to provide context to the drawing. Right away we see that this particular drawing shows buildings in Monaco. If we have a good eye and we are familiar with Bing we will see that the Bing layer has a distorted look. That is because Bing uses Pseudo-Mercator projection, but when the Bing layer is seen within this drawing's window it is being re-projected on the fly into Latitude / Longitude, which distorts it horizontally. In the above illustration we have also used Style to color the areas in the buildings drawing.
We can create a map and then drag and drop the Bing layer into the map. That will set Bing's projection, Pseudo-Mercator, as the projection for the map window. The map shows the whole world in Bing. In the case of the Bing layer, Pseudo-Mercator is what Bing uses so when it is displayed in a Pseudo-Mercator window it is not distorted. Every other layer that appears in the map window will be shown in Pseudo-Mercator as well.
Next, we drag and drop the buildings drawing into the map, right click on the buildings tab and choose Zoom to zoom the map window to the extent of the buildings drawing. The map now shows the buildings layer as if it had been re-projected from Latitude / Longitude into the Pseudo-Mercator projection that the map window uses.
Zooming in we can better see the colors we have applied using Style.
When we import data from GIS formats used for drawings Manifold automatically will import the data into a table that contains geoms and automatically will create a drawing from that table. If we create or import tables that have geometry fields in them we can create drawings from those tables. For example, we might create geometry in a geocoded table, that is, a table with latitude and longitude fields, and then create a drawing from that table, as shown in the Example: Create a Drawing from a Geocoded Table topic.
Coordinate System / Projection - We must know the coordinate system used within the geometry in the table, which for most tables we can find in the Properties of the table in the FieldCoordSystem.Geom property as a human-readable JSON string. If the table has never been used to create a drawing that property might not be present, in which case we must know what coordinate system is used in the geometry so we can specify it when creating the drawing.
Geometry Data Type - Although drawings in Manifold are normally created from geometry fields in table which are Manifold's own native geom data type, we could also use a geometry field that contained geometry information using the open source geomwkb data type, for example, if we have imported a table containing geomwkb data from some external data source.
To create a drawing from a table we right-click the table in the Project pane and then we choose Create - New Drawing.
The New Drawing dialog suggests a default name for the new drawing based on the name of the table. We can change that as we like. The dialog will load the first Geometry field in the table it finds. We can choose whichever geometry field we prefer if there is more than one. The box next to the Geometry choice reports the data type of that geometry field.
If the table contains a spatial index on the geometry field selected the name of that index will be reported. If it does not contain a spatial index on that geometry field a Create spatial index box will appear that is checked by default. That will automatically add a spatial index to the table for the specified geometry field.
If the table's properties contain a FieldCoordSystem.Geom property that reports the coordinate system used by the chosen geometry field that coordinate system will be reported. If the table has never been used to create a drawing that property might not be present, in which case the coordinate system will be reported in red font, using Pseudo Mercator as a placeholder text, and we must know what coordinate system is used in the geometry so we can specify it by using the coordinate picker button.
We can use SQL to create a drawing from a table that has a geometry field and which also has had an rtree index created on that geometry field. If our table is called MyTable and the geom field is called MyGeom and we want to create a drawing called MyDrawing, the SQL would be
CREATE DRAWING [MyDrawing] (
PROPERTY 'Table' '[MyTable]',
PROPERTY 'FieldGeom' 'MyGeom'
);
If the results table for a query contains a geometry field and the query reports a schema without having to run the query, we can create a drawing from that query. We must know the coordinate system used within the geometry in the table, which we can easily find in the Properties of the table in the FieldCoordSystem.Geom property as a human-readable JSON string. The usual rules which apply to creating drawings from tables also apply to creating drawings from queries. For example, we cannot create a drawing when the query resides within a read-only data source, such as a read-only .map project or a read-only DBMS.
Drawings created from queries can be styled just like other drawings, including the use of thematic formatting based on a field the query reports in the results table. To update a drawing to show any changes in data in tables which the query uses, we must choose View - Refresh to refresh the drawing.
We can change the query text within the query from which a drawing is created. After changing the query text we must run the query at least once to update the system, before choosing View - Refresh for the drawing to update the drawing.
No spatial index? - When creating a drawing from a query, If the table from which the query takes the geom field does not contain a spatial index on the geom field, we will have to use a temporary spatial index every time we open the drawing. However, that would be very unusual as normally tables that contain geom fields will have a spatial index built on that geom field as well, and thus a query which includes the geom field in the results table will also include the spatial index on the geom field as well.
See the Example: Create a Drawing from a Query topic, which duplicates the Drawings from Queries video using the Mexico_queries.mxb sample project that may be downloaded from the Examples page on the Manifold web site.
Geometry values, that is, geoms, can be thee dimensional, 3D, and not just two dimensional, 2D. A classic 2D value is just an X, Y coordinate such as a longitude, latitude coordinate. Points, lines and areas made up of such X, Y coordinates all lie in the same flat plane. In addition to the X and Y values a 3D coordinate adds a height component or Z value to create an X, Y, Z coordinate. Points, lines and areas made up of such X, Y, Z coordinates can form a 3D surface such as the undulations of valleys and mountains.
Geoms in Manifold can be 2D or 3D. 3D geoms have Z data and store a Z component for each coordinate. 3D geometry has the following characteristics:
Any given geom must be either entirely 2D or entirely 3D.
Points, lines and areas can be 2D or 3D.
Just as the first and last coordinates of any branch in a 2D area must be the same, the first and last coordinates of each branch of a 3D area must also be the same, including the Z component.
Just like 2D objects, 3D objects can be constructed of curved segments using circle arcs, ellipse arcs and splines.
Geometry operations which have no explicit support for Z data safely ignore it. That allows us to use 3D geometry with 2D operations with no additional conversion steps in queries.
If we like, we can take a drawing with 2D geoms and set one or more of the geoms to 3D. The windows and all operations that do not explicitly support 3D geometry will simply and transparently use the 3D values as 2D, ignoring Z data, and those operations that support 3D geometry will use the Z data
GIS has evolved over many years so working with real-world GIS data is more complicated than the simple areas, lines and points. We can keep it simple if we create all of our own data, but if we want to work with the many petabytes of GIS data accumulated over the last 40 years we need to know a bit more.
The above discussion is all based on the simplified case where each object is a record in a table and objects are created from straight line segments. There are three complications we might encounter working with spatial data:
Curved segments - The use of curved segments to create lines or areas.
Branched Objects - The use of branches to create as a single object what appear to be multiple objects.
Multipoints - A rare use of branched objects where a single record or object includes what appears to be multiple points. This is so counter-intuitive and so seemingly crazy we are lucky that multipoints are very rarely encountered.
The first complication we encounter with geometry in spatial data is the use of curved segments in paths to define lines and areas in addition to straight line segments.
If we zoom far into the States drawing to look more closely at the borders of Durango province, Alt-clicking the province to show as blue boxes the vertexes that define the area boundary, we see that the area boundary is drawn using a series of straight line segments.
Most GIS and CAD systems build lines and areas out of paths that consist of straight line segments between a sequence of coordinates. That's easy for both the system and for any programmers tinkering with the machinery of the system to understand. The area consists of a list of coordinates in order, and to draw a line or area boundary one simply creates a straight line segment from one coordinate to the next.
But straight line segments are not the only way to define the shape and location of a line, nor are they always the most conveniently accurate or the most efficient way to do so. Some CAD and GIS systems can also utilize curved segments in paths to create line and area objects. Curved segments also occur in traverses, as used in surveying and cadastral work.
Consider how we might represent a circle, which is a smooth curve, using straight line segments. If we use a small number of segments, such as five, what we end up drawing is obviously not a smooth circle but a polygon, a pentagon in the case of five segments. We can increase the number of segments but then we end up using very many coordinates to draw a circle that even so will still look like a polygon when we zoom in.
The example below shows a spiral figure, first drawn using many straight line segments, and then drawn using two curved segments.
Instead of storing very many coordinates to draw a smoother looking polygon that represents a circle, as an alternative we could store only two coordinates and then mathematically derive a circle from those two coordinates: a coordinate for the center of the circle and a coordinate located anywhere on the circle to give us the radius from which the circle can be calculated. If the line or area boundary we want to draw consists of a circle or any part of a circle, that is, an arc of the circle, we can draw it with perfect mathematical accuracy with only a few coordinates - if our system can handle the description of circle arcs used as segments of a line or an area. Manifold can do so.
In addition to circle arcs there are two other curvilinear constructs that can be used for curved segments in paths in Manifold: ellipse arcs and spline arcs (or just simply splines). Ellipse arcs are similar to circle arcs in that only a few coordinates are required to exactly specify the section of an ellipse we use. Splines are parametric curves that can be defined using only a few coordinates and which can be easily deformed during manual editing to approximate complex curves.
The illustration above shows a single line that contains both curved segments and straight segments. It consists of a circle arc segment followed by four line segments followed by a spline arc. The small dot on the circle arc segment and the small dots above and below the spline segment are not point objects but are anchor points for defining the circle arc and the spline. Those small dots can be clicked and then dragged to adjust the shape of the circle segment and the shape of the spline segment.
Geoms that store either lines or areas can store them as sequences of segments, either straight line segments or curved segments, or a mix of straight line and curved segments. Each curved segment can be made up of a circle arc, an ellipse arc or a spline. A line, for example, could be made up of five straight line segments followed by a circle arc segment followed by another straight line segment followed by a spline segment followed by an ellipse arc segment.
As a practical matter, most people doing GIS will use straight line segments for lines and areas. Few GIS systems do a good job of supporting curved segments, so there is much less data published using curved segments. Manifold's ability to work with curved segments allows us to use that data within Manifold in a limited way, at least for display and interactive editing.
However, most processing tools in Manifold, such as Transform templates and various Geom SQL functions, do their work by first converting a curvilinear segment into a straight line segment between the same two start and finish coordinates. That will often lead to weird or otherwise unexpected results. To avoid such problems, first convert curvilinear segments into equivalent constellations of straight line segments at whatever resolution is desired, using the Clean transform template with the convert curves to lines operation option and the number of linear segments desired to approximate the curve in the Curve limit parameter.
The second complexity which we encounter with geometry is the use of branched objects. Branched objects can store what appear visually to be more than one object within a single record as a single geom, that is, a single object. Branched objects can be branched points, branched lines or branched areas. With the exception of areas, where the use of branches makes logical sense and is even required to show areas with "holes" in them, the use of branched objects is often not a good idea. The use of branched objects, for example, usually is contrary to best database practices such as that each record in a table is an example of one relevant thing in the collection of things that's being stored, a casual way of describing the classic database maxim of first normal form.
The simplest way to begin to understand branches is to consider real world things like the branches of a tree, where a single branch comes out of the tree trunk and then subdivides at forks into more and more smaller branches, or the branches of a river system, where tributaries flow into each other and ultimately all flow into the same river.
If we want to draw such a thing in a drawing using lines where each line is a single series of coordinates from beginning to end, to deal with the fork where the line splits into two branches we can create two line objects or three line objects.
The illustration above shows the use of three line objects. Each of the three line objects is shown in a different color. The two lines in color both have a beginning coordinate that is the same as the end coordinate of the black line.
In the illustration above we use two line objects, one of which starts at a coordinate that is the same as a coordinate in the black line. But whatever we try we cannot represent the branched diagram with a single line that consists of an unbroken sequence of coordinates from beginning to end. When we come to the fork we can continue the single line one way or the other way but not both ways at once without interrupting the unbroken, single sequence of coordinates.
Branched lines allow us to draw lines that consist of sequences of coordinates that can start and stop. We could represent the diagram immediately above with a single, branched line object that consisted of one sequence of coordinates from beginning to end of the segments in black, a marker that means "this branch ends" and then a sequence of coordinates that define the colored segments in magenta color. The entire, Y-shaped diagram would be represented by a single line object. In Manifold, branched lines can have any number of branches so they could be used to draw many more sequences of segments with many more forks, and each set of segments could utilize straight line segments as well as curved segments.
Branched areas also use branches to provide more than one sequence of coordinates that define a single boundary line. Consider the ring-shaped area object shown above, which has a hole within the area. We could draw the outer boundary line of the area with a single sequence of six coordinates (six because the last coordinate of the boundary line coincides with the first), but we cannot draw both that outer boundary line as well as the inner boundary indicating the "hole" in just a single sequence of coordinates. Area objects use branches to include additional sequences of coordinates within the same area object, to define additional boundaries for the area such as the sequence of five coordinates defining the "hole" in the figure above.
Branches are also used in areas to define "islands," that seem to be different areas but which are all part of the same area object. There is only one record in the table for what we see above. What seems to be three separate area objects is a single, branched area object that consists of five branches. Three of the five branches are used to create the outer boundary of the larger part of the area and the two holes in that larger part. Two more branches are used to create the two "islands" to the right of the larger part.
It can be confusing when what seem to be three areas in a drawing are all part of one record in a table. When each visually distinct thing in a drawing is stored in a table as a distinct record, it is easier to understand what is going on. From the illustration above we see that clarity is violated all the time in data sets one encounters that include branched area objects that represent islands or branched line objects used to represent a river and many tributaries.
Unfortunately, as everyone with technology experience knows all too well, the moment one opens the door to notions such as branched objects there will be people who misuse such notions in all sorts of confusing ways. In the case of branched lines, for example, the different branches of the same line object do not need to be incident, that is, touching. A drawing could show what appear to be totally separate lines, hundreds of them, all throughout the drawing with none of them touching each other or perhaps some of them crossing over each other when all of those hundreds of items are all part of a single very branched line object - very confusing!
An even trickier situation is that points can be branched objects as well. From a database perspective it seems to be a spectacularly bad, not-at-all-normalized idea to have what appear to be multiple, different points in a drawing that all issue from a single record that has a single geom for a very highly branched point object. For example, one might encounter a drawing that appears to show hundreds of points for locations of fire hydrants, street lights and other infrastructure that is created from a table with only five records in it, with one record for fire hydrants, another for street lights, another for stop signs and so on. Each record will consist of a single very, very branched point object geom that stores, say, the location of hundreds of fire hydrants in that one "point" object. That's not a good model for data clarity.
So why does Manifold allow such things, providing the ability to have branched points, lines and areas if such constructs can lead to miserably confusing data organization? Manifold does so to allow us to handle legacy data imported from other systems and to operate on it as we see fit. We can use Manifold to take crazy data and to transform it into more sensible organization.
A complication similar to, but technically different, from branched points are multipoints, which are point objects that are single objects at multiple locations and which appear in drawings as what seem to be separate point objects but which in fact, like branched points, are all the same object.
Traditional explanations of how multipoints might be used seem deeply nuts from a database perspective, for example, "the entrances and exits to a prairie dog den might be represented as a multipoint feature." That is as poorly organized as using a single phone number field to contain multiple phone numbers in a single record for one person who has more than one telephone. A database normalized to 1NF organization would represent a set of prairie dog dens that each have multiple portals by using two tables, one table with a single record for each den and another table with a single record for each portal and having in the record a field giving the den number for each portal. There is no need within well-organized data for a non-1NF kludge of using a multipoint for what should be separate points.
More recently the use of multipoints is defended by the growth of data and the limits of some software, with descriptions such as "Multipoints are often used to manage arrays of very large point collections, such as LiDAR point clusters, which can contain literally billions of points. Using a single row for such point geometry is not feasible. Clustering these into multipoint rows enables the geodatabase to handle massive point sets."
There is something to be said for that rationale, similar to the way raster data sets such as images are stored as tiles and not as individual pixels with one pixel per record. But raster data sets are characterized by pixels in exact, invariant array alignment and order and that is usually not the case with very large vector data sets where there might not be any sort of regular spacing and each individual point is genuinely a distinct X,Y,Z value. It would be better to simply arrange the database machinery to provide necessary performance for very large data sets and not to squish the data inappropriately into non-1NF form for lack of performance. Using multipoints to quasi-rasterize unrelated points into a single multipoint object is usually a kludge that is to be avoided when possible.
Manifold geoms can store multipoints as well as branched points but the capability is there primarily for the ability to work with data sets created by other people. To the extent we can keep our data in first normal form by avoiding the clumping of non-atomic values into a branched object geom or multipoint we should do so.
In most cases, we will run out of machine resources before hitting any limitations of Manifold. There are a few limitations that may be encountered even in large machines:
2 billion objects in .map drawings - Because individual tables stored within the .map file cannot have more than two billion records in the table, a drawing that takes geometry from a table stored in a .map file is limited to 2 billion objects. This limitation will be increased in future builds. Tables stored in external data sources such as Oracle can have many more than two billion records, so drawings based on those tables can have many more than two billion objects.
2 GB limit on individual object vertices - A single object in Manifold cannot have more than 2 GB vertices. When we create very complex drawings automatically, such as creating contours automatically, we might exceed this limitation. This limitation will be increased in future builds.
See the Limitations topic for a current list of limitations.
Why geoms? - It may seem odd that Manifold embeds geometry data within a geom and does not use simple x,y or latitude, longitude coordinate fields as occur in classic geocoded tables, at least for points, or using trendy formats like human readable JSON text for lists of coordinates. There are many good reasons for using geoms but the two main reasons are first, that complex objects such as lines and areas, especially if their segments include curved segments, require a richer type capable of containing lists of many coordinate locations. The second reason is even more important: for fastest possible speed and efficiency in computation and rendering, when working with large lines and areas a dedicated binary data type is essential.
Why do drawings and maps both have layers? What's the difference? - A key difference between layers in a map and layers in a drawing window is that hosting layers is one of the main reason to have maps, while adding layers to a drawing window is a temporary convenience to allow us to quickly see the drawing in the context of other layers. In general, if we want to use layers we should use a map. It is so easy to add layers to a drawing window that it is easy to forget they are temporary. To save work invested into a nice arrangement of layers added to a drawing window, Manifold provides the Edit - Save as Map command.
Curved segments are a poor choice in GIS - It is great that Manifold can work with curved segments, but curved segments are a poor choice in GIS since they rapidly deform when coordinate systems are reprojected. Curved segments are best in CAD systems where only a single coordinate system (projection) will be used.
Areas vs. Polygons - Manifold uses the word "area" instead of "polygon" to avoid the mathematically incorrect use of a perfectly good word, "polygon" to refer to something which often is not a polygon. A "polygon" is a figure made up of straight line segments but in GIS area objects may be created from curved segments as well as straight segments. Whatever we choose to call a figure that is composed of curves such as circle arcs or splines, it is not a polygon.
What about drawings based on geomWKT? - GeomWKT is the use of a "well known text" format to store geometry information. Text, of course, is a very low performance way to store geometry information, but at least it has the merits of being readable without requiring much programming effort, so WKT is at times used as an interchange format. The best way to deal with WKT is to immediately convert it into geom data type or, for interoperability at the price of reduced performance, geomwkb, the "well known binary" open format. We can, however, also create drawings on tables that use WKT. We do that by writing a query that converts WKT to geom in the results table, and then we create a drawing from that query.
Suppose we have a table called Mexico WKT Table that contains geometry in WKT text form in a field called GeomWKT. The table shows provinces in Mexico with a Name for each. Our query could be:
SELECT [mfd_id], [Name], StringWktGeom([GeomWKT]) AS Geometry
FROM [Mexico WKT Table];
There is no spatial index in the results table above, so every time we opened the drawing or refreshed it we would have to respond to the error message offering to build a temporary spatial index. If we like we can do a one-time conversion into a new table by using SELECT ... INTO and creating a spatial index on the new Geometry field:
SELECT [mfd_id], [Name], StringWktGeom([GeomWKT]) AS Geometry
INTO [Mexico Geometry Table]
FROM [Mexico WKT Table];
ALTER TABLE [Mexico Geometry Table]
(
ADD INDEX Geometry_x RTREE (Geometry)
);
We could create a drawing from the new Mexico Geometry Table created by the above, and it could use the spatial index created on the new Geometry field.
Normal Form and Branched Objects - People interested in maintaining first normal form (1NF) in their databases may quite likely object to the use of branches in lines since it seems that this violates the 1NF rule that each attribute of a table must have atomic (single) values. From a database perspective it certainly seems cleaner to store the Y-shaped branched diagram as two line objects or three line objects, but not as a single "line" object that really contains at least two independent sequences of coordinates, either which on its own could certainly be a line.
It seems that is no more 1NF than having a table of employee names and employee telephone numbers where the telephone numbers field stores two or more telephone numbers within a single employee record for those employees who have two or more phones. It is true that by encapsulating all geometry within the geom each geom is indeed an atomic value, but from a logical perspective what the geom represents in a branched object is not geometrically atomic: in the examples above it is either three lines all incident to the same common location (where the Y branches) or one line incident to a location mid-way along a longer line. We could make the table more logically 1NF by using two, separate line object geoms within two, separate records in the table.
The potential lack of 1NF rigor in tables that have many branched objects can often arise as a result of taking shortcuts in data set design or just as a result of the technical limitations of past software systems for GIS or CAD. It is fairly common to encounter data sets from years past that represent entire river systems as a single, extremely branched line object. So, for example, a data set for the rivers of France instead of containing hundreds of records in a table, each having a line object for a specific river or tributary, might contain only a dozen or so records with the entire drainage of the valley of the Loire lumped into a single "Loire" object with a hundred branches, one for each tributary that ultimately flows into the Loire.
A more logically 1NF arrangement would be to have a table where each record was one line, that is one distinct, unbranched river, stream or other tributary, with one line object for the Loire and separate line objects for each tributary, such as the Allier, the Cher and so on. If there is a desire to associate the Loire and all of its tributaries as a single drainage basin the right way to do that from a normalized database perspective is to have a "basin" attribute for each record that could have the common value Loire in it. If we wanted all of the lines associated with the Loire's drainage basin one could simply select those records where the basin attribute had Loire in it.
In contrast, area objects provide a natural use of branches to define holes in the area object. When branches are used to represent a single area that is in a shape such as a doughnut what is represented by the geom is still logically a single, atomic item and thus 1NF. But given the flexible way in which branches in areas can be used we often encounter data sets which violate 1NF philosophy, at times massively so, by using branches in areas to create what in a normalized database really should be separate records.
Consider the example above that shows a single, branched area object that consists of five branches. The illustration shows only a single area object even though it appears to be three areas.
Three of the five branches are used to create the outer boundary of the larger part of the area and the two holes in that larger part. Such a thing is clearly a single item. Two more branches are used to create the two "islands" to the right of the larger part. From a logical perspective it is not 1NF to have a single record that contains what really should be three records, but one encounters such things all the time in the case of areas used to represent countries, provinces or other regions with islands.
For example, people often like the idea of having a table of 50 US states where each US state has a single record into which can be placed attributes such as the state's population in a given year and other demographic totals for the state. But at the same time people often would like to have a drawing that shows the state as well, complete with islands and other details, and with very many islands in the case of states such as Maine. A desire to combine a visual rendering that is not accompanied by a desire for clean database design all too often results in a table of 50 records where most of the records have geoms that may include hundreds if not thousands of branches, to enable hundreds of islands and other small geographic parts of states to be represented by the single record that represents the state.
A cleaner database design would use two tables: a table of 50 records with the record for each state containing the demographic attributes for that state, plus a table of many thousands of records, one for each distinct area that makes up part of a state, with an attribute associating each record with one of the 50 states. In such an arrangement if we want to SELECT, say, Maine including all the islands and other disconnected bits that make up the state of Maine, that is easy to do, at least in Manifold. But it might not have been at all easy to do in some GIS or CAD system from many years ago that had no SQL and no ability to work with tables, and so had no choice but to include hundreds of islands as branches within a single, very branched area object / record for Maine.
How did we get the hatched inner area borders? - The first illustration in this topic shows an area style with fine hatch marks. We accomplished that using an Inner Border effect, as seen in the Inner Border tab below. In the Symbol tab (not illustrated), the Inner / outer offset is the default 3. The Inner border box is checked using a stroke value of 3, with stroke color a darker brown. The Dashes pattern is 1, 2 which means a one point dash followed by a two point space. Given that the stroke width is three points, the effect is that of a line perpendicular to the border. This is easiest to understand by simply trying it in Manifold. The effect tends to work better or worse depending on the sizes of the areas and the relative zoom in/out in the map.
Normalized geometry - An object such as an area is normalized when the coordinates which define it are in orderly, non-redundant configurations, for example, without identical coordinates repeating. The GeomNormalize function will normalize objects. After normalization all outer borders of areas (called outer rings in GIS jargon) will have coordinates in a counter-clockwise sequence and all inner borders of holes within areas (called inner rings in GIS jargon) will proceed in a clockwise sequence, a typical characteristic of normalization not just in Manifold but in virtually all GIS products.
Tolerance - Computers are digital devices which have a limit of accuracy imposed by the limited number of decimal digits that can be represented by the number representations they use, such as floating point values, while the level of accuracy in the analog, real world is effectively infinite. To reconcile the two a tolerance value provides an estimation level within which two values are considered the same.
Each geom within Manifold has a native tolerance that depends on its coordinate values and which is the minimum tolerance the geom can allow. We can force geoms to use an explicit tolerance of our choosing by using the GeomNormalize function with an explicit tolerance to re-normalize geoms to that tolerance. Specifying 0 for the tolerance specifies native tolerance.
NURBS - The splines used for curved geometry are Non-Uniform, Rational, B Splines or NURBS. Manifold is fairly flexible in reading objects from external data sources. For example, Oracle data sources in Manifold will read 2D circular arcs and 2D NURBS while GML and WFS data sources will read 2D circular arcs, 2D NURBS and 2D cubic splines, converting the 2D cubic splines on the fly to 2D NURBS.
Everything is a table - Spatial data in Manifold is stored in tables. Spatial data in tables is also self-describing, with the system using indexes on that spatial data to describe the structure of that spatial data. Drawings and images that show spatial data in visual form are used only for visual display purposes. When topics such as this one show point, line, and area objects in visual settings like drawings, those visual displays are just a convenient user interface for interacting with the actual spatial data, which remains, as always, stored in the associated table.
Multiple records - Some of the illustrations of tables for the Provinces drawing show more than one record for various regions. Why is that? GIS data will often use multiple records for each area that makes up a particular region. For example, the region of Bretagne (known in England as Brittany) includes many islands, each of which is a separate area object in this data.
Provinces vs. Regions - The illustrations in this topic use data from the US military, which show the regions of France as they were before 1 January 2016, when a law passed in 2014 took effect that reduced the number of regions in France from 22 to 13.
Example: Draw Lines, Areas and Points - Simple example of using basic mouse moves to add points, lines and areas to a drawing.
Example: Format a Drawing using the Style Pane - In this example we provide a first, step by step look at how to format areas in a drawing using the Style pane. We can specify the same formatting for all areas or use a field to automatically set formatting, a process usually known as thematic formatting.
Example: Style Properties in the mfd_meta Table - Style properties for drawings such as colors for areas are stored in human readable JSON values as properties in the mfd_meta system table. This example shows how we can copy formatting from one drawing to another by simply copying values between records in the mfd_meta table.
Example: Drawings use Geom Fields in Tables - An essential discussion on how drawings are created from geom fields in tables, including how the drawing knows which coordinate system to use.
Example: Multiple Drawings from the Same Table - Illustrates how easy it is to create multiple drawings that use the same table and same geometry by copying and pasting an existing drawing. Each new drawing takes no additional storage space in the project, but can be formatted differently.
Example: Create a Drawing from a Query - Everybody knows we can create a drawing from a table, but we can also create a drawing from a query. When the query reports different results the drawing changes too. This example show step by step how to create a query and then how to create a drawing from that query. We show how to command Manifold to write a query for us that grabs a selection, and then how to create a drawing based on that new query. This example duplicates the Drawings from Queries video using the Mexico_queries.mxb sample project that may be downloaded from the Examples page on the Manifold web site.
Example: Edit Coordinates While Creating an Object - When creating an object in a map using a tool such as Create Area, right in the middle of the process we can edit coordinates in the Info pane Coordinates tab. This example shows the step by step process.
Example: Edit Attributes, Larger Text, IME for Asian Languages - A tour showing how to edit attributes in a drawing using the Info pane Values tab and the expanded Edit dialog, including advanced Unicode facilities and use of the built in Input Method Editor (IME) to input text in Japanese language.
Example: Edit Attributes and Move a Point - We look at the attributes for a point in a drawing layer and edit one of the attributes using a more expanded Edit dialog. We then move the point to a new location. Easy!
Example: Trace an Area in a Map over an Image Background - In a map with a drawing layer above an image layer, create an area object in the drawing by tracing over the outlines of something seen in the image layer below.
Example: Create a Line using the Info Pane - Step by step creation and modification of a line in a drawing using the Info pane Coordinates tab.
Example: Create an Area with a Hole - Create an area in a drawing where the area includes one or more holes. This is similar to how we create areas that have islands as part of the area.
Example: Create an Area with Holes and Islands - Create an area in a drawing where the area includes holes and also islands.
Example: Create a Multipoint - How to create multipoints. This topic provides two examples: First we create a multipoint and then next we create a multipoint having two branches. The purpose of this topic is to help teach the implementation of geometry in Manifold and other typical spatial packages using a somewhat unusual and rarely met object type, the multipoint, which combines what appear to be many separate points into a single multipoint object.
Example: Create a Geocoded Table from a Drawing - A partner example to Example: Create a Drawing from a Geocoded Table A geocoded table has records with a latitude and longitude for each record. This example starts with a table for a drawing of points where the geom field in the table contains geometry information for each point. We extract the Y and X locations for each point from the geom field to create latitude and longitude fields in the table for each record.
Example: Create a Drawing from a Geocoded Table - A partner example to Example: Create a Geocoded Table from a Drawing A geocoded table has records with a latitude and longitude for each record. This example starts with a table containing a list of cities with a latitude and longitude field for the location of each city. We create a geom from the latitude and longitude fields using a template in the Transform pane and then we create a drawing that shows the cities as points. This example shows all the infrastructure steps involved.
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.