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

H3 4.0.0 Part 1: Renaming otherwise unchanged functions #403

Merged
merged 48 commits into from
Apr 7, 2021

Conversation

dfellis
Copy link
Collaborator

@dfellis dfellis commented Oct 8, 2020

@coveralls
Copy link

coveralls commented Oct 8, 2020

Coverage Status

Coverage increased (+0.1%) to 99.438% when pulling 1f6a7e4 on dfellis:master into a4fda8e on uber:master.

@dfellis dfellis force-pushed the master branch 2 times, most recently from 1b5f90c to fe192a1 Compare October 8, 2020 23:20
@ajfriend ajfriend self-requested a review October 8, 2020 23:46
@dfellis dfellis linked an issue Oct 9, 2020 that may be closed by this pull request
@dfellis
Copy link
Collaborator Author

dfellis commented Oct 9, 2020

I believe this is ready for review!

@dfellis dfellis changed the title WIP H3 4.0.0 Part 1: Renaming otherwise unchanged functions H3 4.0.0 Part 1: Renaming otherwise unchanged functions Oct 9, 2020
@dfellis
Copy link
Collaborator Author

dfellis commented Oct 9, 2020

@sahrk I can't formally assign you as a reviewer, but in case you are interested, we're finally getting started on cleaning up the naming convention for a v4 release.

Copy link
Collaborator

@nrabinowitz nrabinowitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof! A few comments, but overall this looks great - thanks for taking this on!

CMakeLists.txt Show resolved Hide resolved
@@ -35,7 +35,7 @@ int main(int argc, char* argv[]) {
printf("Starting with %d indexes.\n", inputSize);

H3Index* compacted = calloc(inputSize, sizeof(H3Index));
int err = compact(input, compacted, inputSize);
int err = compactCells(input, compacted, inputSize);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had forgotten all about the example files - do these not need H3_EXPORT wrapping?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They use H3 as a library, so H3_EXPORT is not available, and the test compiles it with an empty prefix so this works (or the test suite would be complaining ;) )

src/apps/applib/lib/utility.c Outdated Show resolved Hide resolved
src/apps/applib/lib/utility.c Outdated Show resolved Hide resolved
@@ -17,7 +17,7 @@
* @brief stdin/stdout filter that converts from lat/lon coordinates to integer
* H3 indexes
*
* See `geoToH3 --help` for usage.
* See `pointToCell --help` for usage.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth noting that the CLI utils is one place where the more generic names aren't helpful - if I have a util in my path called geoToH3 I know what it relates to, but pointToCell is much more ambiguous. I wonder if we want an h3 prefix on the filter applications.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should definitely get that decided before we land this.

I would really like to know if anyone actually uses these utility programs, though.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed in the steering committee. @isaacbrodsky suggests consolidating these in a single filter command like h3 pointToCell <...args>. This would be a separate PR, obviously, so what you have here seems sufficient for now.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dfellis I use these :). I can't be the only one that uses pipes in the unix shell to transform data.

I concur with @nrabinowitz that the "CLI utils is one place where the more generic names aren't helpful". Within H3 itself the decision was made to make lat/lon equivalent to point, etc. But the command line user is outside H3 trying to transform between specific location representations, and using the abstract terms obscures that.

src/h3lib/lib/h3Index.c Outdated Show resolved Hide resolved
src/h3lib/lib/h3Index.c Outdated Show resolved Hide resolved
src/h3lib/lib/h3Index.c Outdated Show resolved Hide resolved
src/h3lib/lib/h3Index.c Outdated Show resolved Hide resolved
src/h3lib/lib/vertex.c Outdated Show resolved Hide resolved
Comment on lines +316 to 338
/** @brief exact length for a specific directed edge in radians*/
double H3_EXPORT(exactEdgeLengthRads)(H3Index edge);

/** @brief exact length for a specific unidirectional edge in kilometers*/
/** @brief exact length for a specific directed edge in kilometers*/
double H3_EXPORT(exactEdgeLengthKm)(H3Index edge);

/** @brief exact length for a specific unidirectional edge in meters*/
/** @brief exact length for a specific directed edge in meters*/
double H3_EXPORT(exactEdgeLengthM)(H3Index edge);
/** @} */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should just be edgeLengthRads, edgeLengthKm, and edgeLengthM, since we can drop the exact because we no longer have a naming conflict with getEdgeLengthAvg.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dfellis bump :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, never mind. I see that these aren't in the RFC. I'll make an issue for a follow-up PR to change these.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

