[OSM-talk] RFC - postal addresses (relations)

[Lester Caine]

Andy Robinson (blackadder) wrote:
> Lester Caine wrote:
>> Sent: 13 January 2008 8:07 AM
>> To: OSM Talk
>> Subject: Re: [OSM-talk] RFC - postal addresses (relations)
>>
>> Claus Färber wrote:
>>> I've written a proposal for postal addresses:
>>>
>>>
>> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Postal_Addresses
>>> It covers more than house numbers, i.e. it includes streets, postal
>>> codes, etc., even countries).
>>>
>>> However, the proposal does not allow putting some house numbers on a map
>>> and having the rest be interpolated); this should, IMO, be handled
>>> differently (and discussed at
>>> http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers).
>>>
>>> Due to the nature of postal addresses, the proposal overlaps with the
>>> tagging of geographic areas, such as countries, regions, etc.
>> This is going to be another area where international differences are going
>> to
>> hinder agreement, simply because of the local 'restrictions' on how a
>> 'postal'
>> address can be constructed.
>>
>> But the main problem I am seeing with this proposal is the complete lack of
>> integration into the maps?
>>
>> The proposal seems to be adding a complete new layer of tags, when what is
>> needed is a means of identifying the hierarchy of the existing data.
>>
>> I have a major interest in this currently as I am DEEP in the middle of
>> enhancements to my own commercial software to add and manage NLPG data. The
>> National Land and Property Gazetteer provides a unique property reference
>> number for every building and parcel of land in England and Wales. At some
>> point it will also have data for the boundaries of every property as well.
>> At
>> present it has a location coordinate which I currently have mapping onto
>> OSM
>> with a fair degree of accuracy - except that the area I have access to data
>> for is still rather incomplete on OSM.
>>
>> The layer above the uprn (unique property reference number) is the usrn -
>> unique street reference number, and every property reference has to access
>> a
>> valid street reference. ( As an aside - while these are country specific,
>> some
>>  means of adding such a well defined reference would be appropriate? )
>>
>> The POINT I am getting at here is HIERARCHY - and while I am a little
>> blinkered in my approach - simply because the current data that I am
>> working
>> with *IS* well structured. I've realised what is wrong with *IS_IN* and
>> it's
>> the fact that it's not being used to create hierarchic links! Every node
>> 'is_in' the map, but now we need to add the sub layers! I was thinking that
>> we
>> needed to sort out 'boundaries' so we can brake up the current mass of
>> data,
>> but what we are missing is simply STRUCTURE.
>>
>> We need the boundaries, but rather than trying to rely on reading
>> coordinates
>> to establish if a node is inside or outside a boundary, we need the 'is_in'
>> relation. We ignore the nodes and look at the bigger picture. We create
>> some
>> high level 'boundaries' - the boundary:continent, and then and countries
>> within them. Every country will at some point have a boundary and it is
>> probably the boundary tag that gives us the missing hierarchy since we need
>> a
>> set of country boundaries. Every boundary:country will have an is_in to the
>> boundary:continent. The next layer down becomes more country specific, and
>> it
>> may well be that we have several different types of boundary:county/state.
>> A
>> specific example here is boundary:country of the UK would be THE UK, and we
>> then need boundary:sub-country 'ENGLAND' before going down to
>> boundary:county/state and boundary:ward or boundary:parish AND IMPOTENTLY
>> boundary:city/town/village. It may be that we have to provide 'split'
>> boundaries for some places where parts are within different higher level
>> boundaries, but place would have a single boundary reference, and
>> place/east
>> and place/west would then have different 'is_in' relations. It is probable
>> that we would have multiple 'is_in' relations at some levels, but normally
>> you
>> would only be referring to one level above. So boundary:city/town/village
>> refers to boundary:county/state -> boundary:county/state or
>> boundary:country
>> and we have Gloucester, Gloucestershire, England, UK, Europe ...
>>
>> STREETS then refer to the the town and we have no need to create yet
>> another
>> hierarchy for postal addresses. A building 'is_in' a street ...
>>
>> SEARCHING for things then becomes simple as well?
>>
>> THIS is the bigger picture I have been trying to get across :(

> I agree with most of your sentiment here in that we have most of the
> elements in the database already to define an address but currently have no
> way of expressing it. The big problem will always be though that we cannot
> enforce a tight structure. Contributors don’t want to be told that they must
> add certain tags for the data to be acceptable. Thus we have to think a
> little differently. 
> 
> In my view, and I've been working on this approach for some time now, we can
> define a structure for our tags after the tags themselves have been created
> and used. The contributors don't need to know about this structure at all,
> they get on and add and edit data as normal. But when we want to mine the
> data we deliver it in a structure that has meaning. Presently we have no
> structure for the delivery of tags at all. Perhaps taking this type of
> approach we might be able to imply a street is in a particular town etc etc
> etc by how the data is delivered, for instance the closest Country name,
> City Name, Town name etc might be included with the data set. These just
> need an extension of the API (or via another source like zappy) to provide
> data in alternative formats.
> 
> Options like this move the problem to the hardware/software end and remove
> the heavy burden on the user. If we can keep it sublimely simple (KISS) for
> the data contributor then we have a much better chance of getting the type
> of data we need for a more complete map of the planet.

Andy - check out the tidied up notes in missing structure thread.

On the KISS line. If 'is_in' tags are verified to check that the record they 
are linking to actually exists then I think we are 90% of the way there.

Otherwise we end up just overloading the hardware with yet another layer of 
unrelated data :( Alternatively I just expand 
http://home.lsces.co.uk/lsces/nlpg/list_county.php?list=county and build my own :)

-- 
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