Saltabel verbatim coordinates

[Peter Desmet]

The documentation by Frederic gives a clear indication on how the verbatim coordinates were translated to coordinates in Recorder and how we should treat them:

Some thoughts

Due to point 2, the UTM 5km coordinates are often not the centroid of the used square. This doesn't affect much in our mapping: all fields are still populated correctly, except georeferenceRemarks (see further).

As described in point 1, UTM 1km coordinates are the centroids (25 per UTM 5km square):

As you can see in the screenshot above, the points line up nicely with the grid (which is in WGS84), which to me indicates that Frederic assumed a WGS84 geodeticdatum and mapped the codes to a WGS84 grid. That means we should use WGS84 in our verbatimSRS.

Also, until now we've used a spatial join to get back the UTM codes, while these should actually be in the database (Code van UTMhok), which is a much better why of deriving original = verbatim coordinates. I would try to get them from there if possible.

My suggestions for the mapping:

1. UTM 1km

• verbatimCoordinates: UTM square code, derived from Code van UTMhok, not from a spatial join
• verbatimLatitude:
• verbatimLongitude:
• verbatimCoordinateSystem: UTM 1km
• verbatimSRS: WGS84
• decimalLatitude: latitude
• decimalLongitude: longitude
• geodeticDatum: WGS84
• coordinateUncertaintyInMeters: 707
• georeferenceRemarks: coordinates are centroid of used grid square

2. UTM 5km + deelgemeente

If we can indeed identify those in the database:

• verbatimCoordinates: UTM square code, derived from Code van UTMhok, not from a spatial join
• verbatimLatitude:
• verbatimLongitude:
• verbatimCoordinateSystem: UTM 5km
• verbatimSRS: WGS84
• decimalLatitude: latitude
• decimalLongitude: longitude
• geodeticDatum: WGS84
• coordinateUncertaintyInMeters: 3536 It should be smaller than this, but it's difficult to make an educated guess, so we assume that the district can be larger than the UTM 5km grid and take the uncertainty of the grid.
• georeferenceRemarks: coordinates are centroid of intersection between used grid square and district

3. UTM 5km

• verbatimCoordinates: UTM square code, derived from Code van UTMhok, not from a spatial join
• verbatimLatitude:
• verbatimLongitude:
• verbatimCoordinateSystem: UTM 5km
• verbatimSRS: WGS84
• decimalLatitude: latitude
• decimalLongitude: longitude
• geodeticDatum: WGS84
• coordinateUncertaintyInMeters: 3536
• georeferenceRemarks: coordinates are centroid of used grid square

If we cannot make a distinction between UTM 5km and UTM 5km + deelgemeente we just use for georeferenceRemarks:

coordinates are centroid of used grid square or centroid of intersection between used grid square and district, if known

4. XY

I haven't verified these in QGIS yet... the only thing we could verify here is that Frederic indeed assumed a Belgian Datum 1972 for translating the coordinates to WGS84. We could indicate XY coordinates from original recorder in georeferenceSources if we really want to.

• verbatimCoordinates:
• verbatimLatitude: Y
• verbatimLongitude: X
• verbatimCoordinateSystem: Belgian Lambert 72
• verbatimSRS: Belgian Datum 1972
• decimalLatitude: latitude
• decimalLongitude: longitude
• geodeticDatum: WGS84
• coordinateUncertaintyInMeters: 30
• georeferenceRemarks:

[Peter Desmet]

@timadriaens, see the above description of how we plan to treat verbatim coordinates in Saltabel.

[Tim Adriaens]

a thought: as database manager I spent lots of time looking up the 'right' utem1 or utm5 square based on toponymy, contact with recorders etc. (as Frederiks notes suggest). This is because all of the 'analysis' rather depends on the right square. So as a first comment, having the original utm square one way or the other within the record is important. We will have to clarify that in the metadata.

[Tim Adriaens]

In addition to this, the cleanest for me would simply be to use the centroid of squares as verbatim coord unless xy is known. But I realise this would have to be done in recorder then... and would be a shame for all frederiks and your work.

[Peter Desmet]

simply be to use the centroid of squares

1. that would reduce the accuracy of the coordinates we currently have (based on intersections)
2. that would require us to reassign coordinates to a lot of records
3. if we do it in the mapping view, create a difference between the coordinates in recorder and the coordinates in the published dataset

In addition, coordinates from intersections will still have the correct square code associated with them + will fall in the correct square when doing a GIS analysis, making research analysis requiring squares possible. Therefore, I would not simply use the centroids of the squares, but continue to use the coordinates we currently have, with an indication of how they were derived.

[Tim Adriaens]

ok that's fine as they "still have the correct square code associated with them + will fall in the correct square when doing a GIS analysis" !

[Dimi Brosens]

Update 2020... In the Saltabel datapublication, there are no UTM squares. What we do give is the center of the respective UTM square. So the verbatim coordinates were not published (and not omported in NBN, I assume)

[Dimi Brosens]

Closing this as the only think we could do is to calculate the respective UTM squares based on the original centroïds.

[Peter Desmet]

Update: original squares were found in source database (see #57 (comment)) and included in DwC.