Too many total edges were removed error problem

[ondister]

Each time the error occurs: Too many total edges were removed error problem my consoleoutput:

d:\develop\gpaphhopper_bin>java -Xmx1000m -Xms500m -Dlog4j2.configurationFile=lo
gging.xml  -jar railway_routing-0.0.1-SNAPSHOT-with-dep.jar action=web  graph.lo
cation=graph-cache datareader.file=lithuania-latest.osm.pbf jetty.port=8989 jett
y.resourcebase=webapp vehicle=rail
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$Ref
lectUtils$1 (file:/D:/develop/gpaphhopper_bin/railway_routing-0.0.1-SNAPSHOT-wit
h-dep.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],i
nt,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.
internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflect
ive access operations
WARNING: All illegal access operations will be denied in a future release
2018-04-15 11:29:50,257 [main] INFO  com.graphhopper.http.CmdArgsModule - jsonp
disabled
2018-04-15 11:30:11,137 [main] INFO  com.graphhopper.reader.osm.OSMReader - crea
ting graph. Found nodes (pillar+tower):10а670, totalMB:659, usedMB:367
2018-04-15 11:30:20,129 [main] INFO  com.graphhopper.reader.osm.OSMReader - 12а2
49а446, now parsing ways
2018-04-15 11:30:30,521 [main] INFO  com.graphhopper.reader.osm.OSMReader - 13а6
72а245, now parsing relations
2018-04-15 11:30:30,751 [main] INFO  com.graphhopper.reader.osm.OSMReader - fini
shed way processing. nodes: 2338, osmIdMap.size:10670, osmIdMap:0MB, nodeFlagsMa
p.size:0, relFlagsMap.size:0, zeroCounter:0 totalMB:997, usedMB:741
2018-04-15 11:30:30,753 [main] INFO  com.graphhopper.reader.osm.OSMReader - time
 pass1:20s, pass2:19s, total:40s
2018-04-15 11:30:30,757 [main] INFO  com.graphhopper.routing.subnetwork.PrepareR
outingSubnetworks - start finding subnetworks (min:200, min one way:0) totalMB:9
97, usedMB:741
Exception in thread "main" java.lang.RuntimeException: java.lang.IllegalStateExc
eption: Too many total edges were removed: 1879, all edges:2235
        at de.geofabrik.railway_routing.RailwayRoutingMain.web(RailwayRoutingMai
n.java:169)
        at de.geofabrik.railway_routing.RailwayRoutingMain.<init>(RailwayRouting
Main.java:68)
        at de.geofabrik.railway_routing.RailwayRoutingMain.main(RailwayRoutingMa
in.java:57)
Caused by: java.lang.IllegalStateException: Too many total edges were removed: 1
879, all edges:2235
        at com.graphhopper.routing.subnetwork.PrepareRoutingSubnetworks.keepLarg
eNetworks(PrepareRoutingSubnetworks.java:182)
        at com.graphhopper.routing.subnetwork.PrepareRoutingSubnetworks.doWork(P
repareRoutingSubnetworks.java:83)
        at com.graphhopper.GraphHopper.cleanUp(GraphHopper.java:1194)
        at de.geofabrik.railway_routing.RailwayHopper.cleanUp(RailwayHopper.java
:72)
        at com.graphhopper.GraphHopper.process(GraphHopper.java:649)
        at com.graphhopper.GraphHopper.importOrLoad(GraphHopper.java:619)
        at com.graphhopper.http.GraphHopperModule$3.start(GraphHopperModule.java
:182)
        at com.graphhopper.http.GHServer.start(GHServer.java:118)
        at de.geofabrik.railway_routing.RailwayRoutingMain.web(RailwayRoutingMai
n.java:167)
        ... 2 more

my bat file: java -Xmx1000m -Xms500m -Dlog4j2.configurationFile=logging.xml -jar railway_routing-0.0.1-SNAPSHOT-with-dep.jar action=web graph.location=graph-cache datareader.file=lithuania-latest.osm.pbf jetty.port=8989 jetty.resourcebase=webapp vehicle=rail

[Nakaner]

Well, currently all four profiles only accept Central/Western European standard gauge (1435 mm) but Lithuania uses the Russian gauge (1520 mm). Your exception is caused because the graph only contains very few edges which are probably only siding and yard gauges lacking gauge=* in OSM (no gauge=* tag is treated like a compatible gauge). The PrepareRoutingSubnetworks removes small subnetworks (routing islands).

I created two new issues to track the progress and therefore close this issue.

https://github.com/geofabrik/railway_routing/issues/2 https://github.com/geofabrik/railway_routing/issues/3

