stamen / maps.stamen.com Goto Github PK

Let's make it easy for people to share images of tiles on Pinterest.

Per: http://pinterest.com/about/goodies/

Because I want to be able to serve out tile.stamen.js from an app that is sometimes served over https & maps.stamen.com is only served over http, I can't use the include

The easy solution is to include tile.stamen.js in my app's js. What license is tile.stamen.js under? Would it be possible to include that license in a comment in the source file? Thanks!

I think there are a few too many styles in the dropdown on M2I.

• Not much point in putting Trees, Cabs, Crimes there because that's only SF.
• There are 11 Toner variants. While presenting some "slices in the sandwich" is great, I think we should be putting our best foot forward...

Discuss...

Hi pauloj.raposo,

Thanks for writing in. You're right that Centre Island isn't too well represented in watercolor, whose edges are intentionally "blurred."

I can see the roads too, at zoom #15:
http://maps.stamen.com/watercolor/#15/43.6264/-79.3612

And in the Toner style too:
http://maps.stamen.com/toner/#15/43.6264/-79.3612

All I can do is report the oddness to the engineering team, which I will do right now!

Cheers,
george

On May 7, 2013, at 12:24 PM, [email protected] wrote:

Bug report from [email protected] (174.116.190.133):

Center Island is missing, just off the coast of Toronto, Ontario, Canada, though you seem to have roadways for it on the map image making utility. You can see the island, for example, here:
https://maps.google.com/?ll=43.627254,-79.377079&spn=0.038022,0.082312&t=m&z=14
Cheers,
P

http://maps.stamen.com/watercolor/#12/43.6452/-79.3513

feedback form @ http://maps.stamen.com/feedback.php

Fix Copy HTML 2nd click behavior to close the little code snippit.

In tile.stamen.js we define the min and max zoom, but in some cases these limits aren't enforced in their respective tile layers. So I guess we should do two things:

1. Test the abilities of the MM, Leaflet and Google APIs to enforce zoom limits on a tile layer (we pass these parameters along to the Leaflet and Google layers, but I haven't checked to see if they're respected).
2. Figure out how to enforce zoom limits at the UI level throughout the site, so that people can't, for instance, zoom out past 5 on Terrain or in past 14 on Watercolor.

Potential plugins to use to achieve the picture-in-picture effect:

https://github.com/bbecquet/Leaflet.MagnifyingGlass - seems to allow fixed coordinates, but not fixed window locations
https://github.com/turban/Leaflet.Sync - used for MapStack, but unclear how to initially correctly align the inner windows

To match with Toner/Terrain, let's link to Eric's launch blog post:
http://content.stamen.com/maps_dot_stamen_dot_com_is_live

That would be handy. I often have to send 1-2 emails back and forth to get the correct browser info.

http://anitagraser.com/2012/07/21/stamen-maps-for-qgis/

NOW

http://tile.stamen.com/toner/
http://tile.stamen.com/toner-labels/
http://tile.stamen.com/toner-lines/
http://tile.stamen.com/toner-hybrid/
http://tile.stamen.com/toner-background/
http://tile.stamen.com/toner-lite/

http://tile.stamen.com/terrain/
http://tile.stamen.com/terrain-labels/
http://tile.stamen.com/terrain-lines/

FUTURE

http://tile.stamen.com/terrain-hybrid/
http://tile.stamen.com/terrain-background/

Even after a hard refresh, the search still seems b0rked.

On May 6, 2013, at 7:39 PM, NANCY MCEVOY wrote:

I have Internet Explorer 10 with a 10.0.4 update.

Nancy

Thought for Today
"The library is the temple of learning, and learning has liberated more people than all the wars in history."
--Carl Rowan

From: George Oates [email protected]
To: NANCY MCEVOY [email protected]
Sent: Monday, May 6, 2013 1:04 PM
Subject: Re: [maps.stamen.com / watercolor]: Bug report @ 8/41.633/-75.185

