Ticket #1612 (new defect)

Opened 5 years ago

Last modified 3 weeks ago

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:  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

Change History

comment:1 Changed 4 years ago by tom@…

  • Milestone set to Wishlist

comment:2 Changed 3 years ago by TomH

  • Owner changed from tom@… to rails-dev@…

comment:3 Changed 16 months ago by gpspilot1

  • Priority changed from minor to major
  • Type changed from enhancement to defect

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.

comment:4 Changed 16 months ago by TomH

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 16 months 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 16 months ago by gpspilot1

  • Priority changed from major to critical
  • Milestone changed from Wishlist to OSM 0.5

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-- )

comment:7 follow-up: ↓ 9 Changed 16 months ago by TomH

  • Priority changed from critical to minor
  • Milestone changed from OSM 0.5 to Wishlist

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 16 months 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 16 months 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 16 months 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 16 months 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  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 ;)

comment:12 Changed 4 weeks 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 3 weeks ago by 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.

comment:14 Changed 3 weeks ago by 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.

comment:15 Changed 3 weeks 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 3 weeks ago by 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

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 3 weeks 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.

Note: See TracTickets for help on using tickets.