Karl Newman wrote: > On Jan 17, 2008 12:52 PM, Lukasz Stelmach <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Lester Caine wrote: > > After my missive in the postal addresses thread I had yet another > scout around > > on what is already available and how it is not being managed well. > > > > All mapping is currently based on physical nodes, but I think > that perhaps we > > need an abstract element that we can hang things on. > [...] > > > Day by day it becomes more obvious to me that sooner or later > segments/ways distinction will be back with us. Look at this. > A way (street) may belong to many relations, right? Each relation > may contain different part of the street, right? Especially in big > cities where bus routes can be relations and each bus may take > different turns, there will bo no single way/highway comprising more > than one segment (to be precise I think about lines between > crossings which in case of curved street may comprise more > segments). There will obviously MUST be invented 'street' replation > which takes a few segmetns and gives them common name. The other > relation (perish?) could contain all the objects that belong to a > certain place including half of the segments of the streets that > connects two adjacent places. > > This shows a little problem which, however, should be automatable, a > new object (node/way|segment) has to be assigned to a different > object (relation) rather then assigning the place relation to the > new object. > > I am just shatring my thoughts, maybe someone can come up with some > thing wiser ;-) > > It seems to me we're going about this all wrong. Instead of splitting up > ways just because any of its attributes change (or to break it up for a > route), it seems like a way which denotes the same street (or other > linear feature) should be as long as possible. Then we could hang > attributes on subsections of it: i.e., for way 1234, the speed limit > from node 5522 to node 5595 is 100 km/h. Or, way 1234 is a part of route > "blue bus" from node 9553 to node 2558. Relations could accomplish this, > but they don't have a rigorous structure to enforce all the parts/data > integrity.
This is missing the point *I* was trying to make and while managing the detail at this lower level IS important, it's the integrity of links to the upper levels that need fixing first. A lot of the higher level relationships could be 'calculated' if we had well established areas and fast searching on geographic position, but in the absence of that, a street, or village 'is_in' a ward, parish, county or other area designation, and these areas are then 'is_in' states or countries. So a simple following of the 'is_in' links provides the hierarchy and the integrity of objects used 'is_in' should be enforced to ensure that there is only one occurrence of the target object ! Just allowing any free format matching does not work! OTHER hierarchy is also appropriate such as 'M1' or 'Ermine Street' but proposing to merge all of the ways associated with them would not work. We do need rules as to how the tagging could be used to identify these sorts of divers structures, and a 'place' called Ermine Street which can then be used in an is_in tag on elements of that road, makes sense, but would distract from identifying the appropriate 'address' for properties on it. Another example is postcode, and a long street that has 4 postcodes SHOULD be four ways ( although there may be several branching ways on some housing estates ) each tagged 'postcode' and is_in 'This street' - it's where the object 'This street' exists that is the problem :( -- Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
