[GRASS5] remove error output from pj_do_proj()?

GRASS GIS GRASS GIS developer
1

Ocassionally when I project rasters, r.proj spews out a bunch of errors (pj_transform() failed...). Most of the time they are harmless (ie outside the source raster) and r.proj keeps going, and the projected raster has no problems. The big problem is that they can slow down the projection process VERY much. Wanting to remove these pointless errors, I poked around and found this to be in pj_do_proj().

This doesn't seems like a good place to me - since it spits out an error message based on the pj_transform return code, then immediately returns the pj_transform code, why not leave it up to the calling function to decide what to do with that code. r.proj just ignores it anyways and assigns a null value to the cell, while other commands may do some error checking and/or output a message (haven't looked at the other *.proj commands).

A verbose flag could be added to r.proj (and others) if the user wants to see those errors. And perhaps some error checking could be added to r.proj - some errors might really be fatal (ie when there's no inverse).

Just a suggestion. For now, for myself, I'm just removing the error message from pj_do_proj() (and I hope it doesn't break something else).

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro

2

On Tue, 27 Jul 2004, William K wrote:

Ocassionally when I project rasters, r.proj spews out a bunch of errors (pj_transform() failed...). Most of the time they are harmless

Could you give a few examples to make this clearer? AFAICT any time I've seen an error it meant I was doing something wrong, or it was a clue that the results were going to be erroneous etc.

FWIW pj_do_proj used to only report that projection had failed---I changed it to report the actual PROJ error string which I thought made it much more helpful?

Paul

3

case: location with orthographic projection, projecting from lat/long location that covers the whole globe. The region is rectangular (of course) and the projection is a circle. So there are many cells in the corners that don't map to points on the globe (almost 1/3 of the region). But GRASS will try to project to them anyways (doesn't know until it tries), and give them null if there is an error (which is good).

For all of these cells, both at the allocating/reading stage and the projecting stage, it gives:

pj_transform() failed
cause: tolerance condition error

and moves on to the next cell. There are many of these, and r.proj slows down as it writes all them to the terminal. And during the projecting stage, to % progress is often scrolled off the top of the screen.

In the past (tho I never thought about it until now) I've had similar errors with other projections (don't remember which), I guess also where the inverse projection failed for a few cells. And they also finished with no abnormalities in the projected data.

On Jul 27, 2004, at 5:29 PM, Paul Kelly wrote:

On Tue, 27 Jul 2004, William K wrote:

Ocassionally when I project rasters, r.proj spews out a bunch of errors (pj_transform() failed...). Most of the time they are harmless

Could you give a few examples to make this clearer? AFAICT any time I've seen an error it meant I was doing something wrong, or it was a clue that the results were going to be erroneous etc.

FWIW pj_do_proj used to only report that projection had failed---I changed it to report the actual PROJ error string which I thought made it much more helpful?

Yes, it could be useful. But if I know that they are harmless (like the orthographic above), it would be nice to turn them off. Or the other way - default to off, and turn them on if I notice problems.

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

4

Now I'm beginning to think that there IS something wrong with the projection. Everything looks OK, I can view it, I can do some mapcalc and filtering on it, I can export it (both r.out.tiff and r.out.gdal). I don't see any anomalies in the projected data. But two commands segfault on me - r.resample and r.compress.

In the terminal I get a seg fault error and the command exits. I also get a handy Mac OS X crash report that starts with: (there's somethread state info and binary image info after)

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffbda

Thread 0 Crashed:
0 libz.1.dylib 0x945b24d4 inflate_fast + 0x264
1 <<00000000>> 0x00006000 0 + 0x6000
2 libz.1.dylib 0x945b1208 inflate_blocks + 0x860
3 libz.1.dylib 0x945b1e9c inflate + 0x37c
4 libgrass_gis.dylib 0x0006b5e8 G_zlib_expand + 0xb0
5 libgrass_gis.dylib 0x0006b1ac G_zlib_read + 0x124
6 libgrass_gis.dylib 0x00072ab8 read_data_fp_compressed + 0xac
7 libgrass_gis.dylib 0x00073814 get_map_row_nomask + 0x19c
8 libgrass_gis.dylib 0x00072134 G_get_raster_row + 0x3fc
9 r.resample 0x000024fc main + 0x358
10 r.resample 0x00001c94 _start + 0x188 (crt.c:267)
11 dyld 0x8fe1a558 _dyld_start + 0x64

(the libz led me to try r.compress which also crashes with the same thread trail, otherwise I wouldn't normally use it)

The raster straight out of r.proj crashes about 50% thru r.resample (I'm resampling 1:10 and 1:5). After applying some mapcalc and filtering (which work), the resulting raster crashes immediately. Both are float grids.

The regions are the full area. When I zoom to a smaller area (whether completely within the orthographic area, or overlapping a corner where the pj errors occur), r.resample has no trouble. A couple tests with the region approx 10-20 cells smaller than the default failed tho.

r.resample and r.compress have no problems with rasters in other projections.

2004-7-24 CVS. I reinstalled a previous CVS (7-10), without the shared library path fix, and had the same problem. And it's only with 5.7, 5.3 CVS has no problems.

Oh wait, just tried somthing else. I've been doing my 'super-optimizing' thing lately (-O3, -mcpu= and -maltivec, + -s for LDFLAGS). Without that it's now working. Odd, tho - I'm using the same optimizing on 5.3, but it still works. Maybe the shared libs in 5.7 don't get along with the optimizing (not surprising, had a similar problem with postgre).

So, looks like for now: 5.3 + optimize, 5.7 - no optimize. No big deal - even without optimizing, my 5.7 install is down to 36MB (from the 50+ it used to be). When I have time, I'll play with the optimizing to see which one is the culprit.

On Jul 27, 2004, at 5:29 PM, Paul Kelly wrote:

On Tue, 27 Jul 2004, William K wrote:

Ocassionally when I project rasters, r.proj spews out a bunch of errors (pj_transform() failed...). Most of the time they are harmless

Could you give a few examples to make this clearer? AFAICT any time I've seen an error it meant I was doing something wrong, or it was a clue that the results were going to be erroneous etc.

FWIW pj_do_proj used to only report that projection had failed---I changed it to report the actual PROJ error string which I thought made it much more helpful?

Paul

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

-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin