Opened 11 years ago

Last modified 6 years ago

#1612 new defect

allow map call spanning 180th meridian

Reported by: robx Owned by: rails-dev@…
Priority: minor Milestone: Wishlist
Component: api Version:
Keywords: Cc:


Currently, the API doesn't treat map calls for areas overlapping the 180th meridian nicely.

For a bbox with minlon=179, maxlon=-179, it should return a 2 degree slip along the 180th meridian.

It might be worth specifying -180 <= lon < 180 in general; that's what GPX does, at least:

I'm not sure if there's other situations where the API assumes the earth is a rectangle.

Cheers Robert

Change History (18)

comment:1 Changed 11 years ago by Tom Hughes

Milestone: Wishlist

comment:2 Changed 9 years ago by Tom Hughes

Owner: changed from Tom Hughes to rails-dev@…

comment:3 Changed 7 years ago by gpspilot1

Priority: minormajor
Type: enhancementdefect

This defect has been independently rediscovered by me, and confirmed by aseerel4c26 and scai (see ). Hope I'm not out of line by bumping up the priority.

comment:4 Changed 7 years ago by Tom Hughes

Not really out of line, but it won't make a blind bit of difference to whether anybody feels like fixing it.

comment:5 Changed 7 years ago by gpspilot1

The following bizarre error message is associated with this bug: "A server error occurred. Do you want to retry? (The server said: The node is outside this world)"

If I really did have the power to place extra-worldly nodes, that would be really cool.

comment:6 Changed 7 years ago by gpspilot1

Milestone: WishlistOSM 0.5
Priority: majorcritical

This bug is drastically detrimental to roads in Siberia, as well as in Fiji. (For example, here are two un-joinable Fijian ways: )

comment:7 Changed 7 years ago by Tom Hughes

Milestone: OSM 0.5Wishlist
Priority: criticalminor

No this is not "critical" in any way shape or form. That would be things like "nobody can upload any data".

The API has never supported this, so adding it would basically be an enhancement, and at least one person has argued to me that it shouldn't do so and that clients should split the request - they can do so just as easily as the server can.

comment:8 Changed 7 years ago by emj

It's obviously an issue, people editing borders that span the 180th resort to this:

comment:9 in reply to:  7 Changed 7 years ago by gpspilot1

Replying to TomH:

Oh dear, I really overreached.

But I find it quite annoying that I can't draw a way that spans the 180th. Are you saying that Potlatch2 could be modified to "split the request," and this would fix the problem?

comment:10 Changed 7 years ago by Richard

It certainly could be, but you'd need to find a developer who was interested in fixing the issue!

comment:11 Changed 7 years ago by woodpeck

It is not too difficult to modify the API to return data for bboxes that cross the dateline (I made a start here but this doesn't cover cgimap or AMF). Having clients handle this does mean that *all* clients have to implement it and it also means less efficient querying.

But I guess this is much more than just a "can the API handle this" question. I suspect that if you created a way that went from (179.99,0) to (-179.99,0), most clients (editors as well as renderers) would draw a 40,075 km line along the equator. And why exactly would this be wrong?

Perhaps it isn't the worst thing that creating such ways is currently very difficult ;)

comment:12 Changed 6 years ago by JohnDoe23

Has someone of the developers here ever tried to edit at 180 and -180? I'm editing there right now and can tell you that it's a big mess. Every good GIS-software has no problems with handling the 180th meridian, just OSM can't handle it.

I can't understand why this problem isn't classified as critical - just try editing with JOSM in this area und you'll change your mind.

comment:13 Changed 6 years ago by woodpeck

I had once started a patch to the rails port allowing such bounding boxes (see but after some discussions with other developers I was convinced that this really is an issue for the editor and not for the API.

comment:14 Changed 6 years ago by rvollmert@…

I tend to think this is something that should be handled within API / data model.

The related ticket was recently closed arguing that the OSM world is defined to be a rectangle. I rather see this part of the data model as undefined, does anyone have a reference for this definition?

I'd like to see us define the edge between (179.99,0) to (-179.99,0) to be the short one. In general, take the shorter variant.

I believe that this approach would ultimately lead to less work and a more general solution than working around a cut at the date line.

comment:15 Changed 6 years ago by woodpeck

This logic, however, will have to be implemented in *every* software that deals with OSM data (e.g. currently, if some program would allow you to enter a short line that goes from 179.00 to -179.99, other programs would display that as a very long line spanning the globe). Now if we have to adapt every program individually anyway, we might as well keep the API strict. It's not as if making the change in the API will save the JOSM coders or map painters from implementing code on their side too.

comment:16 Changed 6 years ago by pnorman

The related ticket was recently closed arguing that the OSM world is defined to be a rectangle. I rather see this part of the data model as undefined, does anyone have a reference for this definition?

In documentation

WGS84 has bounds of -180, -90, 180, 90

More importantly than the wiki, in practice data consumers treat OSM data as being in WGS84. These consumers include

  • osm2pgsql
  • imposm
  • nominatim
  • osmosis
  • coastcheck
  • OSMCoastline
  • cgimap
  • the rails port
  • ...

comment:17 Changed 6 years ago by rvollmert@…

The question isn't about node coordinates. Those being WGS84 is clear.

But I don't see that that implies anything about how we interpret a pair of coordinates.

comment:18 Changed 6 years ago by sanderd17

The problem indeed isn't with nodes, but with ways (when two subsequent nodes are on different sides of the date line) and even more complex with areas.


My proposal is that all ways crossing the date line should have two overlapping points at the date line. F.e. if you want a line from (-170, 5) to (170, 15), the way should be [(-170, 5), (-180, 10), (180, 10), (170, 15)]. So four different nodes, with a unique id each.

For editor apps

Editors should just tile the map data over the date line (as the mapnik renderer does). They should not render those overlapping nodes by default, by which I mean, if a way has two subsequent nodes with the same latitude, and as longitudes +/- 180, it should be neglected, and only a line between the next two nodes should be rendered.

When uploading data, the intersection with the date line should be re-calculated, and the correct intersection points added to the way. For advanced editors, it could be beneficial to get the possibility to edit those intersection points directly, but not by default.

For data users

Renderers and most other data users can just split ways every time they see a subsequent +/-180 longitude with the same latitude, and render both parts of the ways separately.

For routers, it's currently almost impossible to see if the roads are connected (luckily there aren't many roads crossing the date line). But when using data like this, passibility is implied. It should just take into account that the distance/travel time between those +/-180 longitude points is zero.


Areas are a bit harder. When you have a circular way that represents an area, and it crosses the date line, that automatically means it crosses the date line at least twice. If you split it on all occurrences of that +/-180 longitude case, you end up with at least two non-closed ways.

If the split is done by an importing tool (s.a. osm2pgsql), and the renderer (like Mapnik) decides if it's a linear way or an area, the renderer has incomplete information. But I believe that when it has a non-closed way, but with both points ending on the date line, it could easily connect the area via the date line.


In short, for most data users, implementing a simple split between the +/-180 longitude point will result in the same sort of quality data (only a bit extra work for areas). While for other data user, they get more complete info about connectedness.

For OSM contributors, it gets a lot more easy to contribute.

Note: See TracTickets for help on using tickets.