Lester Caine schrieb: > Claus Färber wrote: >> I've written a proposal for postal addresses: >> http://wiki.openstreetmap.org/index.php/Relations/Proposed/Postal_Addresses ... > 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.
This is why is used civicLoc from RFC 4119, which intends to cover all international addresses. Of course, you can't create an address only from the address elements. You will also need an address template, for example: United Kingdom: $LMK $HNO$HNS $PRD $A6 $POD $STS $^A3 $^PC Germany: $A4 $PRD $A6$POD$STS $HNO$HNS $PC $A3 This could even be added as a special tag to the hierarchy level vor which it applies, e.g. '''address:template'''. > But the main problem I am seeing with this proposal is the complete lack of > integration into the maps? There's the '''border''' memeber, which can give the outline on the map. Furthermore, you can add any map element as a member to an address relation. What is not possible is to tag a way or node as '''is_in''' another way, node, or relation. However, this is a restriction of the OSM data model: Only relations can contain other relations. Therefore, it is not possible to add the members to the way forming the area, for example. You need to use a relation to do link ways together, which is what this proposal does. If it becomes possible to add members (i.e. ref elements in XML) to a way, then, yes, the tags should be on the way that marks the border. > 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. The proposal does that. Actually, we may need multiple hierarchies, which overlap in some areas. For example, one hierarchy follows '''type'''='''address''', another one could follow '''type'''='''administrative''' and a third one could follow '''type'''='''geographic'''. Postal Address (includes elements that don't appear in the address template): - United Kingdom (country) - England (a1) - London (a2; a3) - City of Westminster (a4) - St. James's (a5) - Downing Street (a6) - SW1A 2AA (pc) - Downing Street (a6, the part in SW1A 2AA) - 10 (hno) Administrative: - United Kingdom (country) - England (sub-country) - London (region; county) - City of Westminster (city) - St. James's (ward) - Downing Street (street) - 10 (property/site) Geographic (physical): - Earth (planet) - Eurasia (supercontinent) - Europe (continent) - British Isles (archipelago) - Great Britain (isle) - River Thames (waterway) The idea is that elements are shared where they are congruent. There would be a single relation for "England", for example, tagged as: type=address;administrative name=England address:type=a1 administrative:type=constituent_country border=>[way #12345] > 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? ) Yes, you can just add additional tags, e.g. ref:uk:uprn or ref:uk:usrn. Other possible examples are ref:iso3166_1, ref:iso3166_2, ref:unlocode, ref:eu:nuts-1, ... I haven't included them yet to keep the proposal simple. (Furthermore, they belong to an administrative hierarchy, not the postal one.) > 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. Yes, that's exactly > > 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. That's too much work for mappers. It's an enormous task to add everything to a "is_in" relation. However, it is also not necessary because it can be inferred from the location, if the hierarchy is correct. BTW, there are multiple hierarchies that can apply; for example, a node can be in London, England, UK (address/administrative) and in Great Britain, British Isles, European continent (physiogeographic). > We ignore the nodes and look at the bigger picture. We create some > high level 'boundaries' - the boundary:continent, or as a relation: relation #1 type=geo name=Europe geo:type=continent border=>[way #12345] > and then and countries within them. Every country will at some point have a > oundary 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. relation #2 type=address address:type=country border=>[way #12346] is_in=>[relation #1] But wait; there's the physiogeographic sub-division, too: relation #3 type=geo geo:type=archipelago border=>[way #12347] is_in=>[relation #1] > 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. An example of such a case is already shown in http://wiki.openstreetmap.org/index.php/Relations/Proposed/Postal_Addresses#crossing_boundaries I like the idea that they share a "single boundary reference", i.e. in my proposal, they would point to the same way in their '''border''' member. > 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. Yes, these can be differentiated by the '''type''' tag: One hierarchy follows type='''address''' and the other one follows type='''geo''', for example. Claus _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
