Open-Harbor/osrm-backend
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity
2da7ca5338
osrm-backend/include/engine/datafacade/datafacade_base.hpp

192 lines
7.7 KiB
C++
Raw Normal View History

renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
#ifndef DATAFACADE_BASE_HPP
#define DATAFACADE_BASE_HPP
// Exposes all data access interfaces to the algorithms via base class ptr
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
#include "engine/approach.hpp"
#include "engine/phantom_node.hpp"
Add viaroute suport for new API
2016-01-28 10:28:44 -05:00
#include "contractor/query_edge.hpp"
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
#include "extractor/class_data.hpp"
Renamed EdgeBasedNode to EdgeBasedNodeSegment
2017-05-16 13:22:41 -04:00
#include "extractor/edge_based_node_segment.hpp"
Support maneuver relations (#4676)
2018-02-09 13:32:09 -05:00
#include "extractor/maneuver_override.hpp"
Don't use bool flags on ExternalMemoryNode because they blow up the struct
2017-07-06 20:16:40 -04:00
#include "extractor/query_node.hpp"
Use ranges with fixed types
2018-04-06 09:09:52 -04:00
#include "extractor/segment_data_container.hpp"
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
#include "extractor/travel_mode.hpp"
Split intersection analysis and guidance code Intersection analysis occupy in osrm::extractor::intersection namespace and guidance code osrm::guidance
2018-01-05 08:33:53 -05:00
#include "extractor/turn_lane_types.hpp"
Move guidance turn generation out of EBGF
2018-01-08 13:12:06 -05:00
#include "guidance/turn_bearing.hpp"
Move guidance pre-processing code into GUIDANCE library
2018-01-05 07:05:53 -05:00
#include "guidance/turn_instruction.hpp"
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
Transforms osrm_exception to exception
2016-01-28 08:27:05 -05:00
#include "util/exception.hpp"
initial version of intersection classification
2016-04-26 07:27:40 -04:00
#include "util/guidance/bearing_class.hpp"
#include "util/guidance/entry_class.hpp"
Turn Angles in OSRM were computed using a lookahead of 10 meters. This PR adds more advanced coordinate extraction, analysing the road to detect offsets due to OSM way modelling. In addition it improves the handling of bearings. Right now OSM reports bearings simply based on the very first coordinate along a way. With this PR, we store the bearings for a turn correctly, making the bearings for turns correct.
2016-08-17 03:49:19 -04:00
#include "util/guidance/turn_lanes.hpp"
initial version of intersection classification
2016-04-26 07:27:40 -04:00
#include "util/integer_range.hpp"
Use ranges with fixed types
2018-04-06 09:09:52 -04:00
#include "util/packed_vector.hpp"
Fix include paths
2016-01-02 11:13:44 -05:00
#include "util/string_util.hpp"
#include "util/typedefs.hpp"
#include "osrm/coordinate.hpp"
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Use ranges with fixed types
2018-04-06 09:09:52 -04:00
#include <boost/range/adaptor/reversed.hpp>
Use ranges in datafacade instead of vectors Range type must use immutable references due to a regression in `boost::any_range`. References: https://svn.boost.org/trac10/ticket/10493 https://stackoverflow.com/questions/42427395/boostany-range-with-optimization-level-o2-causes-crash/42427662
2018-03-19 14:41:02 -04:00
#include <boost/range/any_range.hpp>
Fixes datafacade includes
2016-02-05 08:58:06 -05:00
#include <cstddef>
Support snapping to multiple ways at an input location (#5953) This PR improves routing results by adding support for snapping to multiple ways at input locations. This means all edges at the snapped location can act as source/target candidates for routing search, ensuring we always find the best route, and not the one dependent on the edge selected.
2022-08-27 06:36:20 -04:00
#include <engine/bearing.hpp>
Get rid of boost::optional leftovers (#6977)
2024-07-02 16:37:09 -04:00
#include <optional>
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
#include <string>
Remove util/string_view header
2022-10-30 15:01:46 -04:00
#include <string_view>
initial version of intersection classification
2016-04-26 07:27:40 -04:00
#include <utility>
#include <vector>
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Use nested namespace It's a mechanical change to modernize the code base
2022-12-11 04:10:26 -05:00
namespace osrm::engine::datafacade
Add namespace around all files
2016-01-05 10:51:13 -05:00
{
Add viaroute suport for new API
2016-01-28 10:28:44 -05:00
class BaseDataFacade
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
{
public:
Renamed EdgeBasedNode to EdgeBasedNodeSegment
2017-05-16 13:22:41 -04:00
using RTreeLeaf = extractor::EdgeBasedNodeSegment;
Use ranges in datafacade instead of vectors Range type must use immutable references due to a regression in `boost::any_range`. References: https://svn.boost.org/trac10/ticket/10493 https://stackoverflow.com/questions/42427395/boostany-range-with-optimization-level-o2-causes-crash/42427662
2018-03-19 14:41:02 -04:00
Use ranges with fixed types
2018-04-06 09:09:52 -04:00
using NodeForwardRange =
boost::iterator_range<extractor::SegmentDataView::SegmentNodeVector::const_iterator>;
using NodeReverseRange = boost::reversed_range<const NodeForwardRange>;
using WeightForwardRange =
boost::iterator_range<extractor::SegmentDataView::SegmentWeightVector::const_iterator>;
using WeightReverseRange = boost::reversed_range<const WeightForwardRange>;
using DurationForwardRange =
boost::iterator_range<extractor::SegmentDataView::SegmentDurationVector::const_iterator>;
using DurationReverseRange = boost::reversed_range<const DurationForwardRange>;
using DatasourceForwardRange =
boost::iterator_range<extractor::SegmentDataView::SegmentDatasourceVector::const_iterator>;
using DatasourceReverseRange = boost::reversed_range<const DatasourceForwardRange>;
Use ranges in datafacade instead of vectors Range type must use immutable references due to a regression in `boost::any_range`. References: https://svn.boost.org/trac10/ticket/10493 https://stackoverflow.com/questions/42427395/boostany-range-with-optimization-level-o2-causes-crash/42427662
2018-03-19 14:41:02 -04:00
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
BaseDataFacade() {}
virtual ~BaseDataFacade() {}
Fix errors when loading an incompatible dataset.
2018-03-28 19:18:09 -04:00
virtual std::uint32_t GetCheckSum() const = 0;
Refactor edge unpacking so that it's CH indepenent and we don't repeat ourselves so much.
2016-08-23 02:26:48 -04:00
Store metadata about original OSM data, and return it in the API response, if available.
2019-01-15 05:18:20 -05:00
virtual std::string GetTimestamp() const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
// node and edge information access
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual util::Coordinate GetCoordinateOfNode(const NodeID node_based_node_id) const = 0;
Port OSRM, Engine and Datafacades to be algorithm aware
2017-01-09 15:40:33 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual OSMNodeID GetOSMNodeIDOfNode(const NodeID node_based_node_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual GeometryID GetGeometryIndex(const NodeID edge_based_node_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual ComponentID GetComponentID(const NodeID edge_based_node_id) const = 0;
Move ComponentID to EdgeBasedNodeDataContainer
2017-05-15 06:15:00 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual NodeForwardRange GetUncompressedForwardGeometry(const PackedGeometryID id) const = 0;
virtual NodeReverseRange GetUncompressedReverseGeometry(const PackedGeometryID id) const = 0;
Make forward/reverse weight/offset calculated at query time, rather than being cached in the StaticRTree. This means we can freely apply traffic data and not have stale values lying around. It reduces the size of the RTree on disk, at the expense of some additional data in RAM.
2016-01-29 20:52:20 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual TurnPenalty GetWeightPenaltyForEdgeID(const EdgeID edge_based_edge_id) const = 0;
Allow specifing a weight for routing that is independent of duration
2016-05-12 12:50:10 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual TurnPenalty GetDurationPenaltyForEdgeID(const EdgeID edge_based_edge_id) const = 0;
Allow specifing a weight for routing that is independent of duration
2016-05-12 12:50:10 -04:00
Make forward/reverse weight/offset calculated at query time, rather than being cached in the StaticRTree. This means we can freely apply traffic data and not have stale values lying around. It reduces the size of the RTree on disk, at the expense of some additional data in RAM.
2016-01-29 20:52:20 -05:00
// Gets the weight values for each segment in an uncompressed geometry.
// Should always be 1 shorter than GetUncompressedGeometry
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual WeightForwardRange GetUncompressedForwardWeights(const PackedGeometryID id) const = 0;
virtual WeightReverseRange GetUncompressedReverseWeights(const PackedGeometryID id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Allow specifing a weight for routing that is independent of duration
2016-05-12 12:50:10 -04:00
// Gets the duration values for each segment in an uncompressed geometry.
// Should always be 1 shorter than GetUncompressedGeometry
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual DurationForwardRange
GetUncompressedForwardDurations(const PackedGeometryID id) const = 0;
virtual DurationReverseRange
GetUncompressedReverseDurations(const PackedGeometryID id) const = 0;
Allow specifing a weight for routing that is independent of duration
2016-05-12 12:50:10 -04:00
Enables the use of multiple segment-speed-files on the osrm-contract command line, and exposes the file name used for each edge in the debug tiles.
2016-03-15 02:03:19 -04:00
// Returns the data source ids that were used to supply the edge
// weights. Will return an empty array when only the base profile is used.
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual DatasourceForwardRange
GetUncompressedForwardDatasources(const PackedGeometryID id) const = 0;
virtual DatasourceReverseRange
GetUncompressedReverseDatasources(const PackedGeometryID id) const = 0;
Enables the use of multiple segment-speed-files on the osrm-contract command line, and exposes the file name used for each edge in the debug tiles.
2016-03-15 02:03:19 -04:00
// Gets the name of a datasource
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetDatasourceName(const DatasourceID id) const = 0;
Enables the use of multiple segment-speed-files on the osrm-contract command line, and exposes the file name used for each edge in the debug tiles.
2016-03-15 02:03:19 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual osrm::guidance::TurnInstruction
GetTurnInstructionForEdgeID(const EdgeID edge_based_edge_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual extractor::TravelMode GetTravelMode(const NodeID edge_based_node_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual extractor::ClassData GetClassData(const NodeID edge_based_node_id) const = 0;
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual bool ExcludeNode(const NodeID edge_based_node_id) const = 0;
Add datafacade factory to select avoid flags
2017-07-21 17:55:19 -04:00
Allow users to specify a class for each way This adds the ability to mark ways with a user-defined class in the profile. This class information will be included in the response as property of the RouteStep object.
2017-06-27 18:01:05 -04:00
virtual std::vector<std::string> GetClasses(const extractor::ClassData class_data) const = 0;
First round of lat,lng -> lng,lat switcheroo
2016-02-23 15:23:13 -05:00
virtual std::vector<RTreeLeaf> GetEdgesInBox(const util::Coordinate south_west,
Make StaticRTree and facades const
2016-05-06 20:56:08 -04:00
const util::Coordinate north_east) const = 0;
Implements a vector tileserver so you can see what's going on inside OSRM.
2016-02-16 13:51:04 -05:00
Incoperate PR comments
2015-12-09 16:34:22 -05:00
virtual std::vector<PhantomNodeWithDistance>
First round of lat,lng -> lng,lat switcheroo
2016-02-23 15:23:13 -05:00
NearestPhantomNodesInRange(const util::Coordinate input_coordinate,
Support snapping to multiple ways at an input location (#5953) This PR improves routing results by adding support for snapping to multiple ways at input locations. This means all edges at the snapped location can act as source/target candidates for routing search, ensuring we always find the best route, and not the one dependent on the edge selected.
2022-08-27 06:36:20 -04:00
const double max_distance,
Get rid of boost::optional leftovers (#6977)
2024-07-02 16:37:09 -04:00
const std::optional<Bearing> bearing,
When matching, ignore 'is_startpoint' propert, snap to any edge (#5297) Includes all edges in the rtree, but adds an `is_startpoint` flag to each. Most plugin behaviour remains unchanged (non-startpoint edges aren't used as snapping candidates), but for map matching, we allow snapping to any edge. This fixes map-matching across previously non-is_startpoint edges, like ferries, private service roads, and a few others.
2018-12-13 19:10:32 -05:00
const Approach approach,
const bool use_all_edges) const = 0;
Refactor StaticRTree to remove application dependent code StaticRTree now acts like a container, just returning the input data (NodeBasedEdge) and not PhantomNodes.
2015-12-03 14:04:23 -05:00
Incoperate PR comments
2015-12-09 16:34:22 -05:00
virtual std::vector<PhantomNodeWithDistance>
First round of lat,lng -> lng,lat switcheroo
2016-02-23 15:23:13 -05:00
NearestPhantomNodes(const util::Coordinate input_coordinate,
Support snapping to multiple ways at an input location (#5953) This PR improves routing results by adding support for snapping to multiple ways at input locations. This means all edges at the snapped location can act as source/target candidates for routing search, ensuring we always find the best route, and not the one dependent on the edge selected.
2022-08-27 06:36:20 -04:00
const size_t max_results,
Get rid of boost::optional leftovers (#6977)
2024-07-02 16:37:09 -04:00
const std::optional<double> max_distance,
const std::optional<Bearing> bearing,
Refactoring enum Approach in enum class. Suppress "engine::" Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
2017-05-29 10:13:15 -04:00
const Approach approach) const = 0;
First round of lat,lng -> lng,lat switcheroo
2016-02-23 15:23:13 -05:00
Support snapping to multiple ways at an input location (#5953) This PR improves routing results by adding support for snapping to multiple ways at input locations. This means all edges at the snapped location can act as source/target candidates for routing search, ensuring we always find the best route, and not the one dependent on the edge selected.
2022-08-27 06:36:20 -04:00
virtual PhantomCandidateAlternatives
NearestCandidatesWithAlternativeFromBigComponent(const util::Coordinate input_coordinate,
Get rid of boost::optional leftovers (#6977)
2024-07-02 16:37:09 -04:00
const std::optional<double> max_distance,
const std::optional<Bearing> bearing,
Support snapping to multiple ways at an input location (#5953) This PR improves routing results by adding support for snapping to multiple ways at input locations. This means all edges at the snapped location can act as source/target candidates for routing search, ensuring we always find the best route, and not the one dependent on the edge selected.
2022-08-27 06:36:20 -04:00
const Approach approach,
const bool use_all_edges) const = 0;
Add skeleton code for matching
2014-09-23 12:46:14 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual bool HasLaneData(const EdgeID edge_based_edge_id) const = 0;
virtual util::guidance::LaneTupleIdPair GetLaneData(const EdgeID edge_based_edge_id) const = 0;
Split intersection analysis and guidance code Intersection analysis occupy in osrm::extractor::intersection namespace and guidance code osrm::guidance
2018-01-05 08:33:53 -05:00
virtual extractor::TurnLaneDescription
expose lanes as enums, adjusted for comments
2016-06-21 04:41:08 -04:00
GetTurnDescription(const LaneDescriptionID lane_description_id) const = 0;
Implement Turn Lane Api
2016-06-15 08:38:24 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual NameID GetNameIndex(const NodeID edge_based_node_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetNameForID(const NameID id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetRefForID(const NameID id) const = 0;
return name and reference separately
2016-09-05 09:01:51 -04:00
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetPronunciationForID(const NameID id) const = 0;
Expose pronunciation in RouteStep Uses name:pronunciation by default for cars.
2016-05-25 21:35:38 -04:00
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetDestinationsForID(const NameID id) const = 0;
Add destinations API feature
2016-05-26 18:47:46 -04:00
Remove usage of StringView typedef
2022-10-30 14:52:57 -04:00
virtual std::string_view GetExitsForID(const NameID id) const = 0;
Implements Exit Numbers + Names (`junction:ref` way tag for now)
2017-06-29 16:12:25 -04:00
uturns -> continue_straight
2016-04-12 12:47:00 -04:00
virtual bool GetContinueStraightDefault() const = 0;
initial version of intersection classification
2016-04-26 07:27:40 -04:00
added max_speed to the profiles (#3089)
2016-11-01 17:13:10 -04:00
virtual double GetMapMatchingMaxSpeed() const = 0;
Allow specifing a weight for routing that is independent of duration
2016-05-12 12:50:10 -04:00
virtual const char *GetWeightName() const = 0;
virtual unsigned GetWeightPrecision() const = 0;
Added weight multipliers for speed and turn updates
2017-01-17 03:24:52 -05:00
virtual double GetWeightMultiplier() const = 0;
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual osrm::guidance::TurnBearing PreTurnBearing(const EdgeID edge_based_edge_id) const = 0;
virtual osrm::guidance::TurnBearing PostTurnBearing(const EdgeID edge_based_edge_id) const = 0;
Turn Angles in OSRM were computed using a lookahead of 10 meters. This PR adds more advanced coordinate extraction, analysing the road to detect offsets due to OSM way modelling. In addition it improves the handling of bearings. Right now OSM reports bearings simply based on the very first coordinate along a way. With this PR, we store the bearings for a turn correctly, making the bearings for turns correct.
2016-08-17 03:49:19 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual util::guidance::BearingClass GetBearingClass(const NodeID node_based_node_id) const = 0;
initial version of intersection classification
2016-04-26 07:27:40 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual util::guidance::EntryClass GetEntryClass(const EdgeID edge_based_edge_id) const = 0;
Adding support for left left hand driving. Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
2017-05-22 10:09:53 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual bool IsLeftHandDriving(const NodeID edge_based_node_id) const = 0;
Add code to draw segregated nodes in a tile layer
2017-10-13 09:20:46 -04:00
Clarify identifier types used in data facade The data facade interface contains numerous methods for looking up datapoints by identifiers. Many of the parameters use the NodeID or EdgeID types. However, these two identifier types are used for representing three different contexts: 1. Node-based graph edges and nodes 2. Edge-based graph edges and nodes 3. Packed geometries Consider the use of identifier parameters in these examples: --- GetWeightPenaltyForEdgeID(const EdgeID id) <- edge-based edge GetUncompressedForwardWeights(const EdgeID id) <- packed geometry IsLeftHandDriving(const NodeID id) <- edge-based node GetBearingClass(const NodeID node) <- node-based node --- This mixing of contexts within the same interface makes it difficult to understand the relationships and dependencies between the OSRM datasets. For 1. and 2. we continue to use the NodeID and EdgeID types, but change the interface parameter names to identify them as edge-based or node-based graph properties. For 3. we define a new type definition, PackedGeometryID. These changes are to aid with readability. A next step would be to strongly type these definitions, leveraging the Alias template already used for OSM identifiers.
2021-06-01 15:48:12 -04:00
virtual bool IsSegregated(const NodeID edge_based_node_id) const = 0;
Support maneuver relations (#4676)
2018-02-09 13:32:09 -05:00
virtual std::vector<extractor::ManeuverOverride>
GetOverridesThatStartAt(const NodeID edge_based_node_id) const = 0;
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
};
Fix formatting
2022-12-20 12:00:11 -05:00
} // namespace osrm::engine::datafacade
Add namespace around all files
2016-01-05 10:51:13 -05:00
renamed: Server/*/*.h -> server/*/*.hpp
2015-01-27 06:35:29 -05:00
#endif // DATAFACADE_BASE_HPP
Reference in New Issue Copy Permalink