Select CH profiles by name ? #1708
Comments
1 task
|
What kind of request parameter should be used to select the profile: From #1838:
|
karussell
added a commit
that referenced
this issue
Jan 1, 2020
|
Have now a use case that uses the configurable Weighting for CH preparation and without other bigger modifications and I better understand the requirements: 40c2bbe#diff-34c31269f729871c0059410df746e62dR46 It was required to directly use the If we need to introduce a new parameter I would introduce a |
This was referenced Jan 22, 2020
This was referenced Feb 1, 2020
1 task
|
Fixed via #1934 |
karussell
added a commit
that referenced
this issue
May 1, 2020
* initial version with a basic Weighting support via yaml configuration * implement DelayFlexConfig * use flex model for CH preparation - yeah. Now questions like #1708 arise * reverse priority is logical * add more tests regarding common use cases like max_height and avoid tunnel * avoid special case of config after graphhopper.init * merge FlexResource into RouteResource * avoid additional test classes * add minor java docs * minor fixes * added initial UI * replace min with max priority for proper A* heuristic. Range check also for delay * throw exception if encoded values like max_height does not exists * added todo to PR * improve warning * avoid calling edge.getDistance in weight twice -> we need this for all edge.get(encVal) methods somehow * Remove unused import * Add EnumToValue#toString * rename FlexModelWeighting to CustomWeighting etc to avoid confusion with 'flex mode' * minor doc in config-example.yml * ensure that we currently just ignore URL parameters for POST /route requests * better description and examples * remove DelayCustomConfig for now as virtual edges would artifically duplicate it * reduce default max prio should increase speed; introduce max speed and max priority check * properly pick max priority * set default distance_factor to same like in ShortFastestWeighting instead of 1 * remove delay from CustomWeighting description * change naming custom_models -> custom_profiles #493 * fix tests * for now reduce time for routingLM8_custom * replaced the often not well working average_speed with max_speed map and max_speed_fallback * fix refactoring * normalize priority and speed_factor so it always can be used for LM even if 'prefer' i.e. bigger than 1 * apply max_speed after speed_factor; change order and document this in javadocs and example yml * finally made custom models working with LM, also in Measurement * move custom again to separate /custom endpoint; also move 'model' to root level in request * introduce speed_factor map * make distance_factor map similar to the other factor maps (i.e. a higher value means prefer this edge) * add missing distance factor in weight formula * sum instead product for distance_term * remove distance term for now (can be added later) * fix flex UI to new /custom endpoint and level up the model * config-example.yml: usage of camel case is required due to 8b329df#diff-3b9d114d751c40bc3a90a7625a2bedb7 * enable usage of BooleanEncodedValue * implement avoid area * avoid using block_area property for /custom endpoint * avoid subclassing and reusing CustomWeighting stuff * demo: load yml from URL * refactoring * avoid global snake case due to config.yml backward compatibility * avoid problem due to recently more strict LM fallback and use our test to catch this * normalizing the speed_factor makes no sense. Just use 1 as maximum. * AbstractFlagEncoder: removed newly introduced but unnecessary name parameter * fix typo * merged master * changed formula and make distance_constant_term independent of priority * rename distance_term_constant to shorter distance_influence * change unit of distance_influence to sec/km * removed 'name' parameter from AbstractWeighting; introduced GHRequest.get/setProfile * merged master * move CustomModel into ProfileConfig and auto-create profiles per CustomModel file * CustomModel is tightly coupled to ProfileConfig but should not be part of it as we can imagine multiple different profile configs, CustomWeighting.prepareRequest makes more sense now; renamed 'base' to 'profile' as it should match a previously configured profile (LM or not) * make GeoToValue more efficient; introduces quite a bit complexity * fix test * clean up, move TODO NOWs to later * renamed ConfigMapEntry to EdgeToValueEntry * do kind of autocompletion and more documentation * help with root entries too * make custom model usage more explicit (force profile creation) and limit profile names to ones with weighting=custom * make things even more clear and introduce CustomProfileConfig to remove CustomModel.profile and make other handling easier; introduce customModel.merge * fixed Measurement * test fix * fix Measurement * minor comment change * merged master * no need for CustomProfileConfig.customModel instead store in hints * minor test fixes * fix measurement * add preparation for truck and do timing for custom profile separate * introduce custom light to better compare speed and preparation time to car+fastest * minor fix * make 'pure' custommodel with car faster * add CH profile for custom weighting * try to make CustomWeighting identical to FastestWeighting * make CustomModel.merge compatible or throw illegalarg * revert change in FastestWeighting * fix hints usage * Try to make curl error visible * fix bug: decouple queryCustomModel from merge too * Try to print error response *and* fail the build * fix again: fastest weighting has no default distance influence * measurement: allow multiple CH profile preps * no need to change ProfileResolver anymore * truck profile should use distance influence as we have now car fastest for comparison * fixed something that we cannot really test as parsing the config is replaced with Java objects in our tests already * fixed config-example.yml, related to #1987 * increase Xmx a bit due to DW 2.0.x seems to need 10MB more * Replace DropwizardAppRule * Fix import * Minor clean up * revert changes in ProfileResolver * Minor * Improve (hopefully) javadocs of EdgeToValueEntry * Remove EncodedValueFactory#findValues * Remove ugly ClassCastException catching * Minor rename * Remove gpx stuff from custom route endpoint * better exception if boolean is not specified correctly * Fix misleading javadocs, minor readability fix * no negative values will happen, makes it easier to understand intend * hide CustomWeighting-specific helper methods * Setup measurements for custom profiles * Measurement failed, add debug output and try again * Fix benchmark * Update/extend profiles.md * Some more profiles.md * Fix typo * Continue with profiles.md * More profiles.md: areas also for speed and allowed value ranges for speed&prio * Fix typo * Fix explanation of distance_influence in the presence of priorities * Fix measurement name * Lets see how slow slow routing is * Rename Speed/PriorityCustomConfig to Speed/PriorityCalculator * Enforce custom_model_file=empty for empty custom model * Use AREA_PREFIX constant instead of key() function * add getAllShared to lookup * minor: avoid public constant. not sure if required * throw exception for geo and boolean too if too big speed * Keep slow routing, but for custom only use LM8 node-based * a bit dirty fix regarding CustomModel usage via Java API * Fix benchmark.sh * Move max_weight into priority and more refactorings (#2015) * initial range * refactoring; implement catch-all key * instead of prefer factor bigger than 1 * fix test case * include changes from review * no need to consider boolean keys * Update CustomWeighting java docs (even though it does not yet match the code) * Minor * Another fix for benchmark.sh... * Fix model for measurement for new syntax * ... and another fix * ... and another fix 2 * benchmark: include dijkstra on big map * Add a few tests for priority/speed calculator * Update profiles.md * Some more cleanup, docs and testing * Remove todo * removed yaml endpoint and renamed to /route-custom * accept JSON as custom profile on server side * Fix some of the remaining todos * Minor cleanup * merge 'comparison keys' properly; added tests and docs for this * Remove more todos * Try removing local distance variable, is it slower? * minor Xmx increase * Minor fix in docs * Remove server side custom model inheritance from docs * revert changes in FlagEncoder constructor * add nice use case as test; add missing IntToValueEntry; remove further todos * Trry storying distance in local variable is it faster? * Re-enable all measurements, disable custom/astar measurements for now * Add link to profiles.md Co-authored-by: easbar <easbar.mail@posteo.net>
karussell
added a commit
that referenced
this issue
Sep 28, 2021
) * Use new profile parameter to select routing profile (#1934) * ignore skadi elevation to avoid downloading 7MB file #1929 * trying to upgrade to dropwizard 2.x (#1998) * Edge-based shortest-path trees (Algorithm only) * Remove test output * Change routing time log to use ms instead of micros * Remove remaining usages of DropwizardAppRule * Random cleanups taken from #1841 * Add CarFlagEncoder.setSpeedTwoDirections, remove propertiesString constructor for encoders * Add test about url parameters for POST requests * IsochroneResource can do turn restrictions #1978 * SPTResource can do turn restrictions #1978 * Fixup * GHPointConverterProvider handles null values correctly * NotNull annotation instead of throwing * Same with another parameter * Default error messages are fine, just serialize them properly * Moare declarative validation * Use special Param types to avoid 404 when number not parseable * Enum for response type * Use dw20 facility for custom request parameter type * Same for pt * Default not-null-check * Default handling of Instant parameters * Less code * Move GHJerseyViolationExceptionMapper to bundle * SPTResource: Annotate with error return type * We now get a correct 400 error for missing points * We now get a correct 400 error for bad points * Use pluginManagement for maven compiler&test plugins, use java 8 in parent * no need for these plugins in parent, because it has no code * client-hc, tools and core still using Java 7 * Increase memory limit for tests for now * Only print seeds when tests fail * decrease test memory to 110m as it should be sufficient, #2003 * Remove gpx for post #2006 * Remove documentation for GPX #2006 * Move gpx test from GraphHopperWebIT to RouteResourceTest (#2000) * Throw (client-side) error if gpx export is used with POST * test client-hc routing without internet requirement (#2003) * test client-hc routing without internet requirement * improved alternative route example * parametrized test * use setProfile * Use @EnumSource Co-authored-by: easbar <easbar.mail@posteo.net> * remove RecalculationHook * Upgrade tools to Java and some cleanup + new measurement.name in Measurement * Add missing measurement.names * Add flag to reactivate transfer between stops connected to same OSM node. * Apply same checks for both GET&POST /route, clean up GHRequest#heading stuff (#2010) * timeout should propagate to OkHttp (#2014) * test if timeout propagates to OkHttp * remove maxUnzippedLength * make test a bit shorter via ValueSource * Failing test for traversal nodes over z-limit * Don't traverse nodes over z-limit * Add weight_limit (#2011) * ..but without weight_limit_offset * Don't rebuild pt-locationindex every time * Remove meaning of turn cost provider name, close #1999 * Increase shortcut version because properties file changed * Move parseList helper method to Helper * Unparsable enum indeed gives 400 and not 404 * Put 'took' in pt response * remove legacy turn_costs for isochrone too (#2018) * remove legacy turn_costs for isochrone too * add test case that was red and is now green * isochrone: adapt limit to consumed nodes. visited nodes can be multiple times more * add a test for landmark area-splitting, fixes #2020 * import cleanup from previous commit * Prune by max street time * Profile duration as parameter * Profile duration is optional * Use transportation mode for getOffBike (#2022) * Add instructions to fix error in intellij * Extract createRouteCallBack in main-template.js, as in #1841 * Remove change graph docs * Weighting support via yaml configuration (#1841) * initial version with a basic Weighting support via yaml configuration * implement DelayFlexConfig * use flex model for CH preparation - yeah. Now questions like #1708 arise * reverse priority is logical * add more tests regarding common use cases like max_height and avoid tunnel * avoid special case of config after graphhopper.init * merge FlexResource into RouteResource * avoid additional test classes * add minor java docs * minor fixes * added initial UI * replace min with max priority for proper A* heuristic. Range check also for delay * throw exception if encoded values like max_height does not exists * added todo to PR * improve warning * avoid calling edge.getDistance in weight twice -> we need this for all edge.get(encVal) methods somehow * Remove unused import * Add EnumToValue#toString * rename FlexModelWeighting to CustomWeighting etc to avoid confusion with 'flex mode' * minor doc in config-example.yml * ensure that we currently just ignore URL parameters for POST /route requests * better description and examples * remove DelayCustomConfig for now as virtual edges would artifically duplicate it * reduce default max prio should increase speed; introduce max speed and max priority check * properly pick max priority * set default distance_factor to same like in ShortFastestWeighting instead of 1 * remove delay from CustomWeighting description * change naming custom_models -> custom_profiles #493 * fix tests * for now reduce time for routingLM8_custom * replaced the often not well working average_speed with max_speed map and max_speed_fallback * fix refactoring * normalize priority and speed_factor so it always can be used for LM even if 'prefer' i.e. bigger than 1 * apply max_speed after speed_factor; change order and document this in javadocs and example yml * finally made custom models working with LM, also in Measurement * move custom again to separate /custom endpoint; also move 'model' to root level in request * introduce speed_factor map * make distance_factor map similar to the other factor maps (i.e. a higher value means prefer this edge) * add missing distance factor in weight formula * sum instead product for distance_term * remove distance term for now (can be added later) * fix flex UI to new /custom endpoint and level up the model * config-example.yml: usage of camel case is required due to 8b329df#diff-3b9d114d751c40bc3a90a7625a2bedb7 * enable usage of BooleanEncodedValue * implement avoid area * avoid using block_area property for /custom endpoint * avoid subclassing and reusing CustomWeighting stuff * demo: load yml from URL * refactoring * avoid global snake case due to config.yml backward compatibility * avoid problem due to recently more strict LM fallback and use our test to catch this * normalizing the speed_factor makes no sense. Just use 1 as maximum. * AbstractFlagEncoder: removed newly introduced but unnecessary name parameter * fix typo * merged master * changed formula and make distance_constant_term independent of priority * rename distance_term_constant to shorter distance_influence * change unit of distance_influence to sec/km * removed 'name' parameter from AbstractWeighting; introduced GHRequest.get/setProfile * merged master * move CustomModel into ProfileConfig and auto-create profiles per CustomModel file * CustomModel is tightly coupled to ProfileConfig but should not be part of it as we can imagine multiple different profile configs, CustomWeighting.prepareRequest makes more sense now; renamed 'base' to 'profile' as it should match a previously configured profile (LM or not) * make GeoToValue more efficient; introduces quite a bit complexity * fix test * clean up, move TODO NOWs to later * renamed ConfigMapEntry to EdgeToValueEntry * do kind of autocompletion and more documentation * help with root entries too * make custom model usage more explicit (force profile creation) and limit profile names to ones with weighting=custom * make things even more clear and introduce CustomProfileConfig to remove CustomModel.profile and make other handling easier; introduce customModel.merge * fixed Measurement * test fix * fix Measurement * minor comment change * merged master * no need for CustomProfileConfig.customModel instead store in hints * minor test fixes * fix measurement * add preparation for truck and do timing for custom profile separate * introduce custom light to better compare speed and preparation time to car+fastest * minor fix * make 'pure' custommodel with car faster * add CH profile for custom weighting * try to make CustomWeighting identical to FastestWeighting * make CustomModel.merge compatible or throw illegalarg * revert change in FastestWeighting * fix hints usage * Try to make curl error visible * fix bug: decouple queryCustomModel from merge too * Try to print error response *and* fail the build * fix again: fastest weighting has no default distance influence * measurement: allow multiple CH profile preps * no need to change ProfileResolver anymore * truck profile should use distance influence as we have now car fastest for comparison * fixed something that we cannot really test as parsing the config is replaced with Java objects in our tests already * fixed config-example.yml, related to #1987 * increase Xmx a bit due to DW 2.0.x seems to need 10MB more * Replace DropwizardAppRule * Fix import * Minor clean up * revert changes in ProfileResolver * Minor * Improve (hopefully) javadocs of EdgeToValueEntry * Remove EncodedValueFactory#findValues * Remove ugly ClassCastException catching * Minor rename * Remove gpx stuff from custom route endpoint * better exception if boolean is not specified correctly * Fix misleading javadocs, minor readability fix * no negative values will happen, makes it easier to understand intend * hide CustomWeighting-specific helper methods * Setup measurements for custom profiles * Measurement failed, add debug output and try again * Fix benchmark * Update/extend profiles.md * Some more profiles.md * Fix typo * Continue with profiles.md * More profiles.md: areas also for speed and allowed value ranges for speed&prio * Fix typo * Fix explanation of distance_influence in the presence of priorities * Fix measurement name * Lets see how slow slow routing is * Rename Speed/PriorityCustomConfig to Speed/PriorityCalculator * Enforce custom_model_file=empty for empty custom model * Use AREA_PREFIX constant instead of key() function * add getAllShared to lookup * minor: avoid public constant. not sure if required * throw exception for geo and boolean too if too big speed * Keep slow routing, but for custom only use LM8 node-based * a bit dirty fix regarding CustomModel usage via Java API * Fix benchmark.sh * Move max_weight into priority and more refactorings (#2015) * initial range * refactoring; implement catch-all key * instead of prefer factor bigger than 1 * fix test case * include changes from review * no need to consider boolean keys * Update CustomWeighting java docs (even though it does not yet match the code) * Minor * Another fix for benchmark.sh... * Fix model for measurement for new syntax * ... and another fix * ... and another fix 2 * benchmark: include dijkstra on big map * Add a few tests for priority/speed calculator * Update profiles.md * Some more cleanup, docs and testing * Remove todo * removed yaml endpoint and renamed to /route-custom * accept JSON as custom profile on server side * Fix some of the remaining todos * Minor cleanup * merge 'comparison keys' properly; added tests and docs for this * Remove more todos * Try removing local distance variable, is it slower? * minor Xmx increase * Minor fix in docs * Remove server side custom model inheritance from docs * revert changes in FlagEncoder constructor * add nice use case as test; add missing IntToValueEntry; remove further todos * Trry storying distance in local variable is it faster? * Re-enable all measurements, disable custom/astar measurements for now * Add link to profiles.md Co-authored-by: easbar <easbar.mail@posteo.net> * ui: update jquery version * upgrade osmosis-osm-binary, fixes #2019 * Point to docs in error messages regarding profile * Use profiles in web UI / graphhopper maps (#2023) Co-authored-by: Peter <graphhopper@gmx.de> * Remove geocoding IT * Rename: CHProfile -> CHConfig * Rename: ProfileConfig -> Profile * Rename: CHProfileConfig -> CHProfile * Rename: LMProfile -> LMConfig * Rename: LMProfileConfig -> LMProfile * Minor adjustment in comment * moved package from core/src/test/java/com/graphhopper/routing/profiles to ev #2016 * Update routing.md * Rename: GraphModification -> QueryOverlay * Remove AbstractRoutingTemplate#weighting field * Rename: QueryGraph#lookup -> QueryGraph#create * Rename: PrepareContractionHierarchies#getCHProfile -> getCHConfig * Some minor cleanups in GraphHopper&RoutingTemplates * Street-time parameter is Duration * Rename: PathWrapper -> ResponsePath, fix #1147 * Fix typo * Add compile error * Fix compile error * better estimate factor to store landmark weights more precise (#2027) * no static factor for large areas to store landmark weights more precise * further improve quality of max weight determination (increased prepare.lm.time should be acceptable) * minor fix * half number of landmarks from 6 to 3 in estimateMaxWeight to reduce prepare.lm.time by 10% * minor test fix * minor fix * check profile if used for LM or CH preparation (#2026) * check profile if used for LM or CH preparation * cleanup * first things after review * include custom model in tests and use linkedhashmap for pmap to ensure same version * minor javadocs fix * ensure toString is not only used for debugging * make it similar for Profile and CustomModel * Update isochrone docs * Update low level docs * Update low-level-api.md, fix #2032 * Minor fix of comment in ch algo * moved SPTEntry and ShortcutUnpacker to com.graphhopper.routing(.ch), #2016 * Add measurement info for subnetwork removal time * Fix min one way network size parameter in benchmarks * Use hppc.BitSet instead of java.util.BitSet for TarjanSCC as clearing bits is much faster, speeds up subnetwork removal. * link to custom profiles * Clean up TarjanSCC single node component handling (#2035) * fix android build * Enable surefire&failsafe plugins in parent poms * apparently *IT.java tests were not even running before, probably since 0702206 * compared to the surefire plugin (which binds itself to the test phase) the failsafe plugin has to be added to the plugins section * Rename: GraphHopperIT -> GraphHopperTest, RoutingAlgorithmWithOSMIT -> RoutingAlgorithmWithOSMTest * android: we need to configure profiles * workaround to force building JS until #1700 is fixed * Update error message when u-turn costs are used with profile not supporting turn costs, fix #2040 * Revert took output to milliseconds * Remove bogus constructor * Add documentation about enabling turn costs via Java API, fix #2033 * Remove min_one_way_network parameter, clean up subnetwork removal (#2042) * Improve logging during subnetwork removal and clean up PrepareRoutingSubnetworks * Replace edge filter parameters with access encoded values only * Remove second (BFS) subnetwork removal pass, finding strongly connected components once is enough * Remove no longer needed min_one_way_network parameter * Initialize ProfileResolver more lazily * Remove isNodeRemoved check from Tarjan algo * This is not needed because Tarjan is/should never (be) used on a graph with removed nodes * Remove duplicate logs * Replace Tarjan algorithm with slightly improved version * no object allocation (TarjanState and EdgeExplorer) during search anymore * use BitSet to represent single-node components (but this time correctly) * keep versions with implicit and explicit recursion * add some more tests * Add edge-based version of Tarjan's SCC algorithm * Revert "Add edge-based version of Tarjan's SCC algorithm" (tests are failing) This reverts commit 3d3816a * Revert "Replace Tarjan algorithm with slightly improved version" (tests are failing) This reverts commit bf577d4 * graphhopper.sh: minor fix * include npm as part of the maven cycle (#2041) * include npm as part of the maven cycle but only for a specific mavenprofile * adapt docs * try destination of main.js in target/ * uh, adapt old config.yml - add a notice in changelog :) * Replace Tarjan algorithm with slightly improved version * no object allocation (TarjanState and EdgeExplorer) during search anymore * use BitSet to represent single-node components (but this time correctly) * keep algorithm in two versions with implicit and explicit recursion * add some more tests * Add edge-based version of Tarjan's SCC algorithm (cherry picked from commit 3d3816a) * Fix edge-keys for edge-based Tarjan * Enforce allowWrites for GTFS files #2036: - Load GTFS feeds DBs as readOnly if they already exists. A runtime exception will be thrown if the mapping in transit_schedule DB is not reflected in the folder. - Validate write access (ensureWriteAccess()) before creating GTFS DBs. * Use edge-based subnetwork removal if turn costs are enabled (#2044) Co-authored-by: Andi <easbar.mail@posteo.net> Co-authored-by: Peter <graphhopper@gmx.de> Co-authored-by: Michael Zilske <michael.zilske@tu-berlin.de> Co-authored-by: Mathieu St-Pierre <mathieu.st-pierre@curbside.com> Co-authored-by: Robin <boldtrn@users.noreply.github.com> Co-authored-by: gchevalier <gchevalier@expedia.com> Co-authored-by: Oleksii Kirizii <oleksii@bikemap.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Continuing some of the discussion that started in #1705.
But isn't this the case already ? For example we have
graph.flag_encoder=foot,car|turn_costs=true. Not thinking about CH for a moment this means we can do routing for foot and car and for car we also get a turn cost extension (i.e. we can route with turn restrictions from OSM). Also we can use the different query parameters, like heading, alternative etc. And you mean all the different combinations should be listed upfront ?For CH we have to list this upfront because the preparation needs to be done prior to the routing. One thing that def. can be improved is how these preparations are specified, #493. The other question is then how the request parameters are mapped to the preparations afterwards.
Say somebody sets up a GH server for a new app that has two CH profiles for two different user groups: one group moves around a city using bicycles preferring roads with bicycle lanes and another uses trucks and can only drive to certain parts of the city. I imagine the best to do would be to have a nice way to specify all the parameters that go into the CH preparation like the road weights, the blocked areas etc. (making this easy to configure is #493), then give this profile some (arbitrary) name, and afterwards select the profile using this name (maybe the app that is used knows the user group via login). So here it would be useful to give a profile a name/id and use this on the request.
Or thinking about the GH directions API: It is running for some fixed set of profiles. It would be easy to document what these profiles are and give them an id/name and then choose the profile by name on the request. This seems a lot more intuitive than having to specify the weighting, encoder, u-turn-costs and all this just so the request 'matches' one of the profiles (and in case it does not getting an error / or a slow algorithm if falling back to non-CH). Or even better add an endpoint to the server that lists all the available profiles.
Even for flexible CH it would be similar I think. Say there is the possibility to build a CH preparation 'on the fly'/while the server is running (which I very much hope it will be at some point). This will certainly take a lot of memory and the preparation needs to be stored or kept in memory etc. To use it later it has to have some name and to me its also the most obvious way to use nothing but this name to refer to this preparation.
Right now I cannot come up with a case where it would not be feasible to 1) lookup the documentation/special endpoint etc. of whatever GH server is running, 2) check what profiles are supported and find the name of the one that should be used, 3) run a route request with the name of the desired profile attached ?
The text was updated successfully, but these errors were encountered: