[OpenStreetMap] #1612: allow map call spanning 180th meridian
trac at noreply.openstreetmap.org
Thu Aug 28 14:29:40 UTC 2014
#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
== 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 is a free editable map of the whole world
More information about the rails-dev