[OSM-talk] Mapping everything as areas

[Morten Kjeldgaard]

Anthony wrote:

> Morten,
> 
> On Thu, Nov 26, 2009 at 10:18 AM, Morten Kjeldgaard <mok at bioxray.dk> wrote:
>> It is indeed true that this concept could be expanded to deal with, say, a
>> six-lane highway, a cloverleaf intersection, etc. Fascinating...
>>
>> Well, the internal connections would be constructed from nodes and ways
>> inside the object (but encapsulated from the outside world, so they are only
>> accessible from the object/multiplex itself.) Therefore, the object knows
>> the length of it's internal connections and should be able to answer that
>> question. (Perhaps it sounds like I'm talking about a C++ object but I hope
>> you get the meaning.)
>>
>> In the meantime, I've elaborated a little bit on this idea, illustrated with
>> somewhat more detailed pictures of the intersection. It's on my wiki page [0].
> [snip]
>> [0] http://wiki.openstreetmap.org/wiki/User:Mok0#Multiplex_suggestion
> 
> I think it's great.  The "multiplex" acts sort of like a relation,
> except that it enforces certain constraints rather than letting people
> build structures which don't make logical sense.  I think the concept
> could be extremely extensible.
> 
> What do you think about implementation?  From a database standpoint,
> it looks like a type of relation.  But who enforces the constraints?
> Server-side would certainly best protect the data from corruption.
> Editor imposed constraints would be more in tune with the current OSM
> philosophy (let the mappers do whatever the editors let them do, and
> just mark logically nonsensical situations in weblint).

My feeling is that it will be very hard to introduce something new that does
not stick with the established philosophy.

Here are my thoughts on the data structure:

You are right that this is a kind of relation, but perhaps even more, it is
a miniature instance of a map with an embedded shape?

I guess the novel concept in an OSM context is that there are private things
inside the object that the user does not have access to (or should not, of
course the user can go and edit the XML).

The multiplex object has a list of private nodes and ways. Some of these
nodes are tagged "hotspots". The private ways must start and end in a
hotspot, since these are the multiplex's connection to the outer world.

The object also contains a list of "public" nodes and ways that define the
outer shape of the object, so the user is able to tweak the appearance of
the object. Perhaps the positions of the hotspots as well.

All nodes of the object are relative to an internal origin. When "instanced"
on the map the internal origin is set to the actual coordinates on the world
map. Probably, there is a need for a rotation/skewing operation as well,
which means the object needs to store a 3x3 matrix.

> Any way you can think of that I might be able to help?

TBH I am quite ignorant on how OSM development proceeds, how ideas are
developed and how they are put into real life use. You can certainly help by
enlightening me in that regard :-)

Cheers,
Morten