Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

allow map call spanning 180th meridian #1612

Open
openstreetmap-trac opened this issue Jul 23, 2021 · 16 comments
Open

allow map call spanning 180th meridian #1612

openstreetmap-trac opened this issue Jul 23, 2021 · 16 comments

Comments

@openstreetmap-trac
Copy link

Reporter: robx
[Submitted to the original trac issue database at 10.17pm, Thursday, 19th February 2009]

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

@openstreetmap-trac
Copy link
Author

Author: gpspilot1
[Added to the original trac issue at 5.02am, Sunday, 16th December 2012]

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.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 8.38am, Sunday, 16th December 2012]

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

@openstreetmap-trac
Copy link
Author

Author: gpspilot1
[Added to the original trac issue at 11.10pm, Sunday, 16th December 2012]

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.

@openstreetmap-trac
Copy link
Author

Author: gpspilot1
[Added to the original trac issue at 8.32pm, Monday, 17th December 2012]

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

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 12.30am, Tuesday, 18th December 2012]

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.

@openstreetmap-trac
Copy link
Author

Author: emj
[Added to the original trac issue at 8.31am, Tuesday, 18th December 2012]

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

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

@openstreetmap-trac
Copy link
Author

Author: gpspilot1
[Added to the original trac issue at 7.16am, Saturday, 22nd December 2012]

Replying to [comment:7 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?

@openstreetmap-trac
Copy link
Author

Author: Richard
[Added to the original trac issue at 5.05pm, Saturday, 22nd December 2012]

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

@openstreetmap-trac
Copy link
Author

Author: woodpeck
[Added to the original trac issue at 7.23pm, Saturday, 22nd December 2012]

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

@openstreetmap-trac
Copy link
Author

Author: JohnDoe23
[Added to the original trac issue at 3.29pm, Saturday, 29th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: woodpeck
[Added to the original trac issue at 11.54am, Sunday, 30th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: rvollmert[at]gmx.net
[Added to the original trac issue at 12.08pm, Sunday, 30th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: woodpeck
[Added to the original trac issue at 3.46pm, Sunday, 30th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: pnorman
[Added to the original trac issue at 5.45pm, Sunday, 30th March 2014]

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

  • [http://wiki.openstreetmap.org/wiki/WGS84 OpenStreetMap uses the WGS-84 coordinate system]
  • [http://wiki.openstreetmap.org/wiki/Node Latitude coordinate in degrees (North of equator is positive) using the standard WGS84 projection]
  • [http://wiki.openstreetmap.org/wiki/Node Longitude coordinate in degrees (East of Greenwich is positive) using the standard WGS84 projection]

WGS84 has bounds of [http://spatialreference.org/ref/epsg/4326/ -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
  • ...

@openstreetmap-trac
Copy link
Author

Author: rvollmert[at]gmx.net
[Added to the original trac issue at 6.01pm, Sunday, 30th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: sanderd17
[Added to the original trac issue at 2.29pm, Thursday, 28th August 2014]

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant