Re-calculate polyline stroke width in meters more frequently along path

[ReinisSprogis]

What is the bug?

Hi.
When setting useStrokeWidthInMeter = true on a Polyline, the stroke width does not reflect accurate real-world meter sizing. This appears to be due to a lack of correction for projection distortion, particularly with respect to latitude.
Circle elements do correctly account for projection distortion and render real-world dimensions accurately. For example, using identical size settings (e.g., radius or stroke width in meters), the rendered sizes only match near 0° longitude.

In the attached image:
Blue line: Polyline with useStrokeWidthInMeter = true
Black circle: Circle with radius in meters
Both were configured to the same dimension in meters, but only align visually near the equator or 0° longitude.

Expected Behavior:
The Polyline should account for projection distortion (like Circle does) so that stroke width in meters reflects consistent real-world size across different latitudes.

How can we reproduce it?

  List<LatLng> line = [];
List<CircleMarker> circles = [];
...
//flutter map
 onPointerHover: (event, point) {
      line.add(point);
      circles.add( 
          CircleMarker(point: point,color: Colors.black.withAlpha(50), useRadiusInMeter:true, radius: 10000, ),
       );
       setState(() {});
    }
...
///layers 
 PolylineLayer( polylines: [Polyline(points: line, color: Colors.blue,useStrokeWidthInMeter: true, strokeWidth: 20000.0,)], ),
 CircleLayer(circles: circles),

Do you have a potential solution?

This isn’t a simple fix because a single lineWidth can’t represent a consistent real-world size across different latitudes — metres-per-pixel changes with latitude (due to projection distortion). If two points are added from -90 to +90, it would be fixed size line, so need to split it into segments and scale each segment to real world size. That could cause steps if segments are too long. So maybe need to make polyline out of vertices.

[monsieurtanuki]

@ReinisSprogis A relatively easy solution would be to replace each existing displayed segment by the equivalent trapezoid, with a different size at the start and at the end, depending on the start/end latitudes. That's based on a linear approximation: would that be good enough?

[ReinisSprogis]

Hi. @monsieurtanuki Yes, that's actually what I meant when I said "make a polyline out of vertices." I haven’t looked closely at how Polyline is currently drawn, but I assumed it’s just a Path rendered via CustomPainter. If it's already constructed from vertices, then this might be easier to address. Need to figure out how many segments are needed.
Since the line must maintain a constant real-world width. Need to insert enough intermediate points so that the line visually maintains the correct width everywhere, even near the poles where distortion is stronger.
The line width itself also affects how many subdivisions are required. The wider the line, the more segments may be needed to prevent visible distortion.

[monsieurtanuki]

Oh, I meant it would be relatively easy if we used the already existing segments and if we considered computing the correct "meter width" for the already existing vertices, admitting it's a fair approximation.
You seem to need an extra "split the segments" step so that the segments are "small enough".

[ReinisSprogis]

It would improve if there are enough segments. But what if there are only 2 points from -90 to +90 Thats only one segment.

This is from circles, but PolyLine with useStrokeWidthInMeter = true should look similar. Otherwise it is incorrect. Or that parameter needs renaming to something like scaleOnZoom. But otherwise it would need to be divided into more segments to maintain accuracy. I don't see other way, unless canvas can be skewed somehow.

[monsieurtanuki]

@ReinisSprogis You're right.
What I mean is that we probably shouldn't jeopardize the "normal" use-cases just for your extreme -90/90 polyline.
That's why I suggest to keep the current behavior as the baseline, while adding parameters to polyline:

• "split me into segments not bigger than a specified distance" - that would probably cost a lot, so we need to make it an option.
• "compute the stroke width at both segment ends and display a trapezoid". That would probably cost a lot too.

[monsieurtanuki]

Just had a look at the code displaying polylines.
The thing is that we work most of the time on the projected points, i.e. pixels (as Offsets).
That would mean we would have to add the latitude to the projected points, and compute from pixels the interpolated latitude of segments intersecting the screen border.

Perhaps a solution would be to create a new polyline pattern style (as existing DottedPixelHiker), that would say:

• keep the latitude with the projected points
• every x latitude change, create a new segment and display a trapezoid

Doing so we wouldn't impact the typical use-cases of polylines.

[ReinisSprogis]

I'm not sure to be honest what the solution is. I looked at the code. It uses ui.Path. It doesn't have variable width. Currently setting width based on first point added latitude. How would you draw a trapezoid?

[monsieurtanuki]

Instead of saying that point A and B are linked by a line that has a given width (computed once):

• computing the width widthA in point A
• computing the width widthB in point B
• for the record in both cases we need the latitude, and in both cases at this level we're already at the projected=pixel level, not a the LatLng level anymore
• computing the trapezoid vertices
  • two vertices at point A, of the segment centered on A, perpendicular to segment AB, and with a width of widthA
  • two vertices at point B, of the segment centered on B, perpendicular to segment AB, and with a width of widthB
  • or something like that for side-effect, like a strokeWidth of min(widthA, widthB) and just a triangle

[ReinisSprogis]

Yes, drawing path with vertices would resolve this. But you will lose all the styling options.

[monsieurtanuki]

Yes, drawing path with vertices would resolve this. But you will lose all the styling options.

Indeed.