-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Span.route: Clarify semantics with respect to schematic data #193
Comments
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. |
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. |
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
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? |
Yes, good points.
Yes. Will be a challenge for the reasons you outline but we can definitely do something. |
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
: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.
The text was updated successfully, but these errors were encountered: