Browser restrictions on max open requests are usually per-domain: I don't think there's much reason to have a global limit of 4 requests per provider in all cases - especially for browsers with low (2) connection limits, there can be a big speed boost to opening up the pipes a bit.

Showing broken images or just leaving the map transparent. We did the latter for http://cartagr.am and that's what polymaps does too.

Update: as outlined in #76, it might be desirable to retry and/or to display a meaningful error somewhere if the response is not an image.

In the process of zooming marker jumps. Its location is shifted by several tens of meters at different levels of zoom.

For example: http://m.nadoloni.com (tested on IPhone)

I'm writing some functionality that requires clicks on the map (as well as double-clicks for navigation, of course). Currently I've hacked together something similar to OpenLayers in this respect, but it might be in the scope of Modest Maps itself to deal with the problem of browsers registering dblclick and click 'unusually' in different browsers, and for click events triggering before dblclick events.

Untethering some parts of Modest Maps from the DOM (#23) would make it easier to unit test or integration tests parts of Modest Maps. Unclear what testing frameworks would be involved - I can do a bit of research in that area, and see if there's something that'll work both in node and on the web.

This is when I try to install modestmaps with npm install modestmaps

npm ERR! Unsupported
npm ERR! Not compatible with your version of node/npm: [email protected]
npm ERR! Required: {"node":"= 0.4.x"}
npm ERR! Actual:   {"npm":"1.0.6","node":"v0.4.8"}

Modestmaps probably shouldn't specify an engine at all since there is little that is specific to a JS engine.

The current wiki page is awesome, super-useful, great documentation. And it's good that the source is compact enough that you can read it for most things. Possibly we integrate something a little bit more like API docs or like literate-style documentation to flesh out documentation for 'all of the corners' of the library?

Okay, this one's up for debate, it's just something that's been bugging me:

The com.modestmaps convention in this naming (which polymaps inherited), seems to be a narrowly Flash (and I suppose Java) idiom, not seem elsewhere in Javascript. Could the library eventually move to simply modestmaps?

map.setSize accepts either (x, y) or ({x: 0, y: 0}) as arguments, and then it passes [{x: 0, y: 0}] to its callback. I don't grok any strong reasons why three types of representing size are necessary here - I think we should choose one (probably the size-object), and just go with that.

Hi

I found a bug. Try to do it:

var provider = new com.modestmaps.MapProvider(function(coord) {
var img = 'z'+parseInt(coord.zoom+1)+'/x'+parseInt(coord.column)+'/y'+parseInt(coord.row)+'.png';
return 'http://nadoloni.com/tiles/' + img;
});

map = new mm.Map('map', provider, new mm.Point(256,256))
map.setCenterZoom(new mm.Location(49.2928, 23.5177), 14);

As you can see - empty block. I think, that problem is here:

toKey: function() {
...
}

If toKey return concated string, empty box disappears

Could also support side-by-side small-multiples maps.

Rather than in anyzoom example.

Main layout might look like:

still using new

• Map

object-builders

• Handlers
• Request Manager

Object literals

• Coordinate
• Location
• Point

When you create a bubble with a link just outputs the text.

There are several parts of modest-maps that are reimplementing parts of jQuery, Ender, etc, and a majority of users are already using one of these libraries. Thus, it might constitute a decrease in overall file size and reduce the energy needed on generic DOM tasks, browser-equality, etc., to start using a library for these parts.

The two options that most readily come to mind are jQuery and Ender. Since there's a lot of crossover between the two APIs, trying out one and switching to the other might not be too costly. jQuery certainly has a lot more adoption off the bat.

The expresso tests are decent for some purely mathematical code, but I think we should have jasmine tests to confirm core functionality and utilities cross-browser.

So you can do:

map.addCallback('click', function(){
    alert("HI·THERE");
});

Instead of:

com.modestmaps.addEvent(map.parent, 'click', function(event) { 
    alert('yo');
})

// I'm leaving this uncommented for now but you should never see it:
alert("Gah: trying to removing cached tile even though it's still in the DOM");

Turns out that IE sometimes displays this. Unfortunately, I couldn't figure out how to reproduce this issue.

While stuff like the port of .hash() and the controls in wax, I'm wondering what kind of pattern we should set up for adding controls to maps. Currently I'm going with a chaining approach, where the control is a function on the Map object, but this has started to get weird: in TileMill, we'll do

m.boxselector()

and then

m.boxselector.remove()

to remove it. It's kind of cool, but also a bit awkward, and extending the map object itself seems a lot less modular than I'd like - though it does end up looking nice. Checking out the controls in polymaps, even, most don't support removal - once they're on, they're on - while reusing map objects is kind of becoming more common, especially when people are using hashchange-based and dom-persisting frameworks like Backbone.

(oh, and, yep, TileMill finally dumped OpenLayers (yay))

@yhahn's fix to the IE stack overflow error ( c202b0a ) does the trick on Internet Explorer, but causes all browsers only to execute getLoadComplete after a drawn event. This batches tile loads into fours, despite the fact that the tiles are, in some instances, cached.

Ideally there can be a solution that doesn't lag on other browsers and doesn't break IE. In the near term, we'll probably run with the IE fix in a dreaded if-else to avert this scenario, and I'll work on alternative fixes.

The discussion thread about DOM manipulation and events seems to be useful, let's discuss here about use of prototype and new.

My hunch is that especially in older/slower browsers and js engines, prototype is useful for performance reasons when providing methods on objects that you want to instantiate many times. Location Coordinate and Point are all good examples of this in Modest Maps. There is some evidence for my hunch at http://stackoverflow.com/questions/3493252/javascript-prototype-operator-performance-saves-memory-but-is-it-faster but we should do our own benchmarks.

Removing the use of prototype could also remove the need for new. The methods that are now constructors would become factory methods. It would be possible to protect against forgetting to use new by using an instanceof check in our existing constructors (see http://ejohn.org/blog/simple-class-instantiation/ ). I'm not sure if the opposite protection is possible/necessary, if using factory methods and accidentally typing new?

It's worth noting that JSLint enforces the use of new on functions beginning with a capital letter. Not that we should require its use, but it's a tool to help people write JS code more accurately and is one option rather than changing the existing lib.

There are a couple of options for how to remove use of prototype. Ignoring static methods (like Location.distance) for Location we currently have:

MM.Location = function(lat, lon) {
    this.lat = parseFloat(lat);
    this.lon = parseFloat(lon);
};

MM.Location.prototype = {
    lat: 0,
    lon: 0,
    toString: function() {
        return "(" + this.lat.toFixed(3) + ", " + this.lon.toFixed(3) + ")";
    }
};

This requires use of new, e.g. var l = new Location(0,0) and provides a nicely formatted toString with little/no overhead.

This could become:

MM.Location = function(lat, lon) {
    this.lat = parseFloat(lat);
    this.lon = parseFloat(lon);
    this.toString = function() {
        return "(" + this.lat.toFixed(3) + ", " + this.lon.toFixed(3) + ")";
    };
};

With no API change, less code (easier to maintain?) but (presumably) a bit more instantiation overhead and still requiring new.

Alternatively we could move to:

MM.Location = function(lat, lon) {
    return {
        lat: parseFloat(lat),
        lon: parseFloat(lon),
        toString: function() {
            return "(" + this.lat.toFixed(3) + ", " + this.lon.toFixed(3) + ")";
        }
    };
};

Which would no longer require new and otherwise offers all the benefits of the closure option.

Alternatively we could use Resig's instanceof check which would change the constructor in the first (current) version to something like:

MM.Location = function(lat, lon) {
    if (this instanceof Location) {
        this.lat = parseFloat(lat);
        this.lon = parseFloat(lon);
    }
    else {
        return new Location(lat,lon);
    }
};

This removes the need for new but keeps prototype around.

I haven't checked any of this code, I'm just thinking outloud. Coordinate would be a trickier case to justify because it has many more instance methods. We should definitely bench mark this, since I think it largely boils down to a speed issue - if prototype doesn't offer speed I think other forms are easier to use and maintain.

DOM rendering should always be the default but canvas rendering is useful for pixel manipulation and shouldn't require a fork of the library.

Hello,

I would like to get MBTILES (www.mbtiles.org) working in MM. I created such a file using gdal2tiles.py (https://github.com/developmentseed/gdal2mb). Next I created a PHP script (sqlite reading from https://github.com/mapbox/mbutil/) which reads the correct PNG file from the MBTILES file. It is called in javascript and MM through:
var provider = new MM.TemplatedMapProvider('http://localhost/mb2xyz.php?code={Z}/{X}/{Y}');

This however doesn't work perfectly, the more you zoom in the less of the northern hemisphere is visible. I was wondering if people might recognize this problem as something from MM. If not, I guess it might be my PHP script. The MBTILES file seems to work perfectly when I open it using Maps on a Stick (http://developmentseed.org/blog/2010/oct/02/maps-stick-version-2-released)

A MBTILES example can be downloaded here: http://mapbox.com/#/tileset/natural-earth-2

Cheers, Jelmer

This is kind of something that we should work on when we're near another 'major tag' so that people don't get tons of merge conflicts, but it'd be useful to start moving towards a predictable code style - there are bits where map.js starts adopting the K&R style and then returns to something more javascript-y.

I've been using fixjsstyle and jshint for a quick hit of code-style enforcement on other projects. JSHint is a little severe, yelling at you for useful tricks, but basic stuff like spacing between variables, missing semicolons, etc., are handled pretty well by fixjsstyle.

I've run into a strange issue using modestmaps js in IE 7/8 - when viewing examples/simple and other maps a Stack overflow at line: 0 error will appear. I've found a few references to this error:

• http://stackoverflow.com/questions/226102/stack-overflow-in-line-0-on-internet-explorer
• http://cappuccino.org/discuss/2010/03/01/internet-explorer-global-variables-and-stack-overflows/

What's interesting is that this error can be somewhat difficult to reproduce - I've been able to determine that it only occurs when the length of the request queue pushes the number of recursions between processQueue() and getLoadComplete above 13 or so. For example, on examples/simple I can reproduce the error when there are no browser-cached images, but once the cache is warmed the number of requests drops below 13 and the error no longer appears.

I'm not familiar enough with the modestmaps codebase at this point to see whether the solution described by the second post is viable -- I don't see the global var reference to processQueue() that would need to be switched to a local var. At the suggestion of @kkaefer, I've been able to address this issue with a different stopgap -- using setTimeout to break the recursion and avoid hitting the IE limit:

In getLoadComplete:

    // keep going in the same order
-   theManager.processQueue();
+   // use setTimeout() to avoid the IE recursion limit, see
+   // http://cappuccino.org/discuss/2010/03/01/internet-explo
+   setTimeout(theManager.processQueue, 0);

In a simple options array, it'd be possible to not have the map listen to and kill mousewheel events, allowing for the useful UI tweak on sites that have large maps and need scrolling.

Currently what people find when they look for modest maps is the flash version, with no real way to find this one. The other problem is that there's no way to actually see this version in action without downloading it. I don't see any reason why the examples won't work straight-up in a gh-pages branch.

Any ideas on this? I think this could stay incredibly minimal - just a little more explanation, links to examples, and possibly automatically-built docmentation pages.

See http://bennolan.com/2011/04/08/native-maps-speed-in-javascript.html - 60fps should be possible on mobile devices if things are tuned correctly.

Just a reminder to commit a patch when I get a second.

When the overall zoom of the page isn't exactly 1, some white lines appear:

It might make sense to tastefully block some usage errors from becoming computer-level errors - like when the ID of the map element isn't found, you get a

Uncaught TypeError: Cannot read property 'style' of null' (in line 1003 modestmaps.js).

It'd be a quick line of code to turn this into something like

Uncaught Exception: Map parent DOM element not found.

Might be nice to have a package.json and npm availability too.

e.g. https://github.com/documentcloud/underscore/blob/master/package.json

Here's how underscore handles being attached to either window or loaded via require():

  // Establish the root object, `window` in the browser, or `global` on the server.
  var root = this;

  // (skip a bit)

  // Create a safe reference to the Underscore object for use below.
  var _ = function(obj) { return new wrapper(obj); };

  // Export the Underscore object for **CommonJS**, with backwards-compatibility
  // for the old `require()` API. If we're not in CommonJS, add `_` to the
  // global object.
  if (typeof module !== 'undefined' && module.exports) {
    module.exports = _;
    _._ = _;
  } else {
    root._ = _;
  }

Should be quick and simple to add something similar for us, and allow use of Locations, Coordinates, Points etc on the server side. Later we can figure out how to render static images, perhaps using https://github.com/learnBoost/node-canvas/

When zooming in or out, Modest Maps overlays multiple layers. When they are translucent, this results in an odd effect as shown in http://i.kkaefer.com/transparent_overlap-20110616-203545.png. Modest Maps should crop the tile so that only the most appropriate layer is visible.

Are there any plans to support multiple providers per map? This was, I think, achieved on the FCC project but isn't possible without hacks yet. I'd definitely be interested in helping out if it's not a conscious exclusion.

requestsById in RequestManager is actually managing requests by key. Either key should be renamed id (unlikely) or requestsById should be renamed requestsByKey.

When double-clicking on a item that overlays the map, the map zooms in even though it wasn't the /actual/ target. The same is true for the scroll wheel. Zooming should only happen when the target was the map itself.

Hi,

I'm using MM + Wax and I would like to restrict the map extent. The user cannot browse north or south of the map extent. The user can browse freely from left to right as the map is infinite. The user can only zoom out to the max extent of the map. Is this possible and if so, how can I do this?

Thanks,

Jelmer

Touch mode often falls at mid-zoom levels which are pretty unappealing. It should be optional that users get real zoom levels when they let go of the map. This work and other stuff working in the transformations branch.

There are many API differences from polymaps that could be eliminated - getZoom() and setZoom(x) instead of just zoom() and zoom(x), etc. Personally, I find the polymaps API to be pretty solid and it'd be nice if one could swap out a lot of the functionality of the two toolkits without these more-nitpicky tweaks.

Don't know if this should be considered as an issue.

But ModestMaps does not work with IE6 and IE7.

This is obviously a bit far off and I think it belongs with a push towards using CSS transforms when in supporting browsers, not just in touch mode.

I think this should be pretty simple, and doesn't really require us to creep in some kind of interface for getting handlers - users themselves should be able to do that.

What's the best way to remove a map? Is it just to remove the maps container? I'm working on a page that will have about 10 maps, but doesn't need to have more than 3 at a time.

It'd be nice to have a hashchange-using permalink functionality in modestmaps. I'll develop this loosely connected to the core - not sure what your opinions are on whether this should be in core or outside.

Simply recording a TODO: Coordinate.toKey() is currently a simple implementation, and probably not a huge performance bottleneck, but could be micro-optimized a bit if someone's feeling clever.

Something like:

com.modestmaps.MapProvider.prototype.setZoomRange = function(minZoom, maxZoom) {
    this.topLeftOuterLimit = this.topLeftOuterLimit.zoomTo(minZoom);
    this.bottomRightInnerLimit = this.bottomRightInnerLimit.zoomTo(maxZoom);
}

It's never completely clear whether this should be set on Map or on MapProvider, but in general you'd use this on MapProvider to tell it that tiles only exist between certain zoom levels.

A similar function on Map would probably also want to set panning limits as well as zoom limits. Map will already respect zoom limits set by the provider.

The pattern of getTouchStartMachine returning a singleton bound functions is pretty common - I think it'd be simpler if this module just included a quick .bind(this) implementation.

It's definitely feature-creep, and most implementations are kind of annoying. But it might make sense on mobile, and is worth a shot.

A cool Polymaps trick is to load more tiles so that iPhone 4 users get non-pixellated maps. Might be worth a shot.

Rather than in touch example.

Perhaps shouldn't depend on webkit transform though - do other browsers support touch events now?