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.