Map display addons and map data sources

[Graveeater]

Actually not.
What I'm doing is calculating the Shortest Path Problem.
However, the calculation of that is trivial (I'm using A*).

This thread is about displaying the results.

[Xinhuan]

Originally Posted by Graveeater

Actually not.
What I'm doing is calculating the Shortest Path Problem.
However, the calculation of that is trivial (I'm using A*).

This thread is about displaying the results.

You're still being awfully vague though.

You need something to display your route on the map, i.e You need an addon that can draw the appropriate lines on the map given the appropriate route data.

So in addition to possibly creating this map-data interface, you're also looking at writing a route-displaying addon (or looking to extend Routes' capabilities) because there isn't any such map-display addon at the moment that can draw the lines you want on the map.

[Adirelle]

Graveeater, if you want some authors to include a library or modify in some way their addons, you have to explain why you need it and you have to convince them that it is beneficial, or at least harmless. Being vague like this doesn't appeal to help you. Half the people in this thread doesn't understand what you are trying to do and why it would require a library.

So just clearly state how your path should be displayed on maps and you may get some useful answers.

[Graveeater]

I'm not sure what is unclear, though.
The Addon does not need to know anything about other map nodes, it just needs an display to display the route (or the whole graph, or parts of it).
(In future I'm planning support for including FlightMap data and such, but that is not the point of this thread.)

I agree, we need lines for that. I suppose we need to define an api for that to. I haven't looked at routes or Carto/TomTom in detail, so I'm not sure how you did it.

My current approach would be, to define a library which provides a consistent api to data sources. The library would then relay the information to map displays. However, I'm not sure which kind of things we actually do need.
I certainly need notes/nodes and lines/edges. However, some addons might need more, something like areas (Rare Spawn, Questing stuff?) for example.

Edit: Missed Adirelle's post.
As you can see (I hope) above, I have redisigned the concept: Map displays don't need to change anything if they already have a public interface for the stuff.
Data sources won't need to change anything either (but it makes sense, if they wan't more displays supported).
New displays will be added to the library as the need approaches.
So in fact, noone except me HAS to implement it. However (I hope) datasource addon authors will want to include it to simplify the developement.

My path should be displayed, as a path. That is a sequence of points which are connected with lines.

[Xinhuan]

There isn't really any problem with your proposed library.

However, there isn't any reason why an existing addon such as GatherMate, Gatherer, Routes or otherwise should use your library because all these addons are both a data source and a data display. There is absolutely no reason why the authors of these existing addons should modify their addons to add a library layer between their data and their display.

Routes is a more special case because it is both a data producer and a data consumer: It consumes data from GatherMate/Gatherer/Cart/HandyNotes to produce routes, then displays these routes as a display.

The authors of each addon of those GatherMate/Gatherer/Cart etc addons intentionally want their addons to be standalone, not requiring users to have to install a mapdata source addon for nodes, and then a separate mapdata display addon to display those nodes, they are "seamless solutions" so to speak.

Again, there isn't really any problem with your proposed library. It's just that existing addons are unlikely to convert to it, but new addons can and will likely subscribe to it.

[Graveeater]

Maybe I was not precise enough:
The library should provide a fallback for the default WorldMapFrame (if no display addon is available).
In fact, the library should abstract enough, so that the data source addon can concentrate on what it is used for.

However, you are right, it is unlikely to expect authors to convert existing addons without a good reason.

I think I will propose an api draft soon.

[Xinhuan]

Perhaps you don't understand how GatherMate/Gatherer/Cartographer works then. All 3 addons I just listed use WorldMapFrame directly. Mapster as well. None of these addons create its own world map frame. All the node gathering/display addons and almost all map modifying addons do their work directly on WorldMapFrame.

There is hardly any reason why any addon would create its own map frame unless it is a google-maps style one such as the one in Cartographer3 or Carbonite, but that requires a completely different approach.

Cartographer 3 uses a "hack" where any attempts to draw anything (anchor a child frame) on WorldMapFrame gets redirected to its own google-maps frame at the correct place, thus any existing addon that attempts to draw stuff on WorldMapFrame works seamlessly with Cartographer3 - including GatherMate, Gatherer, Routes and HandyNotes.

[Adirelle]

Thanks for the clarification.

Now it seems you could build your addon on top of a library that would be the mixin of Routes line drawing feature and map pin drawing addons.

[fyrye]

It's like you want to provide a framework for displaying nodes and routes.
And are assuming that the information bound to a node to display it is used only to display a node and needs to be included.

To simplify:
Node data can consist of many many different things.
Loot, Treasure, Trade skill Objectives, Quest Givers, Quest Objectives, etc.
So developers use their own methods of storing this data known as "data source" for later retrieval by their display addon.
As a rough example...
QuestsObjective = {
[124871] = {
name = "Some Quest Name",
obj = "Kill Wolves",
loc = "23,50",
moblvl = "20-30",
source = "Some Quest Giver",
},
}
Which is usually compressed to provide faster results, easier localizations, and so on.
From Cartographer_QuestInfo:
[155] = {
i = "A`14`18`467`234`0`0",
o = "1=0@40:426,715",
s = "65`132`135`141`142`155`166",
},

So in short, a global framework for displaying already existing data sources, is for the most part out of the question.
Creating a framework for others to build their data sources to is a good idea, but you would have to cover all aspects of each node type displayed and provide a means of selecting node types to ensure the correct routes are drawn.
But in return is not practical, as each individual data source currently has their own preferred method of "display" (carto_notes, TomTom, GatherMate, built in), compression, and info.


If I am completely off from what you're tying to accomplish, try explaining it with out being so cryptic, eg:
Goal/s: 1) To provide a singular framework for all node/route addons
Functions: 1) Easily display a node or group of nodes on the World Frame
2) Easily select between a group of nodes and show the shortest route
3) Automatically intercepts new nodes such as mining, herbs, etc
4) Calculate fastest route for node to node, or group of nodes to group of nodes
Benefits:
1) Provide an easy to use and manipulate framework to build your data source addon to
Drawbacks: 1) Does not provide a default data source of nodes

