GuildWiki talk:Interactive map project

Java vs. Javascript
I guess the first few steps would involve deciding which approach to use.

A full fledged mashup which would overlay data on top of an image. This could actually be accomplished with PHP / GD. Map coordinates and an appropriate icon / note can be pulled from a DB and rendered on top of the image.

Or if we wanted to take an approach that would be more of a tool to create an image that is saved. The mashup would be more versatile and allow for more flexibility and options in what can be done.

The various maps located at http://broadbandreports.com is a very good example of a mashup. All the data is housed locally and they basically plot it in real time on top of a Google Map.

The first approach would require a separate infrastructure to support the maps. Map "bases" would have to be installed (continents, zones, etc.).

Some of the obvious benefits of a system that would accomplish this is, Higher Quality and Resolution of mission maps, boss locations etc. Currently we are forced to view the information in whatever resolution the user decided to capture the screenshot. Plotting this information on top of a pre-existing high quality map would be a superior alternative to this.

Additionally data can be 'tweaked' without the need to generate an entirely new screenshot.

I would be happy to design the database structure that would be required to implement a PHP / Java / MySQL variant.

Ideally, a Java applet would be created which would allow panning, zoom, etc of the maps. Also a frontend would have to be created to get POIs (Points of Interest) into the actual database for the mashup to pull from.

I can also provide a development platform for the project. ErkDog 15:41, 20 November 2006 (CST)
 * I have some experience developing Java applets, so I would be happy to work on that side of things. I'm pretty busy for the next two weeks, but after that I have a bit of a break when I could work on this. - Lord Ehzed 15:45, 20 November 2006 (CST)

Previous work
I've already posted this link in GuildWiki_talk:Community Portal:

http://www.phototraffic.com/

It's pretty close to what I envisioned for myself, even though closer integration with Guild Wiki would be great, of course. If we still decide to do our own implementation, I'm strongly in favor of a Javascript solution instead of actual client side Java. DeepSearch 03:11, 22 November 2006 (CST)


 * I think it would be pretty hard to accomplish the things the map client would need to do with JS instead of Java. The map @ pt.com is pretty.... weak.... compared to what I was thinking.  It only zooms like two levels making it hard to distinguish POIs close together.  It also has nothing on it other than Elites, no other POIs or routes. But it is definitely a proof of concept that we can do what we want to do with the Google API and custom maps. Our implementation would require one full map for each continent for elites, then perhaps additional maps for missions to show routes. The zoomed in POI for an elite can be shown in a map window on the page for that elite.  Clicking on a link under the map would switch you to the larger map which is more easily navigable. ErkDog 08:08, 22 November 2006 (CST)


 * I don't think anything you mentioned isn't doable with Google Maps and given the choice, I would definitely pick JS over Java. --Fyren 08:49, 22 November 2006 (CST)


 * As Fyren said, all that is possible with Google Maps. The only thing I'm not a 100% sure of how to implement are routes, but Google can do it, so we should be able to as well. DeepSearch 07:04, 26 November 2006 (CST)

Map data and coordinate system
I played around a bit with the Google Maps API. As it turns out, it's actually extremely simple to use their engine in combination with custom map material. Here's an example I created to get a feel of how the tiles are addressed at different zoom levels:

http://michael.elsdoerfer.name/gwmap/coords

Now the first challenge is going to be to figure out how to fit the Guild Wars maps into there. The following calculations are based on the Elona Map from GWVault:

http://vnmedia.ign.com/gwvault.ign.com/dropbox/Cartography/WorldMapElona.jpg

Each tile has to be 256x256 pixels in size. The number of tiles (in both width and height) is 2^zoomlevel. So the complete map itself is a square as well.

The above Elona map is 6218x5314. Assuming this is the most detailed we can get, it will be used for max zoom level. We need to split it into a number of 256 pixel tiles. 6218/256=24.28, which means we will need 25x25 pieces, which in turn means a 6400x6400 pixel image (again, at max zoom level). 25x25 pieces means we can support 6 zoom levels: 0-5. At zoom level five 2^5=32 tiles are displayed.

