crs-l2-fiji-antimeridian

Rerun

Let me analyze the data:

1. There are 30 transects, some crossing the antimeridian (180° longitude). 
2. Transects flagged `crosses_antimeridian_flag: true` have coordinates that cross the 180° line. In GeoJSON, longitudes are typically -180 to 180. When a line crosses the antimeridian, rendering engines often draw a line wrapping the entire globe instead of the short local path.

For example, T001 has coordinates:
- [178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]

The actual path goes from 178.94 → 179.46 → 179.97 (approaching 180 from east), then jumps to -179.51 (just west of 180), then continues westward. The renderer draws a line from 179.97 all the way around the globe the long way to -179.51.

The fix: For each segment that crosses the antimeridian, we need to split the LineString into multiple parts at the antimeridian (+/- 180°), so that each part stays on one side. This way each part renders as a short local line.

The standard approach:
1. For each coordinate, check if it's on the "east" side (lon > 0) or "west" side (lon < 0)
2. When the sign changes between consecutive coordinates, interpolate the intersection at lon=180 (or -180 depending on direction)
3. Split the line into separate segments at these intersection points
4. Each segment stays entirely on one side of the antimeridian

Actually, a cleaner approach:
- Shift coordinates that are on the "wrong" side by +360 or -360 to make the line continuous
- Then split at 180° longitude

Let me think about this more carefully.

For T001: [178.94, 179.46, 179.97, -179.51, -179.00, -178.48]
- These are all around Fiji, near 180° longitude
- The actual path: 178.94 → 179.46 → 179.97 (east side) → then crosses to -179.51 (west side, but this is just 180.49 in other notation) → -179.00 → -178.48
- So the line crosses from just east of 180 to just west of 180

If we convert all to a continuous coordinate system (e.g. add 360 to the negative ones when they follow positive ones), we get:
- 178.94, 179.46, 179.97, 180.49 (= -179.51+360), 181.00 (= -179.00+360), 181.52 (= -178.48+360)

Now we split at lon=180. The segment from 179.97 to 180.49 crosses 180. The intersection point is at lon=180, lat interpolated.

Then we convert back to -180..180 for the west-side part.

For each transect that crosses the antimeridian, I'll create a MultiLineString with:
- Part 1: points from start up to the intersection at 180°, using lon values as-is
- Part 2: points from the intersection at -180° (or 180°) to the end, using -180..180 convention

Let me write a Python script to do all of this.

The target CRS for Fiji: I need to find Fiji's national metric grid. Fiji uses "Fiji 1986 / Fiji Map Grid" which is EPSG:3460. Let me verify... Actually, there are a few options:
- EPSG:3460 - Fiji 1986 / Fiji Map Grid (this is the national one)

Let me write the script.

Actually, let me think about the proper approach for splitting at the antimeridian:

1. For each coordinate pair (x, y) where x is longitude:
   - If the line crosses from positive to negative (or vice versa) between two consecutive points, we need to find where it crosses 180° (or -180°)
   - Actually, we check if the difference between consecutive longitudes is more than 180° in absolute value — that indicates an antimeridian crossing

2. The interpolation: given two points (lon1, lat1) and (lon2, lat2) where lon1 and lon2 are on opposite sides:
   - If lon1 > 0 and lon2 < 0, the crossing is at lon=180 (same as -180)
   - Actually we want to find the point where longitude = 180 (or -180)
   - Using linear interpolation: t = (180 - lon1) / (lon2 - lon1) where lon2 might be negative
   - But wait, if lon2 < 0, we should adjust it: lon2_adj = lon2 + 360
   - Then t = (180 - lon1) / ((lon2 + 360) - lon1)
   - lat = lat1 + t * (lat2 - lat1)

Let me write the script.

```python
import geopandas as gpd
import pandas as pd
from shapely.geometry import LineString, MultiLineString, shape
from shapely.ops import transform
import pyproj
import json
import math

# Read the GeoJSON
gdf = gpd.read_file('/work/fiji_transects_wgs84.geojson')

def split_antimeridian(line):
    """Split a LineString that crosses the antimeridian into multiple segments."""
    coords = list(line.coords)
    
    # Check if the line crosses the antimeridian
    # We check by looking at the longitude difference between consecutive points
    crosses = False
    for i in range(len(coords) - 1):
        lon1, lat1 = coords[i]
        lon2, lat2 = coords[i+1]
        if abs(lon2 - lon1) > 180:
            crosses = True
            break
    
    if not crosses:
        return [line]
    
    # The line crosses the antimeridian
    # We'll split it into segments, each staying on one side
    segments = []
    current_segment = [coords[0]]
    
    for i in range(len(coords) - 1):
        lon1, lat1 = coords[i]
        lon2, lat2 = coords[i+1]
        
        if abs(lon2 - lon1) > 180:
            # Crossing detected - interpolate the intersection point
            if lon1 > 0 and lon2 < 0:
                # Crossing from east to west at 180
                # Adjust lon2 to be continuous
                lon2_adj = lon2 + 360
                t = (180 - lon1) / (lon2_adj - lon1)
                lat_interp = lat1 + t * (lat2 - lat1)
                interp_point = (180, lat_interp)
                
                current_segment.append(interp_point)
                segments.append(LineString(current_segment))
                
                # Start new segment on west side
                interp_point_west = (-180, lat_interp)
                current_segment = [interp_point_west, coords[i+1]]
            elif lon1 < 0 and lon2 > 0:
                # Crossing from west to east at -180/180
                lon1_adj = lon1 + 360
                t = (180 - lon1_adj) / (lon2 - lon1_adj)
                lat_interp = lat1 + t * (lat2 - lat1)
                interp_point = (180, lat_interp)
                
                current_segment.append(interp_point)
                segments.append(LineString(current_segment))
                
                # Start new segment on east side
                interp_point_east = (-180, lat_interp)
                current_segment = [interp_point_east, coords[i+1]]
        else:
            current_segment.append(coords[i+1])
    
    # Don't forget the last segment
    if len(current_segment) > 1:
        segments.append(LineString(current_segment))
    
    return segments

# Process each feature
new_features = []
for idx, row in gdf.iterrows():
    geom = row.geometry
    props = row.drop('geometry').to_dict()
    
    if geom.geom_type == 'LineString':
        segments = split_antimeridian(geom)
        if len(segments) == 1:
            # No crossing, still a LineString - need to convert to MultiLineString
            new_geom = MultiLineString([segments[0]])
        else:
            new_geom = MultiLineString(segments)
    else:
        new_geom = geom
    
    new_features.append({'type': 'Feature', 'properties': props, 'geometry': new_geom})

# Create new GeoDataFrame
new_gdf = gpd.GeoDataFrame.from_features(new_features, crs='EPSG:4326')

# Now reproject to Fiji Map Grid (EPSG:3460 - Fiji 1986 / Fiji Map Grid)
# Actually let me check the right EPSG code
# Fiji 1986 / Fiji Map Grid is EPSG:3460
new_gdf = new_gdf.to_crs('EPSG:3460')

# Calculate lengths in metres
new_gdf['length_m'] = new_gdf.geometry.length

# Ensure all geometries are MultiLineString
for idx, row in new_gdf.iterrows():
    if row.geometry.geom_type != 'MultiLineString':
        new_gdf.at[idx, 'geometry'] = MultiLineString([row.geometry])

# Write output
new_gdf.to_file('/work/fiji_transects_fmg.geojson', driver='GeoJSON')
```

Wait, I need to think more carefully. The issue is that when a coordinate goes from, say, 179.97 to -179.51, a renderer draws the line going the "long way" around the globe (across 0°), rather than the short way across the antimeridian.

The fix: split the line at the antimeridian so each part stays localized.

Let me think about the interpolation more carefully.

For T001: [178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]

Between [179.97, -17.61] and [-179.51, -17.60]:
- lon1 = 179.97, lon2 = -179.51
- Difference = |-179.51 - 179.97| = 359.48 > 180 → crossing
- lon1 > 0, lon2 < 0 → crossing from east to west
- lon2_adj = -179.51 + 360 = 180.49
- t = (180 - 179.97) / (180.49 - 179.97) = 0.03 / 0.52 = 0.05769
- lat_interp = -17.61 + 0.05769 * (-17.60 - (-17.61)) = -17.61 + 0.05769 * 0.01 = -17.61 + 0.000577 = -17.6094

So the intersection point is at (180, -17.6094) on the east side, and (-180, -17.6094) on the west side.

Segment 1 (east side): [178.94, -17.63] → [179.46, -17.62] → [179.97, -17.61] → [180, -17.6094]
Segment 2 (west side): [-180, -17.6094] → [-179.51, -17.60] → [-179.00, -17.58] → [-178.48, -17.58]

Wait, but after reprojection to a metric CRS, the two segments should meet properly.

Actually, I realize there may be a subtlety. When we have the point (180, -17.6094) which is right on the antimeridian, and the other side (-180, -17.6094) - these are the same point in geographic space. After reprojection to a local metric CRS, they should map to the same point.

Let me also consider: some transects might cross the antimeridian multiple times? Looking at the data, each line seems to cross at most once. But to be safe, let me handle the general case.

Actually, looking more carefully at T004:
[178.87, -17.80], [179.54, -17.60], [-179.79, -17.41], [-179.12, -17.19], [-178.45, -16.99], [-177.78, -16.80]

This crosses once (179.54 → -179.79).

T010: [177.60, -17.28], [179.13, -17.47], [-179.35, -17.65], [-177.82, -17.84]
Crosses once (179.13 → -179.35).

OK so each crossing is at most once. Good.

Now, some of the non-antimeridian-crossing transects might also be simple LineStrings, and the user wants them all as MultiLineString. So I'll wrap them.

Let me also think about the CRS. Fiji's national grid:
- "Fiji 1986 / Fiji Map Grid" - EPSG:3460
- This uses the Fiji 1986 datum and a Transverse Mercator projection

Let me verify by checking if pyproj has this: Yes, EPSG:3460 is valid.

Actually, I should double-check. Fiji has two main CRS systems:
1. Fiji 1956 / Fiji Central Grid (EPSG:2114) - old
2. Fiji 1986 / Fiji Map Grid (EPSG:3460) - newer

The national metric grid for Fiji would be EPSG:3460 (Fiji 1986 / Fiji Map Grid).

Let me write the solution now.

Let me understand the problem:

1. Some transects cross the antimeridian (180° longitude). When coordinates go from positive longitudes (e.g., 179.9°) to negative ones (e.g., -179.9°), GIS software can render them as arcs spanning the whole globe instead of short local segments.

2. The fix is to "unwrap" the longitudes that cross the antimeridian by adding/subtracting 360° to negative longitudes so that the coordinates are continuous (e.g., -179.9° becomes 180.1°). Then we split the geometry where it jumps across the antimeridian.

3. Then we convert to Fiji's national metric grid (Fiji Geodetic Datum 1986 / Fiji Map Grid - EPSG:3460 or EPSG:15088? Let me think... Fiji Map Grid is EPSG:3460 or EPSG:15088. Let me check. Actually, Fiji uses EPSG:3460 (Fiji 1956 / Fiji Map Grid) or EPSG:15088 (FGD 1942 / Fiji Map Grid) or maybe EPSG:3831 (Fiji 1986 / Fiji Map Grid). Let me look at what's most appropriate.

Actually, Fiji's national metric grid is "Fiji 1956 / Fiji Map Grid" (EPSG:3460) or "Fiji 1986 / Fiji Map Grid" (EPSG:3831). Since the data is in WGS84, the modern one would be "Fiji 1986 / Fiji Map Grid" (EPSG:3831). But actually, there's also EPSG:15088 "Fiji 1956 / Fiji Map Grid". Let me just use EPSG:3460 (Fiji 1956 / Fiji Map Grid) or EPSG:3832 (Fiji 1986 / Fiji Map Grid).

Wait, let me think about this more carefully. The commonly used one for Fiji is "Fiji 1956 / Fiji Map Grid" EPSG:3460. But there's also "Fiji 1986 / Fiji Map Grid" EPSG:3832 (note: 3831 is the geodetic datum, 3832 is the projected).

Actually the user says "Fiji's national metric grid" so likely "Fiji 1956 / Fiji Map Grid" EPSG:3460. But the input is in WGS84, and the Fiji 1956 datum is different from WGS84. Let me use pyproj to transform from WGS84 to Fiji Map Grid.

Actually, the most straightforward approach: Let's just use "Fiji 1956 / Fiji Map Grid" EPSG:3460. But in modern Fiji, they might use "Fiji 1986" datum. Let me check what's standard.

Actually I'll go with EPSG:3460 (Fiji 1956 / Fiji Map Grid) as it's the most well-known "Fiji Map Grid". Let me write the solution.

Here's my approach:

1. Read the GeoJSON
2. For each feature:
   a. Check if the coordinates cross the antimeridian (longitudes go from > 170 to < -170 or vice versa)
   b. For those that do, "unwrap" the longitudes: for coordinates that are negative and part of the segment that should be east of 180°, add 360 to make them continuous
   c. Split into parts where there's a big jump (the antimeridian crossing point)
   d. Create a MultiLineString from the parts
   e. For those that don't cross, still ensure they're MultiLineString
3. Reproject to Fiji Map Grid
4. Calculate length_m for each feature
5. Write out as GeoJSON

The key trick: For transects crossing the antimeridian, coordinates like 179.97, ... -179.51 should become 179.97, ... 180.49 (by adding 360 to the negative values). Then we split at the antimeridian (180° or 0° after unwrapping?).

Wait, let me think more carefully.

For T001:
Original: [178.94, 179.46, 179.97, -179.51, -178.99, -178.48]
After unwrapping (adding 360 to negative lons): [178.94, 179.46, 179.97, 180.49, 181.01, 181.52]

Now the segment goes from 179.97 to 180.49 - this crosses the 180° meridian. We need to split this into:
- Part 1: [178.94, 179.46, 179.97, 180.0] (up to the meridian)
- Part 2: [180.0, 180.49, 181.01, 181.52] (from the meridian)

But actually, a simpler approach: after unwrapping, we can just clip/shift coordinates so that any line that spans the antimeridian gets split into two parts at 180°.

Actually, the standard approach in GIS is:

1. Convert negative longitudes that are "east of 180" by adding 360 (so -179 becomes 181)
2. Find where the line crosses 180° (or 0° in the unwrapped space? Actually we need to find where it crosses 180°)
3. Split the line there

Let me think about step 2 more carefully. After adding 360 to the "far east" negative longitudes:
- For T001: [178.94, 179.46, 179.97, 180.49, 181.01, 181.52]
- The crossing from 179.97 to 180.49 crosses 180°.

So I find the segment that crosses 180° (where one is < 180 and the next is > 180), interpolate the point at 180°, and split the line into two parts.

Then, the coordinates that are > 180 get 360 subtracted to put them back in [-180, 180] range for the output GeoJSON in WGS84 before reprojection.

Wait, actually - for the reprojection, I should do the unwrapping, splitting, then reproject the two parts, then combine them into a MultiLineString.

Let me think about the implementation more carefully.

Actually, a simpler approach using shapely:

1. For each linestring, check if it crosses the antimeridian
2. If it does, "unwrap" by adding 360 to negative longitudes that are part of the eastern side after the antimeridian
3. Split at 180° 
4. Convert back by subtracting 360 from coordinates > 180
5. Make the geometry a MultiLineString
6. Reproject to Fiji Map Grid
7. Calculate length

Let me implement this.

Actually, let me think about the simplest robust approach:

For a LineString that crosses the antimeridian:
- The coordinates go from positive eastings (like 179) to negative westings (like -179)
- I can identify which segment crosses the antimeridian (where absolute difference between consecutive longitudes > 300 degrees or so)
- Split into two segments at that point
- For the segment with negative longitudes, add 360 to bring them to positive values
- This gives me a continuous line in the "unwrapped" coordinate system

Then to reproject to Fiji Map Grid, I need to transform from WGS84. But the unwrapped coordinates (> 180) won't reproject directly... So what I should do is:

1. Identify the crossing point
2. Split into two segments
3. For the segment with negative lons, keep them as-is (they're west of the antimeridian)
4. For the segment with positive lons... they're already positive, keep as-is
5. Now I have two LineStrings, each on the correct side of the antimeridian
6. Create a MultiLineString
7. Reproject each part to Fiji Map Grid
8. Calculate the total length

Wait, but the original data has coordinates on both sides. Let me just do:

1. Read coordinates
2. If the line crosses the antimeridian (detected by a big jump in longitude), split it
3. For the eastern part, keep longitudes as positive (e.g., 179)
4. For the western part, keep longitudes as negative (e.g., -179)
5. Now both parts are valid WGS84 coordinates
6. Combine into MultiLineString
7. Reproject
8. Calculate length

Let me code this up.

Actually, let me use a different approach that's cleaner. I'll use `shapely.ops.transform` and handle the antimeridian by using `split` and `normalize`.

Here's my plan:

```python
import geopandas as gpd
import numpy as np
from shapely.geometry import LineString, MultiLineString, Point
from shapely.ops import transform, split, linemerge
from pyproj import Transformer
from functools import partial
import json

# Read the data
gdf = gpd.read_file('/work/fiji_transects_wgs84.geojson')

# Define the antimeridian fix
def fix_antimeridian_line(line):
    """Fix a LineString that crosses the antimeridian by splitting it."""
    coords = list(line.coords)
    
    # Check if this line crosses the antimeridian
    # Detect by large longitude jumps (> 300 degrees)
    splits = []
    i = 0
    while i < len(coords) - 1:
        lon1, lat1 = coords[i][0], coords[i][1]
        lon2, lat2 = coords[i+1][0], coords[i+1][1]
        
        if abs(lon2 - lon1) > 300:
            # We have a crossing. Split here.
            # Interpolate the point at lon = 180 or -180
            # Going from lon1 to lon2 which is a wrap
            # If lon1 is positive (east of 180 meridian) and lon2 is negative (west)
            # then the line goes from ~179 to ~-179, crossing at 180
            # Actually the crossing is at lon=180 (or lon=-180, same line)
            
            # Calculate the fraction where the line crosses 180
            # If going from positive to negative (east to west):
            # lon1 + t * (lon2 - lon1) = 180  ... wait
            # If lon1 = 179, lon2 = -179, the shortest path goes from 179 to 180 to -179
            # So lon1 + t * (lon2 + 360 - lon1) = 180... hmm
            pass
```

Actually, let me think about this more simply with the unwrapping approach:

The standard approach I've seen work well is:

1. Copy coordinates and detect if there's a large longitude jump
2. Where a jump from positive to negative occurs, shift all subsequent coordinates by +360
3. Then split where the coordinate passes 180
4. Convert back

Let me write the full code:

```python
import geopandas as gpd
from shapely.geometry import LineString, MultiLineString, Point, box
from shapely.ops import transform, split, linemerge, snap
from pyproj import Transformer
import numpy as np
import json

def unwrap_lons(coords):
    """Unwrap longitudes to make lines crossing the antimeridian continuous."""
    result = list(coords)
    for i in range(1, len(result)):
        lon_prev = result[i-1][0]
        lon_curr = result[i][0]
        diff = lon_curr - lon_prev
        if diff > 300:
            # Going from negative (west) to positive (east) - shouldn't happen for Fiji...
            pass
        elif diff < -300:
            # Going from positive (east) to negative (west)
            result[i] = (lon_curr + 360, result[i][1])
    return result

def split_at_180(coords):
    """Split unwrapped coordinates at 180° meridian."""
    parts = []
    current_part = [coords[0]]
    
    for i in range(1, len(coords)):
        lon_prev, lat_prev = current_part[-1]
        lon_curr, lat_curr = coords[i]
        
        if (lon_prev < 180 and lon_curr >= 180) or (lon_prev >= 180 and lon_curr < 180):
            # Crosses 180 - interpolate
            t = (180 - lon_prev) / (lon_curr - lon_prev)
            lat_at_180 = lat_prev + t * (lat_curr - lat_prev)
            current_part.append((180, lat_at_180))
            parts.append(LineString(current_part))
            current_part = [(180, lat_at_180)]
        
        current_part.append(coords[i])
    
    if current_part:
        parts.append(LineString(current_part))
    
    return parts
```

Hmm, but there's a subtlety. For transects like T001, the coordinates go:
178.94, 179.46, 179.97, -179.51, -178.99, -178.48

After unwrapping (adding 360 to the negative ones after the jump):
178.94, 179.46, 179.97, 180.49, 181.01, 181.52

The crossing from 179.97 to 180.49 crosses 180. So we split at 180:
Part 1: 178.94, 179.46, 179.97, 180.0 (interpolated point at 180)
Part 2: 180.0, 180.49, 181.01, 181.52

Now for Part 2, we need to convert back to standard WGS84 coordinates by subtracting 360:
180.0-360 = -180, 180.49-360 = -179.51, etc.

So Part 2 becomes: -180.0, -179.51, -178.99, -178.48

And Part 1 stays as: 178.94, 179.46, 179.97, 180.0

Wait, the 180.0 coordinate is ambiguous. Let me think...

Actually, for WGS84, longitude range is -180 to 180. So 180 is the same as -180. Let me keep the eastern part with +180 and the western part with -180.

Part 1 (east of antimeridian): [(178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (180, -17.60)]
Part 2 (west of antimeridian): [(-180, -17.60), (-179.51, -17.60), (-178.99, -17.58), (-178.48, -17.58)]

Both are valid WGS84 coordinates. Good.

But wait, when reprojecting, both parts will have coordinates in the correct hemisphere. Let me code this up properly.

Let me write a complete Python script:

```python
import geopandas as gpd
from shapely.geometry import LineString, MultiLineString, Point
from pyproj import Transformer
import numpy as np

def split_at_antimeridian(line):
    """Split a LineString that crosses the antimeridian into segments."""
    coords = list(line.coords)
    
    # First, check if this line crosses the antimeridian
    # Look for jumps in longitude > 300 degrees
    has_crossing = False
    for i in range(1, len(coords)):
        if abs(coords[i][0] - coords[i-1][0]) > 300:
            has_crossing = True
            break
    
    if not has_crossing:
        # Doesn't cross, just return as a list with one line
        return [line]
    
    # Unwrap the longitudes to make continuous
    unwrapped = list(coords)
    for i in range(1, len(unwrapped)):
        diff = unwrapped[i][0] - unwrapped[i-1][0]
        if diff > 300:
            # Going from negative to positive: subtract 360 from subsequent
            for j in range(i, len(unwrapped)):
                unwrapped[j] = (unwrapped[j][0] - 360, unwrapped[j][1])
        elif diff < -300:
            # Going from positive to negative: add 360 to subsequent
            for j in range(i, len(unwrapped)):
                unwrapped[j] = (unwrapped[j][0] + 360, unwrapped[j][1])
    
    # Now split at 180 (or -180, but with unwrapped coords, we look for crossing 180)
    parts = []
    current_seg = [unwrapped[0]]
    
    for i in range(1, len(unwrapped)):
        lon_prev, lat_prev = current_seg[-1]
        lon_curr, lat_curr = unwrapped[i]
        
        # Check if the segment crosses 180
        if (lon_prev < 180 <= lon_curr) or (lon_prev >= 180 > lon_curr):
            # Interpolate at 180
            if lon_curr - lon_prev != 0:
                t = (180 - lon_prev) / (lon_curr - lon_prev)
                lat_at_180 = lat_prev + t * (lat_curr - lat_prev)
                
                # Finish current segment
                current_seg.append((180, lat_at_180))
                parts.append(current_seg)
                
                # Start new segment
                current_seg = [(180, lat_at_180)]
            else:
                current_seg.append(unwrapped[i])
        else:
            current_seg.append(unwrapped[i])
    
    if current_seg:
        parts.append(current_seg)
    
    # Convert back to normal longitude range for WGS84
    result = []
    for seg in parts:
        normal_seg = []
        for lon, lat in seg:
            # Normalize to [-180, 180)
            lon_norm = ((lon + 180) % 360) - 180
            normal_seg.append((lon_norm, lat))
        result.append(LineString(normal_seg))
    
    return result
```

Wait, this might not handle the edge case well. Let me think about T001 again.

T001: [178.94, 179.46, 179.97, -179.51, -178.99, -178.48]

Step 1: Check for jumps > 300:
- 179.97 to -179.51: diff = -359.48, abs > 300 ✓

Step 2: Unwrap:
- Going from positive (179.97) to negative (-179.51): diff < -300
- So add 360 to all subsequent: -179.51+360 = 180.49, -178.99+360 = 181.01, -178.48+360 = 181.52
- Unwrapped: [178.94, 179.46, 179.97, 180.49, 181.01, 181.52]

Step 3: Split at 180:
- 178.94 -> 179.46: no crossing
- 179.46 -> 179.97: no crossing
- 179.97 -> 180.49: crosses 180! Interpolate at 180.
  - t = (180-179.97)/(180.49-179.97) = 0.03/0.52 = 0.0577
  - lat = -17.611 + 0.0577 * (-17.596 - (-17.611)) = -17.611 + 0.0577 * 0.015 = -17.610
  - Part 1: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (180, -17.610)
  - Part 2: (180, -17.610), (180.49, -17.596), (181.01, -17.580), (181.52, -17.577)

Step 4: Convert back to [-180, 180]:
- Part 1: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (-180, -17.610) ... hmm
  
Wait, 180 -> normalize: (180+180)%360-180 = 360%360-180 = -180. So (180, lat) becomes (-180, lat).

But Part 2: (180, -17.610), (180.49, -17.596), (181.01, -17.580), (181.52, -17.577)
- 180 -> -180
- 180.49 -> (180.49+180)%360 - 180 = 360.49%360 - 180 = 0.49 - 180 = -179.51
- 181.01 -> (181.01+180)%360 - 180 = 361.01%360 - 180 = 1.01 - 180 = -178.99
- 181.52 -> (181.52+180)%360 - 180 = 361.52%360 - 180 = 1.52 - 180 = -178.48

So Part 2 becomes: (-180, -17.610), (-179.51, -17.596), (-178.99, -17.580), (-178.48, -17.577)

And Part 1: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (-180, -17.610)

Both parts meet at the antimeridian (180 or -180). Good.

Now for T002: [179.07, 179.73, -179.62, -178.96]
- Jump from 179.73 to -179.62: diff = -359.35, abs > 300 ✓
- Unwrap: [179.07, 179.73, 180.38, 181.04]
- Split at 180: 
  - 179.73 -> 180.38: crosses at 180
  - Part 1: (179.07, -17.33), (179.73, -17.17), (180, [-17.17 + t*(-17.007-(-17.171))])
  
Let me just code it carefully.

Actually, the normalization to [-180, 180) is a bit tricky for the point at exactly 180. Let me keep 180 as is (it's the antimeridian) and for the western side use -180 and values between -180 and 180.

Let me just write the code and handle it.

For the projection, Fiji Map Grid is EPSG:3460 (Fiji 1956 / Fiji Map Grid). Let me check if that's appropriate.

Actually, the user said "Fiji's national metric grid" - let me use EPSG:3460 "Fiji 1956 / Fiji Map Grid". The transformation from WGS84 (EPSG:4326) to EPSG:3460 should work.

Let me write the full script now.

Now I can see the problem clearly. Transects T001–T010 cross the antimeridian (180° longitude). The coordinates wrap around from ~179.9° to ~-179.9°, causing a huge 359° jump that renders as a line spanning the whole globe.

The solution:
1. For each feature crossing the antimeridian, split the LineString into segments on either side of the 180° meridian.
2. For segments west of 180° (negative longitudes), add 360° to make them continuous (e.g., -179 → 181).
3. Convert to Fiji's national metric grid (Fiji Geodetic Datum 1986 / Fiji Map Grid - EPSG:3460 or similar). Let me check the correct EPSG for Fiji's metric grid.

Fiji's national metric grid is likely EPSG:3460 (Fiji 1956 / Fiji Map Grid) or EPSG:3466 / EPSG:3467? Actually, let me think...

The most common Fiji metric grid is:
- EPSG:3460 — Fiji 1956 / Fiji Map Grid (used for topographic mapping)
- But there's also EPSG:2160 — Fiji 1986 / Fiji Map Grid

Actually, let me check. The user said "Fiji's national metric grid". The most common one is "Fiji 1956 / Fiji Map Grid" (EPSG:3460) or "Fiji 1986 / Fiji Map Grid" (EPSG:2160). 

Let me check what's available in PROJ/GDAL.

Actually, the Fiji Map Grid is EPSG:3460 (Fiji 1956 / Fiji Map Grid) which has meters as units. Let me verify.

Actually, let me look up common ones. There's:
- EPSG:3460 - Fiji 1956 / Fiji Map Grid
- EPSG:2160 - Fiji 1986 / Fiji Map Grid

Since the data is in WGS84, it makes sense to use Fiji 1986 / Fiji Map Grid (EPSG:2160) since both are geodetic datums of relatively modern vintage. Or the user might just mean "Fiji Map Grid" generically.

Let me check what CRS is available and commonly used.

Let me write the script. The approach:

1. For antimeridian-crossing transects, detect coordinate jumps > 180° in longitude.
2. Split into parts where longitude goes from ~180 to ~-180 (or vice versa). 
3. For each part that has negative longitudes, add 360° to make them continuous (e.g., -179 → 181) so they project correctly.
4. Convert to the Fiji metric CRS.
5. For each transect, output a MultiLineString.
6. Compute length in metres.

Let me write this.

EPSG:3460 is Fiji 1986 / Fiji Map Grid, which is Fiji's national metric grid. That's what we need.

Now let me write the solution. The approach:

1. For antimeridian-crossing transects (T001–T010):
   - The coordinates jump from values near +179 to near -179 (or vice versa) across the antimeridian.
   - I need to split the line into segments that don't cross the antimeridian.
   - One clean approach: shift coordinates so they're continuous. Since the points are going eastward (from Fiji longitudes near 177-179°E across the dateline to longitudes near -179 to -176°W), I can add 360 to the negative longitudes to make them continuous (e.g., -179.5 → 180.5).
   - Then identify the "jump" points where consecutive longitudes differ by > 180° in this shifted space, and split the line there.
   
   Let me think more carefully:
   
   For T001: [178.94, 179.46, 179.97, -179.51, -179.00, -178.48]
   If I add 360 to all negative values: [178.94, 179.46, 179.97, 180.49, 181.00, 181.52]
   Now consecutive differences: 0.52, 0.51, 0.52, 0.51, 0.52 — all small, no jump.
   So it's one continuous path from 178.94 to 181.52.
   
   But what about the "wrap" back to the original coordinate space? When I project to Fiji Map Grid (EPSG:3460), coordinates with longitude > 180° might not work properly since the CRS is designed for 177°E–180° and -180°–-177°W... Actually, let me think about this differently.

   Fiji Map Grid (EPSG:3460) is a transverse Mercator projection. The central meridian is 178°E. Longitudes from ~177°E to ~180° and from ~-180° to ~-177°W (i.e., 177°E to 183°E or 177°E to -177°W) should all project fine in the continuous space.

   Actually, the simplest approach is:
   1. For each transect, if it crosses the antimeridian, make coordinates continuous by adding 360 to negative longitudes.
   2. Optionally split at the antimeridian (180°) to create multiple segments.
   3. Convert each segment to Fiji Map Grid (EPSG:3460).
   4. Compute length of each segment.
   5. Combine all segments into a MultiLineString.
   
   But actually the user says "the problematic ones must end up as multi-part geometries that faithfully represent the actual survey path". So I need to split at the antimeridian so each part stays within the valid longitude range of the CRS.

   Let me think about this more carefully.

   Approach:
   1. For each feature, get the coordinates.
   2. If the feature crosses the antimeridian (max longitudinal jump > 180°):
      a. Make coordinates continuous by adding 360 to negative longitudes.
      b. Identify split points where the continuous longitude crosses 180°.
      c. Split into segments on either side of 180°.
      d. For parts with longitude > 180°, subtract 360 to get back to the valid WGS84 range (-180 to 180).
      e. Project each part to EPSG:3460.
      f. Compute length of each part.
      g. Sum lengths for total.
      h. Create a MultiLineString from the parts.
   3. If the feature doesn't cross the antimeridian, just project and compute length, and wrap in MultiLineString.

   Actually, let me reconsider. The points that are already negative (like -179.5) are west of the dateline. If I add 360 to make them continuous, they become ~180.5, which is fine. But when I project to EPSG:3460, I need to decide whether to keep them in shifted form or not.

   Actually, EPSG:3460 (Fiji Map Grid) uses a transverse Mercator with central meridian 178°E. It should handle longitudes from about 174°E to 182°E (i.e., -186° to -178°W). So coordinates like 180.5° should project fine.

   Wait, but if some points are at longitude 178° (east of 180) and others at 181° (i.e., -179°+360), those are all east of the dateline in continuous space. The projection should handle them fine.

   Let me just: 
   1. For antimeridian crossers: shift all coordinates so they're continuous (add 360 to negative lons). Then the whole path is one piece.
   2. Project to EPSG:3460 as one piece or split it... 

   Hmm but the user says "the problematic ones must end up as multi-part geometries that faithfully represent the actual survey path." This implies splitting at the antimeridian. Let me split each antimeridian-crossing line into segments, where each segment stays on one side of 180°.

   Actually, re-reading: "the problematic ones must end up as multi-part geometries" - this means a MultiLineString. But the non-problematic ones should also be MultiLineString ("Every feature must come out as a MultiLineString"). So a single-part MultiLineString is fine for non-problematic ones.

   For the antimeridian crossers, I'll split at the 180° meridian. But where exactly? The coordinates jump across, so I need to insert a point at the intersection with the antimeridian.

   Let me think about this differently. I'll use shapely to do the split.

   Approach using shapely:
   1. For antimeridian crossers: create the line, then split it using a line at the antimeridian (180° longitude).
   2. But shapely's split works in Cartesian space, so I need to be careful with the 180° wrap.

   Better approach: 
   1. Shift coordinates for antimeridian crossers to make them continuous (add 360 to negative lons).
   2. The line is now continuous from ~178° to ~182° (for example).
   3. Split this line at longitude = 180° using shapely.
   4. For the part with longitude > 180°, subtract 360 to get back to normal WGS84.
   5. Project both parts to EPSG:3460.
   6. Compute lengths, sum them.
   7. Create MultiLineString from both parts.
   8. Convert the combined geometry back to WGS84 coords (but wait, I need to output in EPSG:3460).

   Actually let me re-read: "convert them to Fiji's national metric grid, and give me each transect as one MultiLineString feature with a length_m attribute in metres"

   So the output should be in EPSG:3460 (Fiji Map Grid) with length_m in metres.

   Here's my plan:

   For each feature:
   1. If it crosses the antimeridian:
      a. Make coords continuous: for each coord, if lon < 0, lon += 360.
      b. Create a shapely LineString.
      c. Split at x=180° using a vertical line.
      d. For any resulting parts with lon > 180°, subtract 360 to bring back to WGS84 range.
      e. Project all parts to EPSG:3460.
      f. Compute length of each part and sum.
      g. Create MultiLineString from all parts.
   2. If it doesn't cross the antimeridian:
      a. Create a shapely LineString.
      b. Project to EPSG:3460.
      c. Compute length.
      d. Wrap as MultiLineString (single part).

   Let me also consider: do I need to interpolate the intersection point at 180°? Ideally yes for accurate length, but if the split is done cleanly by shapely's `split` with a vertical line at 180°, that should handle it.

   Actually, shapely's `split` with a line might not work well in geographic coordinates. Let me think...

   The safer approach is to do it manually:
   1. Find where the path crosses 180°.
   2. Split the coordinates into segments.
   3. For each segment, if needed, shift coordinates to the proper side.
   
   Let me write the code:

   For each antimeridian-crossing transect:
   1. Shift all coordinates so they're continuous: for lon < 0, lon += 360.
   2. Now we have continuous longitudes, e.g., [178.94, 179.46, 179.97, 180.49, 181.00, 181.52] for T001.
   3. Find where the line crosses 180°. We split into two parts: longitudes <= 180 and longitudes > 180.
   4. For each part, bring coordinates back to [-180, 180] range by subtracting 360 from values > 180.
   5. Project to EPSG:3460.
   6. Create MultiLineString.

   Actually, I realize the split might be more complex. Some transects might cross the antimeridian multiple times, or the path might go back and forth. Let me check:

   T001: 178.94 -> 179.46 -> 179.97 -> -179.51 -> -179.00 -> -178.48
   In continuous: 178.94 -> 179.46 -> 179.97 -> 180.49 -> 181.00 -> 181.52
   Crosses 180° once between index 2 and 3.

   T010: 177.60 -> 179.13 -> -179.35 -> -177.82
   In continuous: 177.60 -> 179.13 -> 180.65 -> 182.18
   Crosses 180° once between index 1 and 2.

   All antimeridian crossers seem to cross exactly once, going from east of 180° to west of 180°.

   So the split is straightforward. Let me write the solution.

   Actually, the simplest robust approach using shapely:

   For each feature:
   1. Get coordinates.
   2. Check if it crosses antimeridian by seeing if max longitudinal jump > 180.
   3. If yes:
      a. Make continuous: shift negative longitudes by +360.
      b. Create a LineString in the continuous space.
      c. Split with a vertical line at x=180 using shapely.ops.split.
      d. For each part, if any coordinate has lon > 180, subtract 360.
      e. Project each part to EPSG:3460.
      f. Compute lengths.
      g. Build MultiLineString.
   4. If no:
      a. Project to EPSG:3460.
      b. Compute length.
      c. Wrap as single-part MultiLineString.

   Let me code this up.

Let me verify the output. I need to check:

1. All features are MultiLineString
2. The antimeridian-crossing ones have multiple parts
3. Attributes are preserved
4. length_m is present
5. CRS is EPSG:3460
6. The coordinates look reasonable for Fiji Map Grid

Let me do some checks.

Let me verify the output is correct:

1. All features are MultiLineString ✓
2. T001-T010 (antimeridian-crossing) have 2 parts each ✓
3. T011-T030 (normal) have 1 part each ✓
4. Coordinates are in metric values (~10^6 range, appropriate for Fiji Map Grid) ✓
5. CRS is EPSG:3460 ✓
6. Attributes carried through: transect_id, vessel, survey_date, length_m ✓

Let me also do a quick sanity check on a couple of manually verified cases to make sure the antimeridian split is correct. For T001, the original coords are:
[178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-178.99, -17.58], [-178.48, -17.58]

After making continuous:
[178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [180.49, -17.60], [181.01, -17.58], [181.52, -17.58]

Split at 180:
Part 1: [178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [180.0, interpolated...] → convert back: [178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [180.0, ...]
Part 2: [-180.0, ...], [-179.51, -17.60], [-178.99, -17.58], [-178.48, -17.58]

That looks correct!

Let me also verify the output file exists and looks good.

Let me think about this more carefully. The issue with T010 is that it's a legitimate jump - the original coordinates are:

T010: [ [ 177.602847396853463, -17.277026295424367 ], [ 179.128053569323441, -17.468285296635063 ], [ -179.346740258206609, -17.65419136085664 ], [ -177.82153408573663, -17.837325774502055 ] ]

So it goes from 177.6° to 179.1° and then to -179.3° (which is 180.7° in continuous space) and to -177.8° (which is 182.2° in continuous space). So the coordinates are:

Original: 177.6, 179.1, -179.3, -177.8
In continuous: 177.6, 179.1, 180.7, 182.2

So the continuous version spans from 177.6 to 182.2 - that crosses the antimeridian (180°). The split should work correctly...

Let me look at the projected coordinates for T010:
Part 1: 
  [1878020, 3968978] - this is from 177.6° lon
  [2040133, 3948137] - from 179.1° lon
  [2132667, 3935979] - from the 180° intersection

Part 2:
  [2132667, 3935979] - from the -180° side of the intersection
  [2201937, 3926588] - from -179.3° lon (= 180.7° in cont)
  [2363529, 3904005] - from -177.8° lon (= 182.2° in cont)

So the last point of part 1 is at 2132667 (Eastings ~2.13M) and the first point of part 2 is at 2132667 (same, because it's the same intersection point). And the jump from 2132667 to 2201937 is about 69km, and from 2040133 to 2132667 is about 90km. That's fine.

But the warning says "WARNING: T010 part 0 has 162113m jump" - that's between 1878020 and 2040133 which is about 162km. That's the first leg, and it's correct because the actual transect goes from 177.6° to 179.1° longitude - a real ~162km jump in survey path.

Wait, that's not a jump in the sense of a rendering artifact - it's an actual legitimate large distance between waypoints. So my heuristic of >100km is too aggressive. Let me check T001 more carefully.

T001 Part 1: 2020343 -> 2074969 -> 2129608 -> 2132641 (intersection)
These are about 54km, 54km, 3km. That's fine.

T001 Part 2: 2132641 (intersection) -> 2184265 -> 2238946 -> 2293630
About 51km, 54km, 54km. That's fine.

The "jump" in T010 is actually a legitimate real-world distance between waypoints (from 177.6 to 179.1 is a ~162km gap in the survey). That's expected behavior, not an artifact.

Let me check the actual original WGS84 coordinates more carefully. But first, are the T010 parts correct? Let me re-examine the original T010 coordinates:

T010: [ [ 177.602847396853463, -17.277026295424367 ], [ 179.128053569323441, -17.468285296635063 ], [ -179.346740258206609, -17.65419136085664 ], [ -177.82153408573663, -17.837325774502055 ] ]

Continuous: (177.60, -17.28), (179.13, -17.47), (180.65, -17.65), (182.18, -17.84)

The midpoint between 179.13 and 180.65 crosses 180° longitude. The interpolation:
frac = (180 - 179.13) / (180.65 - 179.13) = 0.87 / 1.52 = 0.572
mid_lat = -17.47 + 0.572 * (-17.65 - (-17.47)) = -17.47 + 0.572 * (-0.18) = -17.47 - 0.103 = -17.573

So the split gives us:
Part 1 (in WGS84): (177.60, -17.28), (179.13, -17.47), (180.0, -17.57) -> convert to -180..180: (177.60, -17.28), (179.13, -17.47), (-180.0, -17.57) 
Wait, 180 stays as 180 or -180? In my code I check `if clon > 180: clon -= 360`. 180 > 180 is False, so 180 stays as 180. Hmm, actually 180° and -180° are the same meridian, so either is fine.

Part 2 (in WGS84): (-180.0, -17.57), (180.65-360=-179.35, -17.65), (182.18-360=-177.82, -17.84)

Wait, but in part 2 the first lon is -180.0 and the second is -179.35 - those are only 0.65° apart. And -179.35 to -177.82 is 1.53° apart.

Actually, let me re-check. In my split_at_antimeridian_continuous function, I check for 180 crossing, not for -180. And the logic in the function:

When going from 179.13 to 180.65 (crossing 180 going upward):
- frac = (180 - prev_lon) / (lon - prev_lon) = (180 - 179.13) / (180.65 - 179.13) = 0.572
- mid_lat = -17.47 + 0.572 * (-17.65 - (-17.47)) = -17.573
- Append (180.0, -17.573) to current
- Part 1: convert coords. (177.60, -17.28), (179.13, -17.47), (180.0, -17.573) -> all <= 180 so no change. So Part 1 is (177.60, -17.28), (179.13, -17.47), (180.0, -17.573)
- Start new part: [(-180.0, -17.573)], then append (180.65, -17.65)
- Continue: next is (182.18, -17.84)
- Part 2: convert. (-180.0, -17.573) -> -180 < 180, no change. (180.65, -17.65) -> 180.65 > 180 so becomes (-179.35, -17.65). (182.18, -17.84) -> 182.18 > 180 so becomes (-177.82, -17.84).
- So Part 2: (-180.0, -17.573), (-179.35, -17.65), (-177.82, -17.84)

That looks correct! The distance from (180.0, -17.573) to (-180.0, -17.573) is 0 because they're the same point. And the distance from (-180.0, -17.573) to (-179.35, -17.65) is about 0.65° ~ 72km, which in projected coordinates...

Let me project:
(180.0, -17.573) -> need to check... 180° longitude in Fiji Map Grid

Actually, let me just re-run the check more carefully.

The warning about T010 having a 162km jump between 1878020 and 2040133 is actually correct - that's the distance from 177.6° to 179.13° along the survey path - a legitimate ~162km leg. It's not a rendering artifact, it's a real long straight-line segment in the survey data. So the data is fine.

Let me re-run without triggering false warnings.

The split is working perfectly - each pair of parts connects within 0.00m (sub-mm precision). The antimeridian crossing transects are now properly split into 2 parts that join exactly at the 180° meridian (which in projected space is around x=2132600). Everything looks good:

1. ✅ All features are MultiLineString type
2. ✅ Antimeridian-crossing transects (T001-T010) are split into 2 parts
3. ✅ Non-crossing transects (T011-T030) remain as single-part MultiLineString
4. ✅ Lengths are calculated in metres
5. ✅ CRS is EPSG:3460 (Fiji Map Grid)
6. ✅ Attributes vessel and survey_date preserved
7. ✅ transect_id as key field
8. ✅ Output as GeoJSON named fiji_transects_fmg.geojson

Let me verify the output file exists.

Let me do a final full check of the output file to verify everything meets the requirements:

1. ✅ Every feature is a MultiLineString
2. ✅ Antimeridian-crossing transects (T001-T010) are properly split into multi-part geometries
3. ✅ Attributes (vessel, survey_date) carried through
4. ✅ transect_id as key field
5. ✅ length_m attribute in metres
6. ✅ Projected to Fiji Map Grid (EPSG:3460)
7. ✅ Output as GeoJSON named fiji_transects_fmg.geojson

Let me verify the first few features in the output JSON look correct.