[GRASS5] Re: [ArcInfo ungenerate]

GRASS GRASS developer
1

Hi developers,

Seppo Kaitala has found some ungenerate/v.in.arc problems related
to the famous "coastline extractor":
http://rimmer.ngdc.noaa.gov/coast/

Question is if we should modify v.in.arc a bit to accept comma delimited
coordinate pairs in ungen format. Of course the sed trick is feasible,
but not to be expected from the average user. Myself, I am not sure if
comma delimiter are allowed in ungenerate format.

See details below.

Regards

Markus

On Tue, Apr 24, 2001 at 09:14:23AM +0300, Seppo Kaitala wrote:

Hi Markus
That is what I got.

Best Regards
Seppo

Travis Stevens wrote:
>
> Hello Seppo Kaitala,
>
> Although my knowledge of ArcInfo is not great, my sources tell me that the
> comma delimeter is the proper format for ArcInfo ungenerate file format;
> therefor I will keep the ArcInfo format the way it is. However, if you
> work on a unix type operating system, here is a simple command to make the
> comma delimter a space delimeter:
>
> cat oldfile.dat | sed -e ' s/,/ /g ' > newfile.dat
>
> oldfile.dat is the downloaded file from the coastline extracter and
> newfile.dat is a newfile that has the commas replaced with spaces.
>
> If you use Microsoft Windows or a Mac, then I suggest some kind of text
> editor that has search and replace functionality.
>
> If you use any other type of operating system, then I am sorry that I
> cannot help you.
>
> If you have any more questions, please feel free to contact me.
> -Travis
>
> > Dear Travis Stevens
> >
> > I am happy to have the possibility to use your excellent coastline
> > extractor service.
> >
> > However, when I am extracting the data in ArcInfo ungenerate file format
> > I get the data in format
> >
> > > >
> > > > 1
> > > > 20.899230,50.000000
> > > > 20.899447,50.001083
> > > > 20.899154,50.004016
> > > > 20.899740,50.006950
> > > > 20.900327,50.009883
> > > > 20.900327,50.012817
> > > >
> >
> > I was informed, that actually comma separator should not be there but
> > space.
> > That causes some trouble, when I am loading data into GRASS GIS
> > software.
> >
> > If that is a mistake, could you please correct it.
> >
> > Best Regards
> >
> > Seppo Kaitala
> >
> > Merentutkimuslaitos, PL 33 (Lyypekinkuja 3), 00931 Helsinki
> > Institute of Marine Research, PO Box 33, FIN-00931 Helsinki, Finland
> > tel. +358-9-613941 fax +358-9-6857 638

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Markus,

I think that GENERATE format can include commas. The following quote is from a
response on the ESRI knowledge base describing how to create a GENERATE file from
INFO:

'The output file created will be used with the GENERATE
        command, which will read commas as field delimiters. '

It appears either space or comma can be used.

HTH,

Malcolm

Markus Neteler wrote:

Hi developers,

Seppo Kaitala has found some ungenerate/v.in.arc problems related
to the famous "coastline extractor":
http://rimmer.ngdc.noaa.gov/coast/

Question is if we should modify v.in.arc a bit to accept comma delimited
coordinate pairs in ungen format. Of course the sed trick is feasible,
but not to be expected from the average user. Myself, I am not sure if
comma delimiter are allowed in ungenerate format.

See details below.

Regards

Markus

On Tue, Apr 24, 2001 at 09:14:23AM +0300, Seppo Kaitala wrote:
> Hi Markus
> That is what I got.
>
> Best Regards
> Seppo

