On Tue, Feb 23, 2010 at 2:33 AM, John Smith <deltafoxtrot...@gmail.com>wrote:
> On 23 February 2010 17:30, Anthony <o...@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.
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
