Karl Newman wrote: > On Jan 29, 2008 10:56 AM, Lester Caine <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Robin Paulson wrote: > > one of the tag proposals i've been working on recently has got me > > thinking about tagging composite items, and the best way to do it. > > > > in the case of a large site, say a hospital, university or coalmine, > > is there any consensus on how to collectively tag all the buildings, > > sports fields, car parks, etc. so that they are marked > individually as > > whatever they are, but also identified as being part of a greater > > whole? > > > > for instance, say i ask for all the car parks near me, it would be > > good for my routing software to tell me that there's one nearby, and > > for it to implicitly know it's within the boundary of the hospital. > > > > is this best done with relations, or is that over-complicating > things. > > can any part of osm work out all the areas a given point lies within? > > this is subtly different to the problem of administrative boundaries > > we were talking about recently as we generally can get good > > information on the boundaries of entities like hospitals, etc. > > is_in being populated and stored is always going to be quicker to > search than > trying to process a multitude of complex boundaries to find out if a > node is > inside or outside the enclosed area? More so on larger boundaries, > but non the > less a university campus or hospital with multiple buildings, car > parks and > other points of interest will return a simple list via correct is_in > relations, while searching for nodes within boundaries my not > actually give > the right results were nodes are within the boundary area, but not > actually > defined as part of the whole. > > That is not to say that a set of is_in relations can't be generated > from the > graphics. Just that there may need to be a means of editing the > results. Which > is why I'm convinced that correctly managed is_in hierarchy is > essential long > term. > > > Well, that's not in keeping with the principle of being easy on the > mappers. Requiring everyone to tag every entity with an is_in tag seems > unworkable and brittle to future change. What do you put in that tag? > Which admin level or whatever do you pick? What if you decide to change > it later? Not insurmountable problems, to be sure, but it seems like a > lot of extra work. Providing boundary information ("what boundaries > contain this node?") is not necessarily a function that the main API has > to provide. Boundaries could be processed offline from a planet dump and > then maybe set up with a web service for querying.
You have answered your own question! And this as been beefed out in a number of my previous 'missives'. *HOW* an is_in tag is populated is the whole problem. The currently random data being put into there MUST be controlled much better, and processing boundaries off-line may be one way of verifying that data, but the starting point was simply to prevent using 'objects' in the is_in entry that do not exist already as places in the data. Since the larger areas do not have complete boundaries, manually entering Europe in a COUNTRY place record or England in an English county record removes the need for those boundaries to be completed at this stage - if ever? Just doing a "what boundaries contain this node?" has the problem of where do you stop. While the is_in lookup will GIVE all the higher level hierarchy without having to check the larger boundaries? There will be problems with overlapping boundaries such as has been identified in the US where some towns straddle other areas, but this could be just as difficult to unravel from the boundary data, so manual intervention to un-knot the is_in data my be essential anyway. Of cause the main problem here is simply not having unique references which can be used to select the correct place element. *ADDING* all of the higher level hierarchy in a place name is equally confusing and unmanageable :( http://wiki.openstreetmap.org/index.php/Key:is_in explains it's own problem nicely, but adding unique id's to places is something that only the API could handle :( -- 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
