Feature: Worldmap screenfixed objects

[vpithart]

What?

The worldmap is a perfect tool to display geographical objects on the map. However, there are in real also non-geographical objects in play. This PR brings a feature to show them too.

Overview zoom - note the map legend on upper left:

Detailed zoom - note the map legend still on the place:

Why?

Real-world NOC (Network Operations Centre) needs to see a big picture at a glance. Perfectly tuned geographical map shows how's the network. In addition, things like

• DNS server's status
• map legends (what line color is what)
• link to the internal wiki and howtos are very handy to show on the screen too, regardless of the viewport (map center, map zoom).

How?

Two maps - interactive and regular - are merged together. On an interactive map, new option comes into play screenfixed_objects_from_map. Chosen regular map objects simply show on the screen. Since it's regular, objects positions are pixel-based (rather than coordinate-based) so that they're fixed on the screen.

Documentation in English updated on this.

Under the hood

The ViewWorldmap loads this map object and additionally referred regular map objects firing subsequent GET getMapObjects request. Then regular obj.render(); draws them on the screen.

[LarsMichelsen]

Thanks for the suggestion. The feature actually sounds useful.

What I don't like about the proposed approach is that you have to do the configuration in two places.

If I understood that correctly, you have to build a kind of dummy map (regular map) on which you position any objects. This map has to be referenced in the worldmap, then the dummy-map will show the objects as an overlay. Correct?

We should try to implement this feature within the worldmap. For example, I could imagine that you add an object in the normal way and then adjust the way you position it. For this we could adapt the format of the relative coordinates. For example, "viewport%+123" could be a reference to the upper left edge of the map + 123 pixels.

[vpithart]

This very approach (new format of coordinates, in my design it was +123px) was what I tried to do in the first place. I found it way too complicated. Believe me, I have lost 2 full days on it before I've decided to throw it away and go search easier way.

Such coordinates would have belonged to the etc/maps/*.cfg file, whereas "normal" lat/lng coordinates stay in sqlite. Only after modifying the backend re adding/editing an object I found it dead end: tons of code, ifs in doModifyObject($a) or multiple paths to run storeUpdateElement() (dragging objects vs. modifying it in a form). Yet without edge cases implemented - like: manually editing 49.1234 to viewport%+123 -> different source to save it.

On the other hand, combining 49.1234 with viewport%+123 in sqlite DB would complicate already complex queries regarding viewport (the algebra re middle sections of ling lines).

Not to mention the complexity of View* and NagVis* javascript objects that would have needed to be modified so that screenfixed objects don't pan when leaflet map is panned. (Now they also behave like this, elegantly by swapping ViewMap and ViewWorldMap object's render() and related function).