[GRASS5] v.in.dxf attribute question

GRASS GRASS developer
1

Is this why it will NOT read a MapInfo file I export to DXF with attributes and WILL read a MapInfo file exported to DXF without attributes?

Michael Barton

Subject: v.in.dxf not converting 8bit TEXT

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources

DXF has a convention for encoding 8bit strings in 7bit strings by using a
decimal representation ('%%ddd') for bytes with 8th bit set. Example:

  0
TEXT
  8
TOPOGRAPHIE
62
7
10
3453700.036000
20
5556212.001000
30
0.000000
40
3.200000
41
1.200000
  1
Kantstra%%223e
  7
ISO8
50
43.988400000000
51
16.700000000000

v.in.dxf does not convert the 7bit encoding to 8bit.

I have made the following patch to src/mapdev/v.in.dxf/label_box.c to solve
the problem for myself:

*** label_box.c.orig Tue Jan 22 05:51:14 2002
--- label_box.c Sun Nov 16 10:58:00 2003
***************
*** 31,36 ****
--- 31,37 ----
        DXF_DIG *layer_fd, *label_fd;
        int count, char_cnt, code;
        char label[256]; /* same size as dxf_line */
+ char text_style[256];
        double start_x, start_y, angle, theta, height, length, diag;
        double base1, base2;
        int arr_size = 0;
***************
*** 42,47 ****
--- 43,49 ----
        start_y = 0.0;
        height = 1.0;
        angle = 0.0;
+ text_style[0] = '\0';

        while ((code = dxf_readcode (dxf_file)) > 0)
        {
***************
*** 73,78 ****
--- 75,83 ----
                case 50: /* Text angle */
                    angle = atof (dxf_line);
                    break;
+ case 7: /* Text Style */
+ strcpy(text_style,dxf_line);
+ break;

                case 30: /* Z */
                case 41: /* relative X scale factor */
***************
*** 86,92 ****

                debugf("TEXT got unused code %d\n", code );
                case 62: /* Color */
- case 7: /* Text Style */
                case 6: /* Line type */
                default:
                    break;
--- 91,96 ----
***************
*** 181,186 ****
--- 185,195 ----
        ** fprintf (label_fd->fd, "L %lf %lf
%d\n",pt_array[2].x,pt_array[2].y,label);
        ** Labels now characters, not integers BCH-J
        */
+
+ if (strcmp(text_style,"ISO8") == 0) {
+ iso8_convert(label);
+ }
+
      fprintf (label_fd->fd, "L %f %f %s\n",xinfo[0],yinfo[0],label);
      return (0);
  }
***************
*** 212,214 ****
--- 221,252 ----
      }
      return (-1); /* NOT NUMERIC */
  }
+
+ int iso8_convert(char *s) {
+ char *sub;
+
+ if (s == NULL) return(-1);
+
+ while ((sub = strstr(s, "%%")) != NULL) {
+ int sublen = strlen(sub);
+ if (sublen < 5) break;
+ if (isdigit(sub[2]) && isdigit(sub[3]) && isdigit(sub[4])) {
+ char dec[4];
+ int c, i;
+ strncpy(dec, &(sub[2]), 3);
+ dec[3] = '\0';
+ c = atoi(dec);
+ sub[0] = c;
+ i = 5;
+ while (sub[i] != '\0') {
+ sub[i-4] = sub[i];
+ i++;
+ }
+ sub[i-4] = '\0';
+ }
+ s = &(sub[1]);
+ }
+
+ return(0);
+ }

Best regards,
Michael Sczittnick

-------------------------------------------- Managed by Request Tracker

From: Michael Barton <michael.barton@asu.edu>
Date: Sun Nov 16, 2003 12:54:15 PM Europe/Madrid
To: grass5@grass.itc.it
Subject: [GRASS5] i.points and i.rectify question

In versions 5.0.x and 5.3 are the 2 modules i.points and i.points3. The documentation for both versions of GRASS discuss the associated programs i.rectify and i.rectify3. However, there does not seem to be a module i.rectify3 anywhere. Some months back, before I realized that i.rectify3 was missing, I tried both i.points and i.points3 and found i.points3 to be a better program in several respects. However, the output file it creates (image xy and georeferenced coordinate pairs) seems to be ONLY in lat long and does not work with i.rectify. This was a major headache.

Has anyone else run into this? Is there any way to "rectify" this problem? :wink:
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671

From: Thierry Laronde <tlaronde@polynum.com>
Date: Sun Nov 16, 2003 3:05:36 PM Europe/Madrid
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] i.points and i.rectify question

Hello,

On Sun, Nov 16, 2003 at 12:54:15PM +0100, Michael Barton wrote:

In versions 5.0.x and 5.3 are the 2 modules i.points and i.points3. The
documentation for both versions of GRASS discuss the associated
programs i.rectify and i.rectify3. However, there does not seem to be a
module i.rectify3 anywhere. Some months back, before I realized that
i.rectify3 was missing, I tried both i.points and i.points3 and found
i.points3 to be a better program in several respects. However, the
output file it creates (image xy and georeferenced coordinate pairs)
seems to be ONLY in lat long and does not work with i.rectify. This was
a major headache.

Has anyone else run into this? Is there any way to "rectify" this
problem? :wink:

Since I'm wandering in the historical 4.1.5 release, I gave a look at
these.

Indeed, there were (back to 4.1.5) i.rectify in src and i.rectify2 in
src.alpha. In 5.[03] there were a merge between i.rectify and i.rectify2
but it seems that there were some clash: i.rectify2 was due to be
renamed i.rectify, but remained i.rectify2 and there is another
i.rectify3 (with some fixes).

So i.rectify2 and i.rectify3 are in the sources but only a i.rectify is
present in the binaries, which seems to be i.rectify2 since i.rectify3
is not compiled by default.

For i.points, there were in src: i.points, in src.alpha: i.vpoints and
the resulting i.points3 seem to be a merge between i.points and
i.vpoints. And there is no i.points2

Yes, my head spins too...:wink:
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

From: Thierry Laronde <tlaronde@polynum.com>
Date: Sun Nov 16, 2003 7:35:07 PM Europe/Madrid
To: grass5 developers list <grass5@grass.itc.it>
Subject: [GRASS5] Duplicates: some stats

Hello,

I have made a pass to detect C files (whether .c or .h) which are
equals to a particular percentage (i.e. they differ (in lines) for less
than a particular threshold, for less than a particular percentage of
their number of lines).

Here the pass has been made asking for a 95% equality (in other words
for files differing in less than 5% of their lines).

This results in 1622 duplicates.

I attach the resulting file, which reports the pair of files compared.

Interestingly, you will see that some files in src AND in src.nonGPL are
equals...
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
<grass50.duplicates.gz>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671