[Graveeater]

Actually, Cartographer3 does not seem to work with any map data source, of in standalone mode. This would not be an issue, if Cartographer3 would work as intended (not blaming anyone here, I know its in early stage).
In order to use instance maps, I have to seperate Cartographer3 from the worldmap, which results in Cartographer3 not displaying any notes. (For example GatherMate is missing, as well as Rare Spawn Overlay and probably almost all others.

So the idea is, to make map display addon authors life a little bit easier without every single datasource having to support each display.

---

Now more in detail to the goals of the library:
1) Allow addons to easily display nodes, edges and areas on any map display frame the user decides (WorldmapFrame, Cartographer3 Standalone, <insert your favorite google maps addon here>).
2) If possible, allow interaction through the generated nodes/lines/areas (that would not be required on all displays, for example an addon which would display a transparent fullscreen map in the background would NOT want to be clickable). This could be a context menu for example.
3) We do not need to intercept anything from datasources. Each node is explicitly displayed/removed/modified by the datasource. If we provide callbacks (i.e. context menu) we assume the data source to handle them.
4) We provide support for popular display addons (one being the default Worldmap, possible more).
5) We should allow new display addons to register themselves.

So basically, one use case could be as follows:
FancyGatherNoteSource calls

library:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,text or OnTooltipShow, OnRightClick)

with a lot optional parameters.
The library would then dispatch this (drycoded, the api is probably wrong)

function library:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
	-- Default world map
	displayOnDefaultWorldMap(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
	
	-- Extra for standalone stuff
	if Cartographer3 and Cartographer3.isStandalone then
		Cartographer3:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
	end
	
	if Carbonite then
		Carbonite:DisplayNode(type,continent,zone,zoneX,zoneY,icon,relativeWidth,relativeHeight,tooltip,OnRightClick)
	end
end

So the basic idea is, that the library will convert the parameters for the different displays api (assuming there is one). For the default world map we will implement the behaviour, for others we assume an public api which only needs small adaption.


Now an actual usecase for my navigation addon:
The user specifies a target (which is not supported by the library), and the addon calculates the shortest route from the users location to the destintation. Then my addon will ask the library to display this route.