Re: digtize => surface => grdcontour

[Charlton Galvarino]

Forgot the attachment.

> -----Original Message-----
> From: Charlton Galvarino
> Sent: Monday, November 02, 2009 5:16 PM
> To: 'GMT-HELP@...'
> Subject: digtize => surface => grdcontour
>
> Hi, list.
>
> I have some very simple rasters that I am trying to digitize and turn into
> simple LINESTRING's (to be recognized by either a .shp or in PostGIS).
>
> I have played around w/ GDAL's gdalcontour, but it only traces the outside
> of the thick lines (see attachment for a reduced original image that I
> might start w/).  And there is no easy way for me to collapse it or to
> find the midline of the linestrings.
>
> So what I am playing w/ now is to:
>
> * Read each pixel @ (x,y) via PerlMagick and see how many black pixels
> surround this (x,y).  Save this info in a CSV of the format (x,y,hits).
>
> * Run this CSV through surface.
>
> * grdcontour the new grid and spit out .txt for selected contours.
>
> I think what I'm doing is essentially building up an elevation CSV since
> the pixels in the middle of the thick line will have a greater # of hits
> than those closer to the edge.  I realize it can get a bit garbled if two
> lines intersect, but I'm not worried about that (yet?).
>
> I'm not really asking folks to solve my problem here -- I'm mainly asking
> for encouragement that this is not too boneheaded.  I am not ending up w/
> exactly what I want.  If I surface w/ too coarse a grid, I end up w/
> shapes that look nothing like what I started w/.  If I grdcontour w/ too
> few -C's selected, I don't see much.  I've even tried saving log10(hits)
> in my CSV since I really only care about the peaks.  I also tried only
> writing those hits to CSV that were the absolute peak # of hits, but I
> imagine this created points that were too far apart to be connected via
> surface.
>
> Anyway, is this boneheaded, or am I on the right track?
>
> Many thanks,
>
> Charlton
>
>
>
>
>
> Charlton Galvarino
> 1 [phone] : voice
> 1 [phone] :   fax
> charlton@...
>
> P.O. Box 50960
> Columbia, SC 29250

To unsubscribe, send the message "signoff gmt-help" to listserv@...

[Paul Wessel-2]

I would try this instead:

1. convert your rasters to 8-bit Sun rasterfile with convert.
2. Use grd2xyz -S yourraster.ras=rb/1/0/255 to dump ascii x,y,z of the  
black pixel locations
3. Use gmtstitch to assemble continuous lines from these points.

Might have to play with the arguments in 2.  I am guessing z = 255 is  
which so I am setting that to mean NaN which -S will skip.  May also  
have to split all the black pixels into separate 1-point line segments  
for gmtstitch to work.  Not sure.

Paul

On Nov 2, 2009, at 12:17 PM, Charlton Galvarino wrote:

> Forgot the attachment.
>
>> -----Original Message-----
>> From: Charlton Galvarino
>> Sent: Monday, November 02, 2009 5:16 PM
>> To: 'GMT-HELP@...'
>> Subject: digtize => surface => grdcontour
>>
>> Hi, list.
>>
>> I have some very simple rasters that I am trying to digitize and  
>> turn into
>> simple LINESTRING's (to be recognized by either a .shp or in  
>> PostGIS).
>>
>> I have played around w/ GDAL's gdalcontour, but it only traces the  
>> outside
>> of the thick lines (see attachment for a reduced original image  
>> that I
>> might start w/).  And there is no easy way for me to collapse it or  
>> to
>> find the midline of the linestrings.
>>
>> So what I am playing w/ now is to:
>>
>> * Read each pixel @ (x,y) via PerlMagick and see how many black  
>> pixels
>> surround this (x,y).  Save this info in a CSV of the format  
>> (x,y,hits).
>>
>> * Run this CSV through surface.
>>
>> * grdcontour the new grid and spit out .txt for selected contours.
>>
>> I think what I'm doing is essentially building up an elevation CSV  
>> since
>> the pixels in the middle of the thick line will have a greater # of  
>> hits
>> than those closer to the edge.  I realize it can get a bit garbled  
>> if two
>> lines intersect, but I'm not worried about that (yet?).
>>
>> I'm not really asking folks to solve my problem here -- I'm mainly  
>> asking
>> for encouragement that this is not too boneheaded.  I am not ending  
>> up w/
>> exactly what I want.  If I surface w/ too coarse a grid, I end up w/
>> shapes that look nothing like what I started w/.  If I grdcontour  
>> w/ too
>> few -C's selected, I don't see much.  I've even tried saving log10
>> (hits)
>> in my CSV since I really only care about the peaks.  I also tried  
>> only
>> writing those hits to CSV that were the absolute peak # of hits,  
>> but I
>> imagine this created points that were too far apart to be connected  
>> via
>> surface.
>>
>> Anyway, is this boneheaded, or am I on the right track?
>>
>> Many thanks,
>>
>> Charlton
>>
>>
>>
>>
>>
>> Charlton Galvarino
>> 1 [phone] : voice
>> 1 [phone] :   fax
>> charlton@...
>>
>> P.O. Box 50960
>> Columbia, SC 29250
>
>
> To unsubscribe, send the message "signoff gmt-help" to listserv@...
> <foo.gif>

To unsubscribe, send the message "signoff gmt-help" to listserv@...

[Russell Cuthbertson]

Thought someone on this list may have some brilliant insights into my problem -
or better still have already solved it! Conceptually I am wanting to do the
inverse of pscoast.  

Pscoast combines a series of cells into a polygon (the coastline). I want to
convert a polygon into a series of cells. Cells totally within the polygon would
be rectangles. Cells covering the edge of the polygon may be anything -
triangles, quadrilaterals - depending on how many vertices of the polygon fell
within that cell.

The original polygon can be re-entrant but there will not be any nesting. The
grid size of the cells would be user specified.

Ideally there would need to be some ability to combine small cells that are not
entirely within the polygon with adjacent rectangular cells. This would be based
on some criteria - perhaps, area of cell less than some percentage of full cell
size.

Hope I have explained the problem sufficiently. Any bright ideas?

RussC
Brisbane

To unsubscribe, send the message "signoff gmt-help" to listserv@...

[J.J. Green]

Hi Russ

> Pscoast combines a series of cells into a polygon (the coastline). I want to
> convert a polygon into a series of cells. Cells totally within the polygon would
> be rectangles. Cells covering the edge of the polygon may be anything -
> triangles, quadrilaterals - depending on how many vertices of the polygon fell
> within that cell.

Have a look at GPC

  http://www.cs.manchester.ac.uk/~toby/alan/software/

which allows arbitrary and robust intersection of
polygons. The library is is free for non-commercial
use (but not for commercial use).

I hope this helps!

Jim
--
J.J. Green
http://soliton.vm.bytemark.co.uk/pub/jjg/

To unsubscribe, send the message "signoff gmt-help" to listserv@...