Pythagoras of Samos (569-475 B.C.), a Greek mathematician and philosopher, is credited with discovering the Pythagorean Theory. Historians now believe the Babylonians knew of this relationship a thousand years earlier, but Pythagoras was the first to prove it mathematically. At any rate, Pythagoras and his followers, the Pythagoreans, did much to advance the principles of mathematics, especially triangular relationships, which are used daily by surveyors.

The computer program “Pythagoras,” first introduced in Europe in 1992, is a drawing tool based on COGO relationships (intersections, lines by angles and distances, etc.) to place lines, arcs, points and symbols on the drawing. As such, it uses many of the mathematical principles developed by the Pythagoreans. The developers of Pythagoras, ADW Software of Vosselaar, Belgium, hope it will become a common tool for surveyors that will be used for centuries. (I wonder what version of Windows folks will be using then?) Pythagoras is one of those rare programs that will run on the Apple Macintosh platform in addition to Windows.

The developers of Pythagoras wanted a program that would make it easy for land development professionals to create drawings. With this in mind, they took an approach consistent with the way surveyors work. That is, points become the common reference of all drawing entities. For example, the key points for a line and an arc are the ends. If a key point is moved, the object is moved also. When adding lines and curves to the drawing, if points don’t already exist at locations needed to define the object, they are created. If a drawing object, such as a line is moved, the points associated with the line are moved also.

In land development and boundary analysis projects, lines that should join but don’t, such as at a property corner, can cause problems. The procedures used in Pythagoras are designed to prevent this from happening. Another feature is the use of dimensional units and coordinate systems. While there are options for both of these, they are based on the fact that the relationship between two points on the earth’s surface remains fixed (over a short period of time and in the absence of a major disturbance). It is only the way we describe it that changes. Pythagoras maintains this real world relationship by storing all values in a local coordinate system (described later) and in metric units. Then when other units or coordinate systems are active, conversion takes place behind the scenes.

Pythagoras can work in meters, centimeters, millimeters, international feet and U.S. survey feet. The next version will support inches, a common unit used in the United States by architects. If the units are changed from one to another, the coordinates are adjusted accordingly, a convenient capability when converting between metric and English units or between decimal feet (engineering) and inches (architectural). When a unit is selected, it remains the default for all drawings when opened. I would like to see this changed so that the units last used are saved with the drawing. This might prevent some problems for companies working on both metric and English projects, a situation we will need to endure in the United States until we all use the metric system. (I wonder if this will ever happen!)

Figure 1. Layer groups.


Layer options are visible, protected or set. Editing operations are restricted on protected layers while the cursor will not snap to objects on a layer that is set. In addition to these rather standard settings, layers have a scale parameter that is quite useful.

If one has a large project, such as an entire city or large subdivision, with a lot of detail including individual streets, alleys, fire hydrants, utility poles, signs, etc., the drawing becomes quite cluttered at a small scale (perhaps 1/10,000) if all these layers are visible. Using the scale parameter, all major streets can be made visible at any scale, while minor streets could be made visible only at a larger scale (perhaps 1/1000), and utility poles, fire hydrants and other small objects could become visible at an even larger scale (perhaps 1/100). Layer scale is dynamic. It works as you zoom in and out of your drawing as well as when plotting. This operates similar to some trip planners where more detail is displayed as you zoom in closer to your target.

Layer groups, as shown in Figure 1, are still another handy feature. Defined layers can be placed in a group so that the properties, visible, set and protected, can be set for all layers in the group at the same time. For example, when developing lots, the user may want certain layers to be visible, such as roads and contours, and others not to be visible, such as field fences and farm roads. To accomplish this, he or she must create two layer groups. I would like to see an option in the layer groups dialog box to set all layers not in the group to the opposite setting.


“Symbols” has two properties I like very much. A symbol can be rotatable or not rotatable, scalable or not scalable. Not rotatable symbols always remain horizontal on the page regardless of the orientation of the project on the page. Examples would be a tree or fire hydrant. Rotatable symbols can be placed at any angle and retain their relationship to other objects in the drawing, regardless of the orientation of the project on the page. When processing data collector files, rotatable symbols can be set to match the linear features they are associated with. Scalable symbols can be scaled to match real world objects such as the drip line of a tree, while non-scalable symbols, a fire hydrant, for example, are scaled to match the drawing so their size is constant on the printed page, regardless of the drawing scale.

Figure 2. Sample line styles.

Line Styles

User-defined line styles, i.e., line styles that include symbols, are easy to create. One merely draws the repeating pattern on the screen, including any symbol which should be a part of it. The symbols are then unpacked (exploded); hot spots are added to identify the beginning and end of the pattern; and the items making up the pattern are selected. Then by picking a couple of menu items, the line type is created. Line styles also have a scale property. If the line type is created as scale-independent, it will always be printed the same size on the paper regardless of drawing scale. Sample line styles are shown in Figure 2.

When the line style is used, the scale is slightly adjusted as necessary to provide an even number of repetitions between the two points. The line then becomes one entity. When a user-defined line style is exported in a DXF file, it can be unpacked, converted to a solid line or retain its identity as a single entity. If transferred as a single entity, it will become a series of blocks connected together as one. If unpacked, the individual elements making up the pattern appear in the drawing.


Polygons are created by selecting existing lines and points to form a closed area. Polygons are handy for displaying lots, houses, parking areas, easement areas, roads, etc. A polygon has a border and a fill, both of which can be set to none, in which case the polygon is invisible. Options for the fill include various line patterns or solid fill with various colors and degrees of brightness for each. If a line pattern is selected, a background color can be chosen as well.

Figure 3. Display levels control visible characteristics that overlap.

Display Levels

All objects in a drawing can be assigned a display level, which ranges from -10 to +10. This controls the visible characteristics when objects, such as polygons, overlap. This is especially useful for polygons, thus making it possible to show such things as lots and houses that occupy a common area as shown in Figure 3 on page 92. By assigning proper display levels, the most important one can take precedence, but the others could show through if desired.

Data Collection

Pythagoras accepts raw data files from several data collectors, but not all. Standard ASCII point files can be imported for data collectors not directly supported. While this adds an extra step or two, it’s not a major inconvenience. Regardless of how data is imported, Pythagoras uses parameters found in the point description to establish the point symbol and to connect points.

Instructions for translating field entered codes to a drawing seem more difficult than necessary. The process is similar to writing macros for some programs. I believe configuring the coding system to match company standards would be easier to grasp if the parameters were entered in one or more tables.

Figure 4. Basic information about an object.

Creating Objects

The control panel, which is located at the left side of the screen, becomes a major source of information. It contains several of the command buttons plus a display of variable drawing information, depending on the active command or the object closest to the cursor. When the cursor approaches an object, basic information about the object is displayed in the control panel. For a point, it is the point number; for a line, it is the length and the distance the cursor is from each end as shown in Figure 4. The distance to each end of the line is indicated by a value displayed beside the point numbers at the end of the line. However, if point numbers are turned off, it is difficult to tell which end goes with each point number. If points are turned off, I would like to see them displayed temporarily in the drawing when the cursor approaches the line.

When creating objects, “snap” is always active. The object within the snap distance will have a symbol called “the sight” displayed at the snap location. The shape of “the sight” indicates what type of snap will take place, either to a point , perpendicular , tangent or just touching . Thus, there should never be situations where lines appear to join but don’t.

“Confirm operations” is an important setting when creating objects. If turned on, the user must provide specific data, such as the length and/or bearing of a line, or coordinates of a point; otherwise the mouse position is used to determine the information needed.

Coordinate Systems

There are five types of coordinate systems to choose from. They are Local, Global, User-Defined, Page and Temporary.

The Local Coordinate System can be based on any system commonly used in the locality. For example, in my area, Baltimore City and the Washington Suburban Sanitary Commission have each established a coordinate system. State Plane Coordinates are considered as local in most cases.

The Global Coordinate System is needed when two projects with different systems are merged. The Global Coordinate System must be specifically created by transforming the local system to the global system. When doing this, the project can be rotated, translated and/or scaled to fit the global system. For many projects, the local and global system will be the same.

A User Coordinate System is project-specific and up to 16 coordinates can be defined. For example, you might define a User Coordinate System for a large building, thus providing direct distances from a corner. A User Coordinate System is also handy for labeling distances and offsets along a baseline; however, the baseline must be a straight line or a series of straight lines.

The Page Coordinate System deals with placing information on a sheet of paper. Items with no specific coordinates, such as general notes, cross sections and legends are placed in this system.