Thanks for that extra info, Nancy. I'm wondering if it might be a browser problem… Can you tell me which web browser you're using, and even better, which version? (There'll be an "About" option somewhere in one of the menus up the top when your browser is open.)

Cheers,
george

On May 3, 2013, at 8:03 PM, NANCY MCEVOY wrote:

Thanks for the quick reply. I tried doing a hard refresh (if I did it right), but nothing seemed to change--still no search function. Some locations I tried were: Riegelsville, PA, Allentown, PA, Bucks County, PA. I also tried the zip codes: 18077, 18103. Also tried spelling out the state name. No luck.

When I clicked the "Find" button, it would momentarily flash "Finding" before returning to "Find." If it helps, I was trying to search in the Watercolor function. I just tried the same searches in the Toner function with the same results.

Nancy

Thought for Today
"The library is the temple of learning, and learning has liberated more people than all the wars in history."
--Carl Rowan

From: George Oates [email protected]
To: [email protected]
Sent: Friday, May 3, 2013 6:53 PM
Subject: Re: [maps.stamen.com / watercolor]: Bug report @ 8/41.633/-75.185

Hi pnmcevoy,

Thanks for writing in. We've actually been doing a bit of plumbing on search recently. Would you please either a) doing a hard refresh (SHIFT+RELOAD) on the page to get the new search tech, or, b) send me some specific things you tried to search for that didn't work so I can try to recreate here?

Thanks,
george

On May 2, 2013, at 10:41 PM, [email protected] wrote:

Bug report from [email protected] (96.227.1.100):

When I type in either a zip code or a city, name and state, nothing happens when I click the "Find" button.

http://maps.stamen.com/watercolor/#8/41.633/-75.185

feedback form @ http://maps.stamen.com/feedback.php?style=watercolor

Hi George, and thanks for the reply,

There is still something odd about the manner in which the data must be getting interpreted from OSM. Have a look at this section of the map:

http://maps.stamen.com/toner/embed#9/53.3127/-7.0616

Here we see a bunch of places displayed with English language names: Tullamore, Ashbourne, Greystones, Bray, Dublin and others. In OSM, these names would be present in the "normal" "name" tag and, sometimes, also as "name:en".

But we also see a lot of places whose Irish language names are displayed: Durlas, Cill Chainnigh, Sord, Baile Átha Í and others. These names are present in the name:ga attribute on OSM and are not (nor would they have been in an older dataset) in the name attribute. So what we see is an unusual selection logic for the display names, leading to inconsistency and what I must assume is an unwanted effect.

Wild guess: I see that the city of Munich in Germany is shown on the toner map under its English name, whereas the German name is in the standard OSM "name" tag. So I'll assume that the map is attempting, where feasible, to select a specific language version of names (presumably English) in preference to the generic name which might be in any language. However, in this instance it seems to, at least in some cases, prefer an Irish language name instead.

Does this make any more sense?

Dermot

On 5 March 2013 19:23, George Oates [email protected] wrote:
Hi dermotm,

Thanks for writing in - sorry it's taken me a little while to get back to you, but, here goes!

On Mar 1, 2013, at 5:02 AM, [email protected] wrote:

  On the toner map, the placenames in Ireland are displayed inconsistently, with some (Newtown Trim) not being commonly used names at all (should be "Trim") and lots of names being rendered in the Irish language, others in English. Are these names coming from a non-OSM source? Either way, the current result is an inconsistent one.

http://maps.stamen.com/toner/#9/53.3909/-7.3310

The place names are all coming out of OSM, but it's not a live one-to-one mapping. I think we're using a version of OSM that's some months old, so differences you see in the live OSM names won't necessarily show up. We would love to have a more up-to-date version of the maps available, but, that's a herculean task and sadly, the grant we used to fund the Citytracking (and maps.stamen.com) development has ended.

We want to keep the site online though, for sure, because it's been so popular!

Cheers,
george

@mojodna any objection to the increased visibility of the M2I system?

Pending final availability analysis

See
https://github.com/jonahadkins/ags-js-custom-map

Once we get around to updating the OSM data that backs maps.stamen.com, the OSM attribution will need to change to reflect that the data will had been acquired under the terms of the ODbL (their requested attribution appears to be "© OpenStreetMap Contributors"). (http://wiki.openstreetmap.org/wiki/Legal_FAQ)

This map revealed two issues with the google.maps.StamenMapType layers:

1. Tile coordinates aren't wrapped at the meridian, so they generate urls with negative X and Y values, e.g.: http://tile.stamen.com/toner/2/-2/-1.png
2. The subdomain switches don't like negative indices, so they generate urls with undefined where the subdomain should go, e.g.: http://undefinedtile.stamen.com/...

Wrapping the coordinates will solve both of these issues.

Bug report from [email protected] (212.55.211.178):

Your contribution text is not shown on OpenLayers because it is never set. Add it at tile.steamen.js, Line ~186: attribution: provider.attribution. Cheers :)

http://maps.stamen.com/toner/#12/37.7706/-122.3782

...to ease copying and pasting locations from OSM/OpenLayers-powered sites.

E.g.
http://www.openstreetmap.org/?zoom=12&lat=47.47661&lon=19.09595&layers=B00000

Where it says on http://maps.stamen.com:

Immitate the Toner flavors bit by adding to the end of the Terrain section:

Add:

Available in three flavors: standard terrain, labels, and lines.

Just noticed a string of 3 reports about missing lakes... there may be no connection, but thought it might be worth noting.

Bug report from [email protected] (65.170.160.172):

Black Lake is not shown in Northern Michigan ˆ near zip code 49765 between Onaway and Cheboygan.
http://maps.stamen.com/watercolor/#9/45.2319/-84.1981

Bug report from [email protected] (174.52.93.61):

Amazing tool, but...an enormous lake - Utah Lake, south of Salt Lake, is missing -just looks like a big desert.

http://maps.stamen.com/watercolor/#12/40.3642/-111.7378

Bug report from [email protected] (76.21.1.154):

I absolutely LOVE your site!
I have mapped quite a few places and they've all looked fantastic, however, I just tried to watercolor map "Lake Texoma" and it shows the lake area as brown.

http://maps.stamen.com/watercolor/#12/33.9572/-96.5951

On my site using the Stamen tiles in a Leaflet map, the latest update breaks in older IE as the code now includes a forEach method which isn't supported in older IE versions.

forEach found here: https://github.com/stamen/maps.stamen.com/blob/master/js/tile.stamen.js#L64

So that people can use tile.stamen.js on SSL sites.

Once you're in Toner, there are now flavors. Similar for Terrain.

NOW

http://tile.stamen.com/toner/
http://tile.stamen.com/toner-labels/
http://tile.stamen.com/toner-lines/
http://tile.stamen.com/toner-hybrid/
http://tile.stamen.com/toner-background/
http://tile.stamen.com/toner-lite/

http://tile.stamen.com/terrain/
http://tile.stamen.com/terrain-labels/
http://tile.stamen.com/terrain-lines/

FUTURE

http://tile.stamen.com/toner-hybrid/
http://tile.stamen.com/toner-background/

They look great in WebKit, but the combination of line-height and padding makes for much more space below the glyphs than above in IE9.

Both the "windowed" maps up top and the static mini-maps have image scaling issues in IE9. This could be because it's doing sub pixel positioning of the center column.

Either way, it's ugly and needs to stop.

Sorry, @migurski!

On Jan 16, 2013, at 3:51 PM, [email protected] wrote:

Bug report from [email protected] (72.78.208.3):

On android tablet, tiles have white borders around themselves - don't quite touch neighboring tiles.

http://maps.stamen.com/watercolor/#12/40.0020/-75.1180

feedback form @ http://maps.stamen.com/feedback.php?style=watercolor

Add random map style on load for the main page.

Watercolor, Toner, Terrain are the three options.

Add embed code (ala Dotspotting) for main 3-up page and for the dedicated pages.

Some of the help emails I get don't have the map-type stamped in the URL.

Like,
http://maps.stamen.com//#12/37.7706/-122.3782
http://maps.stamen.com/????????/#12/37.7706/-122.3782

From there, I can't tell which map style they're talking about unless they say something specific.

E.g.

Bug report from anonymous (67.186.132.2):

looking great

http://maps.stamen.com//#12/37.7706/-122.3782

feedback form @ http://maps.stamen.com/feedback.php

I'm not sure it's the best place to put this but I was stuck with this error:

Cross-origin image load denied by Cross-Origin Resource Sharing policy.

In Chromium, when using your js/tiles.stamen.js with the watercolor layer.

All the images where nicely downloaded by my browser but not displayed... Here is what I've got to do:

var watercolor = new OpenLayers.Layer.Stamen("watercolor");
watercolor.tileOptions.crossOriginKeyword = null;
map.addLayer(watercolor);

The second line is the important one.
It's an OpenLayer related issue and the solution is explained here: http://dev.openlayers.org/apidocs/files/OpenLayers/Tile/Image-js.html#OpenLayers.Tile.Image.crossOriginKeyword

On the style pages it's too easy to click on the enclosing elements of the search form and zoom controls, which both block the map and prevent panning.

See Wax's implementation.

[redacted]

Where it says on http://maps.stamen.com:

Available in three flavors: normal, no labels, only labels.

Change to:

Available in six flavors: standard toner, hybrid, labels, lines, background, and lite.

Gains us not-selectable line numbering and best practices.

Whoops.

Let's add a bright yellow button alongside the main map style's label in the bottom left map area on the main maps.stamen.com page. Maybe a unicode character like this, in the yellow background (to the right of the text label)?

⇲

Eric has some ideas about this.

Basically the place in the top left corner where it says

maps.stamen.com / MAP_TYPE

Thinking of making MAP_TYPE a live dropdown to the other map types (Toner, Terrain, Watercolor)

Either we're not accounting for "hashchange" event support properly in MM.Hash, or something is going wrong in ProviderHash::update().

...somewhere that we can have an easy deployment process.

The 2 main snags are:

• feedback.php (so it theoretically requires PHP); this isn't working at the moment, so it arguably doesn't matter (though we'd want to drop the "report a bug" link)
• subdirectories that are deployed on Pair that aren't public / in different repos / contain configuration (e.g. mars, m2i, m2i_eric, burningmaps)

I wonder if we really need to use the Yahoo API anymore. The Mapbox geocoder should be just as good for these sorts of cases.

I expect their pricing will be a bit better. This switched over to Yahoo! BOSS from the deprecated endpoint: 8cbfdd2.

The BOSS geocoder is used via stamen/node-geocoder (hosted on Heroku), which returns dramatically filtered results, as BOSS requires OAuth keys.

/cc @standardpixel

Anyone who submits a bug with an email attached should get a Thank You email.

Text tk tk tk.

Hey there! I'm interested in generating some maps bigger than 2000x2000 like I can at http://maps.stamen.com/m2i/, for my own personal use. Is there a way for me to do this? I can't find m2i in the source here.

Thanks!

Need a proxy to manage that behaviours. Poo.

On Jun 16, 2013, at 1:34 PM, [email protected] wrote:

Bug report from [email protected] (77.123.187.11):

Dear Sir or Madam,

The watercolor map (http://maps.stamen.com/test/google.html) is not not displayed in Google Maps in some browsers (Firefox, Chrome) now.

Best regards,
Andriy

http://maps.stamen.com/watercolor/#12/37.6592/-122.3284

feedback form @ http://maps.stamen.com/feedback.php?style=watercolor