Giters

adl1995 / geolib

Geographical distance computation algorithms.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Review 1

vissarion opened this issue · comments

commented

Hi, thanks for sharing this! I have some comments. The more you address the more competitive your application will be.

Regarding the code, first, the requirements state that it should fit in one header file. Moreover, that it should be as generic as possible. There is a lot of space for improvement here. Tip: use templates and look at Boost.Geometry source code.

Regarding algorithms: interesting formulas but none of them is very accurate Cf. Vincenty formula.

Regarding tests: could you test against Boost.Geometry algorithms for distance? Also make them more generic (there is a lot of repentance). You could also have cases of tests for short, medium and long distances. If you like you can use this dataset for extensive tests: https://zenodo.org/record/32156#.WOyaMrUmv7C

commented

Listed below are the tasks based on this issue:

  • Reorganize code to fit in a single header file
  • Use C++ templates to allow for different data types e.g. user should be able to provide input in DMS, DMM, DD
  • Implement the more accurate Vincenty's formula
  • Test the implementation against Boost Geometry algorithms
  • Add a variety of test data
  • Generalize repeated code from tests
commented

I'm not sure how much I should help but I'll give you some general pointers.

Because Boost.Geometry is header-only library your code should also be organized like that (as Vissarion pointed out).

You could ask yourself a few questions. What should your library allow the user to express in the code? What should be defined at compile-time and what at run-time, etc. Should your library require to use a specific point representation like GeoPoint or should it allow the user to use his own point type. What should be the interface of distance calculation? Should it be a free function calculating the distance or class representation of a distance or distance calculated in a member function of GeoPoint? Each way will make some things simpler and other things harder. What if we also had other types of geometries besides points, e.g. polygons? Would the interface be the same in this case or different?

The templates should not be there for the sake of using templates. They should be a result of a design decision.

Unfortunately you don't have much freedom here because you want to contribute to an existing library which already has some interface and internal structure. So it would be the best if your code was similar to the code of Boost.Geometry or at least if it was possible to do a subset of things that are allowed with Boost.Geometry, e.g. to use arbitrary user-defined point type with your algorithms. See how Point Concept is defined in Boost.Geometry and how algorithms are implemented they way they are and why here: (www.boost.org/libs/geometry/doc/html/geometry/design.html)