Geocoordinate Normalization Prompt

This prompt is for GIS specialists, logistics engineers, and data pipeline developers who need to convert a heterogeneous stream of geocoordinates into a single, predictable format for storage, analysis, or API consumption. The core job is to accept a coordinate string in any common notation—decimal degrees (DD), degrees-minutes-seconds (DMS), Universal Transverse Mercator (UTM), or Military Grid Reference System (MGRS)—and return a normalized decimal degree pair with a specified precision. The ideal user is building an ingestion pipeline where downstream systems (mapping libraries, geospatial databases, route optimizers) reject non-standard formats.

Use this prompt when you control the input string but cannot control its format, such as when ingesting user-submitted locations, scraping coordinates from reports, or merging datasets from different field collection tools. The prompt is designed to validate coordinate ranges, interpret hemisphere indicators (N/S/E/W, +/-, grid zone letters), and flag coordinates that fall outside an expected bounding box. It is not a geocoder; do not use it to convert addresses, place names, or landmarks into coordinates. For those tasks, use a dedicated geocoding API and then pipe the results into this prompt for final normalization.

Before deploying, define your precision requirement (e.g., 5 or 6 decimal places) and your expected bounding box. A logistics team tracking deliveries in Texas should set a bounding box that rejects coordinates in the Pacific Ocean, turning a silent data error into a reviewable flag. Always route low-confidence outputs or bounding-box violations to a human review queue rather than silently ingesting them. This prompt is a normalization step, not a data quality panacea—it will not fix coordinates that were collected incorrectly at the source.

This prompt template is the core instruction set for normalizing geocoordinates. It is designed to be copied directly into your prompt management system, API call, or orchestration layer. The template uses square-bracket placeholders for all dynamic inputs, allowing you to inject the raw coordinate string, a target output schema, bounding box constraints, and a risk policy without rewriting the core logic. The instructions enforce a strict chain of operations: parse the input format, validate the coordinate ranges, convert to the target precision, and flag any values that fall outside expected boundaries.

codeCopy
You are a precise geocoordinate normalization engine. Your task is to parse a raw coordinate input, identify its format, validate its values, and convert it to a standard decimal degree representation.

[INPUT]

[CONSTRAINTS]

Follow these steps exactly:
1.  **Format Detection**: Determine if the input is in Decimal Degrees (DD), Degrees Minutes Seconds (DMS), Universal Transverse Mercator (UTM), or Military Grid Reference System (MGRS).
2.  **Value Extraction**: Extract the numeric components for latitude and longitude (or northing, easting, zone for UTM/MGRS).
3.  **Range Validation**: Check that extracted values are within valid ranges for their format. For DD, latitude must be between -90 and 90, longitude between -180 and 180. For UTM, easting must be between 100,000 and 999,999 meters. For DMS, minutes and seconds must be less than 60.
4.  **Conversion**: Convert the extracted values to Decimal Degrees with a precision of [PRECISION] decimal places. If the input is UTM or MGRS, perform the full projection conversion to WGS84 latitude and longitude.
5.  **Bounding Box Check**: If a bounding box is provided in [CONSTRAINTS], check if the final decimal degree coordinates fall within it. If not, set a `bounding_box_violation` flag to `true`.
6.  **Output Generation**: Return the result strictly according to the [OUTPUT_SCHEMA]. Do not include any explanatory text outside the JSON object.

[OUTPUT_SCHEMA]

To adapt this template for your application, replace the placeholders with concrete values at runtime. The [INPUT] placeholder should receive the raw, uncleaned coordinate string from your user or data source. The [CONSTRAINTS] placeholder is where you inject a natural-language description of your expected geographic area, such as "Coordinates must be within the continental United States (approx. 24°N to 49°N, -125°W to -66°W)." The [OUTPUT_SCHEMA] must be a strict JSON schema or a TypeScript interface definition that includes fields for the original input, detected format, decimal degree output, and any validation flags like bounding_box_violation. The [PRECISION] placeholder should be an integer, typically 5 or 6, to specify the number of decimal places required for your downstream GIS or logistics system. Avoid modifying the step-by-step instructions unless you need to add a custom validation rule specific to your data contract.

This prompt is designed to be called as a stateless function inside a data pipeline, API handler, or ETL job. The caller must supply the raw coordinate string, the expected precision, and an optional bounding box. The model returns a structured JSON payload that downstream systems can ingest directly. Because coordinate normalization is deterministic in principle but messy in practice, the harness must treat the model output as a candidate that still requires programmatic validation before it reaches a database or map service.

Wrap the prompt in a service that enforces a strict contract. Before calling the model, validate that the input is a non-empty string under 200 characters. After receiving the response, run a validator that checks: (1) the latitude and longitude fields are present and within [-90, 90] and [-180, 180] respectively, (2) the precision field matches the requested decimal places, (3) the format_detected field is one of the expected enum values, and (4) if a bounding box was provided, the normalized coordinates fall inside it. If the bounding-box check fails, route the record to a human review queue rather than silently accepting an out-of-area coordinate. Log every normalization attempt with the original input, the model's raw response, the validation result, and the final accepted or rejected status. This audit trail is essential for GIS and logistics teams who need to trace coordinate provenance.

Model choice matters. For high-throughput pipelines, use a fast model such as GPT-4o-mini or Claude Haiku with temperature set to 0. For ambiguous inputs that require reasoning about hemisphere defaults or MGRS grid zones, a more capable model may reduce the retry rate. Implement a single retry on validation failure: if the output fails schema or range checks, resubmit the same input with an additional instruction that includes the specific validation error. If the retry also fails, log the failure and route to the repair queue. Do not loop beyond one retry—coordinate strings that cannot be normalized in two attempts are likely malformed or require human interpretation. For regulated environments such as aviation or emergency services, always require human approval before normalized coordinates are used in operational systems, regardless of validation results.