[OSM-talk] Inheritance of roles in nested relations

Dave Stubbs osm.list at randomjunk.co.uk
Sun Dec 21 10:32:42 GMT 2008


2008/12/20 Hugh Barnes <list.osm at hughbris.com>:
> On Sat, 20 Dec 2008 22:53:54 +0100
> Frederik Ramm <frederik at 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


More information about the talk mailing list