Search files, editable visual templates, and live browser targets from one registry-backed directory. Filtered query views stay crawlable for links but are deliberately noindex; the stable taxonomy pages below remain the canonical search surfaces.
Page 6 of 7; 24 results per page.
The five towns in EPSG:4326 — the geographic source, in longitude/latitude degrees. All three files hold the same five places, so reprojecting any one of them and diffing against another scores your transform against a known answer rather than against another implementation of the same library.
A one-line sidecar naming the encoding of the .dbf. Without it a reader has to guess — usually cp1252 — and every non-ASCII attribute value comes back as mojibake, which is the single most common shapefile data-loss bug.
The parcel attribute table, joined to the .shp purely by record order — there is no key and no explicit link. Deleting a geometry without deleting its row shifts every subsequent attribute onto the wrong shape, silently.
Three Polygon records, one of which has two rings: the Mill Court parcel and its courtyard. Shapefile winds rings the opposite way to GeoJSON — exterior clockwise, holes anticlockwise — and it has no explicit hole marker, so winding is the only signal a reader has.
The parcel index, whose second entry is markedly longer than the others because that record carries two rings. Use it together with the roads index to check that seek logic handles multi-part records as well as multi-record files.
The one-line WKT that tells a reader what the .shp coordinates mean. Esri's flavour uses D_WGS_1984 and GCS_WGS_1984 rather than the OGC names and carries no EPSG authority code, so identifying it means matching the datum and spheroid rather than reading an ID.
The road attribute table, including a numeric field declared with two decimal places. DBF stores numbers as right-justified ASCII, so the declared width and decimal count are the only thing that says 9.40 is not 940.
Three single-part PolyLine records, each carrying its own bounding box, a part index and a run of little-endian coordinate doubles. PolyLine and Polygon share this layout, which is why the shape-type byte in the header is the only thing that distinguishes an open line from a closed ring.
Unlike the point index, these entries have different lengths because each PolyLine holds a different number of vertices. That makes it the useful case for testing seek logic — a reader that assumes a fixed stride reads the first record correctly and then garbage.
The attribute table as a dBase III file: fixed-width, space-padded, ASCII numerics. Field names are capped at ten characters and there is no type for dates-with-time or for nested values, which is why shapefile export loses so much of a modern schema.
The geometry half of a point shapefile: a 100-byte header carrying the shape type and bounding box, then five 20-byte Point records. The file is useless on its own — attributes live in the .dbf and the coordinate system in the .prj, which is the point of shipping the whole component set.
The index that lets a reader seek directly to record N of the .shp instead of walking the file. Its header duplicates the .shp header exactly, and a mismatch between the two is the most common way a hand-edited shapefile goes wrong.
A zipped shapefile containing a three-file polygon set with no .cpg, so the DBF encoding is undeclared. Zipping is how shapefiles are actually exchanged, because a bare .shp is meaningless without its sidecars — and it is the upload format most web GIS tools accept.
A zipped shapefile containing the full five-file point set — .shp, .shx, .dbf, .prj and .cpg. Zipping is how shapefiles are actually exchanged, because a bare .shp is meaningless without its sidecars — and it is the upload format most web GIS tools accept.
The sidecar that declares `attributes-cp1252.dbf` as ISO-8859-1. Note that the DBF also carries a language-driver byte in its header, and the two can disagree — which is exactly the ambiguity a reader has to resolve and document.
The sidecar that declares `attributes-utf8.dbf` as UTF-8. Note that the DBF also carries a language-driver byte in its header, and the two can disagree — which is exactly the ambiguity a reader has to resolve and document.
The same four accented attribute rows written in CP1252. Both files are exactly the same size because DBF fields are fixed-width in bytes, not characters — so the UTF-8 table fits fewer characters per field, and a reader that guesses the encoding produces mojibake rather than an obvious failure.
The same four accented attribute rows written in UTF-8. Both files are exactly the same size because DBF fields are fixed-width in bytes, not characters — so the UTF-8 table fits fewer characters per field, and a reader that guesses the encoding produces mojibake rather than an obvious failure.
The same territory quantized to only 100 steps, so rounding error reaches roughly 220 m and several vertices collapse onto the same grid cell. Use it to prove that a tolerance in your comparison code is actually being applied rather than accidentally passing.
Exactly what the shared-arc topology decodes to: two polygons whose rings are stitched from arcs 0, 1 and 2 with arc 0 reversed for the eastern parcel. Because that file is unquantized, this comparison is exact rather than tolerance-based.
Five town geometries that each carry both an `id` member and a `properties` object. TopoJSON keeps these separate, and converters that fold the id into properties (or drop it) break joins against an external attribute table.
Intentionally invalid: East Field references the shared arc forwards when it should use the reversed form, so its ring no longer closes. This is the single most common hand-editing mistake in TopoJSON, and it produces a plausible-looking file that renders as a torn shape.
The full territory quantized onto a 10,000-step grid with a transform block and delta-encoded arc positions — the default TopoJSON encoding. Rounding is bounded by the grid spacing, which over this 0.28-degree extent is about 2.2 m.
One topology carrying three separately named objects — towns, roads and areas — that all index into the same arc pool. This is how a single TopoJSON file ships what would otherwise be three layers, and readers that assume exactly one object silently show only the first.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
