Let's have some use cases out on the table... if my location is
{lat,lon}, where am I? What answer am I expecting? Postal address? Town
or other settlement? The local council? What would a "local" answer?
In the UK, the hierarchy of admin boundaries is incomplete and imperfect
- there are unparished areas, and combined authorities for example.
There are so many black holes in the UK - where you are in no-mans-land
"between A and B but in neither." If nobody lives there, is it actually
necessary to be able to say where you are?
If you ask people where they live, they will probably talk about the
county level and the settlement/town/city, but the informal boundaries
of these settlements will likely not follow the administrative
boundaries. In fact, it may not be possible to agree a polygon with a
sharp boundary of what constitutes a settlement with a given name. Most
place=* polygons in OSM just follow the boundary of the built-up area.
So I see a possible role for is_in - to help out geocoding where
geometrical methods lead to an undesirable (though accurate) result.
//colin
On 2017-08-22 12:57, Dave F wrote:
> This is a reply to a Q. I posed on Talk. Nominatum clearly prefer boundaries
> to is_in & say it's not heavy processing:
> https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html
>
> As UK boundaries are sure be updated in OSM, keeping the secondary is_in
> 'cleanly managed' will be a major task.
>
> On 22/08/2017 09:38, Lester Caine wrote: On 12/08/17 13:12, Dave F wrote: I
> also think the 'is_in:country_code' along with all 'is-_in' tags are
> redundant if there's a boundary tag.. In the past I thought that the is_in
> element was something of a problem,
> but it does have a place when one remembers that OSM is all about the
> data. "if there's a boundary tag" is the problem here if one is
> extracting a set of data? Processing a number of boundaries around a set
> of objects takes time, while cleanly managed is_in:admin_area with a
> proper hierarchy allows a much quicker lookup of information such as -
> in the case of the the UK - parliamentary boundaries, wards, historic
> county, NHS admin area and so on without having to physically draw every
> fine detail of these ever changing boundaries. BUT it only works well if
> there is a well defined hierarchy so tagging is_in:gb-ward
> http://geoportal.statistics.gov.uk/datasets/417e93f21c5c419283ac23abc8eedcce_0
> gives all this data in a format we can freely use as with the other
> 'boundary' data.
>
> It is just a pity that 'postcode' is so badly organised that it quite
> regularly straddles these other boundaries, but is_in:gb-postcode would
> remove the need to add all of the associated address data to every
> object on a particular street, and for the vast majority of postcodes it
> WOULD also identify all of the other is_in: data at a higher level. It
> just needs an object defining is:gb-postcode and is:gb-ward to provide
> all the hierarchy ... without overloading the server with searches for
> all of the boundaries intersecting the original dataset?
>
> Of cause I am also still looking to maintain access to historic data,
> and this model makes it easy to check start and end dates of
> is:gb-postcode and is:gb-ward without having to maintain all of those
> boundaries actually in the base dataset - something which the majority
> of users seems to have decided against :(
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
