OSM is geospatially aware. I'm unsure why there's a reluctance to use it.
is_in tags are far more "incomplete and imperfect" than boundaries.
Boundaries are maintained far more than the antiquated is_in:*.
*Every* entity will require a full set of is_in tags to be workable.
If an entity is in "no-mans-land" of boundaries, it will be in
"no-mans-land" if tag with is_in, Using geospatial calculation with
boundaries it will know it's 'outside' but be able to find the nearest
area. Describing it a 'near to...' isn't perfect but better than nothing
which is what you'd get using is_In.
DaveF
On 22/08/2017 12:23, Colin Smale wrote:
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
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-gb
_______________________________________________
Talk-GB mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-gb
