Drawings

This topic assumes we have read the Tables topic as well as other introductory topics such as the Getting Started and User Interface Basics topics.

 

icon_drawing.png

Drawings provide a visual display of geometric data in tables in the form of geom fields. Each drawing is a viewing window that displays the data from some table.  Drawing windows can also include layers that are other drawings, labels or image.  For example, a drawing will often have a background layer that is pulled from an imageserver, such as a Bing, Google or OpenStreetMap server.

 

To create a new drawing:

 

  1. Choose File - Create - New Drawing.

  2. Specify a Name for the new drawing.

  3. Choose a coordinate system if the default is not desired.

  4. Press Create Drawing.

 

By default, new drawings are created using the EPSG:3857 Pseudo-Mercator coordinate system also used by most web mapping data sources.

 

To create a new drawing based on an existing table:

 

  1. Right-click on the table in the Project pane.

  2. Choose New Drawing.

  3. Choose the Geometry field to use if there is more than one in the table.

  4. Check the box to create a spatial index if one does not yet exist.

  5. Press Create Drawing.

 

We can create a drawing to show a table if the table contains a geometry field with vector geometry data in one of the Manifold geometry data types for vector geometry.

Drawings and Tables

All data in Manifold is kept in tables.  Viewing windows like drawings, maps and images do not contain any data: they just visualize data from fields in tables based on what that viewing 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,  a different selection or even a different subset of or different computed values for objects.

i_areageom01_01.png

 

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 geom field from which it draws the information it displays.   The geom field in the table contains geometric data for drawing the object specified by that record.  The FieldCoordSystem property in the table's Properties says what coordinate system is to be used for that geom field.   

il_drawing_table_cycle.png

In the illustration above, 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 Properties dialog 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.  

 

il_drawing_table_cycle_mfdmeta.png

The properties for a drawing, the table and all other components in the project are also stored in tables 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 table with different sets of objects selected in the different drawings.  

 

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.

Points, Lines and Areas

There is a simple way of understanding geoms and the objects they store that applies for most cases.  In addition to the simple way of explaining geoms and objects there are two complications that are much less frequently encountered.  Let's begin with the simple way:  

 

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.  

il_points.png

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, a simpler term than always writing or saying "X, Y coordinate pairs."

 

il_lines.png

 

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 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 in order which define the line.  

 

il_areas.png

  

Areas are typically composed of straight line segments that define the boundary of the area.  The geom for such an area simply stores the coordinates in order which define the boundary, the last coordinate being the same as the first in that it "closes the loop" of the boundary.

 

il_cities_in_france.png

 

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.

Creating New Points, Lines and Areas in a Drawing

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.  We can create points, lines and areas in the same drawing.

 

To add point, line or area objects to a drawing we Begin by opening the drawing in a drawing window or as a layer in a map.

 

il_create_point_command.png  il_create_point_drawing.png

 

To add new points to a drawing:il_save_changes_popup.png

 

  1. Click on the Create Point command button.

  2. Click on locations in the drawing where a point is to be created.  Manifold will draw a blue preview square at each location.

  3. When all desired points have been clicked, right-click anywhere in the drawing.

  4. In the resulting pop-up menu, click Save Changes to create the points.   Choose Undo Changes to abandon.

 

 

il_create_line_command.png  il_create_line_drawing.png

 

To add a new line to a drawing:il_save_changes_popup.png

 

  1. Click on the Create Line command button.

  2. Click on a location in the drawing to start the line and then click on subsequent locations to indicate where each next coordinate defining the line is to be placed. Manifold will draw a blue preview square at each coordinate with a blue preview line between clicked locations and also extending from the last clicked location to the current cursor position.

  3. After clicking the last coordinate for the line, next right-click anywhere in the drawing.

  4. In the resulting pop-up menu, click Save Changes to create the line.   Choose Undo Changes to abandon.

 

 

To add a new, branched line to a drawing:

 

  1. Click on the Create Line command button.

  2. Click on a location in the drawing to start the first branch of the line and then click on subsequent locations to indicate where each next coordinate defining that branch is to be placed. Manifold will draw a blue preview square at each coordinate with a blue preview line between clicked locations and also extending from the last clicked location to the current cursor position.

  3. For the last coordinate of the branch, shift-click to add that last coordinate.

  4. With the next click a new branch will be started at the clicked location.   Click on subsequent locations to indicate where each next coordinate for that branch should be placed.

  5. After clicking the last coordinate for the last branch,, next right-click anywhere in the drawing.

  6. In the resulting pop-up menu, click Save Changes to create the line.   Choose Undo Changes to abandon.

 

 

il_create_area_command.png  il_create_area_drawing.png

 

To add a new area to a drawing:il_save_changes_popup.png

 

  1. Click on the Create Area command button.

  2. Click on a location in the drawing to start the area and then click on subsequent locations to indicate where each next coordinate defining the area is to be placed. Manifold will draw a blue preview square at each coordinate with a blue preview line between clicked locations and also extending from the first location to the current cursor position.

  3. After clicking the last coordinate for the area, next right-click anywhere in the drawing.

  4. In the resulting pop-up menu, click Save Changes to create the line.   Choose Undo Changes to abandon.

 

To add a new, branched area to a drawing:

 

  1. Click on the Create Area command button.

  2. Click on a location in the drawing to start the first branch of the area and then click on subsequent locations to indicate where each next coordinate defining that branch is to be placed. Manifold will draw a blue preview square at each coordinate with a blue preview line between clicked locations and also extending from the first clicked location of the branch to the current cursor position.

  3. For the last coordinate of the branch, shift-click to add that last coordinate.

  4. With the next click a new branch will be started at the clicked location.

  5. Starting a new branch within an area begins creating a hole in that area.  Starting a new branch outside of an area begins creating an island.

  6. Click on subsequent locations to indicate where each next coordinate for that branch should be placed.

  7. After clicking the last coordinate for the last branch,, next right-click anywhere in the drawing.

  8. In the resulting pop-up menu, click Save Changes to create the area.   Choose Undo Changes to abandon.

 

 

The above are basic moves for creating new objects in drawings.    For editing during creation and more advanced object creation, for example, using curvilinear segments or creating multipoints, we use the New Object Dialog in conjunction with the above basic moves.

 

Formatting

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 the Layers pane.   The three illustrations below show the same drawings as the illustration above, but with default formatting altered by using the Style dialog.

 

il_format_eg01_01.png

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.  The Layers pane was used to set black background color for the drawings.

 

il_format_eg01_02.png

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.  The Layers pane was used to set light beige background color for the drawings.

il_format_eg01_03.png

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 for the drawings.

 

See examples in the Example: Format a Drawing using the Style Dialog and Example: Style Properties in the mfd_meta Table topics.

 

Geoms Specify Geometry

The geom field for each record in a drawing contains the coordinates that define the object specified by that record.   Those coordinates create the shape and correctly place the object within the coordinate system that the table's properties specify for that geom field.   i_areageom01_01.png

 

In the illustration above each record in the States Table table represents a province in Mexico with the Geom field containing a geom that specifies how to draw the area representing each province.  The States drawing displays the geoms in visual form.  

 

We've taken a moment to select Durango province in the table.  We have used the Select dialog to transfer the selection to the drawing so we can see the derived object in the drawing also in red selection color.   The province shown in red selection color, Durango, is drawn using the area geom stored in the Geom field of the record for Durango in the table.

 

i_areageom01_02.png

 

We can see from which table a given drawing takes its geometry by right-clicking on the drawing in the Project pane and choosing Properties.   

 

The Properties dialog for the States drawing shows it takes its geometry from the States Table table, from the Geom field.  If our table had more than one geom field the drawing could have used a different geom field.   There's no requirement the geom field be named Geom; it could be named abc.   However, when Manifold imports vector drawings from GIS or CAD formats and automatically creates tables and drawings to store them in Manifold form the default column name for fields containing the geom data is Geom.

Table Properties Specify the Coordinate System

Fields that are geom type provide the geometry for objects such as areas, lines and points.  The geom contains the coordinates that specify the shape and location of those objects relative to other objects in the table but the geom  does not contain the coordinate system information which specifies how those coordinates should be interpreted by a drawing.

 

Which coordinate system should be used by a drawing to interpret a geom field in a table is specified in the table's properties.   Every geom field in a table that is to be correctly utilized by a drawing or other component should have a FieldCoordSystem.<geom_name> property, where <geom_name> is the name of the geom field.    For example, if a table uses the default name for a geom field, Geom, the coordinate system property will be FieldCoordSystem.Geom.  The coordinate system property's value is a specification of the coordinate system that should be used to interpret the coordinates in the geom values in that field.

 

When a drawing fetches geometry data from a table for display the drawing knows from its own, drawing properties which table to use and which field within that table to use for geom data.   The drawing looks at the table's properties to see what coordinate system that geom field uses.   The drawing can then display the coordinates in the geom values using the correct coordinate system.

Example

Consider a drawing, called Provinces, that shows provinces (regions) in France as areas.

 

il_drawings_from_tables01_01.png

 

If we right-click on the Provinces drawing in the Project pane and choose Properties we can see the properties for the drawing.

 

il_drawings_from_tables01_02.png

 

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.  

 

il_drawings_from_tables01_03.png

 

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.

 

