Span.route: Clarify semantics with respect to schematic data

[duncandewhurst]

The ITU's open data from Brazil includes span routes that look like schematic representations of the connections between nodes, rather than the actual route of the fibre spans:

That conforms to the description of Span.route:

A GeoJSON LineString geometry describing the route of this span.

However, that description is a bit circular (a route is a route) so we should clarify its semantics with respect to schematic data like the Brazil example. I think that we should support the publication of this type of data, but we should consider whether there should be some sort of flag to indicate to users that data is schematic.

[lgs85]

some sort of flag to indicate to users that data is schematic

Happy to think about this, but my concern is that there are so many ways in which a route could be schematically represented that it could lead to a lot of confusion and potential for error.

The most common scenario in which schematic representation of a route will be required is when there are overlapping routes, which in turn will usually (but not always) result from multiple operators using the same cable. Being able to determine who owns/operates fibre over a given route is an important use case for regulators, government and operators, and schematic representation of routes could be a hindrance to this. It might be that we can come up with an elegant solution, but we need to mindful that whatever is implemented is heavily dependent on the solution to #192.

[lgs85]

For balance, multiple stakeholders have flagged that publishing precise geolocation data represents a security concern. Schematic route representation is one potential way to mitigate this. However, I think I prefer the idea of guiding authors to reducing the precision of geographical coordinates to address this.

[duncandewhurst]

All sounds good.

On reflection, I think that defining such a flag would be too difficult since every map is a schematic representation to some extent ("a map is not the territory"). I don't know how we would draw the line (no pun intended) between the actual route of a span and a schematic representation of the route.

That said, I don't think we should disallow schematic representations like the one in the issue description since that would hinder anyone who wanted to take a raster version of a map like that, trace it and publish the data in OFDS format.

In terms of clarifying the semantics of Span.route perhaps we should replace 'describing' with 'that represents' to make it clearer that the field is an abstract representation of the real route:

A GeoJSON LineString geometry that represents the route of this span.

We can then consider providing guidance to publishers on avoiding overly schematic representations, where possible, and to users on identifying and handling cases like the one in the issue description.

Sound good?

[lgs85]

Yes, good points.

We can then consider providing guidance to publishers on avoiding overly schematic representations, where possible, and to users on identifying and handling cases like the one in the issue description.

Yes. Will be a challenge for the reasons you outline but we can definitely do something.