Improve distance computation and add distance tool - #183
Merged
Merged
Conversation
LionelZoubritzky-IGN
changed the title
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
2 times, most recently
from
July 29, 2026 16:50
a0ce3c6 to
95059e1
Compare
This comment was marked as outdated.
This comment was marked as outdated.
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
2 times, most recently
from
August 3, 2026 11:29
5fc4332 to
9e064c5
Compare
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
from
August 17, 2026 13:49
9e064c5 to
cfb544f
Compare
LionelZoubritzky-IGN
changed the base branch from
main
to
142-gpfschemastore0.2.0
August 17, 2026 13:50
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
4 times, most recently
from
August 19, 2026 14:48
11b7333 to
e9d9b0b
Compare
LionelZoubritzky-IGN
marked this pull request as ready for review
August 19, 2026 15:28
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
from
September 21, 2026 12:14
e9d9b0b to
0eae93b
Compare
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
from
September 21, 2026 12:31
0eae93b to
e3d0b0a
Compare
LionelZoubritzky-IGN
force-pushed
the
138/distance-tool
branch
from
October 1, 2026 14:30
e3d0b0a to
98d8ff4
Compare
esgn
force-pushed
the
138/distance-tool
branch
from
October 1, 2026 14:57
98d8ff4 to
c12fc3d
Compare
4 tasks done
node-vincenty (0.0.6, unmaintained, untyped) returns an undefined distance for antipodal or nearly antipodal points, which the wrapper let through. Karney's algorithm always converges; over 40,000 random pairs it differs from Vincenty by at most 0.56 mm. The hand-written node-vincenty types and their tsconfig.test.json entry go away.
The distance tool profiles `direct` and `vincenty` become `spherical` (still the default) and `ellipsoidal`, and the helper's `distanceVincenty` and its `"haversine"`/`"vincenty"` metrics become `ellipsoidalDistance` and `"spherical"`/`"ellipsoidal"`: since the switch to geographiclib, nothing runs Vincenty's formula anymore.
…ween two geographic positions
jsts indexes facets in chunks of 6 segments, so a line of 6k+1 vertices ends with a single-vertex chunk whose location carries the last vertex index. getSegment then read a vertex past the end and threw a TypeError, which failed urbanisme and assiette_sup calls whose nearest object is a line reached at its end, and silently nulled distance_to_filter_center. Clamp the index to the last segment.
The result is rounded to the centimeter, so 0.5 cm, not 1 mm. Drop "coûteuse", the cost being a few microseconds, and the default already published by the schema.
Wall-clock assertions failed whenever other test files ran in parallel. The four timed tests move to *.perf.test.ts files, which test:perf (vitest.perf.config.mts) runs one file at a time and verify:fast chains after test:unit. The 500-vertex distance test now times the median of warm runs, under 15 ms.
esgn
approved these changes
Oct 2, 2026
esgn
added a commit
that referenced
this pull request
Oct 2, 2026
The rebase brought back "plus précise et coûteuse, précision à 1mm" instead of the 0.5 cm wording merged in #183, and the new ", " join produced "suivi :, `spherical`". Join the profile lines as before.
LionelZoubritzky-IGN
pushed a commit
that referenced
this pull request
Oct 2, 2026
* fix(itinerary): route with Valhalla, like the travel time isochrones The distance tool used bdtopo-osrm while travel_time_filter isochrones use bdtopo-valhalla, so the two could disagree by up to 12% on walking times. Reuse TRAVEL_TIME_RESOURCE for the itinerary. * fix(distance): restore the ellipsoidal precision lost in the rebase The rebase brought back "plus précise et coûteuse, précision à 1mm" instead of the 0.5 cm wording merged in #183, and the new ", " join produced "suivi :, `spherical`". Join the profile lines as before. * fix(distance): keep a tenth of a minute in the travel time Rounding to the whole minute turned a 40-second walk into 1 or even 0 minutes. * docs(distance): say which profiles return a travel time `profile` always has a value (`spherical` by default), so "lorsqu'un profil est renseigné" was always true. * fix(distance): round the itinerary distance to the centimeter The spherical and ellipsoidal profiles already round to the centimeter; the itinerary passed the service value through as is.
esgn
added a commit
that referenced
this pull request
Oct 2, 2026
…l` (#207) * feat: Implement itinerary services * feat: plug itinerary into distance tool * 138/review and fix (#208) * fix(itinerary): route with Valhalla, like the travel time isochrones The distance tool used bdtopo-osrm while travel_time_filter isochrones use bdtopo-valhalla, so the two could disagree by up to 12% on walking times. Reuse TRAVEL_TIME_RESOURCE for the itinerary. * fix(distance): restore the ellipsoidal precision lost in the rebase The rebase brought back "plus précise et coûteuse, précision à 1mm" instead of the 0.5 cm wording merged in #183, and the new ", " join produced "suivi :, `spherical`". Join the profile lines as before. * fix(distance): keep a tenth of a minute in the travel time Rounding to the whole minute turned a 40-second walk into 1 or even 0 minutes. * docs(distance): say which profiles return a travel time `profile` always has a value (`spherical` by default), so "lorsqu'un profil est renseigné" was always true. * fix(distance): round the itinerary distance to the centimeter The spherical and ellipsoidal profiles already round to the centimeter; the itinerary passed the service value through as is. --------- Co-authored-by: Emmanuel S. <5435148+esgn@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds a
distancetool that returns the distance in meters between two lon/lat points. Also rewrites the geometry-to-geometrydistancehelper behindurbanisme,assiette_sup,parcellaire-expressand the WFSdistance_to_filter_center.Related issues (if applicable)
Closes #138, supersedes #156
Motivation
The old helper picked the nearest pair of points in a plain lon/lat plane, then measured the haversine distance between them. Away from the equator a degree of longitude is shorter than a degree of latitude, so it could pick the wrong pair, and the distance was only approximate.
Implementation
src/helpers/distance.tsworks in three steps:Facets are indexed in a tree, so the cost grows roughly linearly with the number of vertices. The helper now returns
{ distance, point1, point2 }, and callers are updated. Geometries that cross the antimeridian are rejected (RFC 7946 says to split them).There are two point metrics:
spherical(haversine, the default) andellipsoidal(WGS84 geodesic, throughgeographiclib-geodesic).DistanceToolexposes both metrics asprofileand rounds the result to the centimeter.Timed tests move to
*.perf.test.tsand run one file at a time withnpm run test:perf, whichverify:fastnow chains.Checklist