cellToVertex result seems to be incorrect?

[hello-willy]

i want to get a cell's vertexes, so i use the cellToVertex, but the result seems to be incorrect, is my fault?

the h3index is: 604390566939066367, res 6

uint64_t idx = 604390566939066367;
for (int k = 0; k < 6; k++)
{
        uint64_t vertex;
        if (cellToVertex(idx, k, &vertex) != E_SUCCESS)
        {
            flag = false;
            break;
        }
        if (!isValidVertex(vertex))
        {
            flag = false;
            break;
        }
        LatLng ll;
        if (vertexToLatLng(vertex, &ll) != E_SUCCESS)
        {
            flag = false;
            break;
        }
        OGRPoint p(radsToDegs(ll.lng), radsToDegs(ll.lat));
        extring.addPoint(&p);
}

the result is : p1 = {x=-179.98333732185461 y=31.292185279948786 z=0.0000000000000000 ...} p2 = {x=-179.96420468386472 y=31.324612541714405 z=0.0000000000000000 ...} p3 = {x=-179.98702792671048 y=31.354831946241418 z=0.0000000000000000 ...} p4 = {x=179.97099726090215 y=31.352613250610126 z=0.0000000000000000 ...} p5 = {x=179.95187736175254 y=31.320170609546317 z=0.0000000000000000 ...} p6 = {x=179.97471951336996 y=31.289962044707188 z=0.0000000000000000 ...}

why the x(longitude) is 179 or -179? is it correct?

help me plz, thank you!

[dfellis]

No, that seems right, plugging that index (after converting to hexadecimal) into @nrabinowitz 's Index inspector shows that the hexagon is right on the boundary in the pacific ocean where the coordinate system wraps from -180 to 180 degrees.

(It's that tiny red dot; I had to zoom out quite a bit to get any land to even show up.)

If you don't want to deal boundary crossing ranges like that in your work, you can move the boundary by adding 360 to any negative longitude so it goes from 0 to 360 and the wrap-around point is in ol' Londontown. ;) (But you can't completely avoid the wraparound of the coordinate system on the globe, it's going to happen somewhere.)

[hello-willy]

YES！ in the inspector, it seems correct.

it means the point list is correct, could you help me how to create the bbox correctly?

[dfellis]

So adding 360 to all of the negative numbers will move the wrap-around point such that you get contiguous numbers and an easy-to-calculate bbox (-179.something becomes 180.something when you add 360 to it).

Some systems support -180 to 360 as the input specifically to make this kind of thing easier (probably by doing something like (input + 360) % 360, but I digress) and you can test if doing this only for hexagons that have this problem (easily calculable by max(lng) - min(lng) > 180 as no hexagon in H3 comes anywhere close to 180 degrees in size) and then "patch" the coordinates for just those hexagons and compute a bbox on that. If the system you're putting the bboxes into has the same corrective mechanism, it should work.