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.  

Creating New Drawings

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 do that by creating a new, blank drawing and then adding points, lines and areas to that drawing.   We might do that by tracing over something visible, such as a road or building, in an imageserver 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, blank drawing:

 

  1. Choose File - Create - New Drawing, or use the context menu in the Project pane.

  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, as used by almost all modern 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 Create - 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. Assign the correct coordinate system if the coordinate system is reported in red text.

  6. Press Create Drawing.

 

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

 

To create a new drawing based on a query:

 

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

  2. Choose Create - New Drawing.

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

  4. Assign the correct coordinate system if the coordinate system is reported in red text.

  5. Press Create Drawing.

  6. Drawings created from queries will appear only when used as a layer in a map that contains at least one other layer.

  7. 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 vector geometry data in one of the Manifold geometry data types 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.

Layers in a Drawing Window

Drawing windows can contain layers just like a map.  See the discussion of layers in the Maps topic.  We can add images, drawings and labels as layers to a drawing window, for temporary viewing.  A key difference between layers in a map and layers in a drawing window is that hosting layers is the 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.

 

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.

 

To add a layer to a drawing window:

 

  1. Open the drawing by double-clicking it in the Project pane.  

  2. The drawing will appear as the only layer in the drawing window.   The drawing window will use the projection of the drawing.

  3. Drag and drop any additional desired layers from the Project pane into the drawing.

  4. The drawing window will automatically re-project on the fly all layers into the coordinate system used by the drawing.

  5. Rearrange layers by dragging their tabs left or right, or by using the Layers panel.

  6. 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:

 

 

 

ico_nb_arrow_blue.pngLayers 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.  To save the layer structure added to a drawing, choose Edit - Save as Map and save the window, together with the layers as specified, as a map.

 

OK to Mix Points, Lines and Areas

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.    See the Editing Drawings topic to either modify existing objects in a drawing or to create new points, lines and areas in a drawing.

 

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

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.

Drawings and Tables

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.

 

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 geometry field from which it draws the information it displays.   The drawings 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.

 

il_drawing_table_cycle_01.png

 

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.  

 

il_drawing_table_cycle_02.png

 

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.    

 

il_drawing_table_cycle_03.png

 

 

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

    tech_tina_sm.png

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.

Objects in Drawings

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.

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 term popular in GIS jargon for such coordinate pairs is vertex.   Manifold uses the words "coordinate" and "vertex" as synonyms.

 

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

 

 

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 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 Coordinates tab of the Record panel in the Contents pane will automatically open to show a complete list of 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 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.  

 

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

 

Projections (Coordinate Systems) and Drawings

Data in Manifold can use virtually any coordinate system known. In Manifold, the terms projection and coordinate system are synonyms.   

 

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.

 

There are two key tasks for keeping coordinate systems straight:

 

 

 

Automatic Assignment of Coordinate Systems

The shapefiles used for the illustrations of a buildings layer in Monaco that appear in this topic above included a .prj file that assigned Latitude / Longitude to the drawing as the initial coordinate system.  Although shapefile are an extremely ancient format, over the years users have evolved ways, such as the use of .prj files, to allow GIS data published as shapefiles to automatically convey the correct projection to be used.  Manifold understands those conventions and will automatically use such information, if present, when importing drawings from shapefiles to automatically assign the correct coordinate system to a new drawing.

Projections in Drawings and in Maps

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 panel of the Contents pane reports the projection of the active window and the active layer in that 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.    In the above illustration we have also used Style to color the areas in the buildings drawing.

 

il_drawings01_03.png

 

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.

 

il_drawings01_04.png

 

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

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

 

dlg_create_dwg_from_table.png

 

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'

    );

 

Create a Drawing from a Query

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.

 

tech_lars_sm.png

Use only in maps - In current builds of Release 9, drawings created from queries are visible only when they participate as layers in maps that have at least one other layer.  Drawings created from queries will not be visible when opened in their own drawing window.  If we want to see only the drawing, turn off the other layer in the Layers panel.

 

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.

 

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:

 

 

Complications

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

 

The example below shows a spiral figure, first drawn using many straight line segments, and then drawn using two curved segments.

 

il_curved_straight_segments02.pngil_curved_straight_segments01.png

 

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.  

 

As a practical matter, most people doing GIS will use straight line segments for lines and points.   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.

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

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 can create two line objects or three line objects.

i_branch01_02.png

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.

 

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

eg_newobj04_07.png

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.

How to Use Branches to Confuse People

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.

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

 

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.

 

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

 

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.

 

See Also

Editing Drawings

 

Coordinates

 

Layer Opacity

 

Style

 

Contents Pane

 

Contents - Layers

 

Contents - Record

 

File - Create - New Drawing

 

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

 

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 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 panel and then we create a drawing that shows the cities as points.  This example shows all the infrastructure steps involved.

 

Example: Re-project 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 re-projects on the fly for display.