So, to create the map data, here's what we have to do:
 * Find/create map material we can use. The above elona map seems near perfect (is it based on the U map?), as the outposts, regions and texts seem to be added manually. I guess the dream scenario would be to have the map itself and the "metadata" (outposts etc.) separate, so we could display those as an optional overlay (similar to the Hybrid mode supported by Google Maps). Is anyone familiar with how to create those maps? Maybe it is possible to contact the author of this one.


 * Create a script (ImageMagick, Photoshop?) that does the above calculations, creates the necessary zoom levels and splits everything into tiles. See also http://mapki.com/wiki/Automatic_Tile_Cutter

That would be the first step. Secondly, we need a way to address positions on the map. It is possible to use the traditional lat/long system, but it seems to me that it would be simpler to define a custom one. The most straightforward idea of course is to just use pixels. (0/0) to address the top/left corner, (6400/6400) (depending on map) for the right/bottom corner. Is there anything that would speak against this?

Tell me your thoughts. DeepSearch 06:57, 26 November 2006 (CST)
 * Update: I wrote a small Javascript for photoshop that will run through the process outlined above and create tile images for various zoom levels. You can find it here. I modified the map above to use the new imagery, and you can see the result here: http://michael.elsdoerfer.name/gwmap/elona/ The next step would be to replace the default MercatorProjection with an Euclidean one, to make adression certain spots easier (although I'm sure it that actually be easier, I don't understand the whole projection thing fully yet). DeepSearch 00:24, 27 November 2006 (CST)

I'd love to help
I've been working on a map using the google maps API that I was planning on just posting on a free host and sharing with my guild etc., but would rather work on a map for guildwiki. So if there's anything I can do to help, I'll do it. Here's my progress: if the source is of any use. I load an xml file for the locations (don't have the outpost up yet) and display them my own GOverlay (because I don't like the default marker class) that I haven't finished. I'm just a hobbyist so the code is a bit sloppy and unfinished. Hopefully someone else is better than me at javascript. But, I can provide raw, no-fog-at-all images, or just make the tiles myself (the tiles I put on the site are low quality due to limit space on free host). just need to know about what quality or size (on the site the image quality was set to 40 (if I remember correctly) using Gimp and all the images take a total of 4mb). So images, gathering data, or writing javascript (if you really want me to and if we are going to use google maps api), I'm here to help :D -Smurf 00:17, 27 November 2006 (CST)
 * Not bad at all! I see you even have a custom Projection class as well (btw - where is it centered?). Is this your own map material? The missions and towns are done via overlays, if I did understood correctly. But wouldn't those be already on the screenshots from Guild Wars? Did you remove them afterwards? I guess my question is: How is it possible to get a "clean" map, without fog and all the regions visible, but without town/outpost/mission/shrine/trader/text info on it? DeepSearch 00:42, 27 November 2006 (CST)


 * The center is the top left corner. If your browser allows a website to change the status bar text then it will display the coordinates that your cursor is at. I just use 1 degree lat/lon = 256px. The missions and towns are done with overlays which I'm still unsure if it's the best choice. The map material is my own in the sense that I got it from the game myself and not from a website or someone else, but I didn't use screen shots. -Smurf [[Image:User_Smurf.gif]] 01:58, 27 November 2006 (CST)
 * So, you found out how to pull the map from the hulk of a data file sitting on your computer then? --Thervold 20:07, 27 November 2006 (CST)


 * I didn't quite understand how you created the maps, but that's probably not a part were I can help with anyway ;) As for the overlays, which obviously have the problem that they are always the same size, no matter the zoom level, which means they will either be very small when zoomed in, or too large when zoomed out. I would suggest to use a similar approach as Google's Hybrid mode. The overlay would be created the same way as the map images itself, split into tiles and would be available in the different zoom levels. The challenge then is how to make cities/outposts still clickable? Maybe it is feasible to intercept clicks on the map and look the position up in a small database if a certain lat/lng is withing a clickable hotspot region. DeepSearch 20:22, 27 November 2006 (CST)

