option to change order of input geojson to (lng, lat) about h3 HOT 3 CLOSED

You're specifically referring to polyfill, right? To date, we've delegated this concern to the bindings (JS, Java, etc), which need to marshal data into the GeoPolygon format anyway, and which generally offer both GeoJSON and non-GeoJSON input and output options. We could potentially offer polyfillGeoJSON, but this would simply be doing the same straightforward operation you'd need to do now, copying all of the data into a new structure with reversed geo coords. As this would only apply to C consumers, and as we probably couldn't do it as efficiently as the calling application could (for example, because we don't know whether modifying the polygon in-place is acceptable), I don't see a lot of benefit to adding this wrapper.

from h3.

Thanks. Will add it in the python binding and open a pull request. Curious to know why the library uses (lat,lng) by default?

from h3.

Some of the core is based on DGGRID, which predated GeoJSON by several years and used lat, lon. I used lat, lon in DGGRID because such coordinates are always referred to as "latitude and longitude", not "longitude and latitude".

from h3.