[OpenStreetMap] #1612: allow map call spanning 180th meridian

[OpenStreetMap]

#1612: allow map call spanning 180th meridian
---------------------+-------------------------
  Reporter:  robx    |      Owner:  rails-dev@…
      Type:  defect  |     Status:  new
  Priority:  minor   |  Milestone:  Wishlist
 Component:  api     |    Version:
Resolution:          |   Keywords:
---------------------+-------------------------

Comment (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.

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

--
Ticket URL: <https://trac.openstreetmap.org/ticket/1612#comment:18>
OpenStreetMap <http://www.openstreetmap.org/>
OpenStreetMap is a free editable map of the whole world