Re: [GRASS-user] re-order boundaries by relative position along polyline

2015-05-27 Thread Dylan Beaudette
Thanks Thomas and Adrien! These are some great ideas. I'll be sure to
check out (haha) github repository when I have chance.

It turns out that a combination of GRASS + R did the trick. Essentially:

1. export snapshot of initial mapping linework via R
 * data are kept in their native, projected coordinate system
2. import into PostGIS
 * data are transformed to GCS WGS84
3. create UNION of exterior ring of initial mapping + interior
ring of adjacent polygons
 * a threshold of 0.0001 (~10 meters) is used to locate adjacent polygons
4. export to shapefile
 * data are converted back to native, projected coordinate system
5. import into GRASS
 * data are converted into a topological vector format with snapping
tolerance of 10 meters
6. generate join document in GRASS and export to shapefile
 * result is a set of line segments, one for each join decision
7. create a unique set of IDs for join decision line segments, based
on a hash of (rounded) segment start and end coordinates in R.

The solution-- which is still a work in progress-- is here:

https://github.com/dylanbeaudette/work-misc/tree/master/join-document

I'll be refining this considerably over the next two days for
field-testing the following week. Ideas welcome!

Dylan




On Tue, Apr 7, 2015 at 8:54 AM, Thomas Adams tea...@gmail.com wrote:
 Adrien,

 Thank you! I'll give it a try...

 Tom

 On Tue, Apr 7, 2015 at 10:44 AM, Adrien André adrien.an...@onf.fr wrote:

 Dylan, Tom,

 not about the main question, but to complete Tom's answer:

 I had once to vectorize a raster stream network according to flow
 direction.
 You can find here the Python script i wrote:
 https://github.com/adrienandrem/r.to.vect.dir

 I hope this helps.


 Regards,

 Adrien


 Le 05/04/2015 14:48, Thomas Adams a écrit :
  Hi Dylan!
 
  (I'm about to start a new position — more on that later). This may help…
 
  I had a problem somewhat analogous to this a little while ago, where I
  needed to create a text file that, among a couple of other things,
  needed to identify the 'downstream' pixel for all grid cells within a
  basin area. I was able to do that with help here, but an issue I had was
  that the integer IDs needed to be numbered from 0-N in basically
  upstream to downstream order, but after my GRASS analysis I had IDs with
  some large number ranging to some other very large number for the IDs
  and the 'downstream IDs' (with values skipped and not in order). I got
  help writing a Perl script that uses hashes for a lookup table to relate
  the old ID to the new ID.
 
  Perhaps you could do something like this, starting with a new vector map
  (copy) where you could simply update the attributes using an SQL query?
  Some coding would be needed, obviously…
 
  Just my 2 cents…
 
  Cheers!
  Tom
 
  On Thu, Apr 2, 2015 at 6:31 PM, Dylan Beaudette
  dylan.beaude...@gmail.com mailto:dylan.beaude...@gmail.com wrote:
 
  Hi,
 
  Once again, I am reminded that complex spatial analysis in other
  software
  can usually be reduced to a couple of lines of code in GRASS--
  thanks!
 
  Here is a fun question. Suppose you have a set of line segments, or
  boundaries that are the result of a digitizing process that
  generated
  segments out of order:
 
2 4  1   3
  O-+-++--O
 
  'O' = start / end point
  '+' = vertex
 
  ... in this case order is associated with order in which records
  appear
  in the attribute table and the order in which segments are drawn on
  the
  screen.
 
  Is there a module, or set of modules that could be used to re-order
  the
  segments so that the order of records in the attribute table and
  drawing
  order is:
 
1 2  3   4
  O-+-++--O
 
  Note that I do not wan't to shuffle the linkages between geometry
  and
  attributes, rather, I would like to re-order the segments and
  attribute
  table according to the linear position within the set of contiguous
  boundaries or polyline.
 
  Here is an example set of lines in ASCII format, WGS84 GCS.
 
  ORGANIZATION:
  DIGIT DATE:
  DIGIT NAME:   dylan
  MAP NAME:
  MAP DATE: Thu Apr  2 11:46:34 2015
  MAP SCALE:1
  OTHER INFO:
  ZONE: 0
  MAP THRESH:   0.00
  VERTI:
  B  6 1
   -118.71960108 36.71846736
   -118.71946261 36.71783146
   -118.71905508 36.71717314
   -118.71863837 36.71610377
   -118.71807413 36.71546352
   -118.71786286 36.71527706
   2 132
  B  3 1
   -118.7153795 36.73403608
   -118.71537992 36.73272737
   -118.71538933 36.73177277
   2 133
  B  3 1
   -118.71536851 36.76205202
   -118.7153724 36.7609144
   -118.71537619 36.75980591
   2 150
  B  2 1
   -118.73128842 36.69749903
  

Re: [GRASS-user] re-order boundaries by relative position along polyline

2015-04-07 Thread Adrien André
Dylan, Tom,

not about the main question, but to complete Tom's answer:

I had once to vectorize a raster stream network according to flow direction.
You can find here the Python script i wrote:
https://github.com/adrienandrem/r.to.vect.dir

I hope this helps.


Regards,

Adrien


Le 05/04/2015 14:48, Thomas Adams a écrit :
 Hi Dylan!
 
 (I'm about to start a new position — more on that later). This may help…
 
 I had a problem somewhat analogous to this a little while ago, where I
 needed to create a text file that, among a couple of other things,
 needed to identify the 'downstream' pixel for all grid cells within a
 basin area. I was able to do that with help here, but an issue I had was
 that the integer IDs needed to be numbered from 0-N in basically
 upstream to downstream order, but after my GRASS analysis I had IDs with
 some large number ranging to some other very large number for the IDs
 and the 'downstream IDs' (with values skipped and not in order). I got
 help writing a Perl script that uses hashes for a lookup table to relate
 the old ID to the new ID.
 
 Perhaps you could do something like this, starting with a new vector map
 (copy) where you could simply update the attributes using an SQL query?
 Some coding would be needed, obviously…
 
 Just my 2 cents…
 
 Cheers!
 Tom
 
 On Thu, Apr 2, 2015 at 6:31 PM, Dylan Beaudette
 dylan.beaude...@gmail.com mailto:dylan.beaude...@gmail.com wrote:
 
 Hi,
 
 Once again, I am reminded that complex spatial analysis in other
 software
 can usually be reduced to a couple of lines of code in GRASS-- thanks!
 
 Here is a fun question. Suppose you have a set of line segments, or
 boundaries that are the result of a digitizing process that generated
 segments out of order:
 
   2 4  1   3
 O-+-++--O
 
 'O' = start / end point
 '+' = vertex
 
 ... in this case order is associated with order in which records
 appear
 in the attribute table and the order in which segments are drawn on the
 screen.
 
 Is there a module, or set of modules that could be used to re-order the
 segments so that the order of records in the attribute table and drawing
 order is:
 
   1 2  3   4
 O-+-++--O
 
 Note that I do not wan't to shuffle the linkages between geometry and
 attributes, rather, I would like to re-order the segments and attribute
 table according to the linear position within the set of contiguous
 boundaries or polyline.
 
 Here is an example set of lines in ASCII format, WGS84 GCS.
 
 ORGANIZATION:
 DIGIT DATE:
 DIGIT NAME:   dylan
 MAP NAME:
 MAP DATE: Thu Apr  2 11:46:34 2015
 MAP SCALE:1
 OTHER INFO:
 ZONE: 0
 MAP THRESH:   0.00
 VERTI:
 B  6 1
  -118.71960108 36.71846736
  -118.71946261 36.71783146
  -118.71905508 36.71717314
  -118.71863837 36.71610377
  -118.71807413 36.71546352
  -118.71786286 36.71527706
  2 132
 B  3 1
  -118.7153795 36.73403608
  -118.71537992 36.73272737
  -118.71538933 36.73177277
  2 133
 B  3 1
  -118.71536851 36.76205202
  -118.7153724 36.7609144
  -118.71537619 36.75980591
  2 150
 B  2 1
  -118.73128842 36.69749903
  -118.73130166 36.69760244
  2 175
 B  5 1
  -118.71538933 36.73177277
  -118.7153944 36.73125742
  -118.71573607 36.73044156
  -118.71618977 36.72875872
  -118.71651025 36.72811846
  2 581
 B  15 1
  -118.71651025 36.72811846
  -118.71661716 36.72766138
  -118.71660977 36.7273294
  -118.71645785 36.72668322
  -118.71689758 36.7261392
  -118.71724087 36.72567564
  -118.71747107 36.7248177
  -118.71753527 36.72390024
  -118.71787045 36.72307308
  -118.71797278 36.72237579
  -118.71781832 36.72073331
  -118.71825483 36.72004703
  -118.71908689 36.71948153
  -118.71963768 36.71863545
  -118.71960108 36.71846736
  2 602
 B  8 1
  -118.7180943 36.70872005
  -118.71827421 36.7083356
  -118.71841915 36.7080259
  -118.7190169 36.70752707
  -118.72008403 36.70694237
  -118.72042476 36.70636815
  -118.72049695 36.70608245
  -118.7212077 36.70547966
  2 604
 B  15 1
  -118.7212077 36.70547966
  -118.721692  36.70506892
  -118.72256889 36.70442599
  -118.72372477 36.702873
  -118.72417965 36.70213899
  -118.72496002 36.70190631
  -118.72660809 36.70183505
  -118.72765407 36.70118732
  -118.72831767 36.70100376
  -118.72866574 36.7007615
  -118.72887421 36.70026501
  -118.72998965 36.69849669
  -118.73066541 36.69798083
  -118.73118943 36.69770441
  -118.73130166 36.69760244
  2 609
 B  8 1
  

Re: [GRASS-user] re-order boundaries by relative position along polyline

2015-04-07 Thread Thomas Adams
Adrien,

Thank you! I'll give it a try...

Tom

On Tue, Apr 7, 2015 at 10:44 AM, Adrien André adrien.an...@onf.fr wrote:

 Dylan, Tom,

 not about the main question, but to complete Tom's answer:

 I had once to vectorize a raster stream network according to flow
 direction.
 You can find here the Python script i wrote:
 https://github.com/adrienandrem/r.to.vect.dir

 I hope this helps.


 Regards,

 Adrien


 Le 05/04/2015 14:48, Thomas Adams a écrit :
  Hi Dylan!
 
  (I'm about to start a new position — more on that later). This may help…
 
  I had a problem somewhat analogous to this a little while ago, where I
  needed to create a text file that, among a couple of other things,
  needed to identify the 'downstream' pixel for all grid cells within a
  basin area. I was able to do that with help here, but an issue I had was
  that the integer IDs needed to be numbered from 0-N in basically
  upstream to downstream order, but after my GRASS analysis I had IDs with
  some large number ranging to some other very large number for the IDs
  and the 'downstream IDs' (with values skipped and not in order). I got
  help writing a Perl script that uses hashes for a lookup table to relate
  the old ID to the new ID.
 
  Perhaps you could do something like this, starting with a new vector map
  (copy) where you could simply update the attributes using an SQL query?
  Some coding would be needed, obviously…
 
  Just my 2 cents…
 
  Cheers!
  Tom
 
  On Thu, Apr 2, 2015 at 6:31 PM, Dylan Beaudette
  dylan.beaude...@gmail.com mailto:dylan.beaude...@gmail.com wrote:
 
  Hi,
 
  Once again, I am reminded that complex spatial analysis in other
  software
  can usually be reduced to a couple of lines of code in GRASS--
 thanks!
 
  Here is a fun question. Suppose you have a set of line segments, or
  boundaries that are the result of a digitizing process that generated
  segments out of order:
 
2 4  1   3
  O-+-++--O
 
  'O' = start / end point
  '+' = vertex
 
  ... in this case order is associated with order in which records
  appear
  in the attribute table and the order in which segments are drawn on
 the
  screen.
 
  Is there a module, or set of modules that could be used to re-order
 the
  segments so that the order of records in the attribute table and
 drawing
  order is:
 
1 2  3   4
  O-+-++--O
 
  Note that I do not wan't to shuffle the linkages between geometry and
  attributes, rather, I would like to re-order the segments and
 attribute
  table according to the linear position within the set of contiguous
  boundaries or polyline.
 
  Here is an example set of lines in ASCII format, WGS84 GCS.
 
  ORGANIZATION:
  DIGIT DATE:
  DIGIT NAME:   dylan
  MAP NAME:
  MAP DATE: Thu Apr  2 11:46:34 2015
  MAP SCALE:1
  OTHER INFO:
  ZONE: 0
  MAP THRESH:   0.00
  VERTI:
  B  6 1
   -118.71960108 36.71846736
   -118.71946261 36.71783146
   -118.71905508 36.71717314
   -118.71863837 36.71610377
   -118.71807413 36.71546352
   -118.71786286 36.71527706
   2 132
  B  3 1
   -118.7153795 36.73403608
   -118.71537992 36.73272737
   -118.71538933 36.73177277
   2 133
  B  3 1
   -118.71536851 36.76205202
   -118.7153724 36.7609144
   -118.71537619 36.75980591
   2 150
  B  2 1
   -118.73128842 36.69749903
   -118.73130166 36.69760244
   2 175
  B  5 1
   -118.71538933 36.73177277
   -118.7153944 36.73125742
   -118.71573607 36.73044156
   -118.71618977 36.72875872
   -118.71651025 36.72811846
   2 581
  B  15 1
   -118.71651025 36.72811846
   -118.71661716 36.72766138
   -118.71660977 36.7273294
   -118.71645785 36.72668322
   -118.71689758 36.7261392
   -118.71724087 36.72567564
   -118.71747107 36.7248177
   -118.71753527 36.72390024
   -118.71787045 36.72307308
   -118.71797278 36.72237579
   -118.71781832 36.72073331
   -118.71825483 36.72004703
   -118.71908689 36.71948153
   -118.71963768 36.71863545
   -118.71960108 36.71846736
   2 602
  B  8 1
   -118.7180943 36.70872005
   -118.71827421 36.7083356
   -118.71841915 36.7080259
   -118.7190169 36.70752707
   -118.72008403 36.70694237
   -118.72042476 36.70636815
   -118.72049695 36.70608245
   -118.7212077 36.70547966
   2 604
  B  15 1
   -118.7212077 36.70547966
   -118.721692  36.70506892
   -118.72256889 36.70442599
   -118.72372477 36.702873
   -118.72417965 36.70213899
   -118.72496002 36.70190631
   -118.72660809 36.70183505
   -118.72765407 36.70118732
   

Re: [GRASS-user] re-order boundaries by relative position along polyline

2015-04-05 Thread Thomas Adams
Hi Dylan!

(I'm about to start a new position — more on that later). This may help…

I had a problem somewhat analogous to this a little while ago, where I
needed to create a text file that, among a couple of other things, needed
to identify the 'downstream' pixel for all grid cells within a basin area.
I was able to do that with help here, but an issue I had was that the
integer IDs needed to be numbered from 0-N in basically upstream to
downstream order, but after my GRASS analysis I had IDs with some large
number ranging to some other very large number for the IDs and the
'downstream IDs' (with values skipped and not in order). I got help writing
a Perl script that uses hashes for a lookup table to relate the old ID to
the new ID.

Perhaps you could do something like this, starting with a new vector map
(copy) where you could simply update the attributes using an SQL query?
Some coding would be needed, obviously…

Just my 2 cents…

Cheers!
Tom

On Thu, Apr 2, 2015 at 6:31 PM, Dylan Beaudette dylan.beaude...@gmail.com
wrote:

 Hi,

 Once again, I am reminded that complex spatial analysis in other software
 can usually be reduced to a couple of lines of code in GRASS-- thanks!

 Here is a fun question. Suppose you have a set of line segments, or
 boundaries that are the result of a digitizing process that generated
 segments out of order:

   2 4  1   3
 O-+-++--O

 'O' = start / end point
 '+' = vertex

 ... in this case order is associated with order in which records appear
 in the attribute table and the order in which segments are drawn on the
 screen.

 Is there a module, or set of modules that could be used to re-order the
 segments so that the order of records in the attribute table and drawing
 order is:

   1 2  3   4
 O-+-++--O

 Note that I do not wan't to shuffle the linkages between geometry and
 attributes, rather, I would like to re-order the segments and attribute
 table according to the linear position within the set of contiguous
 boundaries or polyline.

 Here is an example set of lines in ASCII format, WGS84 GCS.

 ORGANIZATION:
 DIGIT DATE:
 DIGIT NAME:   dylan
 MAP NAME:
 MAP DATE: Thu Apr  2 11:46:34 2015
 MAP SCALE:1
 OTHER INFO:
 ZONE: 0
 MAP THRESH:   0.00
 VERTI:
 B  6 1
  -118.71960108 36.71846736
  -118.71946261 36.71783146
  -118.71905508 36.71717314
  -118.71863837 36.71610377
  -118.71807413 36.71546352
  -118.71786286 36.71527706
  2 132
 B  3 1
  -118.7153795 36.73403608
  -118.71537992 36.73272737
  -118.71538933 36.73177277
  2 133
 B  3 1
  -118.71536851 36.76205202
  -118.7153724 36.7609144
  -118.71537619 36.75980591
  2 150
 B  2 1
  -118.73128842 36.69749903
  -118.73130166 36.69760244
  2 175
 B  5 1
  -118.71538933 36.73177277
  -118.7153944 36.73125742
  -118.71573607 36.73044156
  -118.71618977 36.72875872
  -118.71651025 36.72811846
  2 581
 B  15 1
  -118.71651025 36.72811846
  -118.71661716 36.72766138
  -118.71660977 36.7273294
  -118.71645785 36.72668322
  -118.71689758 36.7261392
  -118.71724087 36.72567564
  -118.71747107 36.7248177
  -118.71753527 36.72390024
  -118.71787045 36.72307308
  -118.71797278 36.72237579
  -118.71781832 36.72073331
  -118.71825483 36.72004703
  -118.71908689 36.71948153
  -118.71963768 36.71863545
  -118.71960108 36.71846736
  2 602
 B  8 1
  -118.7180943 36.70872005
  -118.71827421 36.7083356
  -118.71841915 36.7080259
  -118.7190169 36.70752707
  -118.72008403 36.70694237
  -118.72042476 36.70636815
  -118.72049695 36.70608245
  -118.7212077 36.70547966
  2 604
 B  15 1
  -118.7212077 36.70547966
  -118.721692  36.70506892
  -118.72256889 36.70442599
  -118.72372477 36.702873
  -118.72417965 36.70213899
  -118.72496002 36.70190631
  -118.72660809 36.70183505
  -118.72765407 36.70118732
  -118.72831767 36.70100376
  -118.72866574 36.7007615
  -118.72887421 36.70026501
  -118.72998965 36.69849669
  -118.73066541 36.69798083
  -118.73118943 36.69770441
  -118.73130166 36.69760244
  2 609
 B  8 1
  -118.7153867 36.75138736
  -118.7153804 36.7500365
  -118.7153634 36.7464107
  -118.7153465 36.742785
  -118.7153296 36.7391593
  -118.71533791 36.73753527
  -118.7153438 36.7363838
  -118.7153795 36.73403608
  2 610
 B  13 1
  -118.71786286 36.71527706
  -118.71763335 36.71507451
  -118.71748992 36.71480774
  -118.71754381 36.7136
  -118.71750723 36.7131568
  -118.71786592 36.71228789
  -118.71745106 36.71129755
  -118.71716489 36.71079564
  -118.71709787 36.71043286
  -118.71712906 36.71006868
  -118.71740871 36.70978478
  -118.717644  36.709369
  -118.7180943 36.70872005
  2 612
 B  7 1
  -118.71411256 36.77582538
  -118.71445897 36.77550631
  -118.71478471 36.77508229
  -118.7149828 36.77446623
  -118.71532537 36.77406797
  -118.7153339 36.7717931
  -118.71534777 36.76808916
  2 613
 B  3 1
  -118.71534777 

[GRASS-user] re-order boundaries by relative position along polyline

2015-04-02 Thread Dylan Beaudette
Hi,

Once again, I am reminded that complex spatial analysis in other software
can usually be reduced to a couple of lines of code in GRASS-- thanks!

Here is a fun question. Suppose you have a set of line segments, or
boundaries that are the result of a digitizing process that generated
segments out of order:

  2 4  1   3
O-+-++--O

'O' = start / end point
'+' = vertex

... in this case order is associated with order in which records appear
in the attribute table and the order in which segments are drawn on the
screen.

Is there a module, or set of modules that could be used to re-order the
segments so that the order of records in the attribute table and drawing
order is:

  1 2  3   4
O-+-++--O

Note that I do not wan't to shuffle the linkages between geometry and
attributes, rather, I would like to re-order the segments and attribute
table according to the linear position within the set of contiguous
boundaries or polyline.

Here is an example set of lines in ASCII format, WGS84 GCS.

ORGANIZATION:
DIGIT DATE:
DIGIT NAME:   dylan
MAP NAME:
MAP DATE: Thu Apr  2 11:46:34 2015
MAP SCALE:1
OTHER INFO:
ZONE: 0
MAP THRESH:   0.00
VERTI:
B  6 1
 -118.71960108 36.71846736
 -118.71946261 36.71783146
 -118.71905508 36.71717314
 -118.71863837 36.71610377
 -118.71807413 36.71546352
 -118.71786286 36.71527706
 2 132
B  3 1
 -118.7153795 36.73403608
 -118.71537992 36.73272737
 -118.71538933 36.73177277
 2 133
B  3 1
 -118.71536851 36.76205202
 -118.7153724 36.7609144
 -118.71537619 36.75980591
 2 150
B  2 1
 -118.73128842 36.69749903
 -118.73130166 36.69760244
 2 175
B  5 1
 -118.71538933 36.73177277
 -118.7153944 36.73125742
 -118.71573607 36.73044156
 -118.71618977 36.72875872
 -118.71651025 36.72811846
 2 581
B  15 1
 -118.71651025 36.72811846
 -118.71661716 36.72766138
 -118.71660977 36.7273294
 -118.71645785 36.72668322
 -118.71689758 36.7261392
 -118.71724087 36.72567564
 -118.71747107 36.7248177
 -118.71753527 36.72390024
 -118.71787045 36.72307308
 -118.71797278 36.72237579
 -118.71781832 36.72073331
 -118.71825483 36.72004703
 -118.71908689 36.71948153
 -118.71963768 36.71863545
 -118.71960108 36.71846736
 2 602
B  8 1
 -118.7180943 36.70872005
 -118.71827421 36.7083356
 -118.71841915 36.7080259
 -118.7190169 36.70752707
 -118.72008403 36.70694237
 -118.72042476 36.70636815
 -118.72049695 36.70608245
 -118.7212077 36.70547966
 2 604
B  15 1
 -118.7212077 36.70547966
 -118.721692  36.70506892
 -118.72256889 36.70442599
 -118.72372477 36.702873
 -118.72417965 36.70213899
 -118.72496002 36.70190631
 -118.72660809 36.70183505
 -118.72765407 36.70118732
 -118.72831767 36.70100376
 -118.72866574 36.7007615
 -118.72887421 36.70026501
 -118.72998965 36.69849669
 -118.73066541 36.69798083
 -118.73118943 36.69770441
 -118.73130166 36.69760244
 2 609
B  8 1
 -118.7153867 36.75138736
 -118.7153804 36.7500365
 -118.7153634 36.7464107
 -118.7153465 36.742785
 -118.7153296 36.7391593
 -118.71533791 36.73753527
 -118.7153438 36.7363838
 -118.7153795 36.73403608
 2 610
B  13 1
 -118.71786286 36.71527706
 -118.71763335 36.71507451
 -118.71748992 36.71480774
 -118.71754381 36.7136
 -118.71750723 36.7131568
 -118.71786592 36.71228789
 -118.71745106 36.71129755
 -118.71716489 36.71079564
 -118.71709787 36.71043286
 -118.71712906 36.71006868
 -118.71740871 36.70978478
 -118.717644  36.709369
 -118.7180943 36.70872005
 2 612
B  7 1
 -118.71411256 36.77582538
 -118.71445897 36.77550631
 -118.71478471 36.77508229
 -118.7149828 36.77446623
 -118.71532537 36.77406797
 -118.7153339 36.7717931
 -118.71534777 36.76808916
 2 613
B  3 1
 -118.71534777 36.76808916
 -118.71536   36.7645405
 -118.71536851 36.76205202
 2 622
B  4 1
 -118.71537619 36.75980591
 -118.7153848 36.7572883
 -118.7153973 36.7536622
 -118.7153867 36.75138736
 2 623


I have been able to convert these segments into polylines, however, I am
not sure how one would go about computing the position along the polylines.
Perhaps a linear referencing system?



Thanks!
Dylan
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user