mapbox / mapbox/vt-pbf

Possibility to use other projections ?

Open
#22 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
206
Forks
38
PR merge metrics
No merged PRs in 30d

Description

Hey there,
I've described my case [here](https://github.com/mapbox/mapbox-gl-js/issues/5317) and got the suggestion to re-add the issue here. To sum this up:

We have written our own vectortiles service based on vt-pbf, which queries a really large database and transports the tiles in gzipped-geojson (which have to be in 4326 as per the spec, I believe) to our clients. Currently the geometries in our database are still in 4326, but I thought it would be useful to transform those to 3857 in order to save the transformation from 4326 to 3857 in the frontend.

[This](https://github.com/mapbox/tippecanoe/issues/217) is probably also relevant.

@anandthakker replied:

> @gerbsen if you're using vt-pbf to generate vector tiles from GeoJSON data, then yes, the input data are assumed to be in 4326 per the spec.
>
> Is what you're looking for an option to vt-pbf allowing the input to be already projected into 3857? If so, please open an issue in the vt-pbf repo describing your use case / request: https://github.com/mapbox/vt-pbf. This is something we've done in other MVT-generating tools --
> see, for example, mapbox/tippecanoe#217

cheers,
daniel

attn: @abenrob

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing vt-pbf's vector-tile serialization entry points and the linked tippecanoe discussion about projected input. Define how an option for accepting 3857 data would coexist with the current 4326 expectation; done means the requested projection can be used without breaking existing input behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.