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 vector geometric data in tables in the form of geom fields, which contain the geometric data to draw points, lines or areas.   A drawing is a viewing window that displays the data from some table.   More than one drawing can display data from the same data, with each drawing using different formatting.   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.  

 

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.

Terminology

 

 

 

 

 

Importing or Linking Drawings

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 Change Coordinate System in the Contents pane to re-project them into a different coordinate system, and add layers to help understand the drawing better.

 

il_drawings01_01.png

 

Above we see a drawing that was imported from shapefiles extracted from OpenStreetMap.   It shows buildings as areas.

Projections

The shapefiles used for the illustration above included a .prj file that assigned Latitude / Longitude to the drawing as the initial coordinate system.  The Contents pane reports the drawing to be in Latitude / Longitude and the drawing's window therefore also uses Latitude / Longitude.  When a drawing appears as a layer in a map, the map can have any projection and the drawing will be re-projected on the fly into the map window's projection. However, when a drawing is opened in its own drawing window, the drawing's window always uses the same projection as the drawing.   Any other layers dragged and dropped into the drawing's window will be re-projected on the fly into that projection for display so they will line up correctly with the drawing in the drawing's window.

 

il_drawings01_02.png

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.

 

il_drawings01_03.png

 

In the Contents pane we can click on the coordinate system picker for the drawing and use Change Coordinate System to re-project the drawing into Pseudo-Mercator coordinate system.  That will also change the projection used by the drawing's window to Pseudo-Mercator as well.  Every other layer that appears in the drawing's window will be shown in Pseudo-Mercator also.  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.    In the above illustration we have also used Style to color the areas in the buildings drawing.

 

il_drawings01_04.png

Zooming in we can better see the colors we have applied using Style.   

Layers in Drawings are Temporary

We can add layers to a drawing window as a temporary convenience and the drawing window will show those layers like a map window does.   However, while a map maintains its layer structure even after the map window is closed, layers in a drawing window last only as long as that window is open.   If we close the drawing window and then open it again, it will have only one layer, the drawing itself.

 

If we have added layers to a drawing window and want to keep that organization of layers with the drawing for later use, we choose Edit - Save as Map to save that window with its collection of layers as a map.    Maps take zero space since in actuality they do not store any data: they are simply references to other components that are the constituent layers of the map.   Therefore, we should not hesitate to ever use Edit - Save as Map to save any interesting or useful collection of layers we have added to a drawing window.

Creating New Drawings

Although most often the drawings in our projects will result from importing or linking, we can also create new drawings if we like.   We can do that by creating a new, blank drawing and then adding points, lines and areas to that drawing, perhaps by tracing over something visible, such as a road or building, in an imageserver layer that has been added to the drawing.  We can copy and paste items from other drawings as well (make sure the other drawing uses the same coordinate system as the destination drawing).  We can also create new drawings from tables that have geometry in the table.

 

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.  A drawing is just a viewport that displays geometry data in the table.   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 or  a different selection.

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 style or 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.

A Simple Explanation

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 complications that are less frequently encountered which we will discuss below under Complications.  Let's begin with the simple way:  

Points, Lines and Areas

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.  

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, which saves us from always writing or saying "X, Y coordinate pairs."    Another synonym popular in GIS jargon for such coordinate pairs is a vertex.

 

il_lines_vertices01_01.png  il_lines_vertices01_02.png  il_lines_vertices01_03.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 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 in order which define 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.

 

 

il_areas_vertices01_01.png  il_areas_vertices01_02.png  il_areas_vertices01_03.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.  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.  

 

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.   When areas and lines consist of many thousands of coordinates, despite consisting of straight line segments they can seem incredibly 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.  We can create points, lines and areas in the same drawing.   See the Editing Drawings topic to either modify existing objects in a drawing or to create new points, lines and areas in a drawing.

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 Contents - Layers.   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.  Contents - Layers 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.  Contents - Layers 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.    Contents - Layers was used to set light blue background colo

 

See examples in the Example: Format a Drawing using the Style Panel 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.

 

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.   

 

 

i_areageom01_02.png

 

 

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.

Complications

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

The first complication we encounter with geometry in spatial data is the use of curved segments 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 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 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.   Some CAD and GIS systems can also utilize curved segments to create line and area objects.

 

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 created from a mix of straight and curved segments.  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, 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.  

Branched Objects

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, 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 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.   

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 capable of containing lists of many coordinate locations, and second, for computation using, and fast display of, large lines and areas  a dedicated binary data type is essential.

 

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.  

 

Areas vs. Polygons - Manifold uses the word "area" instead of "polygon" to avoid the mathematically illiterate 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 splines, to a mathematically literate person it is not a polygon.

See Also

Getting Started

 

User Interface Basics

 

Editing Drawings

 

Coordinates

 

Layer Opacity

 

Style

 

Contents Pane

 

Contents - Layers

 

Contents - Record

 

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 Panel - In this example we provide a first, step by step look at how to format areas in a drawing using the Style panel.  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: 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 Contents - Record panel's 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 Record panel 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 Record Panel - Step by step creation and modification of a line in a drawing using the Contents - Record panel's Coordinates tab.

 

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.