+1 for relations for me as well, as it is the future of osm. On Tue, Feb 17, 2009 at 11:41 AM, Cameron <[email protected]> wrote: > +1 for relations here. They are less-understood by most people but far more > powerful and flexible. > > ~Cameron > > 2009/2/17 Darrin Smith <[email protected]> >> >> On Mon, 16 Feb 2009 22:09:15 +1100 >> Franc Carter <[email protected]> wrote: >> >> > Ok, it seems my conversion script is now producing sane results so >> > it's time to work out what the final output should look like. >> > >> > The first question that I think we need to answer is, how do we >> > represent the >> > data in OSM, there appears to be 3 options:- >> > >> > 1. Closed ways >> > 2. Relations >> > 3. Borders with a left/right tag >> >> My vote is for #2, and I'd be strongly against the use of #3 since it's >> essentially the system #2 set out to replace and is so dependant on way >> direction and making adjoining suburbs all match directions vs >> left/right will be painful. #1 is a fine choice in city regions but I >> think it will cause ways to be too large in country regions, it also >> prevents someone telling which suburbs a boundary way lies in. >> >> > Then we need to decide on what tags to apply to the data. The raw >> > data has three fields >> > >> > * STATE_2006 A numerical identifier for the state the suburb is >> > in >> > * SSC_2006 An identifier provided by the ABS >> > * NAME_2006 The name of the suburb, which may have the old >> > name in '()' after it. >> > >> > So, my initial proposal for tags is:- >> > >> > * name=? >> > (with any old >> > name removed) >> > * source=Based_on_Australian_Bureau_of_Statistics _data (ABS >> > ask for this) >> > * ABS:reviewed=no >> > * ABS:STATE_2006=? >> > * ABS:NAME_2006=? >> > * ABS:SSC_2006=? >> > >> > The 'ABS' part is just a suggestion - It's a bit short for my liking >> >> My thought: Make it au:ABS:... that way it flags it as an Australian >> thing, and within Australia I don't think there's too many multiple >> uses of 'ABS' in this context :) >> >> > We also need to decide where these tags go - nodes, ways, relations. >> > And if we go for the left/right approach a decision on how to >> >> I think how far 'down' the tagging goes depends on how we want to >> handle the update every 4 years. >> >> - If we plan to do a point by point check each time then we probably >> need to tag each node with a unique ID number to detect changes. >> >> - If we plan to do more of a diffing of the 2 data sets and updating >> changes only then we can probably get away with just tagging the data >> to the ways. >> >> I think the 2nd option is going to work better for us in the long run >> (given how much adjusting the boundaries are looking to need anyway). >> >> Of course if we choose option #2 above then I think both ways and >> relations will need to be tagged, although the ways will only >> need the source= tag and the unique ID #. >> >> -- >> >> =b >> >> _______________________________________________ >> Talk-au mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-au > > > _______________________________________________ > Talk-au mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-au > >
_______________________________________________ Talk-au mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-au
