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 ----------------------------- 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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
