Re: [talk-au] Suburb boundaries - getting close

2009-02-17 Thread Franc Carter
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

2009-02-17 Thread Stephen Hope
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

2009-02-17 Thread Sam Couter
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

2009-02-16 Thread Franc Carter
[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

2009-02-16 Thread BlueMM
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

2009-02-16 Thread Peter Ross
+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

2009-02-16 Thread Cameron
+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

2009-02-16 Thread b . schulz . 10
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

2009-02-16 Thread Ben Kelley
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

2009-02-16 Thread 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


Re: [talk-au] Suburb boundaries - getting close

2009-02-16 Thread Jack Burton
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


[talk-au] Suburb boundaries - getting close

2009-02-16 Thread 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


-- 
Franc
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au