GeoTools
  1. GeoTools
  2. GEOT-3472

Add a higher precision alternative to getGeodeticCurve

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 11-beta
    • Component/s: referencing
    • Labels:
      None
    • Testcase included:
      yes

      Description

      GeodeticCalculator.getGeodeticCurve returns a Shape. A List of Point2Ds would be much more convenient and also give double, rather than float, precision.

      The attached patch deprecates getGeodeticCurve and adds a new method:
      List<Point2D> getPath(int numPoints)

      The patch also adds a private helper method computePoint to avoid the confusing dual use of computeDestinationPoint in the original code.

      Unit tests are included but they could be better.

        Activity

        Hide
        Andrea Aime added a comment -
        Err... geodetic is not the only possible path. getGeodeticPath() maybe?
        Show
        Andrea Aime added a comment - Err... geodetic is not the only possible path. getGeodeticPath() maybe?
        Hide
        Michael Bedward added a comment - - edited
        No, but it's the only kind of path that GeodeticCalculator returns and having "geodetic" in the class and method name seemed a bit much. But I don't really care :-) Your call.
        Show
        Michael Bedward added a comment - - edited No, but it's the only kind of path that GeodeticCalculator returns and having "geodetic" in the class and method name seemed a bit much. But I don't really care :-) Your call.
        Hide
        Andrea Aime added a comment -
        Well, yes and no, there is also the loxodrome method, but as the comment say it's not working
        Show
        Andrea Aime added a comment - Well, yes and no, there is also the loxodrome method, but as the comment say it's not working
        Hide
        Andrea Aime added a comment -
        I also noticed a number of variables have been renamed.
        Now, I agree the new names look better, but having a 1-1 resemblance with the original code is also a feature, if we ever find a problem we can quickly and easily compare with the source of the algorithm... so I would keep them as they are.
        Show
        Andrea Aime added a comment - I also noticed a number of variables have been renamed. Now, I agree the new names look better, but having a 1-1 resemblance with the original code is also a feature, if we ever find a problem we can quickly and easily compare with the source of the algorithm... so I would keep them as they are.
        Hide
        Michael Bedward added a comment -
        I'm going to attempt to change your mind :)

        No fields were renamed, only local variables whose names clashed with field names. Having class and method vars with matching names makes for error prone code. Martin favoured matching names in the code to those used in the published references but I think its confusing.
        Show
        Michael Bedward added a comment - I'm going to attempt to change your mind :) No fields were renamed, only local variables whose names clashed with field names. Having class and method vars with matching names makes for error prone code. Martin favoured matching names in the code to those used in the published references but I think its confusing.
        Hide
        Michael Bedward added a comment -
        Should we close this one as 'will not fix' ? I don't actually remember much about it :)
        Show
        Michael Bedward added a comment - Should we close this one as 'will not fix' ? I don't actually remember much about it :)
        Hide
        Andrea Aime added a comment -
        Committed a "compromise" version of the patch (the new method is an addition, not a replacement, the var names are kept to keep it easy to compare with the original fortran version)
        Show
        Andrea Aime added a comment - Committed a "compromise" version of the patch (the new method is an addition, not a replacement, the var names are kept to keep it easy to compare with the original fortran version)

          People

          • Assignee:
            Andrea Aime
            Reporter:
            Michael Bedward
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: