Locality coordinates improvements

  • DanielMosquin

    #831

    I’m grateful for how easy it is to work with precise point data for Localities. However, I’m wondering if there are plans to improve the system for the “fuzzier” localities?

    Right now, the Precision and Trueness fields are in place. Precision (for coordinate inaccuracy), I presume, is intended to give the ability to record device error (e.g., the GPS tells me I have 12m accuracy). However, the field only accepts an integer value without an accompanying unit value (presumably should be a separate field).

    Trueness (Extent of the locality or distance between coordinates and the true location) also only accepts an integer without a unit.

    In addition to adding units for the above, it might also be good to have some way (likely a flag) to designate whether coordinates for the locality have been assigned by a data technician or the original collector. We have plenty of collections from Sometown that need to be assigned coordinates (and trueness) years beyond the collection event, in order to be mapped.

    On the topic of maps; I know that point coordinates are useful, but if trueness can be incorporated, they are not necessarily precise (and this then gets into how does one truly incorporate trueness for legacy descriptive data; does one use a circular area incorporating radius from an assigned point? or eventually permit custom polygons?).

    It’s likely not a priority to work on doing a full incorporation of trueness into maps, but it might be nice to have maps show a differently-coloured point marker based on a user-defined level of trueness as an intermediate step. For example, if I have three collections with trueness levels of 0m, 10m and 5km, I can select 5m trueness while generating the map and get a green marker for the 0m locality and red markers for the 10m and 5km, or I can select 15m trueness and get green markers for the 0m and 10m markers, and red for the 5km. This at least provides the visual cue for certainty.

    Obviously, one of the programming challenges is that trueness values would have to be converted to a common unit in the background.

    Lastly, what seems to me to be a small bug: after prompting a map popout from a Locality set of coordinates, the default marker on the map of DotGreen can’t be changed to anything else, even though the Marker dropdown implies otherwise.

    Beryl Zhuang

    #4317

    Any updates on this request?

    IrisBG automatically convert original coordinates into decimal degree format and retain the original coordinates. This feature is very helpful for us, as we often receive different coordinate formats from source.

    I second Daniel’s recommendation of using polygon/circle instead of a precise dot to represent coordinates on the map or make this an option to show polygons or just dots. The diameter of the polygon/circle can indicate the precision of the original coordinates.

    Precision can be calculated by the decimal places of the verbatim decimal degrees (DD), or the decimal places in the degrees, minutes, and seconds (DMS) system. Wikipedia has a detail explanation and calculation of the precision. In this case, the precision can be automatically calculated from the original coordinates and can have a default unit. For example, original coordinates 41 26’58”, 127 44’ 27” (DMS) is translated to 41.50, 127.74 (DD) with precision ~884 metres.

    IrisBG converts the original into decimal degrees format (DM) with 6 decimal places, which default the precision to ~1 m. This may give user a false sense of high precision locality as shown on the map. Polygon/circle will be help us to visualize the precision of the original coordinates. An extreme case we have is a locality with original coordinates of 41N, 107E. That’s ~ 84 km in precision, which is not precise at all and we should think of the dot at 41.000000, 107.000000 is just the centre of large range.

    This may get trivial, yet, will affect the precision calculation. Original coordinates of 41.10 N is different from 41.1 N because of the degree decimal places. 41.10 N is more precise than 41.1 N.

    Lastly, the small bug Daniel reported is no longer a problem
    🙂

    Thanks in advance!
    Beryl

    Attachments:
    You must be logged in to view attached files.
Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.