Skip to content
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

Debug low-res tile in example #15

Closed
2 tasks done
kylebarron opened this issue Jun 17, 2020 · 7 comments
Closed
2 tasks done

Debug low-res tile in example #15

kylebarron opened this issue Jun 17, 2020 · 7 comments

Comments

@kylebarron
Copy link
Owner

kylebarron commented Jun 17, 2020

Conclusion:

From below

Ok so this is a bug in pymartini in rescale_positions. Specifically, when you set column_row=False you're using a different transposed matrix for the Martini errors step and for the terrain lookup step!

So basically column_row should always be True so that you're using the same axis ordering for generating the mesh and the terrain lookup, and just add better documentation about whether a .T is needed before passing the tile to pymartini.

Todo:

  • Remove column_row option; make it always True
  • Add docs about needing to transpose input matrix

This tile has a way higher mesh max error than it should.

It should be easy to find this tile's OSM index from the example viewer, then it could be anywhere in:

  • Terrarium tile (unlikely) Ruled out here
  • Decoding (unlikely)
  • Mesh generation (possible)
  • Encoding (possible)
  • Decoding (unlikely)
  • Rendering (unlikely) Ruled out here

image

@kylebarron
Copy link
Owner Author

It's also weird how it's the near corner that happens to be lower res on multiple tiles

image

@kylebarron
Copy link
Owner Author

Ok lets debug this tile, in the central grand canyon: zxy=12/772/1607.terrain. Full Url:

https://us-east-1-lambda.kylebarron.dev/dem/mesh/12/772/1607.terrain?url=terrarium&mesh_max_error=18.82

image

At first glance, you might think the mesh max error of 18.82 is too high, but even if you reduce it to 5, the near corner is still low-res
image

When visualized with quantized-mesh-viewer, the corner is still low-res, so we can rule out a rendering issue. (Note that the mesh being upside down is expected since it's designed to be the same coordinates as a png in this case for use with deck.gl)

image

@kylebarron
Copy link
Owner Author

To be blatantly obvious, it's clear that the actual topography of that section of the canyon is detailed, so there should be a more detailed mesh
image

@kylebarron
Copy link
Owner Author

Swapping the Mapbox terrain source with Terrarium tiles, it's clear the Terrarium tiles aren't wrong.
image

@kylebarron
Copy link
Owner Author

Bug looks to be in the rescale_positions step. When I use

rescaled = rescale_positions(
    vertices, tile, bounds=bounds, flip_y=flip_y, column_row=True)

I see the correct mesh, just rotated
image

When I use

rescaled = rescale_positions(
    vertices, tile, bounds=bounds, flip_y=flip_y, column_row=False)

I see it in the "correct direction" (i.e. looking south (north?), which makes sense since I want it to be the same orientation as the PNG), but with incorrect mesh
image

@kylebarron
Copy link
Owner Author

Ok so this is a bug in pymartini in rescale_positions. Specifically, when you set column_row=False you're using a different transposed matrix for the Martini errors step and for the terrain lookup step!

See how sparse the triangles are in the bottom right, but how there are so many in the flat area on the rim!

@kylebarron kylebarron transferred this issue from kylebarron/quantized-mesh-encoder Jun 18, 2020
@kylebarron
Copy link
Owner Author

So basically column_row should always be True so that you're using the same axis ordering for generating the mesh and the terrain lookup, and just add better documentation about whether a .T is needed before passing the tile to pymartini.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant