Link endpoints

[duncandewhurst]

Links need to reference their endpoints, i.e. the nodes that they connect.

Our understanding is that links are not directional, i.e. they do not have a start or end. Therefore, they could be modelled as a string array containing the identifiers of the nodes connected by the link, e.g.

{
  "nodes": [
    {
      "id": "PIL01",
      "location": {
        "geometry": {
          "coordinates": [
            26.081,
            -24.405
          ]
        }
      }
    },
    {
      "id": "MOC01",
      "location": {
        "geometry": {
          "coordinates": [
            26.141,
            -24.393
          ]
        }
      }
    }
  ],
  "links": [
    {
      "endpoints": [
        "PIL01",
        "MOC01"
      ]
    }
  ]
}

However, a common need is to create a map that shows the connections between nodes, in which case users would need to join links to to the nodes array using the identifiers in endpoints in order to look up the coordinates of each endpoint.

Modelling as a string array creates more work for users because they would first need to split out the values endpoints. Therefore, declaring the endpoint references in separate fields seems preferable.

However, care needs to be taken in naming the fields to avoid implying a direction, e.g. start and end would not be appropriate and, arguably, A and B or 1 and 2 have similar issues.

This issue is to discuss suitable modelling and naming for link endpoints.

[lgs85]

Modelling as a string array creates more work for users because they would first need to split out the values endpoints. Therefore, declaring the endpoint references in separate fields seems preferable.

+1 to this

However, care needs to be taken in naming the fields to avoid implying a direction, e.g. start and end would not be appropriate and, arguably, A and B or 1 and 2 have similar issues.

Yes, and I am struggling to think of anything better. I think that you could imply directionality even from the positioning within an array, so don't think we should worry about this. Suggest going with 1 and 2.

[duncandewhurst]

JSON Graph Specification and GraphML pair Edge.source and Edge.target with a boolean directed field.

[lgs85]

This is pretty heavily loaded, but at least it's clear and has precedent

[duncandewhurst]

I think including a directed field is a good approach but I am not sure about introducing the source and target terminology as we didn't see any examples of that in the supply side research.

The technical working group's draft data model used start and end.

Netdraw VNA uses from and to.

In the supply side research, we saw:

• End A and End B
• start and end
• from and to
• Point 1 and Point 2

I am inclined to go with start and end as that seems clearest to me and to nest those properties underneath an endpoints object, which can include some clarification in its description that the terms start and end are cosmetic and the link should only be considered directional if directed is True.

[duncandewhurst]

I am inclined to go with start and end as that seems clearest to me and to nest those properties underneath an endpoints object, which can include some clarification in its description that the terms start and end are cosmetic and the link should only be considered directional if directed is True.

Actually, we've gone with separate properties for Link.start, Link.end and Link.directed, to align with JSON Graph Specification.

[duncandewhurst]

The alpha schema and codelists added in #101 reflect the latest proposal in this issue.

This issue will remain open against the beta milestone to gather feedback from the alpha consultation.

[duncandewhurst]

We've not heard any further feedback on this issue so I'm going to close it for now.