il_drawings_from_tables01_04.png

 

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:

il_drawing_table_cycle.png

 

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_angus_sm.png

 

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.

Lines and Areas are Drawn with Straight or Curved Segmentsi_areageom01_03.png

If we zoom far into the states drawing to look more closely at the borders of Durango province we see that the area boundary is drawn using a series of straight line segments.  Most GIS and CAD data sets we may encounter will utilize only straight line segments for lines and areas.

 

There are three complications we might encounter working with spatial data:

 

 

Curved Segments

The first complication we encounter in using geoms is the use of curved segments to define lines and areas in addition to straight line segments.

 

Most GIS and CAD systems build lines and areas out of straight line segments between a sequence of coordinates.  That's easy for both the system and any programmers tinkering with the machinery of the system to understand since one has 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.  

 

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.    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 circular 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 to create curved segments in Manifold:  ellipse arcs and 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 image below shows a single line in the process of being created via the New Object dialog.  It consists of a circle arc segment followed by four straight segments followed by a spline.  The small dots are not points but are control points for defining the circle arc and the spline that can be edited to adjust the shape of the line.

 

il_curved_segments_line.png

 

Geoms that store either lines or areas can store them as sequences of segments, either straight line segments or curved segments, where 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.  For examples of such constructions, see the New Object Dialog topic.

 

Branched Objects

The second complexity which we encounter with geoms 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 certain types of areas where the use of branches makes logical sense, the use of branched objects is generally 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 desideratum 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.   

i_branch01_01.png

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 end up creating two line objects or three line objects.

i_branch01_02.png

In the illustration above 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.

 

i_branch01_03.png

 

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.

eg_newobj03_10.png

 

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.

 

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's 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.

 

eg_newobj04_07.png

 

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.

 

Confusing Uses of Branched Lines and Branched Points

 

It is easier to keep a cleaner view of data when objects that appear to be visually distinct in a drawing are stored in the table as distinct records, one record for each visually separate object in the drawing, a sort of First Normal Form notion for drawings.  But as we've seen that's violated all the time in data sets one encounters that include branched area objects that represent islands or branched line objects that show items such as branched river systems.

 

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 innovative and profoundly opaque 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 (that is, not incident at a coordinate in common to both) when all of those hundreds of items are all part of a single very branched line object - not at all 1NF!   

 

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, with each record having 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 database 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 opaque organization of data?  Manifold does so to allow us to handle legacy data imported from other systems and to operate on it as we see fit.   

Multipoints

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 non-1NF from a database perspective, for example, "the entrances and exits to a prairie dog den might be represented as a multipoint feature."   That's clearly as non-1NF 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's no need 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 clearly 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 others.   To the extent we can keep our databases in first normal form by avoiding the clumping of non-atomic values into a branched object geom or multipoint we should do so.

Creating a Drawing from a Table

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.  However, using SQL we can manually create a drawing from any table that has a geom field and which also has had an rtree index created on that geom 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'

    );

 

3D Geometry

 

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:

 

 

Notes

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.  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 than simply x, y coordinate fields, and second, that location is not usually a simple matter of x,y coordinates outside of any context but instead is a richer matter of such coordinates within a specific coordinate system or projection.   Geoms include coordinate system information so that whatever is done with a geom is done accurately.

 

Even in the case of simple points merely specifying their x, y coordinates or even latitude, longitude coordinates does not accurately place them.  Even in the case of supposedly "unprojected" latitude, longitude coordinates, to accurately place the location we need to know the datum for which those latitude and longitude coordinates are intended.  The difference between datums can mean a difference of hundreds of meters for the locations of the exact same latitude and longitude coordinates.

 

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.

 

Curved segments are a poor choice in GIS - It is great that Manifold can work with curved segments, but as noted in the New Object Dialog topic, curved segments are a poor choice in GIS.    Curved segments are best in CAD systems where only a single coordinate system (projection) will be used.  

 

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.  

 

See Also

Getting Started

 

User Interface Basics

 

Coordinates

 

New Object Dialog

 

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 Dialog - In this example we provide a first, step by step look at how to format areas in a drawing using the Style dialog.  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: 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 New Object Dialog - Step by step creation of a line in a drawing using the New Object Dialog.

 

Example: Create a Line using Curved Segments - Creating a line made up from curvilinear geometry using the New Object Dialog.

 

Example: Create an Area with a Hole - Using the New Object Dialog, 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 - Using the New Object Dialog, create an area in a drawing where the area includes holes and also islands.

 

Example: Create a Multipoint - How to create multipoints using the New Object Dialog.  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 dialog and then we create a drawing that shows the cities as points.  This example shows all the infrastructure steps involved.