[OSM-talk] multipolygon (lake) not rendering

Anthony osm at inbox.org
Mon Oct 26 15:03:03 GMT 2009

On Mon, Oct 26, 2009 at 10:30 AM, Frederik Ramm <frederik at 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

More information about the talk mailing list