On Mon, Oct 26, 2009 at 10:30 AM, Frederik Ramm <frede...@remote.org> wrote: > The other is multipolygons, where we (ab)use the relation object which is > *normally* used to model a relation between several primitives, to actually > construct a primitive in the first place. Constructing the geo-object and > putting it in relation to other objects should really happen on separate > layers.
Hmm...that's interesting. I don't like adding tables when it's not necessary, as it tends to introduce ambiguities... But how about an "object" table, which would have the same fields as the relation tables plus a field "object_type". Ways would all be converted to objects with nodes as members (and member_type "node"). Open ways would become objects with type "linestring". Closed ways could have type "polygon" or type "area" depending whether it's supposed to be filled or unfilled. Relations could have type "relation". Integrity checking would ensure that the type matches the data (e.g. polygons/areas must be closed). New objects can be invented without altering the table structure (preferably this ability would still require administrator intervention, though - I don't like the idea of casual editors inventing their own object_types willy nilly). Current: way_nodes, way_tags, ways, relation_members, relation_tags, relations. Proposed: object_members, object_tags, objects > I would also hope that along with a proper area data concept would come the > ability of the API to return an area to the caller even if the area fully > encompasses the queried bounding box. That's basically just an index issue. Now that the database is on Postgresql, updating it to use postgis features will probably go a long way. Some sort of tile-based caching would probably help too. If it's still too much strain on the main database, a read-only cache which potentially lags the live data could definitely do it. As it is, the API wont even return a way which passes through a bounding box, if none of its nodes are located within the bounding box. It's not a schema problem so much as a performance/indexing problem. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
