A city council's survey team in Wellington, New Zealand, keeps its control-mark register in NZGD2000 / New Zealand Transverse Mercator 2000 (EPSG:2193), in an ArcGIS Pro 3.7 project. A contractor's field sheet lists marks by easting and northing: its covering note says NZTM 2000, but the file itself states no coordinate system. Other marks come from a download in longitude and latitude. The team wants one register its project loads, with no mark moved. Any GIS will do — ArcGIS Pro, QGIS or a script: you are graded on what you hand in.
The survey team keeps its control-mark register in NZGD2000 / New Zealand Transverse Mercator 2000 (EPSG:2193), in an ArcGIS Pro 3.7 project. Two inputs have arrived. Hand back one register the project can load, with every mark where LINZ surveyed it.
The contractor's field sheet, wellington-marks-field-sheet: a table with no geometry. Download it as CSV. The file states no coordinate system; the contractor's covering note says:
Easting and northing are NZGD2000 / New Zealand Transverse Mercator 2000 (EPSG:2193), in metres.
| field | type | meaning |
|---|---|---|
code | text | LINZ geodetic code, four characters |
name | text | Mark name |
mark_type | text | Mark type, as LINZ records it |
easting | number | Easting, metres |
northing | number | Northing, metres |
The CSV download also carries an empty geometry_wkt column, because the sheet has no geometry. The Data tab lists the sheet under EPSG:2193 because that is what the covering note says.
The marks layer, wellington-marks-lonlat: points in longitude and latitude, LINZ's NZGD2000 positions stored as GeoJSON, which defines its coordinates as WGS 84. Download the GeoJSON, or the Shapefile, whose .prj declares WGS 1984 and whose layer is named POINT. Its fields are code, name and mark_type, as above.
No mark is in both inputs.
| item | required |
|---|---|
| Format | A GeoPackage (.gpkg), or a zipped Shapefile (.shp, .shx, .dbf, .prj, .cpg) |
| Layer | geodetic_marks (a Shapefile named geodetic_marks.shp) |
| Coordinate system | EPSG:2193 declared, and the coordinates in it |
| Geometry | One point per mark: every mark from both inputs, none twice |
| Fields | code, name, mark_type and source, all text; other fields may stay |
code | The LINZ code as it arrived, on every record |
source | field_sheet for a mark from the field sheet, marks_layer for a mark from the marks layer |
Every mark must sit within 2 m of where LINZ surveyed it, and inside Wellington City: west, south, east, north 174.603, -41.364, 174.861, -41.187, in degrees.
code as text: if your GIS reads the CSV's code as a number, set its type (ArcGIS Pro honours a schema.ini file beside the CSV).These are where the teaching is. Read them twice.
A council survey team's control-mark register, kept in NZTM 2000 as Toitū Te Whenua Land Information New Zealand (LINZ) publishes its geodetic marks. The steps follow ArcGIS Pro 3.7's documentation: Define Projection, Project, XY Table To Point, Calculate Field, Merge and Create SQLite Database (Data Management Tools), JSON To Features and Export Features (Conversion Tools), Use an ASCII or text file, and the ArcGIS Pro 3.6 Geographic and Vertical Transformation Tables that the Project page links. Data: LINZ, CC BY 4.0. Modelled on Esri's documentation; Kharita is not affiliated with Esri.
Download the data from the Data tab, prepare it in the tool you use — QGIS, ArcGIS Pro, FME, GDAL or a script — and upload what came out.
Deliver as GeoPackage or Shapefile, layer geodetic_marks, in EPSG:2193.
Read shows what the file was read as; Submit grades it. The file itself is not kept — what was read from it is.
9 scored, 0 informational
Handed over in the agreed format and layer
10%Declared coordinate system of the register
10%Every mark falls inside Wellington City
15%The register's fields are there, under their names
5%Code, name, mark type and source are stored as text
5%Each mark records which input it came from
5%One record per mark code
3%Every record carries its mark code
2%Every mark, with its attributes, where LINZ surveyed it
45%