"can we impose the first GeoPoint of a Polygon to be top left": I don't think such a constraint is acceptable. Maybe #722 is the correct answer and should be the default mode (disclaimer: I just read the description). More specifically, the S85 / N85 latitude transition makes no sense at all.
Third question: could we be more relaxed about the zoom 0 specific algorithm, as it's a very specific use case to display the whole world (and more) on a smartphone screen?Īs I assume no algorithm can be perfect on that subject, I would recommend that we consider the first GeoPoint of a Polygon to be top left, with the following Polygon's GeoPoints' coordinates computed from this start.ĭoes that make I agree with you on world repetitions. I don't think so, unless we add some parameter to the draw Polygon feature (like offset or justify) Second question: could there be a better algorithm that solve this USA/NYC combination? Looks like a bug to me.įirst question: do we agree on the fact that the zoom 0 specific algorithm is flawed? The GeoPoint and the Polygon will be disconnected. Looks like a sensitive behavior.īut if I scroll the map so that Chicago is on x=0, the NYC GeoPoint will still be on top left, but the US Polygon will be displayed in the middle of the screen (x-wise). The GeoPoint (NYC) is displayed inside the Polygon (USA). If the top left of my screen is on Siberia, the Polygon is displayed top left, and so is the GeoPoint. My screen displays 2x2 worlds (something like a 512x512 screen). Let's say the Polygon is the USA, and the GeoPoint is New York City. There's something wrong with the algorithm: incoherent behavior between Polygon and GeoPoint. * `Projection`: added methods `getLongPixelsFromProjected`, `getLongPixelXFromMercator`, `getLongPixelYFromMercator` and `getLongPixelFromMercator` for overflow reasons removed 2 unused imports * `Polygon`: modified method `buildPathPortion` in order to use less overflow prone `PointL` (instead of `Point`), to consider `Path` as a list of 2D segments, and to clip those segments into a min/max values square added methods `clip`, `isInClipArea`, `intersection`, `lineTo` * `PointL`: added overriden methods `toString` and `equals` added methods `set` and `squareDistanceTo` * `SegmentIntersectionTest`: unit tests on `SegmentIntersection` * `SegmentIntersection`: tools in order to compute the intersection between two 2D segments through `public` method `intersection` * low-zoom "best top-left version" of `Polygon` / `Polyline` With this fix, the `Polygon`s looks OK up to zoom 29. #595 scaling during animations of polyline.#353 Polyline Path too large to render into a texture.All points are off screen, however the viewport covers an area in between some of the points.1 or more points are on screen others are off screen.
polygons in which all points are off screen, however the view port is within the polygon."holes" that are partially offscreen, fill colors.The solution is an accurate clipping mechanism that supports all these strange edge cases when stuff is within or outside of the view port, holes and all at poles polygon disappears when zooming in, it seems to be linked to large polygons that are primarily all offscreen see #353.polygon has strange rendering behavior when the map wraps n/s, e/w.polygon border disappears at zoom levels > 22.Provide proper rendering of polylines and polygons at any zoom level supported by the map view/projection with and without hardware acceleration turned on (really on is the goal)Ĭurrent issues after the merge of #329 #723 If we can't get everything rendering at the higher zoom levels, we may have to set the max zoom to the level at which we can render the content at. This is blocking issue for 6.0.0 release.
0 kommentar(er)
