The two examples below illustrate the issue Query1: [out:csv("name";false)] [bbox:-33.9480172,151.1107534,-33.8594833,151.2207935]; area[name="Sydney"]; way(area)[highway][name]; out; One of the many results (after obtaining lat-lon and distance) is: Airport Drive, Sydney, 2000, -33.9272726, 151.1694315, 2.637km Query 2: [out:csv("name";false)] [bbox:-33.9480172,151.1107534,-33.8594833,151.2207935]; area[name="Mascot"]; way(area)[highway][name]; out; One of the many results (after obtaining lat-lon and distance) is: Airport Drive, Mascot, 2020, -33.9272726, 151.1694315, 2.637km The two results are essentially identical (eg lat-lons) except for the name of the suburb. The problem appears to be due to there being an Administrative Area called Sydney which embraces all suburbs. Also, within the all-embracing Sydney, there is a relatively small suburb area also with the name Sydney (Both of admin level=10). If one is looking for streets in suburbs within a largish BBox well inside the larger Sydney (which includes by design, the smaller Sydney), a large number of 'duplicate' (spurious) streets are generated with a suburb name of Sydney, it would seem, due to the outer Sydney boundary. How can such a situation be avoided? asked 19 Aug '20, 03:35  rorylila |
One Answer:
My bad! I had checked the admin_levels of both the inner and outer Sydneys and concluded they were both 10. However, re-checking, the admin_level of the outer Sydney is 7. Changing the definition of 'area'in the query corrected the problem: area["boundary"="administrative"] ["admin_level"="10"] ["name"="Sydney"]; way(area)[highway][name]; out ; answered 20 Aug '20, 02:54 rorylila |
