I originally wrote this up as a response to the ongoing debate about polygon primitives (a fight I started...), but it's too big for that thread. So, here's another one. I'm pulling the pin and throwing it over the wall.
Since we're talking about API changes, let's look at the OSM file structure. To borrow an idea from the Polish format (.mp) files, it would be easier to deal with ways (polylines) if they included the coordinates inline instead of referring to nodes in a separate location. Topology could be preserved by just referencing node ids (routing nodes, as it were) at the junction points. A sample would look like this (some elements stolen from the API 0.5 Wiki page): <node id="156804" lat="61.8083953857422" lon="10.8497076034546" visible="true" timestamp="2005-07-30T14:27:12+01:00"/> <node id="156805" lat="61.8084115523982" lon="10.8497259103025" visible="true" timestamp="2005-07-30T14:27:12+01:00"/> <way id="35" visible="true" timestamp="2006-03-14T10:07:23+00:00" user="johnz"> <nd lat="61.8083953857422" lon="10.8497076034546" ref="156804"/> <nd lat="61.8084092591305" lon="10.8497172051835"/> <nd lat="61.8084115523982" lon="10.8497259103025" ref="156805"/> <tag k="highway" v="secondary"/> </way> <way id="36" visible="true" timestamp="2006-03-14T10:07:23+00:00" user="johnz"> <nd lat="61.8084115523982" lon="10.8497259103025" ref="156805"/> <nd lat="61.8083953857422" lon="10.8497076034546"/> <nd lat="61.8084092591305" lon="10.8497172051835"/> <tag k="highway" v="secondary"/> </way> (The end of Way 35 is connected to the beginning of Way 36. The point where they connect is a routing node and has an ID of 156805.) Now the ways are self-contained and can be filtered against an area without having to first store all the nodes in the planet to look them up. Including the lat and lon at the routing nodes has concerns about keeping the coordinates synchronized, but maybe it could just included for convenience and the <node/> element coordinates would be authoritative. Obviously this would increase the size of the planet file due to duplicated coordinates, too. Karl P.S. This could be an alternative structure which is derived from post-processing a planet file (or database...).
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
