[RNFdev] Not a pretty picture

[Dan Putler]

Hi Frank,

I assume that a shapefile is a reasonable format. To that end, I've  
attached the shapefile with the boundary linear features for the K2W  
postal code.

The linear features (road segments) that are not ordered within the  
layer. Specifically, two adjoining road segments for the same street  
do not follow one another in the original StatsCan RNF. They are, in  
fact, randomly ordered. Probably to make things render in a more  
attractive fashion. However, the first point of one road segment is  
the same as the last point of the preceding road segment for that  
street (road segments run intersection to intersection). I did not  
use this information in my script (which simply grabs the vertices of  
the line features), but I can see that it could be used order the  
road segments. Where things break down is for linear features that I  
have digitalized. They represent non-road boundaries that are not in  
the RNF itself. These features can be identified since they have a  
NAME attribute of "Fill", and have a value for the RD_SEG field that  
is greater than 3000.

Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: K2W.zip
Type: application/zip
Size: 3660 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/can_rnf/attachments/20060925/5f3beded/K2W.zip
-------------- next part --------------

On 25-Sep-06, at 3:08 PM, Frank Warmerdam wrote:

> Dan Putler wrote:
>> Well, I've created a well behaved radial sort program in R.  
>> Unfortunately, it doesn't completely solve the scrambled vertices  
>> problem when the road segments are used as the basis of creating  
>> the FSA polygons. Below is a screen shot of what I'm getting after  
>> the radial sorting of the vertices, while the second one shows  
>> what I get without sorting the vertices. Both of these are for FSA  
>> K2W. The last thing I could do is take the convex hull of the  
>> vertices, but this would also have problems as well. Based on this  
>> exercise, I don't know whether it is practical to use the FSA  
>> boundary road segments directly in forming FSA boundaries. Frank,  
>> any ideas other than using a radial sort or a convex hull to get  
>> the vertices in the correct order?
>
> Dan,
>
> Is the problem that you are assembling a polygon from a set of linear
> features (roads) without any direct information on how they should be
> stitched together?  I have code for assembling polygons from a set of
> linestrings but it depends on the end of line line string matching  
> only
> one other line string end.
>
> But I got the impression you are starting with a randomly ordered  
> set of
> points that define the polygon border.  If this is the case, it  
> seems you
> don't have enough information to create the polygon in cases less than
> perfectly conditioned situations.
>
> If you can provide some input data in a reasonable accessable  
> format, I
> could look at whether it is easily assembled.
>
> Best regards,
> -- 
> --------------------------------------- 
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http:// 
> osgeo.org
>