[OSM-dev] Relationships - working prototype

[Andreas Brauchli]

On Thu, 2007-08-16 at 23:07 +0200, Christoph Eckert wrote:
> Hi Bart,
> 
> > But isn't it ironic that part of the reason of introducing entities
> > is to solve problems introduced by removing segments or limiting
> > ways to be a strictly sequential list of segments?
> 
> segments have been useful for a long time, but meanwhile have shown 
> disadvantages. Thus there are efforts to drop them.
> The introduction of relationships is not decided yet, and it was not 
> developed to solve problems introduced by dropping the segments.
> Relationships address a wider area. If relationships additionally can 
> help to solve some issues where segments have formerly been (ab)used to 
> model things, why not.

relationships will make editing a lot simpler for a poweruser, but may
confuse the newbie:

advantages
o solves lots of cases which were hard/impossible to do with the 
  current scheme (very static nodes, to change something you always
  have to change the whole way-set)
o any way, node or combination (entity) can be part of a town
  this town-node is part of the district (over-regional entity) node
  which again is part of the state and county/continent node
  so you change a misspelled state-node in one place only and have it
  recursively added to all other sub-entities

disadvantages
o OSM-newbies will find it harder to understand the mechanism, this
  was very easy in the segment-only days or since potlatch. it will 
  be crucial to incorporate this in a seamless manner (JOSM with tag
  selection from a list, hints on entities and help-tips (which can 
  be disabled) and (what i'm the least affraid of) good documentation)
o someone (accidently or willingly) deletes a state node, all
  sub-entries get lost. if this node-deletion isn't undone we'll
  have a lot of widow-childs that are to be converted to the new node
  - a possible solution would be a crediting system that needs you to
  have a certain reputation (probably based on node-creation and
  member-since) in order to write-protect such nodes (readonly=yes)
o the load on the DB will get quite harder as entities will allow 
  much more complex designs. how will this reflect in the api? always
  download the whole entity like in 0.4 where we're always feeding whole
  ways to the client?

other possibilies/ideas
o have an index of countries/states highways and other entities that 
  an editor can fetch from (inside the API may be the cleanest way)
  when downloading/editing a certain area so that the user can choose
  from a list of given (readonly) nodes

i think it's especially important to have a clean design before
implementing it because these are drastic changes (even though good and
necessary). especially people with objections, please shout out!

andreas