Re: [talk-au] Suburb boundaries - getting close
Good point, I hadn't considered that. I will run some stats on the data - there is a chance that some of the long coastline stretches may be big cheers On Tue, Feb 17, 2009 at 11:43 PM, Stephen Hope wrote: > Another reason not to go for 1 is the limit they've been talking about > on the main list (in 0.6) for points in a way. I think some of the > suburb borders could easily hit that limit. > > 2009/2/16 Franc Carter : > > > > 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 > > > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
Another reason not to go for 1 is the limit they've been talking about on the main list (in 0.6) for points in a way. I think some of the suburb borders could easily hit that limit. 2009/2/16 Franc Carter : > > 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 > ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
BlueMM wrote: > I also like Jack's suggestion on name & old_name, plus the is_in tag. +1 for the is_in tag from me, definitely with ", Australia" appended. My reasons are pretty selfish - My choice of GPS software is Navit and it requires the is_in tag to search for towns. I'd be happy enough to try to modify the software to not require is_in but I haven't seen a better solution. -- Sam Couter | mailto:s...@couter.id.au OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
[snip] > > +1 for Relations (I'm in the Darren camp on this one) > > I also like Jack's suggestion on name & old_name, plus the is_in tag. > > Given Darren's suggestion for au:ABS, I wonder if there are any examples of > country namespaced tags? Obviously ABS is not likely to be unique, maybe > ABS_au > or Jack's abs.gov.au? I think I like abs.gov.au the best (eg. > abs.gov.au:SSC_2006). personally, I don't like the double ':' - but I don't care too much either > > > What is the purpose of ABS:reviewed=no tag? Is it to check for obvious data > errors (like Darren pointed out for the industrial estate - assuming it's > obvious)? > Other than that, at this point we don't really have any other source for > this > data, so how could we possibly review boundaries? There are going to be cases where we can 'know' that a boundary is wrong. For example - 'Breakfast Point' in Sydney is not in the ABS data and it's got some fairly obvious boundaries when you drive around it. > > > Assuming we go with the relations option, and ABS:SSC_2006 is tagged on the > relation, what unique id to we tag the individual ways with? Wouldn't most > ways > be derived from 2 closed-area shapes, therefore ABS:SSC_2006 would have to > be a > combination of the parents id's (which might not be unique when converted > anyway). Agreed, as it looks like we are going with relations (based on votes so far) some tags will only be sensible on certain objects > > > I think once we get our import plan finalised (conversion of ways, tagging > scheme etc.) we should update the wiki and post on the Talk mailing list > with > the plan, to hopefully get some comments from veteran importers (like Tiger > & > the midway Canada importers) Yep, I will do this. I also want to talk to them about the technical side of the import. Running an import of this size is something that should be discussed so that it doesn't clog the server up for weeks. > . > > BlueMM > > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
Franc Carter writes: > 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 -- Franc +1 for Relations (I'm in the Darren camp on this one) I also like Jack's suggestion on name & old_name, plus the is_in tag. Given Darren's suggestion for au:ABS, I wonder if there are any examples of country namespaced tags? Obviously ABS is not likely to be unique, maybe ABS_au or Jack's abs.gov.au? I think I like abs.gov.au the best (eg. abs.gov.au:SSC_2006). What is the purpose of ABS:reviewed=no tag? Is it to check for obvious data errors (like Darren pointed out for the industrial estate - assuming it's obvious)? Other than that, at this point we don't really have any other source for this data, so how could we possibly review boundaries? Assuming we go with the relations option, and ABS:SSC_2006 is tagged on the relation, what unique id to we tag the individual ways with? Wouldn't most ways be derived from 2 closed-area shapes, therefore ABS:SSC_2006 would have to be a combination of the parents id's (which might not be unique when converted anyway). I think once we get our import plan finalised (conversion of ways, tagging scheme etc.) we should update the wiki and post on the Talk mailing list with the plan, to hopefully get some comments from veteran importers (like Tiger & the midway Canada importers). BlueMM ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
+1 for relations for me as well, as it is the future of osm. On Tue, Feb 17, 2009 at 11:41 AM, Cameron wrote: > +1 for relations here. They are less-understood by most people but far more > powerful and flexible. > > ~Cameron > > 2009/2/17 Darrin Smith >> >> On Mon, 16 Feb 2009 22:09:15 +1100 >> Franc Carter 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_2006An 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 >> Talk-au@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-au > > > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > > ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
+1 for relations here. They are less-understood by most people but far more powerful and flexible. ~Cameron 2009/2/17 Darrin Smith > On Mon, 16 Feb 2009 22:09:15 +1100 > Franc Carter 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_2006An 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 > Talk-au@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au > ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
Hi hi, Firstly, having suburb boundaries will allow OSM to be even closer to a UBD replacement :). Anyway, my vote would go for relations. Yes, they're tricky and a lot of people don't understand them but given the current OSM data model they're the right choice. My main argument for relations is that suburb boundaries have a tendency to be defined in terms of roads, creeks etc and including these existing ways will greatly reduce the processing load on OSM. Also, having 3 ways in close proximity (eg, 2 suburb boundaries either side of a road) will get rather ugly when editing. Especially in the flash editor where selecting closely spaced objects can be difficult. Whichever data method is used though this will be a great boost to the OSM dataset, your effort is appreciated. - Original Message - From: Franc Carter Date: Monday, February 16, 2009 10:10 pm Subject: [talk-au] Suburb boundaries - getting close To: OSM Australian Talk List > 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 > representthe > 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 > > > -- > Franc > ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
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 > > 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_2006An 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
Re: [talk-au] Suburb boundaries - getting close
On Mon, 16 Feb 2009 22:09:15 +1100 Franc Carter 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_2006An 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 Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries - getting close
On Mon, 2009-02-16 at 22:09 +1100, Franc Carter 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 would be for option 1. I won't bore the list by repeating all the reasons for that. > 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_2006An 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=? Suggest that where there's an old name, put it in an old_name= tag. Then, with the current name in name= and the old name in old_name=, there'd be no need to keep the ABS:NAME_2006 field. Similarly, it would make sense to put the contents of the STATE_2006 field in an is_in= tag, preferably with ",Australia" appended. If we're going to keep this field in the dataset, it may as well be in a format that's consistent with what's already used. ABS:reviewed=no & ABS:SSC_2006=foo would both seem essential, for tracking changes, as would the source= tag to satisfy the license. > The 'ABS' part is just a suggestion - It's a bit short for my liking Yeah, "ABS" does sound a bit short, but then again, "Australian_Bureau_of_Statistics" sounds kinda long. How about "abs.gov.au"? - short enough to type in one breath (e.g. for search) but still uniquely identifiable. > We also need to decide where these tags go - nodes, ways, relations. I think tagging the nodes is a bit pointless, with only three possible exceptions: (a) if the dataset includes central nodes for each suburb, in which case I'd suggest tagging those, but not any other node; (b) if the attribution requirement of the license mandates attribution on everything (in which case tagging nodes with just a source= tag should suffice); or (c) if you plan to update the dataset in some sort of automated manner in the future (in which case the nodes probably only need the ABS:SSC_2006=foo tag) - but from earlier discussions on the list, this does not seem to be the case. If you go with option 1 or 3, then obviously the ways need to be tagged. Under option 2, I'd suggest tagging both the relations and the ways, so the data can be used in as many different manners as possible. Just my 2c worth... Regards, Jack. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
