[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