> Travis Stevens wrote:
> >
> > Hello Seppo Kaitala,
> >
> > Although my knowledge of ArcInfo is not great, my sources tell me that the
> > comma delimeter is the proper format for ArcInfo ungenerate file format;
> > therefor I will keep the ArcInfo format the way it is. However, if you
> > work on a unix type operating system, here is a simple command to make the
> > comma delimter a space delimeter:
> >
> > cat oldfile.dat | sed -e ' s/,/ /g ' > newfile.dat
> >
> > oldfile.dat is the downloaded file from the coastline extracter and
> > newfile.dat is a newfile that has the commas replaced with spaces.
> >
> > If you use Microsoft Windows or a Mac, then I suggest some kind of text
> > editor that has search and replace functionality.
> >
> > If you use any other type of operating system, then I am sorry that I
> > cannot help you.
> >
> > If you have any more questions, please feel free to contact me.
> > -Travis
> >
> > > Dear Travis Stevens
> > >
> > > I am happy to have the possibility to use your excellent coastline
> > > extractor service.
> > >
> > > However, when I am extracting the data in ArcInfo ungenerate file format
> > > I get the data in format
> > >
> > > > >
> > > > > 1
> > > > > 20.899230,50.000000
> > > > > 20.899447,50.001083
> > > > > 20.899154,50.004016
> > > > > 20.899740,50.006950
> > > > > 20.900327,50.009883
> > > > > 20.900327,50.012817
> > > > >
> > >
> > > I was informed, that actually comma separator should not be there but
> > > space.
> > > That causes some trouble, when I am loading data into GRASS GIS
> > > software.
> > >
> > > If that is a mistake, could you please correct it.
> > >
> > > Best Regards
> > >
> > > Seppo Kaitala
> > >
> > > Merentutkimuslaitos, PL 33 (Lyypekinkuja 3), 00931 Helsinki
> > > Institute of Marine Research, PO Box 33, FIN-00931 Helsinki, Finland
> > > tel. +358-9-613941 fax +358-9-6857 638

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Malcolm Blue wrote:

Markus,

I think that GENERATE format can include commas. The following quote is from a
response on the ESRI knowledge base describing how to create a GENERATE file from
INFO:

'The output file created will be used with the GENERATE
        command, which will read commas as field delimiters. '

It appears either space or comma can be used.

Well... I spent a little time on v.in.arc : the problem is in
process_inp.c, which looks :

int process_inp (char *inp)
{
   G_remove_commas(inp);
   while(*inp)
   {
     if((*inp=='D')||(*inp=='d')) *inp='e';
     inp++;
   }
   return 0;
}

G_remove_commas() appears only in v.in.arc and v.in.arc.pg (which is
based on v.in.arc). the function is define in libes/gis/commas.c,
and the comment you found before the function is :

/* removes commas from strings representing a number
  1,234,567 becomes 1234567
  1,234,567.89 becomes 1234567.89
  12,345 becomes 12345
  1234 stays 1234
*/

There is also a G_insert_commas() function for the opposite, that is a
little more used. Here is the command i used from the grass/src dir :

bash-2.03$ find . -name '*.c' -exec grep G_insert_commas {} /dev/null \;
./src/libes/gis/commas.c:int G_insert_commas(
./src/libes/gis/edit_cellhd.c: G_insert_commas(buf);
./src/raster/r.report/cmd/format.c: G_insert_commas (temp);
./src.contrib/SCS/vector/v.report/cmd/format.c: G_insert_commas (buf);

so it appears that

1- G_remove_commas() in never used except where it causes trouble
2- G_insert_commas() seems only used to put commas on rare occasions

Should we keep them in the future release, or modify
src/libes/gis/edit_cellhd.c, src/raster/r.report/cmd/format.c and
src.contrib/SCS/vector/v.report/cmd/format.c (which seems a duplicate
from the former)

In the meantime, I have modified src/mapdev/v.in.arc/process_inp.c
and src.garden/grass.postgresql/v.in.arc.pg/process_inp.c to
replace commas by spaces. This should correct the problem.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

I was using Arcinfo this afternoon, so I looked in the help file for info on the
GENERATE format. This might be useful for future reference if anyone else reports
problems, although with all the other formats supported, GENERATE might not be too
popular anymore. I copied the pages for Points (includes polygon label points), Lines
and Polygons. The polygon format may not be fully supported by the v.in.arc.poly
routines, according to the readme file in that directory.

HTH,

Malcolm

Points
Adds points to a point coverage, or label points to a polygon coverage.
Enter one point per line specifying the Point ID and X,Y location for the point
feature.
Point ID,X,Y:
601,3,7
602,9,7
603,5,4
end

Lines
Adds arcs to the coverage.
Enter the Line ID for the line feature then enter the X,Y coordinate pairs, one pair
per line. The coordinates of each pair may be separated with a comma or a space. Use
the keyword end to end one line and then start another with a new User-ID. End the
file with a final end keyword after the end of the last line.
ID:
X,Y:
X,Y:
X,Y:
X,Y:
ID:
501
2,8
5,8
5,5
end
502
1,2
4,5
end
end

Polygons
Adds polygons and label points to the coverage.
Enter a Polygon ID and the X,Y coordinates for the polygon label on a separate line.
Then enter the x,y coordinate pairs for each vertex along the polygon boundary. The
coordinates of each pair may be separated with a comma or a space. Multiple coordinate
pairs may be placed on a single line if they are separated by semicolon.
Do not use a Polygon ID = -99999. This has a special meaning. The Coverage to Generate
File tool, when used on polygons, flags all island polygons with this special ID. The
Generate to Coverate Wizard will ignore all polygons with an ID of -99999.

If 0 is entered for ID,X,Y, then no polygon label will be generated for that polygon.
For automatic polygon label placement enter AUTO after the POLYGON-ID rather than
coordinate values.
Polygons will be closed automatically from the last vertex entered to the first vertex,
if the two vertices are not the same.
The User-ID of the arcs that make up the newly generated polygon features will be zero.

ID,X,Y:
X,Y:
X,Y:
X,Y:
X,Y:
X,Y:
X,Y:
X,Y:
ID,X,Y:
701,7,7
3,9
4,5
8,4
9,7
6,9
3,9
end
end

Michel Wurtz wrote:

Malcolm Blue wrote:
>
> Markus,
>
> I think that GENERATE format can include commas. The following quote is from a
> response on the ESRI knowledge base describing how to create a GENERATE file from
> INFO:
>
> 'The output file created will be used with the GENERATE
> command, which will read commas as field delimiters. '
>
> It appears either space or comma can be used.

Well... I spent a little time on v.in.arc : the problem is in
process_inp.c, which looks :

int process_inp (char *inp)
{
   G_remove_commas(inp);
   while(*inp)
   {
     if((*inp=='D')||(*inp=='d')) *inp='e';
     inp++;
   }
   return 0;
}

G_remove_commas() appears only in v.in.arc and v.in.arc.pg (which is
based on v.in.arc). the function is define in libes/gis/commas.c,
and the comment you found before the function is :

/* removes commas from strings representing a number
        1,234,567 becomes 1234567
        1,234,567.89 becomes 1234567.89
        12,345 becomes 12345
        1234 stays 1234
*/

There is also a G_insert_commas() function for the opposite, that is a
little more used. Here is the command i used from the grass/src dir :

bash-2.03$ find . -name '*.c' -exec grep G_insert_commas {} /dev/null \;
./src/libes/gis/commas.c:int G_insert_commas(
./src/libes/gis/edit_cellhd.c: G_insert_commas(buf);
./src/raster/r.report/cmd/format.c: G_insert_commas (temp);
./src.contrib/SCS/vector/v.report/cmd/format.c: G_insert_commas (buf);

so it appears that

1- G_remove_commas() in never used except where it causes trouble
2- G_insert_commas() seems only used to put commas on rare occasions

Should we keep them in the future release, or modify
src/libes/gis/edit_cellhd.c, src/raster/r.report/cmd/format.c and
src.contrib/SCS/vector/v.report/cmd/format.c (which seems a duplicate
from the former)

In the meantime, I have modified src/mapdev/v.in.arc/process_inp.c
and src.garden/grass.postgresql/v.in.arc.pg/process_inp.c to
replace commas by spaces. This should correct the problem.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'