That is an excellent start. Much better than the other site that has been mentioned. As far as the actual data though, we need a way to pop that in and out of a database. I would also think another zoom level or two would be good. As well as higher quality images. Smurf / others, I can provide a space for development. I'll setup an account and a database this evening. ErkDog 08:00, 27 November 2006 (CST)
 * Actually, that is in interested design question, which we will have to talk about. One of our goals was to have the possibility to integrate the maps into the wiki, e.g. to specify boss locations. How would that we done? {map boss={PAGENAME}} (how does boss get into the map database?) {map type=boss lat=4.2 lng=12.5 prof=necromancer name={PAGENAME}} (no need for a db at all? but then how do we display a map with ALL bosses, for example) At first thought, what make sense to me most, is a two-fold approach: 1) Specify geo locations on boss pages, e.g. {geo lat=4.2 lng=12.5}. 2) Have a bot parse those and add them to a database. 3) To display a location on a boss page, use the boss name to specify what the map has to show: {map boss={PAGENAME}}. If the bot has not yet added that boss the the database, the map will not show (yet). What are the other options to make the map data editable in wiki-style? DeepSearch 13:05, 27 November 2006 (CST)

The bot approach is probably not the greatest. It would likely be easiest to develop a front end in PHP or Java / JS to handle the modifications of the POI database. http://www.broadbandreports.com is done via the applet itself, so is http://www.frappr.com. Although Frappr uses a Y! API vs Google, but the proof of concept is the same. It can be accomplished with an applet. There would still have to be a custom set of PHP written in order to revert changes. I think the maps would likely be a high target for vandalism. It may be better to simply moderate the changes made to the map POI database. Better to have admins and moderators poke through proposed changes, than to continually deal with cleaning up and rectifying vandalism. ErkDog 13:27, 27 November 2006 (CST)
 * I see you're point about vandalism, although I'm not sure I agree 100%. If the coordinates are in the wiki in text/code form, and cannot be changed directly on the map, the incentive to manipulate them should be that much higher than the rest. On the contrary, confirming a position can require quite some time, it might be even helpful to have the whole comunity available making sure the data is correct. I've given what I wrote before a second thought though - I maybe made it more complicated than needed. The map on a boss page really has only one thing to do: Show the location of the boss (and the towns/outposts, if not directly part of the map). All the other data (locations / bosses / skills), that we need a database for, does not need to be on it. So, for maps showing a certain position or route, simply putting the data directly into the wiki map command should be suffice. DeepSearch 20:33, 27 November 2006 (CST)
 * If there was an easy way to have the API pull data from a wiki page then sure, although I don't know if there is, although, I don't really know how the API works period, lol. But I would think it best to not be pulling data from wiki pages.  If the Wiki HTTP/Squid/etc is slow then the maps won't work :( ErkDog 21:35, 27 November 2006 (CST)

Map Zoom Levels
When I play GW in a window, and I make it small, the resolution of the "zoomed in" m-map is lower. Is there a maximum resolution though? This would be good to know for making our base maps. - Lord Ehzed 09:24, 27 November 2006 (CST)


 * Not sure about window mode but in fullscreen mode you can change the interface size and that will make the map larger. Normal size will be 1:1 and anything larger will just be blown up like the compass. -Smurf [[Image:User_Smurf.gif]] 19:27, 27 November 2006 (CST)

Wiki Data vs Database
Ok, well for me to setup the development environment, I need to know if the data will be pulled from a database directly or from a wiki page.

I think it would be much more robust and flexible to pull it directly from a database. Although, a CSV on a Wiki page can accomplish the same thing if necessary. As long as the API knows what goes in which colum such as:

POIName,Lat,Lon,Icon

Then the data could exist directly on the page.

Each "set" of data could exist as a separate page.

The benefit of making it mash data into the GoogleAPI from a Wiki page is that we gain all the history and reversion benefits of the wiki itself. Although, this means that the functionality of the map is tied to the functionality of the Wiki.

Conversely, the Google API could be programmed to read the "text" of the actual wiki article directly from the database instead of parsing the information directly from the Wiki HTML. It would likely be more efficient that way too, since it's a direct database query versus having to load the Wiki HTML, and then parse it.

RFC ErkDog 21:39, 27 November 2006 (CST)