Much debate centres around the way features are tagged and how they are rendered (for example recent discussion of golf course tagging, the term 'highway', rendering power lines,...) and it seems that much of this is inextricably involved with the OSM data itself. I wondered if it was time, while OSM is still relatively young and before it becomes too ossified and institutionalised, for the approach to be reviewed.
My own thoughts, for what they are worth, are that the data structure should be language/locale agnostic. For example, ways could have a numeric type field with, hypothetically, 10-19 being used for roads. In this scenario 11 might be a UK motorway, an Italian autostrada or an American interstate, while 19 might be a rough track (10 being reserved for some not-yet-invented super highway, after all some of us were here before motorways). The editors used to input data (Potlatch, JOSM, whatever) would hide this structured data from the user and translate it to/from human language. One immediate advantage is that a German user could tag an autobahn rather than a motorway and global users would not have to use language clearly derived from the British motorway/trunk road/A/B (and little-known C) road classification system. Instead, local nomenclature would be mapped (no pun intended) to the underlying data structure by the local edition of the editor. Highways are an obvious example we are all familiar with, but the principle would apply to all feature types. Places of worship could be mapped as cathedrals, churches, chapels, etc in Britain or as mosques, temples, shrines, whatever in the east. Rendering of the data is I think less tied up with the data itself, but again could be implemented differently by different map viewers. My paper road map of Ireland shows primary roads red in Ulster and green in Eire. Autbahns are green on my map of the Alps while autopistas are patriotically red and yellow on my Spanish map. Local or customisable viewers are possible with the current OSM but not, as far as I know, implemented yet, but the principle of separating the core data from the way it is described and depicted is, I believe, important. Another aspect of the base data structure is that of level-of-detail (LoD) filtering. This is obviously done at present (villages and footpaths disappear as you zoom out) but is dictated by the people who code the viewers and is not, as far as I know, very well addressed in the API, so LoD filtering has to be done after data has been acquired, when it should be possible to specify LoD when requesting data. If LoD were considered in structuring the database it would be easy to filter data (eg. road types 10-13 only or for major ways of all types *0-*3). This is simpler for programming than clumsily using named tags (highway=motorway|trunk|primary) and would be invisible to users who might see autopista, autovia or carretera general. elvin ibbotson _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
