-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Depending on cutting-room-floor module #105
Comments
https://github.com/mapbox/mapbox-geostats was the intended replacement for tile-stat-stream. But my memory is hazy -- not sure if its an easy fit or not. I was pretty sure we'd worked mapbox-geostats into our downstream tile-generation service, which makes me wonder if any tile statistics that are being generated by this repository are just being ignored? |
Correct, we're using mapbox-geostats now and are not using the 🍎 a new major release completely removing stats generation |
While we're here, let's update dependencies to get rid of these warnings:
|
@springmeyer just to confirm - are you in favor of 🍎 or 🍌 ? |
@mapsam 🍎 |
Working over in #107 Some upstream updates will be necessary to get rid of all these module warnings 😞 (including mapnik). Here are the culprits queue-async - I've updated this immediate module to use d3-queue, but this will persist until tilelive and tilelive-omnivore are updated.
tough-cookie - these are largely in some big upstream modules that will largely be fixed by updating request in all of them (no small feat) and updating node-sqlite3
node-uuid - will be fixed by updating request.js in tilelive-vector
minimatch ✅ fixed by updating tape protozero - requires update to mapnik/mapnik-vector-tile to install via mason instead of NPM
|
This will depend on mapbox/mason#396, unless we shortcut by using a git submodule (currently done as a hack in node-mapnik for geometry.hpp) |
I noticed we are depending on https://github.com/cutting-room-floor/tile-stat-stream (https://github.com/mapbox/mapbox-tile-copy/blob/master/package.json#L36). I presume this is not a good thing because cutting room floor modules are deprecated/unmaintained.
Anyone know if this is a mistake to have moved that to the cutting room floor? Or an oversight that we should be using something else?
/cc @rclark @davidtheclark @mapsam @GretaCB
The text was updated successfully, but these errors were encountered: