[OSM-talk] Data model discussion discussion (fork from Superways again)

Dan Moore writetodan at yahoo.com
Fri Mar 16 21:24:21 GMT 2007

hi all,
didn't somebody create a datamodel mailing list?
anyways, this is tongue in cheek so don't read on if you're in a bad mood.

mapper A says to mapper B, "you know, i don't want to get bogged down in all this model broohaha..."
"yeah, tell me about it," nods B.
"but, really, we should be using supernodes.".
"supernodes?" questions B.
"if we had supernodes, we wouldn't need any of this segment, way rubbish"
"just a moment... are you gone mad?", says B, incredulously.
"well, we'd only ever need nodes and their tags: simplicity INCARNATE.  look,
take your node, add "segment_from=<some unique id>" and get a node at
the other end, add "segment_to=<that id again>" et voila!  a couple of way tags
and way_ref tags and maybe some bezier curve parameters and you've got a
fully-functional map of man's entire domain.  what do you reckon?"
"surely it is a shame you have said this... " B intones, rising darkly from his seat, 
"for as a secret member of the xrubyrender sub-project, i must crush all competing
data model change requests, until our plan to attach ruby rendering closures to all 
map elements has transcended mere key-value status."

...is pretty much what i hear in my head when i read most of these discussions.

there is often little frame of reference.  no agreed set of goals.  no agreed prioritisation of goals.  often 
random intermingling of discussions of database issues vs API syntax issues vs data dictionary vs 
rendering vs whatever.  no agreed roadmap for what qualities the model should strive for in future, 
for staged releases.  and sometimes, literally, no stated reason other than it *could* be done.

essentially, that's why everything seems to go round in circles - you can't agree on *how* if you don't 
have a *common* concept of what you're trying to achieve first.

i'm probably being obtuse / abstract (/ plain wrong), so i've jotted down some *hypothetical* phased 
goals below, in case it helps explain what framing i think is missing at a higher level.
cheers, dan.

A - 0-6 months 
- assume current node/segment/ways structure
- refine data dictionary to allow consensus format for capture of *whatever* information ppl wish to add to DB
- aim to turn around dictionary format definitions in 1 week
- addition to trac of issues / constraints inherent in current model, w.r.t agreed areas of usage e.g. 'render quality', 'ease of
rendering', 'data integrity', 'ease of client dev', 'syntax clarity', 'localisation' etc.
- discussion of data model goals for subsequent phases, against trac-ked areas of usage
B - ~6 months 
- gateway stage, review of DB for non-consensus formats to be updated to agreed formats.
- capacity / usage predictions to be presented by dev
- potential underlying db changes to be presented by dev, including benefits and constraints these might place on data model
- decisions to be made on what, if any, information types to be not allowed / purged
- review of data model issues / discussions / dev reports to decide on critical or highly beneficial changes to implement
- consensus to be formed on future phase timings / goals
C - 6-9 months
- dev/migration of agreed model changes
etc. usw. and so forth

Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.

More information about the talk mailing list