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

Andy Robinson (blackadder) blackadderajr at googlemail.com
Sun Jan 13 14:47:33 GMT 2008


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 :(
>
>--
>Lester Caine - G8HFL
>-----------------------------

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.

Cheers

Andy





More information about the talk mailing list