Getting Started With The Polaris Geometry Framework
From BluWiki
Contents |
Introduction
This document explains the fundamental concepts necessary to understand and work with the Polaris Geometry Framework. You should read this page if you are writing LocusXML Documents, or if you are working with a software implementation of the Polaris Geometry Framework.
Number Format
This is a very important concept, and one that could prove to be the most tricky for newcomers to the Polaris Geometry Framework. That is why it is placed near the beginning of this document. There are typically 2 types of formats for the numbers we use in the decimal number system.
The first format allows an unlimited number of digits on the left side of the decimal point. These digits are used to store the fractional parts of a whole number in the decimal system. For example the number 3.25 uses the digits "25" to represent 1/4 of a whole number. Numbers in this type of format are often referred to as floating point numbers.
The second format does not contain a decimal point or any digits that represent a fractional portion of a whole number. In this format, only whole numbers can be represented. Numbers in this type of format are often referred to as integers.
The Polaris Geometry Framework always uses integers to represent the value of coordinates. Coordinates are used to indicate the position of geometries. It never uses floating point numbers for this purpose. This raises 2 important issues that this document will now address.
[1] Why are only integer values used to store positional information?
[2] What does this mean for the individual working with the Polaris Geometry Framework?
Why are only integer values used to store positional information?
There are inherit problems with using floating point numbers to store coordinates. For one thing, floating points numbers can be difficult to map to the binary number system, which computers use to store all information. It is also more complicated to work with floating point numbers than it is to work with integers. For example, what floating point number would you use to store the value of 1/3? How many digits do you carry to the left of the decimal place to accurately store that value? Here is another example. If you want to multiply 10.25 and 126.36594, how many digits do you place to the left of the decimal point in the product, or the number that results from the multiplication? Do you use 5 digits, or 2 digits, or something in between?
When integers are used to store positional information these problems are avoided. It does, however raise another important question.
What does this mean for the individual working with the Polaris Geometry Framework?
"If I can only use integer values to define the coordinates of my geometries", you might ask, "how do I represent a coordinate with fractional values?". It is important to recognize that fractional values are really not necessary. Any number expressed as a floating point number can also be expressed as an integer. The way to make this conversion is to take the smallest fractional unit you want to store and make that equal to 1 whole unit in your unit system. An example will make this easier to understand.
Example
Joe has a group of 3D points that he would like to represent in a LocusXML document using Polaris Geometries. He has computed the values of each coordinate to the 1/100 of a foot. Here is the coordinate for the first of his 3D points:
Northing: 5121.23
Easting: 10263.85
Elevation: 4332.17
How would Joe represent this coordinate as part of a Polaris Geometry?
He needs to make the smallest fractional unit equal to one whole unit in his unit system. In this particular case, Joe's smallest fractional unit is 1/100 of a foot. In order to make 1/100 of a foot equal to one whole unit in his unit system, Joe must multiply all of his values by 100. This will remove the fractional portion of his coordinates values, and Joe will be left with coordinates that are rperesented soley by integers. Does this change the relationship between those coordinates. No! Joe only has to remember that one whole unit is now equal to 1/100 of a foot instead of 1 whole foot.
After the conversion, the first of Joe's 3D points now looks like this:
Northing: 512123
Easting: 1026385
Elevation: 433217
What about rounding? What happens when Joe is permorming a calculation that will split a value in half? If we now round that value, one or more of Joe's coordinates involved in the calculation could be off by 1/100 of a foot. This demonstrates an important point!
When determining the smallest fractional unit that you want to convert to 1 whole unit, take into consideration the rounding of coordinate values that occurs in calculations or operations applied to those coordinates.
In our example, Joe might want to make 1/1000 of a foot equal to one whole unit, so that rounding errors are avoided.
Using only integer values in coordinates "snaps" all geometires to a fixed grid where the distance between the intersection of the grid lines is equal to the smallest fractional unit being stored. This forces the person creating or defining the positinal data to consider the precision of that data. It forces them to choose a reasonable level of precision that will be reflected in the coordinate values of his data. It is only possible to locate spatial objects in the real world to a certain degree of precision. The requirement to store coordinates with integer values reflects this reality.
