[RNFdev] Some thoughts of FSA Centroids and Polygons

[Dan Putler]

Hi Dave,

Sorry for being a bit thick, but I am still not sure I understand  
exact problem you are trying to tackle. I think the process you are  
proposing makes sense in terms of creating polygons that have "good  
hygiene".  Although, there are a couple of comments/questions. First,  
the thinned RNF typically won't produce closed polygons based on the  
road segments alone, and we will need to digitalize some of the non- 
road line segments. Any overshooting and undershooting problems will  
largely be associated with the added line segments as opposed to the  
original RNF road segments (working with this data, it looks like  
StatsCan did a thorough job of cleaning the geometry of the road  
segments, so they tend not to overshoot or undershoot, assuming they  
exist at all in the RNF). However, your basic point that the polygons  
will need some post creation cleaning is spot on. Although, as  
indicated above, in the vast majority of cases the problems will be  
with the added segments, so it will likely be more of an issue of  
fixing less than perfect added segments, more than investigating the  
causes of the error.

In terms of the attribute data, my guess is that we will need to  
create FSA polygons on a one by one bases. As a result, I think it  
makes more sense to add an attribute table with the FSA field to the  
polygon at the time of its creation. I don't think it would be too  
hard to modify Frank's  python script to do this.

Let me know if I'm still not understanding the issue.

Dan

On 28-Sep-06, at 6:15 AM, Sampson, David wrote:

> I guess my brain storm made sense to only my brain.
>
> I'll try to clarify. Some abstract thought was probably involved in my
> brain.
>
> The polygons I originally referred to were polygons created by the
> thinned out RNF.... When a network of roads create a filled in shape
> this can be thought of as a polygon. So changing the road network to a
> series of polygons. This is obviously an imperfect method for all  
> areas,
> but may work well for the urban areas.
>
> Then the FSA centroids will occur SOMEWHERE within these polygons...
>
> These FSA centroids can act as vector polygon labels. These labels  
> hold
> the attribute data about a particular polygon.
>
> 1. Change vector lines to polygons
> 2. clean danglers and overshoots (loose ends that extend PAST an
> intersection
> 3. investigate undershoots (where two lines have not meta and  
> require a
> virtual extension or more data
> 4. Attribute tabular data through the FSA centroid as labels
> 5. investigate tagged polygons as bellow
>
> Does this make more sense?
>
> What is your unfeasible idea?
>
>
> -----Original Message-----
> From: Dan Putler [mailto:putler at sauder.ubc.ca]
> Sent: September 27, 2006 16:43
> To: can_rnf at geodata.osgeo.org
> Subject: Re: [RNFdev] Some thoughts of FSA Centroids and Polygons
>
> Hi Dave,
>
> I'm unclear on a couple of things. You indicate:
>> The thought is
>>
>> 1. Create the reduced RNF
>> 2. Create the FSA Centorids
>> 3. in a GIS import both the reduced RNF and the FSA centroids 4. do
>> some queries:
>>         a. find all polygons with one FSA point
>>         b. find all polygons with more than one FSA point
>>         c. find all polygons lacking any FSA tag 5. use this info to
>> help with manual edits.
> What I'm confused about two things. First, which polygons are you
> referring to above? The reduced RNF contains only road segments and
> other lines (not polygons), FSA centroids contains only points, or are
> you referring to the CSD polygons? The mention of FSA centroids  
> leads to
> my second question, specifically, are the FSA centroids the ones
> available from geoconnections? If yes, they appear to have some  
> accuracy
> issues.
>
> I've also been thinking about other things we could that would be  
> easier
> than creating FSA polygons. I have an idea, but I don't know if it
> feasible.
>
> Dan
>
>> From that we can hypothesise that in
>>         case A the polygon is either correct (requiring some manual
>> cleaning) or requires enlargement (manual merges maybe)
>>
>>         case B the polygon requires additional information such as
>> other non-road features
>>         case C the polygon has been split too much and something
>> needs to be blown away.
>>
>> Some of this might be able to be automated or atleast again a
>> probability choices made.
>>
>> Any thoughts
>>
>