crs-l2-fiji-antimeridian

Rerun

Let me analyze the problem. Several transects cross the antimeridian (180° longitude), and their coordinates go from positive longitudes (e.g., 179.xxx) to negative longitudes (e.g., -179.xxx). When plotted naively, these lines would wrap around the entire globe instead of crossing the dateline locally.

For Fiji, the appropriate projected coordinate system would be the Fiji Map Grid (FMG), which is EPSG:3460 (Fiji 1956 / Fiji Map Grid) or more likely EPSG:3460. Let me check what's appropriate.

Actually, the Fiji Map Grid (FMG) is EPSG:3460. But there's also EPSG:3139 (Fiji 1956 / Fiji Map Grid) and the newer EPSG:1500 (Fiji Geodetic Datum 1998 / Fiji Map Grid).

The standard Fiji Map Grid uses EPSG:3460 (Fiji 1956 / Fiji Map Grid). Let me verify.

Actually, let's look this up. The key CRS for Fiji:
- EPSG:3460 = Fiji 1956 / Fiji Map Grid
- EPSG:3139 = also Fiji 1956 / Fiji Map Grid (actually I think 3460 is the one)

Let me check. EPSG:3460 is "Fiji 1956 / Fiji Map Grid" and uses meters.

Now the problem: coordinates that cross the antimeridian. For example, T001:
[178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-178.99, -17.58], [-178.48, -17.58]

When these go from 179.97 to -179.51, the software might try to draw a line that goes all the way across the globe (e.g., going from 179.97 eastward through 180 to -179.51, which is a very short distance), OR it might go the wrong way (westward through 0°, wrapping the entire globe).

The fix is to adjust the longitudes so they are continuous - typically by adding 360 to the negative longitudes when they appear after positive ones, or using a method to normalize the coordinates.

For transects like T001 that cross the antimeridian, the coordinates go from positive (east of 180) to negative (west of 180). The actual path crosses the dateline locally. So we need to adjust the negative longitudes by adding 360 to make them continuous.

For example, T001 adjusted:
178.94, 179.46, 179.97, then -179.51 becomes 180.49 (since -179.51 + 360 = 180.49), -178.99 becomes 181.01, -178.48 becomes 181.52

This way the coordinates are continuous and don't wrap around the globe.

But then we need to project this to FMG. Since FMG is centered on Fiji (roughly 177°E), coordinates up to 181.52 should still project fine since the UTM zone covers appropriate area.

Let me write a Python script to handle this.

Actually, let me think more carefully. The approach:

1. For each feature, check if it crosses the antimeridian (the flag `crosses_antimeridian_flag` is True for those that do).
2. For those that cross, split the line into segments at the antimeridian and create a MultiLineString.
3. For those that don't cross, keep as a single LineString (but convert to MultiLineString with one part).
4. Project all to FMG (EPSG:3460).
5. Calculate length in metres.
6. Write as GeoJSON.

But wait - "faithfully represent the actual survey path". The issue is that when you project the continuous coordinates (with adjusted longitudes +360), the projected shape will be correct because it will be a continuous line in the projected space. But if we split at the antimeridian, we get multiple segments.

Let me think about this differently. 

Option A: Adjust the longitudes to be continuous (add 360 to negative values after crossing), then project, then the line is continuous in projected space.
Option B: Split at the antimeridian into segments, project each segment, then combine into MultiLineString.

Option A is simpler and produces a single LineString (which we'd then convert to MultiLineString with one part). But does it "faithfully represent the actual survey path"? The projected coordinates would be correct since the coordinates are continuous.

Actually, looking at it more carefully, the problem statement says:
- "fix the geometries so they render correctly"
- "the problematic ones must end up as multi-part geometries that faithfully represent the actual survey path"

So they want the antimeridian-crossing ones to be split into multiple parts (a MultiLineString where each segment is on one side of the dateline, and they connect properly).

Let me go with splitting at the antimeridian.

Actually wait, let me re-read: "Every feature must come out as a MultiLineString, so do not leave any transects as plain LineString"

So ALL features need to be MultiLineString. For non-crossing ones, it's a MultiLineString with a single LineString. For crossing ones, it's split at the antimeridian into multiple LineStrings.

Let me think about how to split at the antimeridian (180° longitude).

For a line that goes from 179.97 to -179.51 (which is 180.49 after adjustment), the actual path crosses the 180° meridian. We need to split the line at the 180° meridian.

The algorithm:
1. For each pair of consecutive coordinates, check if the segment crosses the antimeridian.
2. A segment crosses the antimeridian if the longitude difference between the two points is more than 180° in absolute value (or if one is positive and the other negative, with a large gap).
3. If it crosses, split the segment at the antimeridian (interpolate the intersection point).
4. Collect all segments on either side.

Let me write the script.

For the projection, I'll use EPSG:3460 (Fiji 1956 / Fiji Map Grid). Let me verify this is correct.

Actually, let me check what CRS is available in pyproj for Fiji.

Let me just write the code and test it.

Here's my approach:

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

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

# Define CRS
wgs84 = pyproj.CRS('EPSG:4326')
fmg = pyproj.CRS('EPSG:3460')  # Fiji 1956 / Fiji Map Grid

# Projection function
project = pyproj.Transformer.from_crs(wgs84, fmg, always_xy=True)

def split_at_antimeridian(coords):
    """Split a list of coordinates at the antimeridian (180°).
    Returns a list of lists of coordinates (each sublist is one continuous segment)."""
    if len(coords) < 2:
        return [coords]
    
    segments = []
    current_segment = [coords[0]]
    
    for i in range(1, len(coords)):
        lon1, lat1 = coords[i-1]
        lon2, lat2 = coords[i]
        
        # Check if this segment crosses the antimeridian
        # If the longitude jump is > 180 in absolute value, it crosses
        lon_diff = lon2 - lon1
        if abs(lon_diff) > 180:
            # Normalize the direction
            if lon_diff > 0:
                # Crossing from west to east (e.g., -179 to 179)
                # The actual crossing is at lon=180
                # Interpolate the point where lon=180
                t = (180 - lon1) / (lon2 - lon1)  # This should be between 0 and 1
                # Actually if lon1 is -179 and lon2 is 179, then lon_diff = 358
                # t = (180 - (-179)) / 358 = 359/358 ≈ 1.003
                # Hmm that's wrong. Let me think again.
                
                # Actually, if we go from -179 to 179 (crossing the dateline westward... no, eastward?)
                # Let me just use the approach of adding/subtracting 360.
                
                # Actually, the crossing direction depends on the actual survey path.
                # For our data, the crossing goes from positive to negative (e.g., 179.97 to -179.51)
                # This means crossing the dateline from east to west.
            else:
                # Crossing from east to west (e.g., 179 to -179)
                pass
        else:
            current_segment.append(coords[i])
    
    # ...
```

Let me think more carefully. For our data, the antimeridian-crossing transects go from positive longitudes to negative longitudes. For example:

T001: 178.94, 179.46, 179.97, -179.51, -179.00, -178.48

The actual path goes from ~179°E to ~178°W, crossing the 180° meridian. The jump from 179.97 to -179.51 is actually a small jump (about 0.52° of longitude) crossing the dateline.

To detect this crossing, I check if abs(lon2 - lon1) > 180 (since 179.97 to -179.51 has a diff of about 359.48, which is > 180).

When this happens, I need to split the segment at the antimeridian. The intersection point is where the line crosses 180° longitude.

For the segment from (lon1, lat1) to (lon2, lat2) crossing the dateline:
- If lon1 is positive and lon2 is negative (crossing east to west):
  The adjusted lon2 should be lon2 + 360 for continuous coordinates.
  The parameter t where longitude = 180: t = (180 - lon1) / ((lon2 + 360) - lon1)
  The latitude at the crossing: lat = lat1 + t * (lat2 - lat1)
  The crossing point is (180, lat)

Wait, but I also need to handle the case where both points are on the same side but the segment still crosses. Actually, with our data, the crossing is always from positive to negative (or vice versa).

Actually, let me use a simpler approach. Instead of splitting at the antimeridian first, let me:

1. For each feature, check if it crosses the antimeridian (flag is True or we detect the crossing).
2. If it does, adjust the coordinates to be continuous (add 360 to negative longitudes after the crossing).
3. Split the continuous line into segments at the antimeridian (where longitude passes through 180).
4. For non-crossing features, just wrap as MultiLineString directly.

Let me just write the complete script.

Actually, I think the cleanest approach is:

For each feature with coordinates:
1. Process all coordinate pairs to detect antimeridian crossings.
2. When a crossing is detected, interpolate the intersection with the 180° meridian.
3. Build segments: each segment stays on one side of the antimeridian.
4. Create a LineString for each segment.
5. Create a MultiLineString from all segments.
6. Project to FMG and calculate length.

Let me code this properly.

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

# Read the GeoJSON
with open('/work/fiji_transects_wgs84.geojson') as f:
    data = json.load(f)

wgs84 = pyproj.CRS('EPSG:4326')
fmg = pyproj.CRS('EPSG:3460')  # Fiji 1956 / Fiji Map Grid
transformer = pyproj.Transformer.from_crs(wgs84, fmg, always_xy=True)

def interpolate_at_meridian(lon1, lat1, lon2, lat2, meridian=180.0):
    """Find the intersection point of a segment with a meridian."""
    # Adjust the longitudes so the segment is continuous
    if abs(lon2 - lon1) > 180:
        if lon1 < 0:
            lon1_adj = lon1 + 360
        else:
            lon1_adj = lon1
        
        if lon2 < 0:
            lon2_adj = lon2 + 360
        else:
            lon2_adj = lon2
    else:
        lon1_adj = lon1
        lon2_adj = lon2
    
    # Now find t where longitude = meridian
    # For the crossing from lon1->lon2, we want the point at meridian
    # But if we're going from >180 to <180 or vice versa, we need to handle correctly
    
    # Actually, let's think about this differently.
    # If lon1_adj <= meridian <= lon2_adj or lon2_adj <= meridian <= lon1_adj:
    # Then the segment crosses the meridian.
    
    if lon1_adj == lon2_adj:
        return None
    
    t = (meridian - lon1_adj) / (lon2_adj - lon1_adj)
    
    if 0 <= t <= 1:
        lat = lat1 + t * (lat2 - lat1)
        return (meridian, lat)
    return None

def split_line_at_antimeridian(coords):
    """Split a sequence of coordinates at the 180° meridian.
    Returns a list of coordinate lists, each representing a continuous segment."""
    if len(coords) < 2:
        return [coords]
    
    segments = []
    current_segment = [coords[0]]
    
    for i in range(1, len(coords)):
        lon1, lat1 = coords[i-1]
        lon2, lat2 = coords[i]
        
        # Check if this segment crosses the antimeridian
        lon_diff = lon2 - lon1
        
        # Normalize to [-180, 180] range for detection
        # A crossing happens when the straight-line difference > 180
        if abs(lon_diff) > 180:
            # Crosses the antimeridian
            # Find intersection with 180° meridian
            inter = interpolate_at_meridian(lon1, lat1, lon2, lat2, 180)
            if inter:
                # End current segment at the intersection
                current_segment.append(inter)
                segments.append(current_segment)
                # Start new segment
                current_segment = [inter, coords[i]]
            else:
                current_segment.append(coords[i])
        else:
            current_segment.append(coords[i])
    
    if current_segment:
        segments.append(current_segment)
    
    return segments

# Actually, let me think about this more carefully.
```

Hmm, let me re-think. For coordinates like:
[179.97, -17.61] to [-179.51, -17.60]

The segment goes from 179.97°E to 179.51°W (which is -179.51°). The actual path crosses the 180° meridian.

Using adjusted coordinates:
- lon1 = 179.97, lat1 = -17.61
- lon2_adj = -179.51 + 360 = 180.49, lat2 = -17.60

The segment from (179.97, -17.61) to (180.49, -17.60) is a short segment that crosses 180°.

The intersection point with 180° meridian:
t = (180 - 179.97) / (180.49 - 179.97) = 0.03 / 0.52 ≈ 0.0577
lat = -17.61 + 0.0577 * (-17.60 - (-17.61)) = -17.61 + 0.0577 * 0.01 = -17.6094

So the intersection point is (180, -17.6094).

Now for the segments:
- Segment 1: from (179.97, -17.61) to (180, -17.6094) - this is on the East side (positive longitudes)
  But wait, longitude 180 is the antimeridian itself. Which side does it belong to?
  
  Let me split so that the first segment ends at (180, lat) and the second starts at (180, lat).
  
  Actually, for the projected coordinates, points at 180° longitude are at the edge of the projection. Let me see what EPSG:3460 does with 180°.

Actually, I think a simpler approach is:

1. Adjust all coordinates to be continuous (add 360 to negative longitudes when they appear after positive ones in a crossing).
2. Project to FMG.
3. The projected coordinates will be correct and continuous.
4. Create a single LineString from the projected coordinates.
5. Wrap in MultiLineString.

But the problem says "the problematic ones must end up as multi-part geometries that faithfully represent the actual survey path." This suggests they want the MultiLineString to have parts that correspond to segments on either side of the dateline.

Let me go with the splitting approach.

Actually, maybe even simpler: I can use Shapely's `intersection` with a bounding box or with a polygon that covers the eastern hemisphere and the western hemisphere separately.

Let me think about this differently.

A clean approach:
1. For each line, if it crosses the antimeridian, split it at 180°.
2. Create LineStrings for each segment.
3. Combine into MultiLineString.
4. Project to FMG.
5. Calculate total length.

For the splitting, I'll use a simple algorithm:
- Iterate through coordinate pairs
- If crossing detected, interpolate intersection with 180°, split the line there

Let me write a complete script now.

Actually, I just realized there's an even simpler approach using geopandas and shapely. I can:

1. For each feature, create a LineString from the coordinates.
2. Use `shapely.ops.split` or manually split at the antimeridian.
3. Or alternatively, just adjust the coordinates to make them continuous, project, and then create MultiLineString with one part.

Let me go with the coordinate adjustment + projection approach. It's the most straightforward.

For antimeridian-crossing features:
- Iterate through coordinates
- Keep track of an offset (0 or 360)
- When a crossing is detected (abs diff > 180), toggle the offset
- Apply the offset to each coordinate

Wait, actually the offset approach is simpler. Let me think...

For T001: [178.94, 179.46, 179.97, -179.51, -179.00, -178.48]
- Start with offset = 0
- 178.94 (offset 0) -> 178.94
- 179.46 (offset 0) -> 179.46 (diff = 0.52, < 180, ok)
- 179.97 (offset 0) -> 179.97 (diff = 0.51, < 180, ok)
- -179.51 (offset 0? diff = -179.51 - 179.97 = -359.48, abs > 180!) -> crossing detected!
  We need to add 360 to this and subsequent coordinates
  So: -179.51 + 360 = 180.49, and offset becomes 360
- -179.00 (offset 360) -> 180.00 (wait, -179 + 360 = 181, hmm no: -179.00 + 360 = 181.00)
- -178.48 (offset 360) -> 181.52

Wait, -179.00 + 360 = 181.00? No: -179 + 360 = 181. Yes, 181°E.

So continuous coordinates: [178.94, 179.46, 179.97, 180.49, 181.00, 181.52]

These are all > 175 and < 182 roughly, which should project fine in Fiji's metric grid.

For non-crossing features, just use the coordinates as-is.

Then for all features:
1. Create LineString from (adjusted) coordinates.
2. Project to FMG.
3. Calculate length.
4. Wrap in MultiLineString.

Wait, but the requirement says "the problematic ones must end up as multi-part geometries". So for crossing ones, they should be split at the antimeridian.

OK let me split at the antimeridian. Here's my plan:

1. For each feature:
   a. Check if it crosses the antimeridian (from the flag or by detecting large longitude jumps)
   b. If it does:
      - Split the line at 180° longitude
      - Create LineStrings for each segment (east side and west side)
      - Combine into MultiLineString
   c. If it doesn't:
      - Create a single LineString
      - Wrap in MultiLineString with one part

2. For each part of each feature:
   - Project to FMG
   
3. Calculate total length in metres from projected coordinates.

4. Write to GeoJSON.

For the splitting:

Let me iterate through coordinates. For each pair, if they cross the antimeridian, I interpolate the intersection point. The segments before and after the intersection go into different parts.

For T001: 
coords: [(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):
- This crosses the antimeridian
- Interpolate: lon goes from 179.97 to 180.49 (adjusted), crossing at 180
  t = (180 - 179.97) / (180.49 - 179.97) = 0.03/0.52 = 0.0577
  lat = -17.61 + 0.0577 * (-17.60 + 17.61) = -17.61 + 0.0577 * 0.01 = -17.6094
  Intersection at (180, -17.6094)

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)]

Then project each segment and create a MultiLineString.

But wait - when I project the west side coordinates (180 to -178.48), the point at 180 is at the very edge. In the projected CRS, 180° longitude might be at the edge of the valid area. The coordinates -178.48 to 180 in the western hemisphere... 

Actually, in EPSG:3460 (Fiji Map Grid), the projection is a Transverse Mercator centered around 177°E (or some central meridian for Fiji). Points at 180° longitude should project fine. Points at -178° longitude (which is 182°E) also project fine.

But wait, for the west side segment, the coordinates go from 180 to -178.48. In the projected space, these are continuous and fine.

Let me just code this up.

Actually, I realize another approach: instead of splitting, I can use a bounding box or clip approach. But let me just go with the interpolation approach.

Let me write the script now.

Let me check the available Fiji CRS options. I know EPSG:3460 is Fiji 1956 / Fiji Map Grid. Let me also check EPSG:3141 or other Fiji projections.

Let me also figure out the antimeridian issue. The problem is that when lines cross the 180° meridian, the longitude values jump from ~179.97 to ~-179.99 (or similar), but when rendered on a typical map, the software might connect them by going all the way around the world instead of crossing the dateline locally.

The fix is to:
1. For lines that cross the antimeridian, split them into segments at the 180° meridian
2. Each segment will have coordinates that stay on one side of the dateline
3. Then project to Fiji Map Grid
4. Calculate lengths

Let me look at which CRS is the Fiji Map Grid.

EPSG:3460 - Fiji 1956 / Fiji Map Grid - this seems to be the classic Fiji Map Grid.

Let me also check what CRS is commonly used for Fiji Map Grid. The Fiji Map Grid is based on the Clarke 1880 ellipsoid with a Hotine Oblique Mercator (also known as Rectified Skew Orthomorphic) projection.

Actually, looking at the problem more carefully:

The coordinates that cross the antimeridian have longitudes like:
- 178.94, 179.46, 179.97, -179.51, -179.00, -178.48

So the line goes from east of 180° (179.97) to west of 180° (-179.51). This is a short hop across the dateline but when the software connects them it goes the long way around.

The solution is to identify where the longitude jump is > 180° (or < -180°) and split the line at that point, adding vertices at the antimeridian (180° or -180°).

Let me write a comprehensive Python script.

Let me understand the problem. The lines that cross the antimeridian (180° longitude) have longitude values that cross from positive (e.g., 179.9) to negative (e.g., -179.9). When rendered in a standard web map or in a projected CRS, the lines will go "the long way around" because the coordinate system thinks -179.9 is at 179.9 degrees west when it's really at 180.1 degrees east.

The fix is to adjust the longitudes so they are continuous - for lines crossing the antimeridian, we need to shift the longitudes on the negative side by adding 360° (or shift the positive side by subtracting 360°).

Let me look at the data more carefully to understand each transect:

Transects flagged as crossing the antimeridian (T001-T010):

**T001**: 178.94, 179.46, 179.97, **-179.51**, -179.00, -178.48
- The jump from 179.97 to -179.51 means the line wraps around the globe. To fix, add 360 to the negative values: 179.97 → 180.49, 180.0, 181.52... wait no.

Let me think about this differently. For T001:
- Points: [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 line goes from 178.94°E to 179.46°E to 179.97°E to -179.51° (which is 180.49°E) to -179.00° (181.00°E) to -178.48° (181.52°E).
- Wait, -179.51° is actually 180.49°E in continuous terms. So the line goes from 178.94° to 181.52°.

Actually, the problem is that these coordinates cross the 180° meridian. In WGS84, longitudes are normally -180 to 180. But survey lines that cross the dateline have coordinates like 179.97 (near 180°E) followed by -179.51 (which is 180.49°E, or 179.51°W).

To make them render correctly, we need to "unwrap" the longitudes so they are continuous. Specifically:
- For points with longitude < 0 (west of the prime meridian), if they are part of a line that crosses the antimeridian from east to west, we should add 360 to make them continuous.

Let me think about T001 more carefully:
- It goes: 178.94, 179.46, 179.97, -179.51, -179.00, -178.48
- These are in order: 178.94°E → 179.46°E → 179.97°E → 180.49°E (i.e., -179.51°W + 360) → 181.00°E → 181.52°E
- But wait, after 179.97°, the next point is -179.51°. Since we're going eastward, -179.51° = 180.49°E. So continuous: 178.94, 179.46, 179.97, 180.49, 181.00, 181.52.

But 181.52° is beyond 180°, so in EPSG:4326 that's not valid. We need to split the line at the 180° meridian.

The approach:
1. Find points where longitude jumps significantly (e.g., from ~180 to ~-180 or vice versa)
2. Split the line at the antimeridian
3. For each segment, adjust longitudes to be continuous (add 360 to negative values on the east side, leave as-is on the west side)
4. Also compute intersection points with the antimeridian

Actually, a simpler approach used by many GIS tools (like `shapely.ops.split`) is:

For lines crossing the antimeridian:
1. Shift all longitudes so that the line is continuous (no wrap-around)
2. Split at the antimeridian
3. Create separate parts and adjust coordinates back to valid WGS84 ranges

Let me think about this more carefully.

For T001, the coordinates are:
[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 jump is between 179.97 and -179.51. The difference is 179.97 - (-179.51) = 359.48, which means the line goes the long way. To fix, we need to add 360 to all negative longitudes (or all longitudes after the jump).

More precisely: when going eastward across the antimeridian, the longitude changes from +179.97 to -179.51 (which is actually 180.49). So we need to add 360 to the negative values: -179.51 + 360 = 180.49, -179.00 + 360 = 181.00, -178.48 + 360 = 181.52.

But wait, some of these lines might cross the antimeridian from west to east (going west). Let me check T010:
[177.60, -17.28], [179.13, -17.47], [-179.35, -17.65], [-177.82, -17.84]
Going from 179.13 to -179.35. That's a jump of 358.48. To make continuous: -179.35 + 360 = 180.65, -177.82 + 360 = 182.18.

But actually, wait. Let me reconsider. For T010:
177.60 → 179.13 → -179.35 → -177.82

The longitude goes: 177.60 → 179.13 (eastward) → then jumps to -179.35 which is ~180.65°E (eastward) → -177.82 which is ~182.18°E (eastward).

So yes, the line goes eastward all the way, crossing the 180° meridian.

For T003:
[177.64, -17.36], [178.46, -17.42], [179.29, -17.47], [-179.89, -17.53], [-179.06, -17.59]
Going: 177.64 → 178.46 → 179.29 → -179.89 (=180.11°E) → -179.06 (=180.94°E)
All eastward. So we add 360 to the negative values.

For 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]
179.54 → -179.79 (=180.21°E) → ... → -177.78 (=182.22°E). Add 360 to all negative values.

For T005:
[177.60, -17.92], [178.16, -18.01], [178.72, -18.10], [179.29, -18.18], [179.85, -18.27], [-179.58, -18.36], [-179.02, -18.44]
179.85 → -179.58 (=180.42°E) → -179.02 (=180.98°E). Add 360 to negatives.

For T006:
[178.62, -18.38], [179.21, -18.18], [179.79, -17.99], [-179.63, -17.79], [-179.04, -17.60], [-178.46, -17.39], [-177.88, -17.20]
179.79 → -179.63 (=180.37°E) → ... → -177.88 (=182.12°E)

For T007:
[177.92, -17.15], [178.70, -17.10], [179.47, -17.05], [-179.75, -17.00], [-178.97, -16.96], [-178.19, -16.91]
179.47 → -179.75 (=180.25°E) → ... → -178.19 (=181.81°E)

For T008:
[179.40, -17.93], [179.67, -17.90], [179.95, -17.86], [-179.78, -17.81], [-179.51, -17.77], [-179.23, -17.72]
179.95 → -179.78 (=180.22°E) → -179.51 (=180.49°E) → -179.23 (=180.77°E)

For T009:
[178.07, -16.66], [178.56, -16.69], [179.05, -16.72], [179.55, -16.75], [-179.96, -16.78], [-179.47, -16.80]
179.55 → -179.96 (=180.04°E) → -179.47 (=180.53°E)

Now let me think about the approach. When we split at the antimeridian (180°), each part that is east of 180° gets its longitude reduced by 360 (back to valid WGS84 range -180 to 180). Each part that is west of 180° stays as-is.

Actually, a cleaner approach:

1. For each line, check if it crosses the antimeridian (absolute longitude difference between consecutive points > some threshold like 180°).
2. If it does, shift all longitudes by adding/subtracting 360 to make the line continuous.
3. Split the line at the 180° meridian.
4. For each resulting segment, shift coordinates back to valid WGS84 range (-180 to 180).
5. Project to Fiji Map Grid.
6. Compute length.

But actually, I think there's an even simpler approach using shapely's `intersection` and a bounding box. Let me think...

Actually, the standard approach for antimeridian handling in shapely:

1. Create a copy of the geometry where we shift the longitudes to make them continuous (by adding 360 to negative longitudes for lines that cross the antimeridian).
2. Create a "splitter" geometry (a line along the antimeridian).
3. Split the shifted geometry with the splitter.
4. Shift the resulting parts back.

Let me write a comprehensive script.

Actually, I think the cleanest approach is:

For each geometry:
1. Detect if it crosses the antimeridian.
2. If yes, "unwrap" the longitudes by adding 360 to all coordinates where the longitude is negative (this makes them continuous eastward).
3. Create a copy also shifted by subtracting 360 (for continuity westward).
4. Actually, let me think about this more carefully.

The key insight: We have a line that goes from, say, 178°E to 182°E (which is -178°W in WGS84). When we look at the raw coordinates, it appears as 178 → 179 → 180 → -179 → -178. The system interprets this as going from 178 eastward past 180 to -179 (which is actually 181) to -178 (which is actually 182).

To fix this properly, I need to:
1. Detect which direction the line crosses the antimeridian.
2. Create a continuous version where longitudes don't wrap (so add 360 to negative longitudes for eastward-crossing lines).
3. Intersect this with the antimeridian to split into segments.
4. Shift each segment back to valid WGS84 range.

Let me write a Python script using shapely.

Actually, let me look at how this is typically done. The `shapely.geometry.box` for the valid WGS84 range would be (-180, -90, 180, 90). But that doesn't directly help.

Let me use a different approach:

For lines crossing the antimeridian, I'll:
1. Unwrap the longitudes (make them continuous) by adding 360 to all longitudes < 0.
2. Then create a splitter line along the antimeridian (180° longitude).
3. Use `shapely.ops.split` to split the unwrapped line at the antimeridian.
4. For each resulting part, shift longitudes > 180 back by subtracting 360 (to get into -180 to 180 range).
5. Parts with longitudes <= 180 stay as-is.
6. Also handle the case where the line crosses the antimeridian going westward (by subtracting 360 from positive longitudes first).

Wait, let me think more carefully. The coordinates in the file are all in WGS84 (-180 to 180). For lines that don't cross the antimeridian, they render fine. For lines that do cross, the renderer connects the dots the "short way" across the map, resulting in a line wrapping around the globe the wrong way.

OK, let me just write a practical script. The approach:

1. For each transect, check if it crosses the antimeridian (there's a jump in longitude > ~300° between consecutive points).
2. If yes, create a "unwrapped" version where:
   - For eastward-crossing lines (going from positive to negative through 180): add 360 to all longitudes < 0
3. Split this unwrapped line at the antimeridian (longitude=180) using intersection.
4. For each part, if any longitude > 180, subtract 360.
5. Convert to MultiLineString.
6. Project to Fiji Map Grid and compute length.

Let me code this up properly.

Actually, there's an even simpler and more robust approach. The `shapely.ops.transform` function can be used to transform coordinates. And `shapely.ops.split` can split a line by a point or line.

Let me just write the script:

```python
import json
import geopandas as gpd
import shapely
from shapely.geometry import LineString, MultiLineString, Point, box, shape
from shapely.ops import split, transform
from shapely import wkt
import pyproj
from functools import partial
import math

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

# Define projections
wgs84 = pyproj.CRS('EPSG:4326')
fmg = pyproj.CRS('EPSG:3460')  # Fiji 1956 / Fiji Map Grid

projector = pyproj.Transformer.from_crs(wgs84, fmg, always_xy=True).transform

def unwrap_longitude(geom, direction='east'):
    """Unwrap longitudes by adding 360 to negative values."""
    def unwrap_coords(coords):
        x, y = coords
        if direction == 'east':
            if x < 0:
                return (x + 360, y)
        else:
            if x > 0:
                return (x - 360, y)
        return (x, y)
    return transform(unwrap_coords, geom)

def wrap_longitude(geom):
    """Wrap longitudes back to [-180, 180]."""
    def wrap_coords(coords):
        x, y = coords
        while x > 180:
            x -= 360
        while x < -180:
            x += 360
        return (x, y)
    return transform(wrap_coords, geom)

def split_at_antimeridian(line):
    """Split a LineString at the antimeridian (180° longitude)."""
    # Create a line along the antimeridian
    antimeridian = LineString([(180, -90), (180, 90)])
    
    # Split
    result = split(line, antimeridian)
    return result
```

Hmm, let me think about this differently. The `shapely.ops.split` splits a line by another line, but it might have precision issues. Let me use a different approach.

Actually, I think the simplest and most robust approach is:

1. For each LineString that crosses the antimeridian:
   a. Unwrap by adding 360 to negative longitudes
   b. Find intersection points with the antimeridian (x=180)
   c. Split the line at those intersection points
   d. For each segment, wrap longitudes back to [-180, 180] range
   e. Combine into MultiLineString

Let me write this out.

Actually, let me use a simpler method. I'll iterate through the coordinates and construct segments manually.

For a line that crosses the antimeridian from east to west (like T001):
- Points go: 178.94, 179.46, 179.97, -179.51, -179.00, -178.48
- The jump is between 179.97 and -179.51. The line should cross the antimeridian between these two points.
- To split: find the intersection of the segment (179.97, -17.61) to (-179.51, -17.60) with the antimeridian (x=180).
- Actually, let me think in continuous space: the segment goes from (179.97, -17.61) to (180.49, -17.60). Where does it cross x=180?
  - Linear interpolation: at x=180, the fraction is (180-179.97)/(180.49-179.97) = 0.03/0.52 ≈ 0.0577
  - So the y coordinate is -17.61 + 0.0577 * (-17.60 - (-17.61)) = -17.61 + 0.0577 * 0.01 ≈ -17.6094
  - So the intersection point is (180, -17.6094)

Then:
- Part 1 (east of antimeridian): [178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [180, -17.6094]
  - All longitudes ≤ 180, so they're fine. But 180 needs to be mapped to... well 180° is fine.
  
- Part 2 (west of antimeridian): [180, -17.6094], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]
  - Wait, -179.51 is actually 180.49°E in continuous space, but in WGS84 it's -179.51°W. So for Part 2, the coordinates should be:
    [180, -17.6094], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]
  - These are all valid in WGS84 range (-180 to 180).

But wait, the issue is: in continuous space, Part 2 goes from 180°E to 180.49°E to 181.00°E to 181.52°E. If we map these to WGS84 by subtracting 360: 180 → 180 (unchanged), 180.49 → -179.51, 181.00 → -179.00, 181.52 → -178.48.

Actually, there's a subtlety. The segment between (180, -17.6094) and (-179.51, -17.60) is a valid straight line in continuous space going from 180°E to 180.49°E. But when mapped back to WGS84, the segment goes from (180, -17.6094) to (-179.51, -17.60), which in WGS84 crosses the antimeridian again! But that's just because the same line is being represented with the second point wrapped. In reality, the segment between the intersection point and the next survey point is entirely on the west side of the antimeridian.

OK, I think the standard approach is:

After splitting at the antimeridian, Part 2's coordinates should be:
[180, -17.6094], [181.0 (which is -179.0 in WGS84)? No wait...

Let me re-think. The original survey path in continuous space is:
A(178.94, -17.63) → B(179.46, -17.62) → C(179.97, -17.61) → D(180.49, -17.60) → E(181.00, -17.58) → F(181.52, -17.58)

Where D = (180.49, -17.60) corresponds to original (-179.51, -17.60)
E = (181.00, -17.58) corresponds to original (-179.00, -17.58)
F = (181.52, -17.58) corresponds to original (-178.48, -17.58)

The line crosses x=180 between C and D.

Part 1 (east of antimeridian, in continuous space): A → B → C → intersection (180, y)
In WGS84: A(178.94, -17.63), B(179.46, -17.62), C(179.97, -17.61), I(180, y)
All fine.

Part 2 (west of antimeridian, in continuous space): I(180, y) → D(180.49, -17.60) → E(181.00, -17.58) → F(181.52, -17.58)
To get these into WGS84 [-180, 180]:
- I(180, y) → (180, y) - stays at 180
- D(180.49, -17.60) → subtract 360 → (-179.51, -17.60)
- E(181.00, -17.58) → subtract 360 → (-179.00, -17.58)
- F(181.52, -17.58) → subtract 360 → (-178.48, -17.58)

So Part 2 in WGS84: I(180, y), D'(-179.51, -17.60), E'(-179.00, -17.58), F'(-178.48, -17.58)

This is a valid line in WGS84 going from (180, y) westward to (-178.48, -17.58).

Now when we project this to Fiji Map Grid, we need to project both parts separately and then combine into a MultiLineString. The length will be the sum of the lengths of both parts.

Let me code this up.

Actually, I realize there's a potential issue: `shapely.ops.split` might have trouble splitting exactly at the antimeridian. A more robust approach is to manually find the intersection points and construct the parts.

Let me write a comprehensive script.

Actually, thinking about it more, I think there's a much simpler approach using the `shapely` library:

1. Read the GeoJSON
2. For each feature, check if it crosses the antimeridian (using the crosses_antimeridian_flag or detecting it)
3. For antimeridian-crossing lines, "unwrap" the longitudes
4. Use `shapely.ops.split` to split at x=180
5. For each resulting geometry, clip to WGS84 bounds and then project

Let me write the script:

Now I understand the problem. The lines that cross the antimeridian (180° longitude) have coordinates that go from, say, 179.97° to -179.51°. When rendered on a map, this creates an arc going the long way around the globe instead of the short local path across the 180° meridian.

To fix this, I need to:
1. For lines crossing the antimeridian, split them at the 180° meridian
2. Shift longitudes so the coordinates are continuous (e.g., for the parts east of 180°, use 180°+ to avoid the wrap-around)
3. Then split into segments that cross the 180° meridian

Let me think about the approach:

For each transect that crosses the antimeridian (T001-T010), the coordinates jump from ~179.xx to ~-179.xx. To make these render correctly, I should:

1. Normalize longitudes to a continuous range - instead of having 180° wrap, shift the negative longitudes for the western side by adding 360° so they become > 180° (e.g., -179.5° becomes 180.5°). Then split at 180° to create segments.

Actually a cleaner approach:
- For each LineString crossing the antimeridian, split it into segments where each segment stays on one side of 180°
- For coordinates near 180°, we need to convert them so the line actually goes across 180° locally rather than wrapping around the globe

The standard approach for this:
1. Normalize the coordinates so they're continuous: if longitude jumps by > 180° between consecutive points, add/subtract 360° to make them continuous
2. Then find where the line crosses 180° and split there
3. For each side, project to the local projected CRS

Let me think about this more carefully.

Actually, the best approach is:

1. Convert the LineStrings to a continuous coordinate system by "unwrapping" longitudes
2. For points east of the antimeridian, they have lon in [0, 180], for points west, they have lon in [-180, 0]
3. The antimeridian-crossing lines have coordinates that go, e.g., [179.97, -179.51, -179.00, -178.48]
4. To make this continuous, I can add 360 to the negative longitudes: [179.97, 180.49, 181.00, 181.52]
5. Now the line is continuous in longitude space
6. Find the intersection with the line lon=180 to split
7. Split into segments on each side of 180°
8. For the segment east of 180°, convert longitudes back to [-180, 180] range (subtract 360)
9. Now we have two LineStrings that properly represent the local path

But wait, in the projected CRS (Fiji Map Grid), the coordinates will be in meters. Fiji Map Grid (EPSG:3460) is a transverse Mercator projection centered on Fiji. The antimeridian is at 180° which is in the middle of Fiji's longitude range (approximately 177°W to 180°... actually Fiji is at around 177°E to 180°). So EPSG:3460 should handle both sides fine.

Let me think about the algorithm again:

For each LineString that crosses the antimeridian:
1. Convert to a continuous representation by shifting longitudes
2. Find the intersection point(s) where the line crosses 180°
3. Split into separate line segments for each side of 180°
4. For the segments west of 180° (longitudes > 180° in continuous space), subtract 360 to get back to [-180, 180] range

Wait, actually for EPSG:3460 (Fiji Map Grid), it spans eastings from... let me check. EPSG:3460 uses a Transverse Mercator with central meridian at 178°E, false easting 1000000. So both sides of 180° should project fine.

But the issue is that rendering software (like GIS systems) will draw the line from e.g. 179.97 to -179.51 the "wrong way" around the globe. We need to ensure the geometry actually goes through 180°.

Let me write the script:

For each antimeridian-crossing LineString:
1. Create a copy of coordinates with unwrapped longitudes
2. Add 360 to any longitude that's negative (which should make them continuous)
3. Now we have a continuous line in [~177, ~182] range
4. Find where it crosses 180° and interpolate the intersection point
5. Split into segments
6. For each segment, convert longitudes back to [-180, 180] range if they're > 180
7. Create the geometry

Let me write this properly with shapely.

Actually, a simpler approach using shapely's `split` and `intersection`:

1. Create the line with normalized continuous coordinates
2. Create a vertical line at x=180
3. Split the line at the intersection
4. For parts east of 180, subtract 360 from longitudes

Let me code this up.

Wait, the output features also get the survey_date from props which was already converted to str. Let me check the code flow more carefully.

In the output_features loop:
```python
for feat in fixed_features:
    props = feat["properties"]
    ...
    output_features.append({
        "type": "Feature",
        "properties": {
            "transect_id": props["transect_id"],
            "vessel": props["vessel"],
            "survey_date": props["survey_date"],
            "length_m": round(length_m, 2)
        },
        ...
    })
```

Since props["survey_date"] was stored as str() already, this should be fine. Let me run it again.

Let me verify a few things:

1. All features are MultiLineString - check.
2. The antimeridian-crossing ones have 2 parts - check (T001-T010 all have 2 parts).
3. The non-crossing ones have 1 part - check.

But I need to verify that the antimeridian crossing ones were correctly split. Let me check the output geometry more carefully, especially the coordinates around the 180° boundary for the problematic ones.

Let me also double-check T010 - it has lons: 177.60, 179.13, -179.35, -177.82. The jump is from 179.13 to -179.35 (difference of 358.48°). This should be split. Let me verify.

And I need to check T008 - lons: 179.40, 179.67, 179.95, -179.78, -179.51, -179.23. The jump from 179.95 to -179.78 is 359.73°. Should be split.

Let me peek at the output.

The output looks good. All features are MultiLineString. The antimeridian-crossing ones (T001-T010) have 2 parts, while the non-crossing ones have 1 part. Let me verify the output file itself to make sure it's well-formed GeoJSON.

Let me also double-check T001 specifically to make sure the antimeridian fix is correct. The original was:
[178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]

After fix, it should split the line at the 180° meridian into:
- East part: points with longitudes 178.94, 179.46, 179.97 (then 180.0)
- West part: points with longitudes -179.51, -179.00, -178.48 (starting from 180.0)

The projected coordinates look reasonable for Fiji Map Grid (EPSG:3460) - the eastings are around 1.8-2.5 million meters and northings around 3.8-4.0 million meters which makes sense for Fiji.

Wait, let me also check T010 which has a very large jump (358.5°). Its original coordinates span from 177.6 to -177.82 via -179.35. Let me verify that the split is correct.

Actually, I notice something about my fix_antimeridian_line function. The `ops.split` approach might introduce an extra segment at the antimeridian crossing. Let me look more carefully.

Also, I should look at the split more carefully. The `ops.split` function in Shapely splits a line at intersection points, but I'm using a vertical line at lon=180 as the "splitter". When I unwrap the coordinates, points that were originally at longitudes just west of 180 (like -179.5) become 180.5 (after +360). So the continuous line might go from e.g., 179.97 to 180.5, crossing 180 exactly.

Let me check if the split is correctly producing 2 parts for each antimeridian feature. From the output above, T001-T010 all have 2 parts, which is correct.

Let me also check if T008 has a proper split. Its original coordinates: [179.40, 179.67, 179.95, -179.78, -179.51, -179.23] - all these are very close to the antimeridian. After unwrapping: [179.40, 179.67, 179.95, 180.22, 180.49, 180.77] - this crosses 180. So the split should work.

Let me verify the output GeoJSON structure properly.

The output looks good. But I notice the survey_date has `00:00:00` appended because I converted the Timestamp to string using `str()`. The original format was `"2025-08-15"` without time. Let me fix this to keep the original format.

Also, let me check if the antimeridian splitting is correct. For T001, the original coordinates were:
- [178.94188, -17.63230] → part 0
- [179.45666, -17.62377]
- [179.97143, -17.61107]
- [-179.51379, -17.59620] → crossing point (between 179.97 and -179.51)
- [-179.00002, -17.57963]
- [-178.48424, -17.57732] → part 1

The split should happen between the 3rd and 4th coordinates. Looking at the output:
- Part 0 has 4 vertices: [2020343, 3930017] to [2132641, 3932030] (4 points - the first 3 original + 1 at the split)
- Part 1 has 4 vertices: [2132641, 3932030] to [2293630, 3933970] (the split point + the last 3 original)

Wait, that doesn't quite add up. Let me think... The original had 6 coordinates. After splitting at 180°:
- The first 3 points (lon 178.94, 179.46, 179.97) are east of 180... no wait, they're positive and less than 180.
- Wait, 178.94, 179.46, 179.97 are all < 180. So they're all on the eastern side (in the Fiji region, which is east of Australia).
- -179.51, -179.00, -178.48 are also in the western hemisphere but near the antimeridian.

Actually, both sets of coordinates are near Fiji, which straddles the 180° line. The points at 179.97 and -179.51 are on opposite sides of the antimeridian but geographically very close.

In my fix_antimeridian_line function, I unwrap to continuous coordinates. So: 178.94, 179.46, 179.97, then -179.51+360=180.49, -179.00+360=181.00, -178.48+360=181.52.

Wait, the unwrapping: starting from 178.94, next is 179.46 (fine), next is 179.97 (fine), next is -179.51 which has a jump of 359.48° from 179.97, so I'd add 360 to get 180.49. Then -179.00 → 181.00 (since 181.00 - 180.49 = 0.51, no wrap needed since the check is about difference from prev_lon). Actually let me re-check the code logic:

```python
while cur_lon - prev_lon > 180:
    cur_lon -= 360
while prev_lon - cur_lon > 180:
    cur_lon += 360
```

So for the jump from 179.97 to -179.51:
- prev_lon = 179.97, cur_lon = -179.51
- cur_lon - prev_lon = -179.51 - 179.97 = -359.48, which is not > 180 (false)
- prev_lon - cur_lon = 179.97 - (-179.51) = 359.48, which is > 180 (true)
- So cur_lon += 360 → cur_lon = 180.49

Good. Then -179.00 → prev_lon = 180.49, cur_lon = -179.00
- cur_lon - prev_lon = -179.00 - 180.49 = -359.49, not > 180
- prev_lon - cur_lon = 180.49 - (-179.00) = 359.49 > 180
- cur_lon += 360 → 181.00

Then -178.48 → 181.52.

So the unwrapped line is: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (180.49, -17.60), (181.00, -17.58), (181.52, -17.58)

Now splitting at lon=180:
- Part 0: coordinates with lon < 180: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61) + intersection point at (180, ~-17.60)
- Part 1: coordinates with lon > 180: intersection point at (180, ~-17.60) + (180.49, -17.60), (181.00, -17.58), (181.52, -17.58)

But then for Part 1, avg_lon > 180, so I subtract 360:
(180-360, -17.60) = (-180, -17.60), (180.49-360, -17.60) = (-179.51, -17.60), (181.00-360, -17.58) = (-179.00, -17.58), (181.52-360, -17.58) = (-178.48, -17.58)

Wait, the intersection point at lon=180... if it's exactly 180, then avg_lon = (180 + 180.49 + 181.00 + 181.52) / 4 = 180.75 > 180, so it gets shifted.

Hmm, but the intersection point... when ops.split splits at the antimeridian line, the split geometry includes a vertex exactly at the intersection. So part 0 ends at (180, y) and part 1 starts at (180, y). When part 1 gets shifted back by 360°, (180, y) → (-180, y). 

So the final result:
- Part 0: (178.94, -17.63), (179.46, -17.62), (179.97, -17.61), (180.00, -17.60) - east of antimeridian, but shifted... wait, avg_lon of part 0 would be < 180 so it's kept as-is.
- Part 1: (-180.00, -17.60), (-179.51, -17.60), (-179.00, -17.58), (-178.48, -17.58)

So Part 0 has 4 vertices, Part 1 has 4 vertices - which matches the output. Good!

Now about the survey_date format - I should fix it to keep the original format. Let me check how geopandas reads the date.

Let me fix the survey_date issue. The problem is that pandas reads the date as datetime, and when converting to string, it adds "00:00:00". I should convert it to the original format `YYYY-MM-DD`.

Let me also look at my splitting logic more carefully. For T001, the coordinates go:
[178.94, -17.63], [179.46, -17.62], [179.97, -17.61], [-179.51, -17.60], [-179.00, -17.58], [-178.48, -17.58]

When unwrapped:
- 178.94 (unchanged)
- 179.46 (unchanged, > prev 178.94 by 0.52)
- 179.97 (unchanged, > prev 179.46 by 0.51)
- -179.51 → unwrap: prev is 179.97, -179.51 - 179.97 = -359.48 < -180, so add 360 → 180.49... wait let me re-check: prev_lon=179.97, cur_lon=-179.51. cur_lon - prev_lon = -179.51 - 179.97 = -359.48. Since -359.48 < -180, we're in the second while loop: while prev_lon - cur_lon > 180: cur_lon += 360. prev_lon - cur_lon = 179.97 - (-179.51) = 359.48 > 180, so cur_lon += 360 → -179.51 + 360 = 180.49. Now prev_lon - cur_lon = 179.97 - 180.49 = -0.52, which is not > 180. So cur_lon = 180.49. Good.

Hmm, actually that's 180.49 which is > 180 but < 180+... let me check if my split at 180 will work. The continuous line goes through lon values from 178.94 up through 180.49. That crosses 180 fine.

-179.00 → prev is 180.49. cur - prev = -179.00 - 180.49 = -359.49 < -180, add 360 → 181.0. prev - cur = 180.49 - 181.0 = -0.51, not > 180. So 181.0.

-178.48 → prev is 181.0. cur - prev = -178.48 - 181.0 = -359.48 < -180, add 360 → 181.52. prev - cur = 181.0 - 181.52 = -0.52, not > 180. So 181.52.

Wait, something's off. The unwrapped longitude should be increasing (going eastward from Fiji). 178.94 → 179.46 → 179.97 → 180.49 → 181.0 → 181.52. That's a nice eastward path. 

Then we split at lon=180. The parts would be:
- Part 0: from 178.94 up to 180.0 (intersection point) → since avg_lon < 180, keep as-is → then shift... wait the part's coords are in unwrapped space. So the part that's west of 180 has lon < 180, and the part that's east has lon > 180.

For the part with lon > 180 (east side), subtract 360 to get back to [-180, 180] range: 180.49 → -179.51, 181.0 → -179.0, 181.52 → -178.48. That's correct!

For the part with lon < 180 (west side), keep as-is: 178.94, 179.46, 179.97. That's correct!

Great, the splitting logic seems right. Let me just fix the date format issue.

Now let me also think about whether the splitting logic is correct. Let me trace through T001 to understand.

T001 coordinates (WGS84):
[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 line goes eastward from 178.94 to 179.97, then jumps to -179.51 (which is really 180.49 in continuous space). So the line crosses the antimeridian going east.

My unwrapping logic: 
- Point 0: (178.94, -17.63)
- Point 1: (179.46, -17.62) - difference from prev: +0.52, fine
- Point 2: (179.97, -17.61) - difference from prev: +0.51, fine
- Point 3: (-179.51, -17.60) - difference from prev: -359.48, so while prev_lon - cur_lon > 180: 179.97 - (-179.51) = 359.48 > 180, so cur_lon += 360 → cur_lon = 180.49. So unwrapped = (180.49, -17.60)
- Point 4: (-179.00, -17.58) - prev_lon=180.49, cur_lon=-179.00. prev_lon - cur_lon = 359.49 > 180, so cur_lon += 360 → cur_lon = 181.00
- Point 5: (-178.48, -17.58) - prev_lon=181.00, cur_lon=-178.48. prev_lon - cur_lon = 359.48 > 180, so cur_lon += 360 → cur_lon = 181.52

So unwrapped line goes from 178.94 to 181.52 continuously, crossing 180. Good.

Now the antimeridian line at lon=180 spans from min_lat-1 to max_lat+1.

But wait - the split line will have intersections at points where the continuous line crosses 180. The issue is that the original coordinates may not have an exact vertex at the antimeridian. The split operation will insert a new point at the intersection.

After splitting:
- Part 0: points with lon < 180 → these stay as-is
- Part 1: points with lon > 180 → these get 360 subtracted

But there's a subtlety: the split may produce a point exactly at 180°, and that point gets included in both parts (as the endpoint of part 0 and start of part 1). Let me check if the split operation handles this correctly.

Actually, looking more carefully at my output, I see that for T001:
- Part 0 last coord: [2132641.3519591475, 3932030.6236885176] 
- Part 1 first coord: [2132641.3519591503, 3932030.6236885176]

These are very close but not exactly equal (tiny floating-point difference). That's because the split inserted a point at the antimeridian, and then when I projected, the slight difference in the lat values (from different interpolation on each side?) caused the coordinates to differ slightly. Let me look more carefully...

Actually the difference is in the 10th decimal of the second coordinate (3932030.6236885176 vs 3932030.6236885176). Wait, the x differs: 2132641.3519591475 vs 2132641.3519591503. That's a tiny difference of about 0.0000028 meters. That's fine, just floating point.

The key question is: are the geometries faithful representations? Let me think...

For T001, the original coordinates in WGS84 represent a path that goes east from Fiji (178.94°E) across the dateline to about 180.49°E (or 179.51°W), then further east to about 181.52°E (or 178.48°W). In the Fiji Map Grid projection, the east side (part 1) would be in the eastern part of the grid, and the west side (part 0) would be in the western part.

The split produces the correct result: the parts are split at 180°, with the eastern-side coordinates shifted back to their proper WGS84 longitudes before projection.

I think this is correct. Let me re-run the script to fix the date format issue.

Actually, let me also double-check one thing: for T010, which has coordinates:
[177.60, -17.28], [179.13, -17.47], [-179.35, -17.65], [-177.82, -17.84]

This goes from 177.60 to 179.13 (eastward), then to -179.35 (which is 180.65 in continuous space), then to -177.82 (which is 182.18 in continuous space). So it crosses 180 between points 1 and 2. After unwrapping, we get:
- 177.60, 179.13, 180.65, 182.18

Split at 180 gives:
- Part 0: 177.60 to 179.13 (the segment from 179.13 to 180 gets interpolated)
- Wait, the split would include the segment from 179.13 to 180.65 that passes through 180. So part 0 would be from 177.60 to 180 (at the antimeridian), and part 1 would be from 180 to 182.18.

Hmm, but the original point (179.13, -17.47) is fully on the east side. After shifting back to WGS84: (179.13 - 360, -17.47) = (-180.87, -17.47)... wait that doesn't make sense. 

Let me re-read my logic more carefully:

```python
avg_lon = sum(c[0] for c in part_coords) / len(part_coords)
if avg_lon > 180:
    shifted = [(lon - 360, lat) for lon, lat in part_coords]
```

So I'm checking if the average longitude of a part is > 180. For T010:
- After split, part 0 would have coordinates from 177.60 up to 180 (the split point). avg_lon ≈ 179, so it stays as-is.
- Part 1 would have coordinates from 180 down to 182.18. avg_lon ≈ 181, so it gets shifted: (180-360, lat) = (-180, lat), (180.65-360, lat) = (-179.35, lat), (182.18-360, lat) = (-177.82, lat).

But shifting the point at 180° to -180° changes its longitude! Let me think... 180° and -180° are the same meridian (the antimeridian), so (-180, lat) and (180, lat) are actually the same point. So this is fine.

But the point (179.13, -17.47) should stay in the western part because it's at 179.13°E which is west of the dateline... Wait, 179.13°E is east of 180°? No, 179.13°E is west of 180° - it's between 0° and 180°E. So the original point (179.13, -17.47) is on the "west" side of the antimeridian (using standard terminology where the International Date Line is at approximately 180°).

Let me trace through T010 more carefully:

Original coords: [177.60, -17.28], [179.13, -17.47], [-179.35, -17.65], [-177.82, -17.84]

Unwrapping:
- Point 0: (177.60, -17.28)
- Point 1: (179.13, -17.47) - diff from prev: +1.53, fine
- Point 2: (-179.35, -17.65) - diff from prev: 179.13 - (-179.35) = 358.48 > 180, so cur_lon += 360 → cur_lon = 180.65. So unwrapped = (180.65, -17.65)
- Point 3: (-177.82, -17.84) - diff from prev: 180.65 - (-177.82) = 358.47 > 180, so cur_lon += 360 → cur_lon = 182.18

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

Split at 180°:
The line goes from 179.13 to 180.65, crossing 180. So the antimeridian split inserts a point at (180, some_lat).

Part 0: from (177.60, -17.28) to (180, lat_at_intersection)
- This includes (179.13, -17.47) 
- Average lon < 180, so no shift
- After projection, this is the western part of Fiji

Part 1: from (180, lat_at_intersection) to (182.18, -17.84)
- This includes (180.65, -17.65), (182.18, -17.84)
- Average lon > 180, so shift: (180-360, lat), (180.65-360, -17.65) = (-179.35, -17.65), (182.18-360, -17.84) = (-177.82, -17.84)
- After projection, this is the eastern part of Fiji (since Fiji stretches east of 180° too)

Wait, this is reversed! In the original data, the points go from 177.60°E (west of 180) to 179.13°E (still west of 180) to -179.35° (which is 179.35°W, east of 180) to -177.82° (177.82°W, also east of 180).

So the survey path goes from west of the antimeridian to east of it. In Fiji, the antimeridian/date line passes through Fiji, and some islands are on the east side (like the Lau group) while most are on the west side.

After my processing:
- Part 0 (lon < 180 in unwrapped space): the segment from 177.60 to 180°. This represents the portion of the transect that is west of the antimeridian.
- Part 1 (lon > 180 in unwrapped space, shifted back): from 180° to 182.18, shifted to -180° to -177.82°. This represents the portion east of the antimeridian.

This looks correct! The survey path starts west of 180° and ends east of 180°.

But wait - the point (179.13, -17.47) has longitude 179.13°E, which is west of 180° (since 0° to 180°E goes eastward, 179.13°E is still west of the date line). So it correctly stays in Part 0.

And the point (-179.35, -17.65) which is 179.35°W is east of the antimeridian (since from 180° going further east, you get to -179°W = 179°W), so it correctly ends up in Part 1.

Great, the logic is correct.

Let me run the fixed script.