Developed to power Conveyal's web-based interface for scenario planning and land-use/transport accessibility analysis, R5 is our routing engine for multimodal (transit/bike/walk/car) networks with a particular focus on public transit
R5 did not properly handle the edge case where WGS84 extents fall exactly on a web Mercator pixel boundary, or slightly outside it due to floating point math. This is being addressed in https://github.com/conveyal/r5/pull/892
In discussion of this problem we found the ideal solution to be specifying Mercator extents using integers on the HTTP API (instead of using floating point WGS84). However, our existing way of sending origin/destination extents has weird inconsistent behavior that we don't want to replicate for both WGS84 and Mercator. The extents parameters also behave differently for single point and regional analyses, and freeform or gridded point sets. We don't want to replicate or perpetuate this behavior.
We also don't want to bake more Mercator-specific details into the API, because increasing use of GL-accelerated maps means Conveyal may eventually deprecate web Mercator.
My suggestion is that we work toward eventually having IDs for each pointset created by the user, whether they're freeform, Mercator, or grids in some other coordinate system, and pass those IDs in as the origin and destination points in the API, having separate fields for origins and destinations.
This does mean the workers need access to some additional information via API or direct database access (if grid characteristics are stored in a database). Currently workers never contact the database so this change requires careful consideration.
Alternatively, we could have a shared type for origin and destination points fields, which allows specifying web Mercator extents or freeform points by ID in separate properties. But I feel like web Mercator is on the way out. Related to #735.
R5 did not properly handle the edge case where WGS84 extents fall exactly on a web Mercator pixel boundary, or slightly outside it due to floating point math. This is being addressed in https://github.com/conveyal/r5/pull/892
In discussion of this problem we found the ideal solution to be specifying Mercator extents using integers on the HTTP API (instead of using floating point WGS84). However, our existing way of sending origin/destination extents has weird inconsistent behavior that we don't want to replicate for both WGS84 and Mercator. The extents parameters also behave differently for single point and regional analyses, and freeform or gridded point sets. We don't want to replicate or perpetuate this behavior.
We also don't want to bake more Mercator-specific details into the API, because increasing use of GL-accelerated maps means Conveyal may eventually deprecate web Mercator.
My suggestion is that we work toward eventually having IDs for each pointset created by the user, whether they're freeform, Mercator, or grids in some other coordinate system, and pass those IDs in as the origin and destination points in the API, having separate fields for origins and destinations.
This does mean the workers need access to some additional information via API or direct database access (if grid characteristics are stored in a database). Currently workers never contact the database so this change requires careful consideration.
Alternatively, we could have a shared type for origin and destination points fields, which allows specifying web Mercator extents or freeform points by ID in separate properties. But I feel like web Mercator is on the way out. Related to #735.