loaders.gl icon indicating copy to clipboard operation
loaders.gl copied to clipboard

Tracker: Release checklist

Open ibgreen opened this issue 5 years ago • 2 comments

v3.1

General

  • [ ] MVTLoader tests fail under Safari (yarn test browser, open localhost:5000 in Safari) P1 @kylebarron @jesusbotella
  • [ ] Lighting is broken in gltf example?
  • [ ] Support ecmascript modules
  • [ ] Support node 16
  • [ ] Define category format for textures @ibgreen - P0 #747

New Loaders

  • Experimental Geotiff, Zarr, Parquet, ...

Worker Support

  • [ ] Support batched workers. @ibgreen

  • [ ] Support Node.js workers in @loaders.gl/worker-utils

  • deck.gl

    • [ ] Update 3d-tile example to not import and register DracoLoader @dryabinin-actionengine
    • [ ] Update gltf example to not import and register DracoLoader @dryabinin-actionengine
    • [ ] Update 3d-tile JSON example to not import and register DracoLoader @dryabinin-actionengine
    • [ ] Update i3s JSON example to not import and register DracoLoader @dryabinin-actionengine
    • [ ] Update pydeck examples to not import and register DracoLoader @dryabinin-actionengine
    • [ ] Remove draco install from package.json files @dryabinin-actionengine

v3.0

Shipstoppers

  • [ ] tile-converter issue
  • [ ] GIS category typescript issues

Worker Support

  • [x] Rebase WorkerLoaders on @loaders.gl/worker-utils - P0
  • [x] Support Workers in Crypto library. @ibgreen

Updates to other frameworks

  • luma.gl
    • [x] Update gltf example to not import and register DracoLoader https://github.com/visgl/luma.gl/pull/1386

ibgreen avatar Jun 07 '20 15:06 ibgreen

  • MVTLoader tests fail under Safari

It's this test that's failing.

https://github.com/visgl/loaders.gl/blob/112b16c544debdebaf17dfefad9814107e9e6283/modules/mvt/test/mvt-loader.spec.js#L125-L144

Specifically it looks like there are some float precision errors in Safari. The created geojson is expected to match this file. In this screenshot the first console.log is the geojson decoded from MVT, and the latter is what's expected to match. There are several such differences. image

So I'd guess a good solution would be to use some epsilon instead of strict equality for float checking here?

kylebarron avatar Jun 14 '20 18:06 kylebarron

Thanks for investigating, this makes sense. It is not really a bug then, but nevertheless, it would be good to get a clean test run.

There is a test/utils/tape-assertions that exports tapeEqualsEpsilon(t, value, expected, epsilon, message),

ibgreen avatar Jun 15 '20 16:06 ibgreen