Allow arbitrary scales to be specified, e.g. @4.2x (particularly useful for static api and printing)

[samwillis]

I am using tessera to generate static maps for printing (replacing similar functionality in Mapbox Studio Classic), to do this you need to be able to set arbitrary scales rather than just @1x, @2x, or @3x (actually @1x can’t currently be explicitly be set) for example @4.2x. This is needed so that you can create images of the correct size and DPI.

This also implements a cache of 100 sourceURIs (randomly evicted) so that it isn't re-creating the sourceURI for each tile drawn. If we were to save the sourceURIs permanently the list would grow infinitely over time as more unique scales are used. Scales 1, 2 and 3 are never evicted from the cache.

This functionality may want to be behind a configuration options so that it’s not available by default on a publicly accessible server?

[mojodna]

Ooh, cool!

Don't worry about the caching--that's taken care of by tilelive-cache (you can increase the number of sources cached using -S). It's an LRU, so it's moderately smart about not dropping the more heavily-used sources. Can you remove that logic from the PR?

Yes, this should definitely be a configuration option.

I wonder if scale should be a URL parameter rather than part of the filename... Do you know of prior art for including arbitrary scales in filenames?

[samwillis]

Happy to remove the caching of sourceURIs, I added it as you currently pre-generate the uri's for @2x and @3x maps. Shall we just keep them pre-generated and make all other scale uri's on the fly for each tile?

I will have a read through the code and see if I can workout how best to add and an arbitrary scales option to both the command line and the config files (I'm relatively new to Node and map stuff so this is fun).

Mapbox Studio uses: /static/{zoom}/{minX},{minY},{maxX},{maxY}@{scale}x.png?id={style} so the scale is in the filename. It seems to be the right place for it as you want to keep the retina scales in the filename to follow convention. In a way this is just abusing the retina option but is exactly as Mapbox Studio does it when creating a high resolution map to print.

Maybe another static option for the future would be something like: /static/{minX},{minY},{maxX},{maxY}/{zoom}/{widthPX}x{heightPX}.png so that you don't have to calculate the scale needed (as I currently do on my end) to get the right image dimensions as this would be done by tessera? Its almost a cross between boundsPattern and centerPattern. Having the zoom option is good as it lets you specify the level of detail on the generated map.

[mojodna]

Have a look at #31--I think it's part of the way there. At present, scale is determined from the URL (using the @<scale> suffix), but it could be calculated on the fly (I have code kicking around somewhere that does this), given a target image size + bounding box.

Adding more variable scales to the static endpoint seems preferable to me over arbitrary tiling (then it doesn't need to be a configuration option).

Happy to remove the caching of sourceURIs, I added it as you currently pre-generate the uri's for @2x and @3x maps. Shall we just keep them pre-generated and make all other scale uri's on the fly for each tile?

Yeah, that's what I'd do. Pre-generating (and then calling tilelive.load) the common sizes just pre-warms the configuration (for complicated styles, Mapnik can take a little while to initialize).

Mapbox Studio's URLs make sense since it's clear (to me, anyway) that they're dynamic according to the bounding box. So if it makes more sense to use that, the scale could go in the path. My hesitation derives from Apple's filename guidelines for retina assets and any associated magic.

[mojodna]

...while I may have code sitting around, scale calculation may already be in abaculus, so I'd start there.

[mojodna]

@samwillis have you had a chance to revisit this?

[edvinbrobeck]

Any updates regarding this?