While there are similarities between a Temporary and a User Coordinate System, the Temporary system is not saved with the drawing, while all of the others are.

Pythagoras can display coordinates in either Cartesian or Polar. If displayed in Cartesian, there are options for North, East or x, y. If displayed in Polar, the options are horizontal or slope distance and elevation or vertical angle. Vertical angle can be either zenith- or horizontal-based.

User Defaults

One of my favorite features, which I almost missed, is “user defaults.” This feature lets the user set parameters for the layer, point style, line style, text style and/or polygon pattern and store this information for selection at a later time. Thus, at the touch of two buttons, all of these items can be set for the operation about to take place. These defaults are global in nature, i.e., they are available for any drawing once established.

While this is a powerful feature, the user default assigns the same layer to points, lines, text and polygons. A common practice among surveyors is to assign different layers to these items when working with such things as lots, roads, buildings, etc. I would like the option to assign individual layers for these drawing objects in user defaults. Setting the units and coordinate system might be another handy feature in user defaults.

Scanned Images

Scanned images can be added to the drawing and can be placed either on the page as for a location map or company logo, or placed in the Local Coordinate System as for another drawing. When inserting a scanned image that is to be used for heads-up digitizing, most images need to be stretched in several directions (rubber sheeting) to take out distortions in paper stretch, errors in scale, etc. Pythagoras takes the opposite approach. An image is scaled in the x and y direction to the scale desired, then the information is digitized. Then the digitized data is “transformed” by selecting up to 10 points and supplying the correct coordinates for each. This not only takes the paper distortion into account, but takes out some of the inaccuracies in selecting points in the scanned image while digitizing.


Pythagoras has several forms of annotations. These include bearing, length, coordinates, etc. These must be used one at a time, and the location of the resulting text is preset. Thus, if a user wishes to label a line with the bearing and distance, it requires two operations, and the resulting text is placed on top of each other requiring that one of them be moved. I would like to see a function to label both at the same time with options for placement locations.

Annotations are always created using the current drawing units and coordinate system. Therefore, it is possible to annotate coordinates of columns in a building in reference to a baseline, and also in feet and inches (to be included in the next release) if desired by the builder. Then by changing to a different coordinate system, surveying monuments can be labeled in a different style.

Technical Support

Technical support consists of telephone support for “simple” questions, and E-mail support for “more complex” problems (e.g. sending drawings that contain problems).

Technical support is offered free for the first six months. After this initial free period, it is available on a subscription basis for 15 percent (per year) of the purchase price of the installed modules. The subscription service offers free upgrades in addition to the items listed above.

As usual, I received my technical support via E-mail. I always received prompt and courteous responses to my questions. I found them to be receptive to suggestions as evidenced by their intention to add inches as a unit in the next release.


I enjoyed digging into Pythagoras. At first I missed some of the traditional approaches to computer drafting, but as I looked into it more, I discovered that they often had a better solution. One example is the user defaults discussed earlier. User defaults provide the flexibility to set a number of parameters at one time, thus eliminating numerous keystrokes or creating objects in the wrong line style, on the wrong layer, etc.

I especially like the way they create custom line styles. It is so easy to create a custom line style that companies can develop line styles to fit any requirement.

The automatic conversion from their native local coordinate system and metric units to any other the user needs at the touch of a button is more than a convenience. Consider working on a project requiring annotations in dual units. Just set the units for a requirement and place annotations. Change the units, switch to a different layer and repeat the operation. That’s all there is to it. Their unit and coordinate system management is also a convenience for merging an architectural drawing into a site plan. Just set up a user coordinate system so that the origin corresponds with the origin of the architectural drawing and at the proper orientation, set the units to match and then import the drawing. It’s that easy. An added bonus is that if it’s necessary to communicate with architects, as in the case when their buildings don't close, you can discuss it in their units. When exporting coordinates, they are always in the coordinate system active at the time.

Other features I was impressed with are the rotate and scale properties for symbols, display levels for all objects and scale properties of line styles. I can think of situations where all of these would have been very useful and time saving.

Or take the case of preparing drawings for presentation to clients, approving agencies, the general public or potential buyers. The properties available for polygons make it a snap. Since we all know how important it is to present a clear picture of the proposed project, this capability alone would pay for the software in cases where it is difficult to sell a controversial project. c