chore(Arrow): add test cases for multipolygon with holes

[lixun910]

I am getting stuck on using the valueOffsets in an Arrow column to identify the holes (inner rings) within a multi-polygon, like this: [[extrior ring1], [interior ring1]], [exterior ring2]]. I think, like wkb or shapefile, we need offset values for 1) 'polygons', 2) 'parts within polygon', and 3) 'rings within parts'

Will create another PR to do earcut on arrow geometries directly:

• polygonIndices and primitivePolygonIndices are not used together to render polygon (binary) with holes in deck.gl currently, so we pass geomOffset as a workaround. This issue needs to be fixed in deck.gl (utils/iterable-utils: getAccessorFromBuffer())

[kylebarron]

I wrote up some text on how to understand geoarrow polygons in https://observablehq.com/@kylebarron/geoarrow-and-geoparquet-in-deck-gl.

You can also see how I'm using earcut in https://github.com/geoarrow/deck.gl-layers/blob/eb157f1ef9b393f6348da950b2f058aa2291d467/src/earcut.ts#L26-L60. Does that help?

[lixun910]

Thanks, @kylebarron! I did read your post and code. It works on simple polygon, polygon with holes and multipolygon. However, it seems not working with multipolygon with holes. See the committed multipolygon_hole.arrow file and the expected GeoJson in the test. Let me know if I miss something. Thanks again!

[kylebarron]

I handle multipolygons by running earcut on each underlying polygon. So I'm rendering polygons individually, and only in picking do I reconstitute what the original multipolygons are.

[lixun910]

@kylebarron See the sandbox code that replicates the issue: https://codesandbox.io/s/test-multipolygons-w-holes-gygchx?file=/src/index.tsx (Please see the comment and console.log in the code. I am using your code in deck.gl-layers). Let me know if this makes sense. Thank you!

It seems we can't get the holes from multipolygon structure from current logic:

The geojson version and the GDAL/Arrow version are correct:

[lixun910]

Attached data:

• mp_hole.geojson
• multipolygon_hole.arrow (created using ogr2ogr)

data.zip

[lixun910]

@kylebarron Never mind. My apologies: the Arrow file generated by ogr2ogr is not correct. After using ogr2ogr holes.arrow mp_hole.geojson -f Arrow -lco COMPRESSION=NONE -sql "SELECT id, name FROM mp_hole", everything works fine now. Thanks for your help!

[lixun910]

Hi @ibgreen can you help to approve this pr? Thanks!

[ibgreen]

I am confused about this.

• What is the correct thing to pass? An array with zero elements?
• What is in the work around? geomOffsets can we name this better or comment on it? Why does that work for deck?

[lixun910]

From the doc (https://deck.gl/docs/api-reference/layers/geojson-layer#polygons), we should pass polygonIndices and primitivePolygonIndices together to deal with the case that polygon has any holes.

Correct me if I am wrong: when I read the code in deck.gl, it seems this only happens in carto-vector-tile-loader (see here), not in solid-polygon-layer with binary geometry format. They are simply used for polygon and polygonOutline indicies (see here)

Thanks, @ibgreen!

[lixun910]

I created another PR #2785 to add triangle indices using earcut, so we can pass geomOffsets for both polygonIndices and primitivePolygonIndices along with the triangles props for solid-polygon-layer with binary geometry format.

[ibgreen]

Correct me if I am wrong: when I read the code in deck.gl, it seems this only happens in carto-vector-tile-loader (see here),

@felixpalmer I see your name on those lines in carto module. Is that something that could/should be upstreamed to the generic / non-carto module?

[ibgreen]

@lixun910 FWIW - when I ask for clarification, I am usually not asking for additional detail in the PR comments, but for additional detail in the source code comments, so that things are easier for me to understand when I come back to this code in 6 months.

[felixpalmer]

The reason we have the triangulation in the carto module is so that we can perform it in our worker. As I commented on the deck.gl repo, SolidPolygonLayer should support triangulation with binary data automatically.

My experience is that triangulation can be a very costly operation, so if it can be performed in the worker thread in loaders.gl that will likely give the best performance. Once you put it into deck, it is being done on the main thread and will lead to jank