Hi. I would go for option 2 for pretty much the reasons Darrin suggested. Closed ways would mean that every way would be duplicated (one way for the suburb on one side, and one way for the suburb on the other side).
Do we have any idea how relations render, and how they are supported by other tools? (e.g. OSM->Garmin, other routing tools, namefinder) I think your tag suggestions look fine. It would be good to avoid needing to tag nodes, but I agree that we might need some kind of ID on nodes if we were ever going to re-import. Is a re-import realistic? Presumably at some point the ABS will update their data, but will it be possible to correlate their new data to the old data? e.g. Will the NAME_2006 ID match the NAME_20xx ID? - Ben Kelley. 2009/2/16 Franc Carter <franc.car...@gmail.com> > > 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 > > 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 > > 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 > >
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