@isaacbrodsky isaacbrodsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I apologize for the delay in reviewing this PR. Thanks for pushing this part of the 4.0 effort forward.

I was able to complete reading through it and I think it makes sense to me. I see Nick and AJ have already commented on a few things, and I agree especially with the gridDiskDistancesUnsafe comment (or the one where the arguments were more complicated than needed), etc.

Comment on lines +145 to +162
src/apps/filters/cellToPoint.c
src/apps/filters/h3ToLocalIj.c
src/apps/filters/localIjToH3.c
src/apps/filters/h3ToComponents.c
src/apps/filters/geoToH3.c
src/apps/filters/h3ToGeoBoundary.c
src/apps/filters/kRing.c
src/apps/filters/hexRange.c
src/apps/filters/pointToCell.c
src/apps/filters/cellToBoundary.c
src/apps/filters/gridDisk.c
src/apps/filters/gridDiskUnsafe.c
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest leaving the names of the filters as-is and they can be refactored in a subsequent PR. I don't think this needs to be removed from this PR though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@isaacbrodsky Could you make a follow-up issue? Or is this covered by #415?

CMakeLists.txt Show resolved Hide resolved
src/h3lib/include/h3api.h.in Outdated Show resolved Hide resolved
src/h3lib/lib/faceijk.c Outdated Show resolved Hide resolved
* Class III resolution (rotated versus the icosahedron and subject
* to shape distortion adding extra points on icosahedron edges, making
* them not true hexagons).
* @param h The H3Index to check.
* @return Returns 1 if the hexagon is class III, otherwise 0.
*/
int H3_EXPORT(h3IsResClassIII)(H3Index h) { return H3_GET_RESOLUTION(h) % 2; }
int H3_EXPORT(isResClassIII)(H3Index h) { return H3_GET_RESOLUTION(h) % 2; }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this should accept a resolution rather than an index.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is letting people know if the hexagon is a class III hexagon. I would prefer it to just be isClassIII and return isResDigitClassIII to this name, but that isn't what we agreed upon in the RFC and I think the relitigation of these decisions all the time is why 4.0 is taking so long to get out the door. :/

Copy link
Collaborator

@isaacbrodsky isaacbrodsky Nov 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposed function name is probably fine to keep. My comment here should not block this PR, more of an off the cuff impression.

Copy link
Contributor

@ajfriend ajfriend Apr 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to revisit in a follow-up. I could debate names all day 😛 .

I think these changes have taken so long just due to the scale and the coupling between name changes. After this PR lands, I think @dfellis has done most of the hard work. I'd expect follow-up adjustments like this to be smaller-scale and less-coupled, so we should be able to resolve them fairly quickly. 🙏

#443

@sahrk
Copy link

sahrk commented Nov 20, 2020

@sahrk I can't formally assign you as a reviewer, but in case you are interested, we're finally getting started on cleaning up the naming convention for a v4 release.

Thanks for the heads up @dfellis, and sorry for being late to the party. I am looking at it now and will make any comments this evening. Overall it looks great; I'm especially happy to have a standard naming for "ring" and "disk" that can be adopted outside of H3 going forward.

@sahrk
Copy link

sahrk commented Nov 20, 2020

Within the function names Point is now synonymous with lat/lon. It feels a little redundant to me to then use GeoPoint for the lat/lon data type. Maybe it should just be Point?

@ajfriend
Copy link
Contributor

ajfriend commented Apr 3, 2021

Within the function names Point is now synonymous with lat/lon. It feels a little redundant to me to then use GeoPoint for the lat/lon data type. Maybe it should just be Point?

Good point. Fair. Let's consider in follow-up? #415

Copy link
Contributor

@ajfriend ajfriend left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thanks for doing all the hard work @dfellis!

I've tried to move any outstanding discussions to issues/PRs that we can follow up on, so that we can finally land this thing! 🎉

@dfellis dfellis merged commit b744bed into uber:master Apr 7, 2021
@ajfriend ajfriend mentioned this pull request May 30, 2021
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

Successfully merging this pull request may close these issues.

Change all existing function names per naming RFC
6 participants