[OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]
Hugh Barnes
list.osm at hughbris.com
Mon Nov 3 22:37:44 GMT 2008
On Tuesday 04 November 2008, 07:01:09, Matt Amos did write:
> On Mon, Nov 3, 2008 at 6:47 PM, Frederik Ramm <frederik at remote.org> wrote:
> > If the only thing that connects two objects is that they have a common
> > property, I'd say a relation is not the way to model that.
>
I have been holding back on saying this for a while because (a) I know
relations have come a long way, and (b) without doing more constructive
planning or development, I really have no right. Still, this might inform
future discussion.
I had a very different different idea of what relations were before I looked at
them properly. I was disappointed to see that they just appear to be named
groupings. …
> i think you're right. mathematically speaking, set membership by
> shared properties and explicit references are identical, but that
> doesn't mean that we should treat them as interchangeable :-)
>
+1
… Disappointed because it doesn't seem to add anything that I can see. You can
already do this, as Frederick says, by assigning common properties. That said,
I guess there's a performance advantage, but that is of no interest to me in
the role of mapper. Optimise away from the interface (if that's what's going
on).
So it's more of a grouper AFAICS, far from intuitive (in a moment, I'll
illustrate by explaining my original expectations) and, as Matt is saying, a
little arbitrary in application. Perhaps even a renaming to "groups" would
help.
> it also seems to me that (generally) relationships should indicate
> locality, as this is more meaningful in the context of bounding box /
> map calls. i.e: when i resolve all members of an ldp / route / turn
> restriction, those members (if they are complete) should be connected.
> likewise, if i resolve members of an addr:associatedStreet, i would
> expect the houses to be quite close to the street.
>
This is closer to what I expected. Something like – if you'll forgive me
donning my astronaut helmet for an excursion into space – what Dublin Core do
with the is* and has* properties (e.g. isPartOf and hasPart) and more
generally what we have with RDF predicates, i.e. A [relationship] B.
Here's a couple of uses cases I originally thought I would use relations for,
before I found out they were not much more than groupings (again, I'm often
wrong, so please correct this if so):
1. A bus stop has a relationship to a road. It's not on it, and it can be
tricky to infer it (snap it) with routing software. So I thought I might be
saying "Bus-stop isAdjecentTo Road" or maybe "Bus-stop serves Road". This is
kind of what the left-right proposal was trying to _achieve_.
2. There are several split roads in my area. I thought I'd be able to tag
"WayA isSameAs WayB". I guess that's more for street name searches and indexes
than for routing. You wouldn't necessarily want to find a street listed three
times in an index.
Now that's off my chest. Possibly that's all this contribution is good for.
Even as a distraction, I'd be interested to hear any views about it. Thanks if
you read it. :~)
Cheers - Hugh
More information about the dev
mailing list