[Nakaner]

@ondister The routing engine now comes with two gauge-agnostic profiles (one for electric engines).

[MindaugasBernatavicius]

Adding an example configuration that solved the issue for me (graphhoper-2.3 branch, does not work main branch):

graphhopper:
    # Path to OpenStreetMap input file
    datareader.file:

    # Graph directory
    # If the value is not set, you have to define it using command line arguments, see README.md.
    graph.location:

    ##### Vehicles #####

    # Enabled flag encoders. This is a string (comma separated) of all enabled flag encoders.
    # You can use any name defined in flagEncoderProperties section or any of the predefined encoders.
    # Don't forget to add "|turn-costs=true" after each name.
    # This property replaces graphhopper.profile used in previous versions.
    graph.flag_encoders: tgv_all|turn_costs=true,freight_electric_15kvac_25kvac|turn_costs=true,alltracks|turn_costs=true

    # Add additional information to every edge. Used for path details (#1548), better instructions (#1844) and tunnel/bridge interpolation (#798).
    # Default values are: road_class,road_class_link,road_environment,max_speed,road_access (since #1805)
    # More are: surface,max_width,max_height,max_weight,max_axle_load,max_length,hazmat,hazmat_tunnel,hazmat_water,toll,track_type
    # graph.encoded_values: surface,toll,track_type

    ##### Routing Profiles ####

    # Routing can be done for the following list of profiles. Note that it is required to specify all the profiles you
    # would like to use here. The fields of each profile are as follows:
    # - name (required): a unique string identifier for the profile
    # - vehicle (required): refers to the `graph.flag_encoders` used for this profile
    # - weighting (required): the weighting used for this profile, e.g. fastest,shortest or short_fastest
    # - turn_costs (true/false, default: false): whether or not turn restrictions should be applied for this profile.
    #   this will only work if the `graph.flag_encoders` for the given `vehicle` is configured with `|turn_costs=true`.
    #
    # Depending on the above fields there are other properties that can be used, e.g.
    # - distance_factor: 0.1 (can be used to fine tune the time/distance trade-off of short_fastest weighting)
    # - u_turn_costs: 60 (time-penalty for doing a u-turn in seconds (only possible when `turn_costs: true`)).
    #   Note that since the u-turn costs are given in seconds the weighting you use should also calculate the weight
    #   in seconds, so for example it does not work with shortest weighting.
    # - custom_model_file: when you specified "weighting: custom" you need to set a yaml file that defines the custom_model.
    #   If you want an empty model you can also set "custom_model_file: empty".
    #
    #   For more information about profiles and especially custom profiles have a look into the documentation
    #   at docs/core/profiles.md or the examples under web/src/test/resources/com/graphhopper/http/resources/ or
    #   the CustomWeighting class for the raw details.
    #
    # To prevent long running routing queries you should usually enable either speed or hybrid mode for all the given
    # profiles (see below). Otherwise you should at least limit the number of `routing.max_visited_nodes`.
    profiles:
        - name: tgv
          vehicle: tgv_all
          weighting: fastest
          turn_costs: true
          u_turn_costs: 600
        - name: normal
          vehicle: freight_electric_15kvac_25kvac
          weighting: fastest
          turn_costs: true
          u_turn_costs: 1200
        - name: all
          vehicle: alltracks
          weighting: fastest
          turn_costs: true
          u_turn_costs: 1200

    # Speed mode:
    # Its possible to speed up routing by doing a special graph preparation (Contraction Hierarchies, CH). This requires
    # more RAM/disk space for holding the prepared graph but also means less memory usage per request. Using the following
    # list you can define for which of the above routing profiles such preparation shall be performed. Note that to support
    # profiles with `turn_costs: true` a more elaborate preparation is required (longer preparation time and more memory
    # usage) and the routing will also be slower than with `turn_costs: false`.
    profiles_ch:
        - profile: tgv
        - profile: normal
        - profile: all

    # Hybrid mode:
    # Similar to speed mode, the hybrid mode (Landmarks, LM) also speeds up routing by doing calculating auxiliary data
    # in advance. Its not as fast as speed mode, but more flexible.
    #
    # Advanced usage: It is possible to use the same preparation for multiple profiles which saves memory and preparation
    # time. To do this use e.g. `preparation_profile: my_other_profile` where `my_other_profile` is the name of another
    # profile for which an LM profile exists. Important: This only will give correct routing results if the weights
    # calculated for the profile are equal or larger (for every edge) than those calculated for the profile that was used
    # for the preparation (`my_other_profile`)
    profiles_lm: []