Avoid reprojection & use coordinates in 3857

[gerbsen]

Hey there,
Is there any way to insert coordinates in web mercator projection without the intermediate transformation to 4326?

We do have lot's of geometries for our vectortiles service on the server in 3857, we have to transform them to 4326 only to let mapbox gl reproject them again to 3857.

cheers,
daniel

[mourner]

Can you describe your use case in more detail? Mapbox vector tiles coordinates are Mercator-projected. Or are you referring to GeoJSON support?

[gerbsen]

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 client. 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.

[mourner]

You could convert to vector tiles on the server then. E.g. PostGIS recently added native support for MVT. I don't think there's anything actionable about this issue on the GL JS side.

[gerbsen]

I don't quite get it, sorry. mapbox gl js is forcing me to provide geometries in 4326, right? is there anyway to add geometries in 3857?

[mourner]

We have written our own vectortiles service
mapbox gl js is forcing me to provide geometries in 4326, right?

I'm really confused. Mapbox GL JS renders vector tiles. Vector tiles efficiently encode 3857-projected geometry. What am I missing?

[anandthakker]

@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

[wai-code]

i add the geojson source to the map, my geojson file useed epsg:3857 projection.
when i add this data to a layer, mapbox-gl-js can't render the geojson data.
what's the problem?

[andrewharvey]

@Devcopper so right now your geojson must be in epsg:4326 (wgs84 geographic coordinates) to use with the GeoJSON source

[wai-code]

@andrewharvey the mapbox-gl-js draws map with the epsg:3857(webmecartor), my data is epsg:3857 too.
Now i must convert the data to epsg:4236 as GeoJSON source, the data will convert to epsg:3857 when drawing.
i means that it wastes time and it is meaningless.

the mapbox-gl-js draws map with the epsg:3857(webmecartor), why the GeoJSON data not support epsg:3857?

do you understand me ? so sorry for my poor english.

[andrewharvey]

@Devcopper Yeah I understand. If you use the vector source and provide Mapbox Vector Tiles these will be in EPSG:3857 and so no reprojection is needed. However in the GeoJSON RFC7946 the data must be in EPSG:4326 and so most GeoJSON data is in that projection.

I don't think anyone here's said a flat out no it shouldn't be supported, but if you're proposing to implement I'd ask:

1. Do performance profiling to see how much of a penalty doing the re-projection has, ie. if there's negligible performance difference, then is it worth it?
2. Since the GeoJSON spec doesn't support other coordinate systems, you'd be providing invalid GeoJSON, though still possible you'd need to flag it as such external to the GeoJSON, it can't be handled transparently.

Personally I don't think it's worth implementing, but if you can provide 1, then I think you have a fair argument on why it should be supported.

I reckon though if you're dealing with large enough data to even have a chance of making a difference with respect to the performance, then GeoJSON source is probably not the best option anyway, and you should be using MVT, which negates this whole feature.

just my 2c.

[sabit990928]

@andrewharvey I'm not quite sure is my problem related to especially this issue, but let me explain what problem I'm currently facing

On the server we have wkb_geometry data in epsg 3857 format. In the front we have mapbox config as below:

const mapConfig = {
  minzoom: 0,
  maxzoom: 22,
  tileSize: 256,
  style: {
    version: 8,
    sources: {
      'carto-light': {
        type: 'raster',
        tiles: [
          'https://a.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://b.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://c.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://d.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
        ],
      },
    },
    layers: [
      {
        id: 'carto-light-layer',
        source: 'carto-light',
        type: 'raster',
      },
    ],
  },
}

For some reason there some translation/transformation issue as in the screen below:

Is there someone who faced to such issue?

[someerror]

@andrewharvey I'm not quite sure is my problem related to especially this issue, but let me explain what problem I'm currently facing

On the server we have wkb_geometry data in epsg 3857 format. In the front we have mapbox config as below:

const mapConfig = {
  minzoom: 0,
  maxzoom: 22,
  tileSize: 256,
  style: {
    version: 8,
    sources: {
      'carto-light': {
        type: 'raster',
        tiles: [
          'https://a.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://b.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://c.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
          'https://d.basemaps.cartocdn.com/light_all/{z}/{x}/{y}@2x.png',
        ],
      },
    },
    layers: [
      {
        id: 'carto-light-layer',
        source: 'carto-light',
        type: 'raster',
      },
    ],
  },
}

For some reason there some translation/transformation issue as in the screen below:

Is there someone who faced to such issue?

Hello. I have the same problem.
Tell me plz, did you manage to solve the problem?