We should get popups working, if nothing else to test the full mode of interaction formatters.

We should implement this soon.

To be clear here, we've actually been working around an undocumented interaction API that extends TMS:

• 1.0.0/{map}/formatter.json
• 1.0.0/{map}/legend.json
• 1.0.0/{map}/{z}/{x}/{y}.grid.json

This is actually distinct from the MBTiles interaction spec, which is essentially a spec about how MBTiles should store data such that a service would have what it needs to implement the endpoints above.

We should figure out where this spec should live and revisit some decisions. I'm now thinking that formatter.json & legend.json should be combined into a single endpoint that is also a marker indicating that a certain layer supports the spec. At the moment wax is querying for grid.json against every layer that seems like it might support the spec and it would be good to avoid this.

The manual should displace the need for examples.

if their api supports custom layers: let's see.

Hi,
the interaction example in the manual ( http://mapbox.github.com/wax/manual/index.html ) seems to be currently broken. It only works as long as you don't pan/zoom. Then, when moving the mouse over the map, it throws

Uncaught TypeError: Cannot call method 'charCodeAt' of undefined

at wax.mm.js:287 (in wax.GridInstance.getFeature)

At one instance, this was because (y-tileY) was negative, though I have no idea how this can happen...

Next big task -- update tilestream to use wax, as well as our examples if possible. This will tell us where the wax API is broken and probably more likely which of our "glue code" needs to be refactored to be more friendly toward reification.

Some initial guesses at bad apples that need to get in line:

• "externals", e.g. wax.ol.ZoomOnLoad
• the google maps connector code

Currently, wax tries to redownload a grid.json file on every mouse movement when the previous download failed due to a 404. We should either send a 200 response with a reasonable default or stop wax from attempting to redownload failed grid.json files.

This is an optimization I see around town - might be good.

Basically, figure out a scenario to allow iPad touch interaction without breaking other kinds of interaction.

This should be replaced with $.proxy or better call structures when possible.

Currently the Google Maps code is all in one file, incorrectly named Interaction.js.

We'll need to abstract the OL legend control and implement it for google.

Currently working on nice documentation for actual API usage.

It would be useful to the expose the actual API objects that the wax record creates so you can use a more traditional API for further manipulation after the wax is processed.

This would allow you to use a wax record as a starting point, but then follow traditional documentation to add further functionality.

Once we have some interaction mbtiles up publicly on mapbox.com we'll be able to point our examples at them.

If formatter.json fails to load, retry requests continue to hit the server. We should bail after failure or implement a max_retry.

https://skitch.com/diggersf/rt8m6/firebug-tilestream

Got to do it sometime.

There seems to be a lack of documentation on how to use openlayers with Wax. All of the examples in the manual are for ModestMaps or Google Maps. I looked back at the /examples directory that used to be part of Wax, but it focused on Records based maps. Are there some simple examples out there of how to put together a Wax based OpenLayers map?

I am using a base layer and then an interactivity overlay on top of that. It looks like I need to use OpenLayers for that because ModestMaps only support a single layer. I have built the docs using Docco, but they don't provide too much insight.

Thanks for any pointers you can offer!

When there's a public tileset with legend data, make a good demo of it in the manual.

• Different offsets from pageX, pageY
• IE
• Broken interaction code

In the move to MM in TileMill we lost the ability to right click on the tile and copy the "path to the image" so that a tile url can be quickly grabbed for debugging.

Any suggestions on how to do this with mm? (or ideally re-create what we had with OpenLayers?) Tagging as an issue here because I assume we need to write a custom MM control.

Just discussed this with tmcw we need to restructure wax to be easier for implementers to use and know what to include.

One possibility:

wax/
  connectors/
    ol.js
    g.js
  lib/
    grid.js
    tooltip.js
    legend.js
    json.js

Other layout proposals?

I am not quite sure at what layer this issue lies (TileMill, Stream or Wax). It doesn't look like the toolchain can handle interactivity layers where there are multiple points and the same location. An example would be 3 points at the same addresses, you would want information for all 3 points returned when moused over. Is this currently possible and I am doing this wrong? Is special coding need for the Wax tooltips when you have multiple points?

The ideal behavior would be that you would get all of the items displayed with you mouse over a point and all of the detailed information for all of the points when you click.

No map appears at http://developmentseed.org/blog/2011/may/16/tilemill-020-release in Firefox 3.6.16.

The manual should say something about NRP and MapBox.

Long-running pages will fill up with grid data. The Google API gives us nice utilities for this OpenLayers might. We should use them to garbage-collect.

Zooming out sometimes kills maps, leaving an error about coord.zoom being undefined. This might be a modestmaps core bug - will need more investigation.