Hi, Steve Hill wrote: >> Your concept is utterly unworkable of course with the current software >> landscape, > > Would you like to explain why it is utterly unworkable?
Every single OSM tool treats relations as some "nice to have" extra, whereas I understood your concept to make them central. A way would not have any meaning by itself but only in the context of a relation. I believe this would require a major re-write of many tools to remain halfway efficient, thus my verdict of "utterly unworkable with the current software landscape". > I'm not sure what you mean by this - Every object on a map is a > geometric object, so what are you claiming is the difference between "a > geometric object with some properties" and an "object with some > properties"? An object with some properties among which them one is the geometry. The difference is about the identity of the object. Our current model makes the geometry the identity; a way is defined mainly by its geometry, and everything else is secondary. A way, as the central meaningful object class in our database, is "a line on the map with some attributes added". In contrast, if you make a relation (or some other object type) your central object, then your central object class will become abstract; no more will it be something that can be drawn on the map by itself. An object would be something like "the M25 between exit 23 and 24", and among its many attributes there will be one that specifies the geometry. (There need not even be - if you know that the road exists but are unable to enter its geometry then you could just leave that empty, just as you can today enter a road without knowing its name.) But maybe I really misunderstood you and you didn't want to go quite that far. > 1. the tagging schemes between relations and other objects are unified. > So the tags "type=road, classification=primary", etc. can be applied to > either a way, or a relation consisting of ways. > > 2. the "type" tag can be used to define a context for normal objects, > much as it does for relations. So rather than having to understand that > a large number of fairly arbitrary tags, such as "highway=road" and > "amenity=school" define what the object is, you now only have to know > that the "type" tag is going to define what the object is. I see. That's much more down-to-earth then. I'm not into re-designing the tagging world at all, but I have often said that I would like to reach an understanding where a relation can be used instead of a way in every context, which bears some similarity with what you're saying but doesn't require the strict type stuff. I thought that if you had a relation that was tagged "highway=motorway" then this should be treated like a way by everyone, with the exception that an extra recursion is required to get at the geometry. A route relation as we know it today would then be able to have relations as members (in addition to ways), and these would be "flattened" for processing. Your concept, then, boils down to another old question: Should we have the logic be in the software (ah, this one has a highway tag, so it probably is a road) or should we have the logic in the database (type=highway). We have the same issue with many other things; for example say you want to distinguish between different types of water bodies. Then you can either tag the full hierarchy like so: natural=water, water=lake - or you can do a natural=lake and expect everyone to know that lake is a "subclass" of water. Putting the logic in the database makes processing easier but creates room for inconsistency and burdens the database with a lot of unnecessary information. Putting the logic in the software makes writing software harder and creates the danger of different pieces of software working to different specification. > Both of these points seem compeltely workable with the current software. Yes, sure, but to be honest it now seems to me like an exercise in cosmetics ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev