Objects in drawings, such as areas, lines, or points are defined by the sequence of coordinates necessary to draw them in a connect the dots fashion. People from a graphics arts background will often refer to the sequence of coordinates used to draw a vector object like a line or an area as a path, since that is the word that millions of people have learned for that from PhotoShop and other graphics arts packages.
Coordinates are simply the numbers for each X and Y (and possibly Z) position that defines the object, the numbers getting their meaning from the coordinate system / projection that the drawing uses. The sequence of coordinates that defines an object is also called its geometry by GIS people or, in older terminology, its metric.
Coordinates for objects are stored within a geometry data type, usually a geom data type, in records within the drawing's table.
To edit the coordinates that define an object, see the Editing Drawings topic.
To change the coordinate system / projection used by a drawing, see the Reproject Component topic.
Consider a drawing that contains five objects: an area, a line and three points.
The objects in the drawing are defined by the coordinate numbers that are used to draw them in sequence in a "connect the dots" fashion, that is, by the path specified by those coordinates. The coordinate numbers for each object are stored within the geom field in the record that stores data for that object.
The area, for example, is nothing more than a list of five coordinates within the geom that defines the area:
We can see the coordinates of any object in a drawing by Alt-clicking the object to pick it for the Info pane, and then clicking the Coordinates tab to display the list of coordinates that make up that object. A shortcut way of switching to the Coordinates tab is to Alt-click an object to pick it, and to then click on any handle or segment in the picked object.
In the illustration above we have Alt-clicked an area to pick it, and then we clicked on one of the handles. The Info pane immediately launches showing the Coordinates tab to show a list of coordinates for the object. Each coordinate appears in the drawing as a box in blue preview color. The coordinate for the row with a darker row handle in the Coordinates list appears as a larger box.
Based on the coordinate system in use, Manifold knows how to interpret a geom to make sense of the coordinate numbers it contains as an area, a line or a point as the case may be. Manifold understands how to use the coordinate numbers for each object type, for example, knowing how to draw the area correctly to show what is the inside and what is the outside of the area.
By default, Manifold uses geoms to store the coordinates that define objects because the binary geom data type is compact, unambiguous and very efficient. A big, complicated area such as the one that might define the boundary of continental Canada, replete with endlessly convoluted shoreline, might consist of many tens of thousands of coordinates even at fairly low resolution. Large areas at high resolution might consist of many millions of coordinates.
Manifold interprets coordinate numbers as spatial data by using the coordinate system for the drawing to know how those numbers should be interpreted. By themselves the raw coordinate numbers describe only the relative position and shape of objects within the drawing. If we do not have coordinate system information we would not know, for example, if the number 3 in the area's coordinates is supposed to be three centimeters or if it is three degrees of longitude. If the 3 is not degrees of longitude we do not know from the number by itself if it is supposed to represent an unprojected coordinate in a CAD drawing or if it is a number that has some meaning within some specific geographic coordinate system.
In Manifold the properties of the table which contains the geom tell Manifold the coordinate system within which the coordinates are to be interpreted. Between the table's properties and the coordinate information in the geom we have precise and complete information on the exact placement and shape of the object. See the Drawings topic for illustrations.
Nothing says that all geometries for all objects must always be sensible. Especially when objects are created by programmatic processes the geometry created may be perfectly legal but might not be sensible. Area objects, for example, might contain redundant coordinates or consist of coordinates that are placed in topologically crazy orders, for example, causing areas to overlap themselves.
Consider the area object shown in the first two illustrations below, with the coordinates that define it marked by square symbols. The blue square symbol marks a location where two coordinates exist, both exactly at the same place.
The area is defined by traversing the coordinates which mark the boundary of the area, as shown by the blue arrows in the second illustration above. The outlying coordinate is redundant, because there is no area out there. One of the two coincident coordinates at the location marked by the blue square is also redundant, since its only purpose is to send out or to catch the path out to the outlying, redundant coordinate.
If redundant coordinates are removed the area becomes a normalized area that is not pathological, that is, it does not contain any crazy or unnecessary coordinates. Fix pathologies like this using the Topology: clean (generalize) transform template.
The discussion above provides an elementary introduction to how objects are defined by coordinates using the most common case of straight line segments between coordinates. In addition to the simple case, objects in Manifold can be created from curved segments, also called curvilinear segments. See the Curved Segments discussion in the Drawings topic.
As a practical matter, most people doing GIS will use straight line segments for lines and areas. Few GIS systems do a good job of supporting curved segments, so there is much less data published using curved segments. Manifold's ability to work with curved segments allows us to use that data within Manifold in a limited way, at least for display and interactive editing.
However, most processing tools in Manifold, such as Transform templates and various Geom SQL functions, do their work by first converting a curvilinear segment into a straight line segment between the same two start and finish coordinates. That will often lead to weird or otherwise unexpected results. To avoid such problems, first convert curvilinear segments into equivalent constellations of straight line segments at whatever resolution is desired, using the Clean transform template with the convert curves to lines operation option and the number of linear segments desired to approximate the curve in the Curve limit parameter.
A simplification - This topic simplifies the nature of coordinates in a geom. From the Editing Drawings topic we can see that in addition to the classic specification of points, lines and areas by coordinates that draw the object in connect-the-dots fashion Manifold can also specify lines and areas using curvilinear segments where the coordinate numbers specify circle arcs, ellipse arcs or splines.
Everything is a table - Spatial data in Manifold is stored in tables. Spatial data in tables is also self-describing, with the system using indexes on that spatial data to describe the structure of that spatial data. Drawings and images that show spatial data in visual form are used only for visual display purposes. When topics such as this one show coordinates in visual settings like drawings, those visual displays are just a convenient user interface for interacting with the actual spatial data, which remains, as always, stored in the associated table.
Transform - Geometry
Example: Draw Lines, Areas and Points - Simple example of using basic mouse moves to add points, lines and areas to a drawing.
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: Create a Geocoded Table from a Drawing - A partner example to Example: Create a Drawing from a Geocoded Table A geocoded table has records with a latitude and longitude for each record. This example starts with a table for a drawing of points where the geom field in the table contains geometry information for each point. We extract the Y and X locations for each point from the geom field to create latitude and longitude fields in the table for each record.
Example: Create a Drawing from a Geocoded Table - A partner example to Example: Create a Geocoded Table from a Drawing A geocoded table has records with a latitude and longitude for each record. This example starts with a table containing a list of cities with a latitude and longitude field for the location of each city. We create a geom from the latitude and longitude fields using a template in the Transform pane and then we create a drawing that shows the cities as points. This example shows all the infrastructure steps involved.
Example: Convert a 0 to 360 Degree Projection - We often encounter data, both images and drawings, using latitude and longitude degrees that appears to be in Latitude / Longitude projection but which has longitude values from 0 degrees to 360 degrees and latitude values from 0 degrees to 180 degrees, instead of the usual arrangement of -180 degrees to 180 degrees for longitude centered on the Prime Meridian, and -90 degrees to 90 degrees for latitude centered on the Equator. This example shows how to utilize such data by assigning the correct projection.