[OSM-talk] Mapping streets as areas - can I do it now?

Anthony osm at inbox.org
Tue Feb 23 14:33:23 GMT 2010


On Tue, Feb 23, 2010 at 2:33 AM, John Smith <deltafoxtrot256 at gmail.com>wrote:

> On 23 February 2010 17:30, Anthony <osm at inbox.org> wrote:
> > Perhaps they did, but they would be wrong.
>
> Because of hindsight?
>

No, because ways aren't powerful enough to build complex data structures.

> Relations are recursive - they can contain other relations.  Ways can only
> > contain nodes.
>
> You missed the point, I'm just giving examples to show that people who
> think everything we need, we already have at our disposal, the
> suggestions on this I've made in the past require changes to database
> tables etc to work, rather than trying to shoe horn existing tools to
> do something they aren't very well suited for.
>

The power of OSM is that we can create new data types without bugging the
DBAs and the people with svn access.  When we decided we wanted to map
barriers we didn't have to add a barrier table - we just took the existing
way structure and gave it a barrier tag.  However, as I said above, ways
cannot contain other ways, they can only contain nodes.  So when it came to
building a data structure which contained multiple ways (quintessential
example being the multipolygon), ways alone were not sufficient - we needed
relations.

The idea of building multipolygons (aka "complex multipolygons" in
OSM-speak) using relations was really a wonderful idea.  Kudos to whoever
came up with it.  I don't think they were the type of structure that was
intended by relations, since relations has that silly term "relation"
instead of a more powerful name like "object".  But, in any case, the power
was discovered - and is being used to great effect right now - without ever
having to go through the hassle of creating a new table in the database and
new code in the svn.

Interestingly, now that we have relations, we don't actually need ways any
more - a relation can do everything that a way can do and then some.
However, 1) we might as well keep them around for backward compatibility
purposes; and 2) they make the job of database optimization a little bit
simpler.

In any case, my point is that requiring the DBAs and developers to get
involved every time you come up with a neat idea for a new data type just
doesn't make any sense.  You already have the tools to build what you want -
show that your design is sound first and then if it catches on you can
always convert your relation type to its own table later.  If I thought you
had a sound design in the first place I would have already shown you how the
same thing can be accomplished (just as elegantly) using relations, but so
far you haven't convinced me of that.

If it turns out there's something in your design which really can't be
handled elegantly without adding a new table - fine, but then I'd suggest a
more general solution so that we're not once again tied to the developer
cycle every time a new idea comes along.  In any case, I don't see it
happening.  Just take the name of the table and put it as the relation
type.  Then take the fields of the table and make them keys in the
relation.  Or, if any of those fields are foreign keys into the nodes, ways,
or relations table, designate them as members.  When you get into the
billions of rows and the database starts slowing down, *then* you can talk
about splitting those rows out into their own table.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20100223/a790aca6/attachment.html>


More information about the talk mailing list