allow map call spanning 180th meridian

[robx]

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: ​http://www.topografix.com/GPX/1/1/#type_longitudeType

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

Cheers
Robert

[gpspilot1]

This defect has been independently rediscovered by me, and confirmed by aseerel4c26 and scai (see ​https://help.openstreetmap.org/questions/18437/osm-shows-2-road-segments-potlatch-2-only-shows-one ). Hope I'm not out of line by bumping up the priority.

[TomH]

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

[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.

[gpspilot1]

This bug is drastically detrimental to roads in Siberia, as well as in Fiji. (For example, here are two un-joinable Fijian ways: ​http://osm.org/go/FEABUUQBB-- )

[TomH]

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.

[emj]

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

http://www.openstreetmap.org/browse/way/46113981

[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?

[Richard]

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

[woodpeck]

It is not too difficult to modify the API to return data for bboxes that cross the dateline (I made a start here ​https://github.com/woodpeck/openstreetmap-website/tree/bbox-cross-dateline 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 ;)

[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.

[woodpeck]

I had once started a patch to the rails port allowing such bounding boxes (see ​https://github.com/woodpeck/openstreetmap-website/tree/bbox-cross-dateline) but after some discussions with other developers I was convinced that this really is an issue for the editor and not for the API.

[rvollmert@…]

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

The related ticket ​https://trac.openstreetmap.org/ticket/1647 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.

[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.

[pnorman]

The related ticket ​https://trac.openstreetmap.org/ticket/1647 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

• ​OpenStreetMap uses the WGS-84 coordinate system
• ​Latitude coordinate in degrees (North of equator is positive) using the standard WGS84 projection
• ​Longitude coordinate in degrees (East of Greenwich is positive) using the standard WGS84 projection

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
• ...

[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.

[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.

Ways

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

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.

Conclusion

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.