Map feedback

[duncandewhurst]

@codemacabre @Lathrisk I tested the latest version of the ng branch on my local machine with the OFDS-formatted version of the Brazil data published by the ITU (see Planio-36509) and it's looking really good!

I have a couple of suggestions/questions:

• Can we replace 'Select a Node data field for colour-coding' with 'Colour nodes by' and similar for Spans
• The legend is (almost) too large for the viewport. Is there a way to limit the number of entries for fields with a large number of categories and put all the other categories in an 'other' bucket? Ideally, we'd show the top X categories with most nodes/spans. Edit: I guess a fall back option could be only to allow users to chose fields with less than a certain number of categories.
• Instead of suffixing each entry in the legend with '(Node)' or '(Span)', can we add a 'Nodes' and a 'Spans' sub-heading to the legend and group the entries accordingly?
• Why is status missing from the Span drop-down?
• Is there a way of keeping colours in sync between nodes and span? i.e. if a user selects 'status' to colour both nodes and spans, the colours used for each status should be consistent.

[lgs85]

it's looking really good!

Huge +1 to this, great work all

The legend is (almost) too large for the viewport. Is there a way to limit the number of entries for fields with a large number of categories and put all the other categories in an 'other' bucket? Ideally, we'd show the top X categories with most nodes/spans. Edit: I guess a fall back option could be only to allow users to chose fields with less than a certain number of categories.

Another/additional possibility here (though possibly a technical nightmare) would be to scale the legend to only include nodes/spans in the viewport at a given time, so that when you zoom in to a given area you only see the providers (or whatever you've coloured by) in that area. This isn't a request but rather an idea for discussion.

[Lathrisk]

@duncandewhurst

Thanks for the feedback. The map looks good but I agree with above (or quoted below). In addition I might try to increase the number of unique colours (currently 7). Repeating the colours is as much use as selecting random colours that are similar.

• Can we replace 'Select a Node data field for colour-coding' with 'Colour nodes by' and similar for Spans

Yes

• The legend is (almost) too large for the viewport. Is there a way to limit the number of entries for fields with a large number of categories and put all the other categories in an 'other' bucket? Ideally, we'd show the top X categories with most nodes/spans. Edit: I guess a fall back option could be only to allow users to chose fields with less than a certain number of categories.

We could create two legends, one for nodes, and one for spans, and I think there is an option to make them collapsible. I'll have a play and update here with options.

• Instead of suffixing each entry in the legend with '(Node)' or '(Span)', can we add a 'Nodes' and a 'Spans' sub-heading to the legend and group the entries accordingly?

See above, we could have subheadings or completely distinct legend frames.

• Why is status missing from the Span drop-down?

I think this is a small bug. I used the field names from the issue verbatim, which in this case was status.name but I think we just want status in that instance.

• Is there a way of keeping colours in sync between nodes and span? i.e. if a user selects 'status' to colour both nodes and spans, the colours used for each status should be consistent.

I'll look into this. At the moment it sequentially maps an array of colours to unique fields which depends on ordering, but I'm sure we can add some logic it to consistently map the correct colours across nodes and spans.

[Lathrisk]

Another/additional possibility here (though possibly a technical nightmare) would be to scale the legend to only include nodes/spans in the viewport at a given time, so that when you zoom in to a given area you only see the providers (or whatever you've coloured by) in that area. This isn't a request but rather an idea for discussion.

I think this should be possible. I've done similar things in the past, just not in leaflet. The limiting factor is likely to be the legend library itself but we should be able to repopulate it every time the map bounds change. I'll look into that too.

[lgs85]

@Lathrisk could i just check that the behaviour when spans overlap. e.g. these parallel spans:

should be the product of true differences in coordinates rather than a visualisation feature? I can check the raw data if easier

[Lathrisk]

@lgs85 overlapping features has been in the back of my mind. My untested understanding is that the features should overlay directly and appear as a the last line drawn. This looks like the coordinates will differ, unless leaflet is doing some auto-magic that I don't know about. I'm pretty sure its the former though.

[lgs85]

thanks @Lathrisk that makes sense - i'll double check the data to be sure. For context this is likely to be a key issue moving forward, as combinations of operators will likely report both i) data on the same span in different roles (e.g. one as a physical infrastructure provider and one as a network provider), as well as different spans following the same, or very similar, routes. A key need for users of the data will be to be able to determine the difference between multiple operators using the same fibre vs multiple operators with different lengths of fibre in the ground. I think the current data model and visualiser should mostly deal with this ok, though we might want to consider what to do for truly overlapping spans.

[duncandewhurst]

@Lathrisk, regarding #51 (comment) - all sounds good! status.name was my mistake :-)

A key need for users of the data will be to be able to determine the difference between multiple operators using the same fibre vs multiple operators with different lengths of fibre in the ground. I think the current data model and visualiser should mostly deal with this ok, though we might want to consider what to do for truly overlapping spans.

This seems like a good topic for some user guidance - I've created an issue: Open-Telecoms-Data/open-fibre-data-standard#192

[Lathrisk]

@duncandewhurst @lgs85 (cc @codemacabre)

So one options is to have expandable legends. These will expand on mouse over and collapse otherwise. It's not a great interaction and still has the problem of too many legend items. We can also put a legend on either side of the map so that there is more total stacking space when they expand.

We can also write a custom legend fairly easily. This could sit within the map, but we might also be able to dynamically generate the HTML to allow us to position it outside the map in the case where there are too many legend items.

Collapsed:

Expanded:

Either side:

[duncandewhurst]

In either case, I guess we're still going to have a layout problem if there are lots of categories. Could we make the legends scrollable?

[Lathrisk]

@duncandewhurst @lgs85 (cc @codemacabre @odscjames)
I've updated the map so that we now have scroll bars on the legends. All of the colours should match between nodes and spans as well. See attached image.

[duncandewhurst]

Looks awesome!

[Lathrisk]

These changes are now live, it would be good to throw a range of data at it. I suspect I create fairly specific set of test cases for local development.

The only outstanding issue is one of overlapping nodes and spans, but we might wanted a dedicated issue to track that, particularly if we want to do some user research.

[Lathrisk]

All issues resolved with the exception of overlapping nodes and spans which is now detailed in Open-Telecoms-Data/open-fibre-data-standard#192