When crossing the dateline, the label is not displayed at the center of a line

[James_Ridley]

I have noticed that a line that crosses the dateline does not apply the label:

I noticed it was also an issue it our old WPF map, but I never noticed. The arrow at the dateline should also be at the endpoint in China:

I am also forcing the line curvature in Blazor, below is without my changes to force curvature. It was automatic in WPF.

I did not attach source but can extract it and send it if necessary.

Thanks,
James R.

[James_Ridley]

The label is there on the dateline crossing line when not adjusting for curvature:

[James_Ridley]

Disregard this, I did get it working. It is just not showing at all zoom levels, so I have to work out why that is.

Thanks,
James R.

[James_Ridley]

Unless you can make it so I do not have to calculate the curvature anyway

[Ben]

Hi James,

Thanks for the report — it’s recreated and fixed in 15.0.0-beta126.

The label of a line split at the dateline was anchored to the longest piece and could be dropped entirely at certain zoom levels. Beta126 treats the two pieces as one continuous line: the label now sits at the center of the whole line and shows at every zoom level. Your current approach (splitting at ±180) is exactly what it expects — no code changes needed.

On the other two points: the arrow appears at the dateline because each split piece ends there — for now, place arrowheads from your own route endpoints instead of the line ends. And we’re working on making the built-in great-circle support usable so you won’t have to calculate the curvature yourself; we’ll follow up here when that’s ready.

Thanks,
Ben

[James_Ridley]

Ben,

Thanks. I removed my curvature changes, just to test, but I also see another issue. When zooming in on lines that cross the date line, as you zoom closer one end disappears. See the two images below.

Also, not seeing my line labels on those lines.

[James_Ridley]

Ben,

Another update the last issues appear to be only when I first draw the line. If it is loaded from data I get this. The line is complete, but the label is replicated multiple times.

Thanks,
James R.

[James_Ridley]

Ben,

Last update, the line is still not drawing completely either. The previous image had it missing from the opposite end than the other images. I added another shorter line, so it was easier to see.

Thanks,
James R.

[Ben]

Hi James,

It’s fixed in 15.0.0-beta127. Now you can go ahead and use the great circle:

MultilineShape route = startPoint.GreatCircle(endPoint);  // decimal degrees; project before adding
textStyle.SplineType = SplineType.StandardSplining;        // required, or the label is dropped

That draws the whole line across the dateline (no disappearing end), centers the label at every zoom, and drops your manual curvature. Use it for all connectors — even near-straight ones label cleanly this way.

Two notes:

• Geometry must stay within ±180. A raw unsplit line (longitudes past ±180) still drops its far half — GreatCircle keeps it split for you.
• Endpoint arrows: place them from your route endpoints (first vertex of the first part, last vertex of the last part), not the line ends.

Thanks,
Ben

[James_Ridley]

Ben,

That would work except our lines are define as new LineShape(vertices), where vertices is a list of vertexes from the data, or drawn to follow specific paths. Unless I am missing something.

Thanks,
James R.

[James_Ridley]

Ben,

Attaching the source of what I have working. The only thing it does not do is handle labels very well on crooked lines, the one line at the very top between the US and China. Also, the end of the line is missing US to China lines.

BaseMap.zip (382.0 KB)

Thanks,
James R.

[Ben]

Hi James,

You can read my mind! I was about to ask you for the source

I found two things in MapUtilities.cs:

1. The line is kept unwrapped on purpose — ConvertMapCoordinateToMetersPreserveLongitude (~line 251, “preserve unwrapped longitude”) gives new LineShape(vertices) longitudes past ±180. Under WrapDateline the tiles only fetch geometry inside the world, so the far half is never drawn — that’s the missing end. Split it at ±180 instead (or run your densified vertices through it), so each part stays in-world and the whole line renders:

var split = DecimalDegreesHelper.SplitByDateline(lineInDecimalDegrees);  // then convert each part to meters

2. The helper-line label (~lines 283–330) is why crooked lines label poorly — it’s a fake horizontal stub at the middle vertex, not on the route. Once the line is split, drop that: label the real split line and set SplineType.StandardSplining so the label follows the curve and sits at the center.

I reproduced your exact setup and both symptoms and confirmed the split version renders fully and labels correctly.

Thanks,
Ben

[James_Ridley]

Ben,

I was unaware of the split method, and it did fix the line ending and label issues. Yes, the helper label was a work around that I did not like. Now I just need to add the arrows, and I think I have everything I need. I am only saving the original points, instead of that huge list of densified points also, as it that will be the way the data would come in anyway. Once we allow modification of the lines, I may have to revisit that.

Thanks,
James .R.

[Ben]

Hi James,

We want to get to the bottom of this dateline thing once and for all. Can you upgrade to 15.0.0-beta132, in which we have the following changes for you?

1. Labels. A line split at the dateline is now recognized as one line by the SDK itself, not by the label code guessing from the endpoints. The label sits at the center of the whole line at every zoom level, in every tile, for any layer type (InMemory, shapefile, pre-split GeoJSON), and with a custom WrappingExtent too.

2. Splitting and joining. There is a new DatelineHelper that works directly in meters, so you can skip the degree round trip:

var world = MaxExtents.GetDefaultMaxExtent(GeographyUnit.Meter);

// before adding a route to the layer (no-op if it doesn't cross)
var feature = DatelineHelper.Split(new Feature(lineInMeters), world);

// for your arrows: the continuous line back, true endpoints at [0] and [last]
var whole = DatelineHelper.Merge(feature, world);

DecimalDegreesHelper.SplitByDateline still works exactly as you use it now. Either way the split feature carries a hidden column
__tg_dateline_split, which is what the SDK reads.

3. Editing. EditOverlay handles the dateline now: a linecomes back in Features and in OnFeatureDrawn alreadysplit, while on the map you edit it as one continuous line. This covers the “once we allow modification of the lines” point from your
   last post. One thing to be aware of: a crossing line not a LineShape.

4. Great circle. Unchanged from beta127: start.GreatCirceady split on the seam.

Nothing in your current code needs to change for betasplitting and helper-label code if you want, but itkeeps working as is. If you try the editing path and anything looks off, send us a screenshot.

Thanks,
Ben