<commit_before>package com.conveyal.r5.streets;

import com.conveyal.osmlib.Node;
import com.conveyal.r5.common.DirectionUtils;
import com.conveyal.r5.common.GeometryUtils;
import com.conveyal.r5.labeling.StreetClass;
import com.conveyal.r5.profile.ProfileRequest;
import com.conveyal.r5.profile.StreetMode;
import com.conveyal.r5.rastercost.CostField;
import com.conveyal.r5.trove.AugmentedList;
import com.conveyal.r5.trove.TIntAugmentedList;
import com.conveyal.r5.trove.TLongAugmentedList;
import com.conveyal.r5.util.P2;
import com.conveyal.r5.util.TIntIntHashMultimap;
import com.conveyal.r5.util.TIntIntMultimap;
import gnu.trove.iterator.TIntIntIterator;
import gnu.trove.list.TByteList;
import gnu.trove.list.TFloatList;
import gnu.trove.list.TIntList;
import gnu.trove.list.TLongList;
import gnu.trove.list.TShortList;
import gnu.trove.list.array.TByteArrayList;
import gnu.trove.list.array.TIntArrayList;
import gnu.trove.list.array.TLongArrayList;
import gnu.trove.list.array.TShortArrayList;
import gnu.trove.map.hash.TIntIntHashMap;
import gnu.trove.set.TIntSet;
import gnu.trove.set.hash.TIntHashSet;
import org.locationtech.jts.geom.Coordinate;
import org.locationtech.jts.geom.Envelope;
import org.locationtech.jts.geom.LineString;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.Serializable;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.EnumSet;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.StringJoiner;
import java.util.function.IntConsumer;

import static com.google.common.base.Preconditions.checkState;

/**
 * This stores all the characteristics of the edges in the street graph layer of the transport network.
 * The naive way to do this is making one object per edge, and storing all those edges in one big list or in outgoing
 * and incoming edge lists in each vertex. However, representing the street graph as an object graph has some
 * disadvantages, including devoting a large amount of space to pointers, making serialization more complex, and
 * possible memory locality effects on speed.
 *
 * Originally we considered using a library that would simulate compound value types (C structs). A column store with
 * parallel arrays is better than a struct simulation because:
 * 1. it is less fancy, 2. it is auto-resizing (not fixed size), 3. I've tried both and they're the same speed.
 *
 * This problem will be solved when Java JEP 169 (value/inline types) finally becomes part of the language, especially
 * when inline types are available in generic types like ArrayList. The "record types" now in JVM preview would improve
 * readability and maintainability but are still reference classes, so not worth the migration.
 *
 * Edges come in pairs that have the same origin and destination vertices and the same geometries, but reversed.
 * Therefore many of the arrays are only half as big as the number of edges. All even numbered edges are forward, all
 * odd numbered edges are reversed.
 *
 * Typically, somewhat more than half of street segment edges have intermediate points (ie. their geometry contains
 * points other than the two endpoints). Therefore it's more efficient to add a complete dense column for
 * references to intermediate point arrays, instead of using a sparse HashMap to store values only for those edges that<commit_msg>chore: remove unused imports<commit_after>package com.conveyal.r5.streets;

import com.conveyal.osmlib.Node;
import com.conveyal.r5.common.DirectionUtils;
import com.conveyal.r5.common.GeometryUtils;
import com.conveyal.r5.labeling.StreetClass;
import com.conveyal.r5.profile.ProfileRequest;
import com.conveyal.r5.profile.StreetMode;
import com.conveyal.r5.rastercost.CostField;
import com.conveyal.r5.trove.AugmentedList;
import com.conveyal.r5.trove.TIntAugmentedList;
import com.conveyal.r5.trove.TLongAugmentedList;
import com.conveyal.r5.util.P2;
import com.conveyal.r5.util.TIntIntHashMultimap;
import com.conveyal.r5.util.TIntIntMultimap;
import gnu.trove.iterator.TIntIntIterator;
import gnu.trove.list.TByteList;
import gnu.trove.list.TIntList;
import gnu.trove.list.TLongList;
import gnu.trove.list.TShortList;
import gnu.trove.list.array.TByteArrayList;
import gnu.trove.list.array.TIntArrayList;
import gnu.trove.list.array.TLongArrayList;
import gnu.trove.list.array.TShortArrayList;
import gnu.trove.map.hash.TIntIntHashMap;
import gnu.trove.set.TIntSet;
import gnu.trove.set.hash.TIntHashSet;
import org.locationtech.jts.geom.Coordinate;
import org.locationtech.jts.geom.Envelope;
import org.locationtech.jts.geom.LineString;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.Serializable;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.EnumSet;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.StringJoiner;
import java.util.function.IntConsumer;

/**
 * This stores all the characteristics of the edges in the street graph layer of the transport network.
 * The naive way to do this is making one object per edge, and storing all those edges in one big list or in outgoing
 * and incoming edge lists in each vertex. However, representing the street graph as an object graph has some
 * disadvantages, including devoting a large amount of space to pointers, making serialization more complex, and
 * possible memory locality effects on speed.
 *
 * Originally we considered using a library that would simulate compound value types (C structs). A column store with
 * parallel arrays is better than a struct simulation because:
 * 1. it is less fancy, 2. it is auto-resizing (not fixed size), 3. I've tried both and they're the same speed.
 *
 * This problem will be solved when Java JEP 169 (value/inline types) finally becomes part of the language, especially
 * when inline types are available in generic types like ArrayList. The "record types" now in JVM preview would improve
 * readability and maintainability but are still reference classes, so not worth the migration.
 *
 * Edges come in pairs that have the same origin and destination vertices and the same geometries, but reversed.
 * Therefore many of the arrays are only half as big as the number of edges. All even numbered edges are forward, all
 * odd numbered edges are reversed.
 *
 * Typically, somewhat more than half of street segment edges have intermediate points (ie. their geometry contains
 * points other than the two endpoints). Therefore it's more efficient to add a complete dense column for
 * references to intermediate point arrays, instead of using a sparse HashMap to store values only for those edges that
{'fraction_non_alphanumeric': 0.07463131237896618, 'fraction_numerical': 0.006554446596156711, 'mean_word_length': 4.973309608540926, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7482453', 'n_tokens_mistral': 2065, 'n_tokens_neox': 1971, 'n_words': 721}