How are “on the line” cases handled (i.e., data on a boundary between 2 or 4 adjacent squares)?
By definition, data “on the line” are always into the next “higher” square in absolute terms (e.g. 10 rather than 9; -10 rather than -9), subject to the two types of special case described above (Q.8). This means that, for example, a point with latitude 10 N is encoded within a 10-degree square extending from 10-20, not 0-10 degrees. By extension, a search for data in a square which is notionally 0-10 is in reality a search for data in the range 0-9.9999… , which may have to be borne in mind in some circumstances. One caveat to this applies to the endpoints of lines, or local maximum extents of polygons, where these occur on a boundary but the line or polygon does not extend into the next “higher” square. In these cases, the last point is not coded since to do so would result in an incorrect representation of the line or polygon concerned (e.g. a square extending from 9-10 in both directions would appear to extend across four squares, 9-11 in both directions, instead of the expected
Related Questions
- How does OR mapping deal with cases where data is not fully committed to the database? How would rollback take place on complex queries?
- How much overlap should be allowed between adjacent precision data products from the same flight line?
- How are "on the line" cases handled (i.e., data on a boundary between 2 or 4 adjacent squares)?
