Talk:180th meridian

Also of interest to geohashing: https://geohashing.site/geohashing/antimeridian Arlo James Barnes (talk) 06:07, 2 August 2020 (UTC)

Design idea for a general solution for element-level clients ("180me")

Here's a peanut-gallery design idea (I have no experience with mapping across the 180th meridian nor developing OSM-based software) to enable clients that work at the OSM element level and use a coordinate system that handles the meridian without problems to work seamlessly with arbitrary virtual elements that cross the meridian. I suspect we may never be able to completely remove the risk that some old OSM client will break badly if ways or relations of certain types crossing the 180th meridian exist in the data set. So instead, there could be a convention (which I'll call "180me" in this discussion) for encoding arbitrary elements that cross the meridian so that clients that don't implement 180me will handle them safely (in many cases, by just ignoring them) and clients that do implement it will automatically reassemble them in memory when they see them. The basics of 180me:

• A node on the meridian that has things attached to it on both sides is represented by a pair of nodes at +/-180° belonging to a relation tagged with 180me=node. When a 180me client tries to move such a node, it will see the relation and know to either move both underlying nodes along the meridian or move one node off the meridian and delete the other (and the relation).
• In general, a way that crosses the meridian (possibly back and forth multiple times) is split into multiple ways that are stripped of their usual tags but have a special 180me=way tag. Then there is a relation with 180me=way that contains the pieces of the way in sequence plus the tags of the original way (if there is a risk that the use of the original keys breaks non-180me clients, 180me: can be prefixed to their names). When a 180me client sees a 180me=way relation, it automatically reassembles it into the original way.
• In general, a relation that "crosses" the meridian is represented by a relation with 180me=relation, 180me: prefixed to all its original keys and/or role names if there is a risk of use of the originals breaking non-180me clients, and the relation's original members. A relation is said to "cross" the meridian if it (1) is of a type (e.g., a turn restriction) that clients generally assume to have connected elements and/or a small bounding box or (2) needs to contain another 180me-encoded element. For a relation that just (for example) represents a union of areas that clients don't assume to be close together, an area crossing the meridian can just be represented as two areas. A node on the meridian that is involved in such a relation should have a 180me=node relation so an 180me editor that moves it updates both copies, but there is no need to do anything else special.
• If a degraded version of data crossing the meridian should be exposed to non-180me clients (e.g., if there is an area that would ideally be represented as a whole but can be represented as two areas without breaking clients), the degraded elements are added directly to the OSM map but they get special tags so that 180me clients will reassemble the degraded elements into the better view of the data (e.g., the single area). When a 180me client edits the better view, it automatically makes the appropriate updates to the degraded data. This may require some ad-hoc logic per element type; I haven't thought through the details. If a non-180me client edits the degraded data (e.g., by moving one part of a split area but not the other), this may corrupt the 180me view; 180me clients will need to detect this and show the degraded data instead unless/until a user fixes the corruption.

Ideally, the whole scheme can be encapsulated in one or more alternative libraries, each of which can be reused by any number of clients that are technically capable of accessing the library (e.g., based on limits on mixing programming languages). The scheme relies on the assumption that non-180me clients won't be broken by the existence of relations of types unknown to them with huge bounding boxes; I don't know whether that's a safe assumption.

In a pinch, a client that can't handle elements crossing the meridian at all can be used with 180me data by using software that decodes the 180me data and generates a copy shifted to a different longitude, which can then be read safely by the non-180me client (albeit with wrong longitudes). The shifting can be done offline or on the fly by wrapping an API that retrieves the OSM data. Similarly, a changeset that the client wants to upload can be mapped back to a changeset to the encoded data, although we'd have to be really careful to avoid bugs in this process. Any other data that goes in or out of the client (e.g., GPS input) would need its longitude to be virtualized in the same way.

M3232 (talk) 14:14, 30 January 2021 (UTC)

A survey of existing approaches

The antimeridian problem extends well beyond OSM-based software, so here are a few common ways of dealing with the problem, as a point of reference:

• GeoJSON recommends representing the feature as two distinct geometries joined by a multilinestring or multipolygon. [1]
• Apple's MapKit libraries take the shorter way around the globe between any two coordinates. [2]
• Mapbox libraries respect the GeoJSON standard but also accept coordinates beyond ±180°, cutting the feature along the antimeridian before display. This makes some nifty visualizations possible, such as a day-night map implemented using a geodesic circle. [3]

 – Minh Nguyễn ^💬 23:41, 7 February 2021 (UTC)

https://github.com/mapbox/mapbox-gl-native/pull/14534 appears to be rejected ("This pull request has been automatically detected as stale because it has not had recent activity and will be archived.") Mateusz Konieczny (talk) 04:59, 8 February 2021 (UTC)

@Mateusz Konieczny: Yes, that particular feature got pocket-vetoed, but it's only an application of the antimeridian behavior I was referring to. – Minh Nguyễn ^💬 06:39, 12 February 2021 (UTC)

Average map reading users are baffled

All I know is people see this weird line cutting the tip of Siberia and that Island north of it. So maybe when one is doing a query feature on the OSM website, the query program should recognize that we're on 180 and perhaps offer some explanation. Jidanni (talk) 07:55, 30 December 2022 (UTC)