For a UG32 corridor survey inquiry, define a crossing before asking for a crossing count. Two lines may meet at an endpoint, cross through one another, or occupy the same stretch of a drawing. Each is an intersection in ordinary conversation. They do not describe the same relationship in a GIS. Require the receiving register to distinguish the cases, retain the source line identifiers, and label uncertain physical relationships for review. A map intersection alone is not evidence of an asset connection, an obstruction or a safe place to fly.

Ask what the count will be used for

An infrastructure owner may need a list of places where a mapped path passes through a utility alignment. A maintenance planner might instead care about every place where the two datasets meet, including a path that ends at the alignment. Both teams can request a “crossing survey” and expect different rows. Start by asking which action follows from an entry. A list used to allocate desk reviews may sensibly include more candidates than a list used to assign individual site visits.

Write a short definition for each output class in language a reviewer can use. For example, say that an interior crossing is a point common to the interiors of both simple line features. Say that a boundary contact is a meeting without that shared interior. Keep a separate class for a shared segment. Name a fourth outcome, not determined, for a record that cannot be classified from the available geometry. This avoids treating a missing decision as a negative finding.

Do not call the first class a physical crossing unless separate evidence supports that wording. A two-dimensional diagram cannot show by itself whether two objects share a level, whether one is buried, or whether the mapped positions represent a current installation. Those are engineering and inventory questions. The spatial classification is still useful: it tells the reviewer which geometry triggered the record and how to reproduce it. It should not promise more than that.

Four pairs that expose an ambiguous specification

Draw one horizontal line from the left edge of a sheet to the right. Place a second line vertically through its middle and extend it on both sides. In this simple example the two interiors meet at one point. Now shorten the vertical line until it ends exactly at the horizontal one. There is still a common point, but only one line has that point in its interior. The receiving register should change its relationship label if that distinction matters to the contract.

For a third case, lay a second line along a short portion of the horizontal one. The common part now has length. Calling it a single crossing leaves the recipient unable to tell whether the intersection is a point or a stretch requiring a different inspection decision. Finally, move the vertical endpoint just clear of the horizontal line. A human viewing thick symbols may see contact, while the stored lines have no common point. This tests whether the reviewer is evaluating geometry or the ink used to display it.

These four pairs are deliberately abstract. They can be tested without a flight, without a sensitive asset map and without any claim about UG32 positioning performance. Agree the expected result for each pair, including whether it belongs in the buyer's count. If the owner elects to count endpoint contacts as well, that is a legitimate design decision. The important part is to make it explicit and preserve the underlying classification so another team can use a different summary later.

What the software predicate actually decides

The PostGIS definition of ST_Crosses gives a concrete implementation for testing a spatial relationship. For line against line, it looks for a zero-dimensional intersection of the interiors. Its companion ST_Touches definition describes a nonempty intersection with no interior intersection. Neither function knows what the buyer means by a utility crossing. The analyst chooses the question, runs the appropriate comparison, and converts the answer to a business label using a documented rule.

Insist on seeing the geometry types used in the example. An analyst comparing a line against a corridor polygon is asking a different question from one comparing two centre lines. A line entering a broad corridor is not necessarily crossing the alignment inside it. The polygon may be appropriate for a screening list, but the result should say corridor entry, not quietly inherit the label for a line-to-line crossing. When bidders use different representations, compare their definitions before comparing the numbers they return.

One junction can change class when a feature is split

Imagine that one source represents a long route as a single feature. A short branch crosses through it midway along both lines. In the next delivery the supplier cuts the long route into two records at the branch location, perhaps to assign separate inspection owners. The visible route has not moved. Yet the point that lay in the interior of the long record is now an endpoint of each daughter record. A relationship calculated on the new features can change even when all coordinates describing the site are unchanged.

This is the field lesson worth taking into a handover meeting. Ask for both the persistent route identity and the segment identities used in the calculation. Decide whether classification happens on individual segments, on a reconstructed route, or on both. Do not merge features merely to achieve a preferred answer. The segmentation may carry responsibility or inspection information that the recipient needs. Retain enough lineage to explain why a route-level result differs from a segment-level result.

Try the split deliberately on a copy of the example. Record the old line identifiers, the two new ones, the point geometry and the labels from each run. A buyer who sees two new rows can then decide whether they represent two records about one location or two separately actionable items. That decision belongs in the counting policy. A spatial predicate can reproduce its own result without resolving the maintenance team's unit of work.

Design a register that can survive a second delivery

Request fields for source dataset and revision, source feature keys, classification rule, resulting geometry type, review status and a stable project event identifier where appropriate. Agree how the identifier is assigned and how the recipient handles a split, merge or retirement. The original feature keys should remain visible even if a display layer combines records into a more readable map. Without them, an apparent increase in crossing count is hard to distinguish from a different partition of the same route.

Include the excluded cases in an accompanying exception table or summary. If an endpoint pair is omitted from the main count by design, a reviewer should not need to rediscover that policy by rerunning the entire job. Equally, a near miss should not be silently snapped into contact. Where a tolerance-based screen is useful, ask for its own label, units and evidence. Keep its candidates distinct from intersections found in the unmodified source geometry.

For delivery acceptance, choose a few records from both the included and excluded groups. Open their input geometries and recreate the classifications in the receiving environment. Check that any coordinate transformation or geometry repair was recorded and that the register identifies the actual version tested. A screenshot is useful for explaining the rule to a project sponsor, but it is not a substitute for the feature pair. A reviewer should be able to reconstruct the result after the original analyst has left the project.

Connect the test to the purchase order

Agree who can close a disputed record. A GIS technician can reproduce a point intersection; an asset owner may still need to decide whether the location belongs in a maintenance queue. Give those two decisions separate fields so the technical review can finish without implying that the asset owner has accepted an assignment.

Separate the aircraft decision from the processing deliverable. The UG32 mapping and inspection aircraft listing identifies a platform for a configuration inquiry. It does not specify which GIS predicates will be run, establish that an underground asset is in a certain place, or confer authority for corridor operations. Ask the supplier to identify the capture work, reference data, processing tools and reviewer responsibilities that are actually included. For unconfirmed equipment or service details, contact us for configuration details.

A related survey contour acceptance example illustrates a similar receiving problem: visually similar lines can mean different things when their numeric definition changes. Procurement teams ordering a first trial before a larger contract can also use the first article decision guide to distinguish approval of the trial evidence from acceptance of future deliveries. In each case, define the decision a particular piece of evidence supports instead of treating a successful demonstration as a blanket pass.

Browse the VTOL and fixed-wing range for aircraft context. To scope a corridor inventory quotation, send a redacted line pair from each class, the action each class triggers and the field names expected in the register. Request a worked return showing the original inputs and the chosen classification. That small exchange will tell you more about whether the proposed survey meets your operational need than an impressive crossing total without a counting rule.