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