Recent from talks
Nothing was collected or created yet.
ISO 6709
View on WikipediaThis article relies largely or entirely on a single source. (July 2020) |
This article needs to be updated. The reason given is: was written before current (third) edition of the standard. (May 2023) |
| Geodesy |
|---|
ISO 6709, Standard representation of geographic point location by coordinates, is an international standard for representation of latitude, longitude and altitude for geographic point locations.
The first edition (ISO 6709:1983) was developed by ISO/IEC JTC 1/SC 32. Later the standard was transferred to ISO/TC211, Geographic information/Geomatics in 2001. The committee completely revised the second edition (ISO 6709:2008). There was a short technical corrigendum (ISO 6709:2008/Cor 1:2009) released in 2009.[1] The third edition ISO 6709:2022 was published in 2022.[2]
The second edition consists of a main part and eight annexes (Annexes A through H). The main part and Annexes A and C give encoding-independent general rules to define items to specify geographic point(s). Annex D suggests a display style for human interface. Annexes F and G suggest styles of XML expression. Annex H suggests string expression, which supersedes the first edition of the standard.
General rules
[edit]Items
[edit]A geographical point is specified by the following four items:
- First horizontal position coordinate (Φ or y), such as latitude (negative number south of equator and positive north of equator)
- Second horizontal coordinate (λ or x), such as longitude (negative values west of Prime Meridian and positive values east of Prime Meridian)
- Vertical coordinate, i.e. height or depth (optional)
- Identification of coordinate reference system (CRS) (optional)
The first three items are numerical values called coordinates. The CRS gives the relationship between the coordinates and a point on the earth. The identification of CRS could be a full description of properties defined in ISO 19111; only an identifier given by some registry (such as EPSG) is used in most cases, since only such identification is enough for most information exchange purposes.
Order, sign, and units
[edit]Order, positive direction, and units of coordinates are supposed to be defined by the CRS. When CRS identification is missing, the data must be interpreted by the following conventions:
- Latitude comes before longitude
- North latitude is positive
- East longitude is positive
- Fraction of degrees (decimal degrees) is preferred in digital data exchange, while sexagesimal notation is tolerated for compatibility
There is no such interpretation rule for vertical coordinates.
Representation at the human interface (Annex D)
[edit]When there is no guideline given from the user community, the following styles are suggested:
- Coordinate values (latitude, longitude, and altitude) should be delimited by spaces.
- The decimal point is a part of the value, thus must usually be configured by the operating system.[a]
- Multiple locations should be represented by multiple lines.
- Latitude and longitude should be displayed by sexagesimal fractions (i.e. minutes and seconds).
- When minutes and seconds are less than ten, leading zeroes should be shown.
- Degree, minutes and seconds should be followed by the symbols ° (U+00B0), ′ (U+2032), and ″ (U+2033), without spaces between the number and symbol.
- North and south latitudes should be indicated by N and S following immediately after the digits.
- East and west longitudes should be indicated by E and W following immediately after the digits.
- Units of elevation or depth should be given by symbols, immediately after the digits.[b]
- Elevation below zero-level reference or depth above reference level should be indicated by a minus sign − (U+2212).
Examples:
- 50°40′46″N 95°48′26″W 123.45m
- 50°03′46″S 125°48′26″E 978.90m
The standard does not specify how coordinates at the equator, prime meridian or antimeridian should be written.
XML representation (Annex F)
[edit]The XML representation based on the conceptual model of Annex C uses XML namespace http://www.isotc211.org/2006/gpl[permanent dead link]. However, there is no published XML schema at the time of writing (August 2011).
<gpl:GPL_CoordinateTuple xmlns:gpl="http://www.isotc211.org/gpl">
<gpl:tuple srsName="urn:ogc:def:crs:EPSG:6.6:4326">
35.89421911 139.94637467
</gpl:tuple>
</gpl:GPL_CoordinateTuple>
String expression (Annex H)
[edit]A string expression of a point consists of latitude, longitude, height or depth, CRS identifier, and trailing solidus (/) without any delimiting character. When height or depth is used, there must be CRS identifier.[c]
Latitude
[edit]Latitude is a number preceded by a sign character. A plus sign (+) denotes northern hemisphere or the equator, and a minus sign (-) denotes southern hemisphere.[d]
The integer part of the number is a fixed length. The number of digits in that part indicates the units, thus leading zero(es) must be filled when necessary. The fractional part must have the appropriate number of digits to represent the required precision of the coordinate.
| num. digits | units | format | example |
|---|---|---|---|
| 2 | deg | ±DD.D | +40.20361 |
| 4 | deg, min | ±DDMM.M | +4012.22 |
| 6 | deg, min, sec | ±DDMMSS.S | +401213.1 |
Longitude
[edit]Longitude is a number preceded by a sign character. A plus sign (+) denotes east longitude or the prime meridian, and a minus sign (-) denotes west longitude or 180° meridian (opposite of the prime meridian).[e]
Rules about the number of digits are the same as for latitude.
| num. digits | units | format | example |
|---|---|---|---|
| 3 | deg | ±DDD.D | -075.00417 |
| 5 | deg, min | ±DDDMM.M | -07500.25 |
| 7 | deg, min, sec | ±DDDMMSS.S | -0750015.1 |
Height or depth
[edit]- When height or depth is present, CRS identifier must follow.
- Positive direction and units are defined by CRS.[f]
- Negative number does not necessarily mean position below reference level.
- Positive is up for height, down for depth.
CRS identifier
[edit]The CRS identifier begins with "CRS". There are three styles:
- When a registry provides online resolver, CRS<url>
- When a registry is offline, CRSregistry:crsid
- When the data creator provides full definition of CRS using ISO 19111, CRS<CRSID>
The example of original Annex H always use "CRSWGS_84".
Examples
[edit]- Atlantic Ocean +00-025/
- France +46+002/
- Paris +48.52+002.20/
- Eiffel Tower +48.8577+002.295/
- Paris +48.52+002.20/
- Mount Everest +27.5916+086.5640+8850CRSWGS_84/
- North Pole +90+000/
- Pacific Ocean +00-160/
- South Pole -90+000+2800CRSWGS_84/
- United States +38-097/
- New York City +40.75-074.00/
- Statue of Liberty +40.6894-074.0447/
- New York City +40.75-074.00/
See also
[edit]Notes
[edit]- ^ Probably the intention is that the locale environment should not be overridden.
- ^ This is different from SI style guides.[disputed – discuss]
- ^ Height without CRS identifier was allowed in the first edition, but not today. Ending with longitude is still allowed.
- ^ Annex H allows letters
NandSas sign characters, but gives no examples. - ^ Annex H allows letters
EandWas sign characters, but gives no examples. - ^ This is different from the 1983 edition.
References
[edit]- ^ "ISO 6709:2008/Cor 1:2009 -". ISO. Archived from the original on 4 August 2016. Retrieved 8 June 2016.
- ^ "ISO 6709:2022". www.iso.org. Archived from the original on 26 May 2023. Retrieved 26 May 2023.
External links
[edit]Standards
[edit]- Catalogue entry for ISO 6709:2022 (Edition 3)
- Final draft of ISO 6709:2008 (archived)
- Profile by W3C GeoXG
Implementations
[edit]- Point Location 6709 - an open-source Java parser and formatter on GitHub
- Point Location 6709 - an open-source JavaScript implementation on GitHub
- C# Implementation Archived 2011-08-20 at the Wayback Machine at Codeplex
- Objective-C Implementation on GitHub
ISO 6709
View on GrokipediaIntroduction
Scope and Objectives
ISO 6709:2022 defines a geographic point location as a position on, above, or below the Earth's surface specified by a coordinate tuple consisting of latitude and longitude, with optional height or depth values.[1] This representation may include an optional coordinate reference system (CRS) identifier to specify the datum and other parameters for unambiguous positioning.[3] The primary objectives of the standard are to ensure compatibility across diverse geographic information systems by maintaining consistency with prior editions, while supporting both decimal degrees and sexagesimal (degrees, minutes, seconds) notations for latitude, longitude, height, and depth.[1] It facilitates unambiguous representation of these coordinates in both digital data interchange formats and human-readable forms, promoting universal interpretability in applications such as mapping, navigation, and geospatial data exchange.[3] The standard applies specifically to the representation of single 2D or 3D geographic points on Earth and excludes methods for non-coordinate-based location descriptions, coordinate transformations, or map projections.[1] Clause 4 of ISO 6709:2022 delineates this scope, emphasizing text string formats for electronic exchange and simpler structures for visual or manual use.[3] Clause 5 provides normative references, including ISO 19111:2019 for definitions of coordinate reference systems, ensuring alignment with broader geospatial standards.[3]Development History
The first edition of ISO 6709, published in May 1983, established a variable-length format for representing latitude, longitude, and altitude using degrees, minutes, seconds, and decimal notations to facilitate data interchange in geographic point locations.[4] This edition was initially developed under the auspices of ISO/IEC JTC 1/SC 32, which focuses on data management and interchange standards.[5] In 2001, responsibility for the standard was transferred to ISO/TC 211, the technical committee dedicated to geographic information and geomatics, to align it with evolving needs in digital spatial data standardization.[6] The second edition, ISO 6709:2008, represented a technical revision that canceled and replaced the 1983 version, expanding the scope to include coordinate representations suitable for both human-readable and machine-interchangeable formats, such as XML schemas and alphanumeric strings.[2] A technical corrigendum, ISO 6709:2008/Cor 1:2009, was issued in January 2009 to address minor errors and clarifications in the 2008 edition.[7] This edition introduced eight informative annexes (A through H) detailing various representation methods, including sexagesimal notations, decimal degrees, and integration with geographic information systems.[8] The third edition, ISO 6709:2022, was published on September 27, 2022, marking a comprehensive update to enhance compatibility with modern digital environments while maintaining backward compatibility options from prior editions.[1] Key revisions included refined coordinate tuple structures for latitude, longitude, and optional height or depth, along with explicit support for coordinate reference systems (CRS) and temporal associations.[9] These changes were driven by the need to harmonize with other ISO/TC 211 standards, such as ISO 19111 on spatial referencing by coordinates, to ensure consistent geospatial data exchange; to clarify normative requirements for broader applicability; and to accommodate advances in geodesy and digital data handling since the 1983 edition.[9]General Principles
Coordinate Elements
ISO 6709 defines the geographic point location (GPL) through a set of coordinate elements that describe a position on or near the Earth's surface. The primary elements are latitude and longitude, which together form the horizontal position in a geodetic coordinate system. Latitude represents the angular distance north or south of the Equator, measured in degrees from -90° (South Pole) to +90° (North Pole). Longitude represents the angular distance east or west of the Prime Meridian, measured in degrees from -180° to +180°. These angular measures are geodetic, referencing an ellipsoidal model of the Earth.[1][9] In addition to the primary elements, ISO 6709 includes optional vertical components to specify positions above or below the reference surface. Height denotes the vertical position relative to the reference surface (such as the ellipsoid), expressed in meters, with positive values indicating upward (above) and negative values downward (below). Depth denotes the vertical position relative to the reference surface (such as the ellipsoid), expressed in meters, with positive values indicating downward (below) and negative values upward (above). These vertical elements enhance precision for applications requiring altitude or submergence data.[1][10] The Coordinate Reference System (CRS) identifier is another optional element that unambiguously defines the reference frame for the coordinates, such as the datum, ellipsoid, and prime meridian used. Common identifiers include EPSG codes, like EPSG:4326 for WGS 84. The CRS ensures interoperability across systems; the CRS must be identified to ensure unambiguous positioning; without it, the location representation is ambiguous. Sign conventions follow established geodetic practice, with positive latitude for north and negative for south, and positive longitude for east and negative for west.[1][9][11]Representation Conventions
ISO 6709 establishes standardized conventions for the representation of geographic coordinates to ensure unambiguous interchange and consistency across systems. The coordinate tuple follows a specific order: latitude first, followed by longitude, with optional height or depth, and an optional coordinate reference system (CRS) identifier.[11] The sign convention uses positive values for north latitudes and east longitudes, and negative values for south latitudes and west longitudes, eliminating the need for directional letters such as N, S, E, or W in core machine-readable representations. For height, positive values indicate upward and negative downward relative to the reference surface. For depth, positive values indicate downward and negative upward relative to the reference surface. This approach promotes numerical simplicity and compatibility in digital processing.[11][10] Units for angular coordinates prioritize decimal degrees for machine-readable formats to facilitate precise computation and data exchange, while sexagesimal notation (degrees, minutes, seconds) is permitted for human-readable contexts. Height or depth is expressed in meters relative to the ellipsoid or other surface defined by the CRS, unless otherwise specified. Precision in decimal degrees is determined by the application's requirements, with the least significant digit defining resolution; conversions to sexagesimal follow standard rounding practices to maintain accuracy without mandating fixed decimal places.[11][10] The 2022 edition maintains backward compatibility with the 2008 version, particularly in coordinate tuple structure and basic representations, while enhancing clarity for digital interchange requirements such as explicit CRS identification.[11]Representation Formats
Human Interface Format
The human interface format specified in ISO 6709:2022, defined in Clause 7, provides guidelines for presenting geographic point locations (GPL) in a human-readable manner suitable for end-user interfaces, such as screens, maps, and documents. This format uses a simple, labeled structure with delimiters like colons and commas to represent latitude, longitude, and optionally height or depth, ensuring clarity and unambiguity. It supports decimal degrees primarily, with provisions for sexagesimal notations within the labeled framework, and requires explicit coordinate reference system (CRS) identification if not the default (e.g., WGS 84).[1][11] Key elements include labels such as "lat:", "lon:", and "h:" followed by signed decimal values, with units for height (e.g., meters) and CRS notation. For example, a representation might appear as "lat: 40.2036, lon: -75.0042, h: +10 m CRS: EPSG:4326". Positive values imply north/east/upward, negative south/west/downward, though explicit signs are used. If the CRS differs from the default, it must be indicated, such as using EPSG codes or URIs, to avoid positioning ambiguity. These conventions align with ISO 19111 for CRS handling.[1][11] Guidelines emphasize separating the coordinate string from surrounding text, using parentheses or dedicated fields for legibility in user interfaces. Decimal degrees are recommended for precision in digital contexts, while sexagesimal can be used for intuitive readability (e.g., "lat: 40° 12′ 13″ N, lon: 75° 00′ 15″ W"). Annex B (informative) provides compatible styles, including mixed formats, to support legacy systems. The 2022 edition clarifies usage for mixed notations and strengthens CRS requirements, enhancing interoperability while preserving readability principles from prior editions.[1][11]XML Format
The 2008 edition of ISO 6709 (ISO 6709:2008) provided a structured XML encoding for geographic point locations using the Geography Markup Language (GML) as defined in ISO 19136, to support interoperability in geospatial data exchange. This format used XML schemas for coordinate tuples, with decimal degrees for latitude and longitude, optional height or depth, designed for machine parsing. Annex G (informative) included examples of XML fragments compatible with GML.[2] The namespace was http://www.isotc211.org/2006/gpl, with core structure gml:Pointgml:poslat lon [height]</gml:pos></gml:Point>, ordered latitude-longitude. For instance:<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>50.0795725 -1.2345678</gml:pos>
</gml:Point>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>50.0795725 -1.2345678</gml:pos>
</gml:Point>
String Format
The string format in ISO 6709 provides a compact, linear notation for representing geographic point locations, optimized for machine-readable data interchange and digital parsing. Specified in Annex H of the 2008 edition and revised in Clause 6 of the 2022 edition, it expresses coordinates as a single tuple of signed decimal degrees for latitude and longitude, with optional signed height or depth in meters, and an optional coordinate reference system (CRS) identifier. This format prioritizes simplicity and unambiguity, using delimiters to separate elements without spaces between core coordinate values. The 2022 edition enhances parsability and CRS integration per ISO 19111, maintaining compatibility with prior versions.[1] The basic syntax follows the structure LatLon[/Height][ CRS], where latitude (Lat) and longitude (Lon) are concatenated directly after their respective signs (positive for north/east, negative for south/west), forming a continuous string like "+40.7128-74.0060". Latitude always precedes longitude, both in decimal degrees. The optional height or depth follows a forward slash delimiter, expressed as a signed numeric value in meters (e.g., "/10" for 10 m above the reference surface or "/-5" for 5 m depth below it). If no height is included, the slash and value are omitted. The CRS identifier, if present, is appended after a space or the height slash, using standardized codes such as "EPSG:4326" for the WGS 84 geodetic CRS or "CRS84" for the OGC equivalent. For example, the full string "+40.7128-74.0060/10 EPSG:4326" denotes a point at 40.7128° N, 74.0060° W, 10 m height, in the EPSG:4326 system.[1][9] This format is normative for digital string representations in the 2022 edition. Legacy support includes sexagesimal notation enclosed in quotes (e.g., "+40°42'46.08"-74°00'21.6""), but decimal degrees are mandated for new implementations to facilitate automated processing. No spaces are permitted within the coordinate elements to avoid ambiguity in parsing.[1][9] Precision guidelines recommend at least four decimal places for latitude and longitude to achieve sub-kilometer accuracy suitable for most applications, with higher precision (up to six decimals) for surveying needs; trailing zeros are omitted to minimize string length. Height values follow similar decimal conventions, typically to two places for meter-level resolution. Validation ensures latitude falls between -90 and +90 degrees, longitude between -180 and +180 degrees, and height within context-appropriate bounds, rejecting invalid ranges to maintain data integrity. Sign conventions align with ISO 19111, where positive values indicate north or east directions and upward elevation, while negative denote south, west, or downward depth.[1][9]Examples and Applications
Usage Examples
One practical application of ISO 6709 involves representing the geographic coordinates of New York City, located at 40.7128° N latitude and 74.0060° W longitude.[12][1] In the human-readable format specified by the standard, this point is expressed as 40° 42′ 46″ N 74° 00′ 36″ W, using degrees, minutes, and seconds with directional indicators for clarity in non-digital contexts.[1] The same New York City coordinates can be conveyed in the compact string format of ISO 6709 as +40.7128-74.0060, where the positive sign denotes northern latitude, the negative sign indicates western longitude, and decimal degrees provide precision suitable for electronic data exchange.[1] This string omits spaces and separators to facilitate machine parsing while adhering to the standard's conventions for sign placement and order (latitude before longitude).[1] For scenarios requiring height or a coordinate reference system (CRS), ISO 6709 supports integration with formats like Geography Markup Language (GML). An example for New York City at an approximate height of 10 meters above sea level in the EPSG:4326 CRS (World Geodetic System 1984) is rendered in XML as:<gml:pos>40.7128 -74.0060 10</gml:pos>
<srsName>EPSG:4326</srsName>
<gml:pos>40.7128 -74.0060 10</gml:pos>
<srsName>EPSG:4326</srsName>
Implementations
ArcGIS handles representations compliant with ISO 6709:2008 for geographic point locations, facilitating accurate conversion between formats in vector data processing.[14] This support ensures compatibility with the standard's decimal degree conventions, including latitude preceding longitude, in operations like reprojection and spatial querying. Additionally, dedicated Python libraries like iso6709 provide explicit parsing for ISO 6709 formatted strings into decimal coordinates, supporting applications in data validation and geospatial analysis.[15] In web standards, GeoJSON as defined in RFC 7946 specifies coordinate arrays in longitude-latitude order for positions, which complements ISO 6709 by providing a structured format for geospatial data exchange while adhering to related conventions for decimal representation and axis ordering in broader OGC ecosystems.[16] Although GeoJSON prioritizes x-y (longitude-latitude) sequencing aligned with simple feature access standards, ISO 6709's emphasis on latitude-longitude for human-readable interchange helps inform consistent handling in web-based geographic services.[17] Mapping software implementations frequently output coordinates in formats compliant with ISO 6709. The Google Maps JavaScript API utilizes a LatLng class where latitude precedes longitude in decimal degrees, directly aligning with the standard's representation conventions for point locations.[18] Similarly, OpenStreetMap's Overpass API employs ISO 6709 standard order for bounding box specifications, with latitude values listed first (southern-most latitude, western-most longitude, northern-most latitude, eastern-most longitude), ensuring precise query bounding in vector data retrieval.[19] The 2022 edition of ISO 6709 maintains backward compatibility while expanding options for coordinate reference system identification.[1] OGC implementations, such as those in Esri's ArcGIS Server, reference ISO 6709 alongside WMS/WFS protocols to support interoperable geospatial data serving.[20] ISO 6709 addresses key challenges in geographic data handling, notably the persistent confusion between latitude-longitude and longitude-latitude ordering in legacy systems. By mandating latitude before longitude in its primary representation, the standard mitigates risks of misinterpretation, such as erroneous positioning in navigation or mapping applications, thereby promoting safer and more reliable data interchange across diverse platforms.[21] This clarification has been instrumental in resolving ambiguities in international geospatial workflows, aligning with safety-oriented guidelines in standards development.[22]References
- https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL