2008/12/20 Hugh Barnes <list....@hughbris.com>: > On Sat, 20 Dec 2008 22:53:54 +0100 > Frederik Ramm <frede...@remote.org> wrote: > >> >> Hugh Barnes wrote: >> > It's a shame. You have to admit it's a useful device and would >> > reduce duplication of work (creation and maintenance) and storage >> > significantly. >> >> Sure but it's not something that should be done on the API level. The >> API is intended as an as-simple-as-possible storage engine. How you >> interpret data coming out of the API is your (the client's) choice. >> > > Right. I don't think I suggested the API, just client apps (and > community expectation, I guess). > >> >> I think that in the long run, all tools should be able to, on a >> fundamental level, accept a relation everywhere they would expect a >> way, and then substitute the relation's members. > > That's right. > >> Which would apply >> recursively and thus neatly solve your problem. > > Why would it necessarily apply recursively? > >> I'm not sure there is a need to explicitly tag the fact that >> something is a "parent" or "child" relation in your case. >> > > To provide clear guidance for clients, because as you said — and I think > is right, though I can't currently think of examples — this inheritance > is not always desirable. Also, component=yes prevents someone > deleting something that looks useless on its own. >
Please also bear in mind when thinking these things through that our users are actually going to have to edit these nested relations. They sound pretty good from a data model perspective, but our current editors are going represent everything in an exceptionally unhelpful manner (Potlatch won't show relation members, and JOSM isn't even going to have the "parent" because the map call won't return it). I'm not saying don't try to use the full power of relations, just that editor UI suggestions (and patches!) to properly cope with these use cases are going to be essential :-) Dave _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
