Digitizing in GRASS

[Alejandro Imass]

David D Gray wrote:

>
> Do you need a real centroid, ie. a mass point of the area, or would a
> centrally located interior point do? If you just want a point for
> labels, attribute assignments, perhaps the second option is what
> you need. But there might be calculations you need to do that

Sorry for the misunderstanding, I was referring to the cuasi-centroid from the
labelling process (the second option you mentioned above).
It's just that I was thinking about using areas to figure out which arcs surrounded
this interior point, I got this idea from a centroid calculator I found in the contrib
dir of shapelib. It is probably not a good idea since as you can tell, I'm by no means
a GIS person.

OK, perhaps if I define the problem in more detail.... I will do the best I can.

So suppose that you only had three well defined areas. Two big areas, and a smaller
one in the middle, something like Ucrania, Rumania, and Moldavia. We have digitized
and labelled these areas, trimmed the file and come up with a total of 6 arcs, 4
nodes, and 3 center-or-inner points that define which country is which.

Now when you export this to any of two (GRASS and ARC/INFO) ascci formats, you will
end up with an arc-node file and a labels file which contains the centerpoints.
This is correct and perfect, but ARC/View, or rather MapServer which reads ARC/View
data, is kind'a dumb and what it interprets are 6 distinct polygons that will be
closed arbitarirly at at all end-nodes. This is because (and was explained to my by an
ARC/View user, so it could be wrong) ARC/View does not really support topology, so in
order to display this data correctly, it would need only three polygons defined as a
set of points, and it will close it at the end points if they are not snapped. What
you would call an Island in a package like GRASS.

So basically what I'm trying to do is create a little program that, known the center
points, can figure out which arcs surround it and can build these Islands which are
snapped to one another like jigsaw pieces. The ascii file from the GRASS export would
be fed to this progam and the resulting file would be in turn fed to gen2shp. Another,
probably better idea would be to add a parameter to gen2shp and have it read the .lab
file. The work of figuring out which arcs surround which centerpoint has to be done
either way.
It's just that building this into gen2shp, would probably be better becuase I guess a
lot of people already use this program.

BTW I think that Justin Hickey's program does exaclty this, in this case no further
work needs to be done, since it uses the area definitions in GRASS. I will test it
today and comment on this later.

What I cannot understand, and has me very curious,  is why this has not been widely
needed before. It is hard for me to believe that only Justin and I have this
requirement !

Thanks, and hoping to hear your comments.

Best Regards,
Alejandro