Detail Bug Report
https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_2071fe25-4731-4a2d-b250-461641b507ef
Summary
- Context: The
DirectionsEndpoint class represents an origin or destination for directions, supporting both free-form addresses and coordinate pairs.
- Bug: The
formatCoordinatePair method uses Double.toString() to format latitude and longitude, which results in scientific notation for values close to zero (between -0.001 and 0.001).
- Actual vs. expected: For a coordinate such as
0.0001, Double.toString() returns "1.0E-4", but the Apple Maps Server API expects a standard decimal representation like "0.0001".
- Impact: Directions requests involving locations near the equator or the prime meridian will likely fail as the API will fail to parse the scientific notation as a valid coordinate component.
Code with Bug
private static String formatCoordinatePair(double latitude, double longitude) {
return Double.toString(latitude) + COORDINATE_SEPARATOR + Double.toString(longitude); // <-- BUG 🔴 uses Double.toString(), can emit scientific notation
}
Explanation
Double.toString() switches to scientific notation for very small magnitudes (e.g., 0.0001 -> 1.0E-4). When DirectionsEndpoint.toQueryString() is used to build Apple Maps Server API query parameters, these scientific-notation components are not accepted as valid latitude/longitude, causing requests near longitude/latitude 0 to fail.
Failing Test
package com.williamcallahan.applemaps.domain.model;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
class DirectionsEndpointTest {
@Test
void formatCoordinatePairWithSmallValue() {
// A coordinate within ~111 meters of the prime meridian
DirectionsEndpoint endpoint = DirectionsEndpoint.fromLatitudeLongitude(37.3349, 0.0001);
// Actual: "37.3349,1.0E-4"
// Expected: "37.3349,0.0001"
assertEquals("37.3349,0.0001", endpoint.toQueryString());
}
}
Test output:
org.opentest4j.AssertionFailedError: expected: <37.3349,0.0001> but was: <37.3349,1.0E-4>
Recommended Fix
Use BigDecimal.valueOf(value).toPlainString() (or equivalent locale-independent decimal formatting) when formatting coordinates.
private static String formatCoordinatePair(double latitude, double longitude) {
return java.math.BigDecimal.valueOf(latitude).toPlainString() + COORDINATE_SEPARATOR + java.math.BigDecimal.valueOf(longitude).toPlainString(); // <-- FIX 🟢
}
History
This bug was introduced in commit 33eca2a. The commit added strongly-typed domain model records, but incorrectly used Double.toString() for formatting geographic coordinates, which produces scientific notation for values near zero.
Detail Bug Report
https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_2071fe25-4731-4a2d-b250-461641b507ef
Summary
DirectionsEndpointclass represents an origin or destination for directions, supporting both free-form addresses and coordinate pairs.formatCoordinatePairmethod usesDouble.toString()to format latitude and longitude, which results in scientific notation for values close to zero (between -0.001 and 0.001).0.0001,Double.toString()returns"1.0E-4", but the Apple Maps Server API expects a standard decimal representation like"0.0001".Code with Bug
Explanation
Double.toString()switches to scientific notation for very small magnitudes (e.g.,0.0001->1.0E-4). WhenDirectionsEndpoint.toQueryString()is used to build Apple Maps Server API query parameters, these scientific-notation components are not accepted as valid latitude/longitude, causing requests near longitude/latitude 0 to fail.Failing Test
Test output:
org.opentest4j.AssertionFailedError: expected: <37.3349,0.0001> but was: <37.3349,1.0E-4>Recommended Fix
Use
BigDecimal.valueOf(value).toPlainString()(or equivalent locale-independent decimal formatting) when formatting coordinates.History
This bug was introduced in commit 33eca2a. The commit added strongly-typed domain model records, but incorrectly used
Double.toString()for formatting geographic coordinates, which produces scientific notation for values near zero.