NMEA 0183: LF Line Endings Instead of CRLF
The same sentences terminated with a bare LF rather than the CR LF the standard mandates: what you get after a log passes through a text editor or a Unix pipeline. Parsers that strip only "\r\n" leave a stray character on every line and then fail the checksum.
$GPGGA,120000.00,4703.8414,N,01228.9205,W,1,08,0.9,12.1,M,49.0,M,,*4D
$GPRMC,120000.00,A,4703.8414,N,01228.9205,W,3.20,41.0,010126,,,A*41
$GPGSA,A,3,03,07,11,18,22,25,29,31,,,,,1.8,0.9,1.5*35
$GPVTG,41.0,T,,M,3.20,N,5.93,K,A*36
$GPGSV,3,1,11,03,72,132,42,07,45,215,39,11,33,058,35,18,25,301,31*74
$GPGSV,3,2,11,22,64,275,44,25,18,142,28,29,52,047,40,31,11,320,22*71
$GPGSV,3,3,11,08,07,198,19,,,,,,,,*4E
$GPGGA,120015.00,4703.9709,N,01228.6852,W,1,08,0.9,18.9,M,49.0,M,,*42
$GPRMC,120015.00,A,4703.9709,N,01228.6852,W,3.25,41.4,010126,,,A*4D
$GPGSA,A,3,03,07,11,18,22,25,29,31,,,,,1.8,0.9,1.5*35
$GPVTG,41.4,T,,M,3.25,N,6.02,K,A*3C
$GPGGA,120030.00,4704.0978,N,01228.4512,W,1,08,0.9,24.8,M,49.0,M,,*46
$GPRMC,120030.00,A,4704.0978,N,01228.4512,W,3.30,41.8,010126,,,A*4F
$GPGSA,A,3,03,07,11,18,22,25,29,31,,,,,1.8,0.9,1.5*35
$GPVTG,41.8,T,,M,3.30,N,6.11,K,A*36
$GPGGA,120045.00,4704.2323,N,01228.2161,W,1,08,0.9,30.5,M,49.0,M,,*4C
Specifications
- Format
- NMEA 0183
- Talker
- GP (GPS)
- Crs
- WGS 84 (EPSG:4326)
- Encoding
- ASCII
- Checksum Algorithm
- XOR of bytes between $ and *
- Date
- 2026-01-01
- Seed
- 20260807
- Sentences
- 16
- Line Endings
- LF (the standard requires CRLF)
- All Checksums Valid
- true
- Defect
- line terminator does not match NMEA 0183, which mandates CR LF
Testing contract
Expected to recover- Scenario
- Parse the log with a reader that expects CR LF terminators.
- Expected result
- All 16 sentences still verify because the checksum covers only the bytes between $ and *; a reader that assumes CR LF must tolerate the bare LF rather than failing every line.
What is a .nmea file?
An .nmea file is a log of NMEA 0183 sentences, the ASCII protocol GPS and marine electronics use. Each line begins with `$` and a five-character talker-and-type identifier such as GPGGA, GPRMC, or GPGSV, carries comma-separated fields, and ends with `*` and a two-digit XOR checksum. Positions are encoded as degrees-and-decimal-minutes with a separate hemisphere field, not as decimal degrees.
How to use this file
Use an example .nmea file to test GPS log parsers and track converters, verifying checksum validation, correct degrees-minutes-to-decimal conversion, and sensible handling of sentences emitted before a fix is acquired.
How to use this file for testing
“NMEA 0183: LF Line Endings Instead of CRLF” is a deterministic Testaroo fixture for Geospatial, Error handling, Encoding detection. GeoJSON, GPX, and KML files with points, lines, polygons, and tracks, for testing map tools, route parsers, and geo importers.
Documented properties for this file: seed 20260807 · ASCII · LF (the standard requires CRLF). Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Geospatial fixtures publish one invented territory across formats, with the coordinate reference system and feature counts documented in specs. Convert or reproject and diff against the twin in the same group; edge-case geometries state exactly which assumption they are built to break.
Generated by generation/geospatial.py. Free for any use, no attribution required, license.
Related files
- geojsonGeoJSON Feature: Null GeometryRFC 7946 permits `"geometry": null` for a feature with attributes but no location. Readers that assume every feature has coordinates crash here, and writers that emit an empty Point instead corrupt the record's meaning.
- geojsonGeoJSON Geometry: GeometryCollectionA single Feature whose geometry is a GeometryCollection of a Point, a LineString and a Polygon. Many simple readers flatten or silently drop these, and many writers cannot produce them at all, so it is the usual place a conversion loses data.
- geojsonGeoJSON, Intentionally Invalid: Coordinates as JSON StringsIntentionally invalid: the file is perfectly good JSON but the coordinates are quoted strings, which RFC 7946 does not allow. It is exactly what a CSV-to-GeoJSON script produces when it forgets to cast, and a permissive reader will coerce it and hide the bug.
- geojsonGeoJSON, Intentionally Invalid: Hole Outside Its ShellIntentionally invalid: the second ring is a whole separate parcel filed as an interior ring of the first, which OGC Simple Features forbids. It is what happens when a MultiPolygon is flattened into a Polygon by concatenating rings.
- geojsonGeoJSON, Intentionally Invalid: Latitude Before LongitudeIntentionally invalid: the five towns with their coordinates written latitude-first. RFC 7946 fixes the order as longitude then latitude, and this is the mistake that arrives via an EPSG-URN-ordered source such as the GML twin in the territory subcategory.
- geojsonGeoJSON, Intentionally Invalid: Latitude Outside -90 to 90Intentionally invalid: latitude 95, five degrees past the north pole. This is the value that appears when longitude and latitude have been swapped somewhere upstream, so catching it early usually finds an axis-order bug rather than a data-entry one.
