Curious why this is a fork?

[migurski]

…and if there’s something we could do with upstream TileStache so it doesn’t need to be? I see some data-specific changes in VecTiles for example, and think it might make more sense for that to be in a separate repository.

[nvkelso]

Before my time... but this Mapzen fork started off with the intent to merge back to TileStache master (the integration-1 branch here), but over time we're now only using the TileStache python-based Mapzen specific transforms in Mapzen's tile cut process. Mapzen projects like tileserver and tilequeue have replaced the tile seeding and serving utility that TileStache used to provide, with Fastly in front of that. The plan is for the remaining transforms to also be pulled out of this TileStache fork so the fork becomes EOL'd.

Ragi at Amigo Cloud is very interested in the pulling this stuff back to master, too. But it's not straight forward to figure out what should actually be taken back to TileStache master (nor is it core to the remaining Mapzen work).

[migurski]

Thanks, this is really useful background info!

[mjcunningham]

cc-ing @rmarianski for any extra deets.

[rmarianski]

Yea, we're using TileStache as a library now instead of as a server. Imho the parts that would be useful to extract out into separate packages are the different format encoders. We have the mvt encoding already separated out, but topojson and opensciencemap would be nice to separate out too.

Like Nathaniel mention, we've also been putting the transformation steps in there that are used to process the data. It would make more sense to have that live closer to the queries, because they tend to be updated together. Those are Mapzen specific.

We'd have to double check the details, but with those pieces extracted out we might not have to run a fork any more.