[GRASS5] Re: [GRASSLIST:881] Re: Live Earthquake Map: GRASS/PHP

I notice on the USGS page they center the world on 180 lon. May I
suggest the same for your map? "g.region w=0 e=360"

oops, that won't work anymore.. the >90 lat tweak broke it:
G61> g.region w=0 e=360
G61> d.redraw
WARNING: Fixing subtle input data rounding error of east boundary
         (180>1e-06)
G61> g.region -p
WARNING: Fixing subtle input data rounding error of east boundary
         (180>1e-06)
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 90N
south: 90S
west: 0
east: 180E
nsres: 0:05
ewres: 0:05
rows: 2160
cols: 2160

This needs to be fixed, lon needs to be able to go up to 360
(remember mars example...)

The previous code allowed you to go endlessly east or west on input,
so just rip out east/west boundary fixes? (ie only keep >90lat fix)

I have disabled the epsilon check for LL e-w in CVS. Global wrapping is
much more important than accommodating a broken dataset.

Maybe we just need a better test:

  if(fabs(180-lon) < GRASS_EPSILON) lon=180.0; sort of thing?

I don't really like that kind of trick much either.

Can you point to some test data?

Hamish

Hamish wrote:

I notice on the USGS page they center the world on 180 lon. May I
suggest the same for your map? "g.region w=0 e=360"

oops, that won't work anymore.. the >90 lat tweak broke it:
G61> g.region w=0 e=360
G61> d.redraw
WARNING: Fixing subtle input data rounding error of east boundary
        (180>1e-06)
G61> g.region -p
WARNING: Fixing subtle input data rounding error of east boundary
        (180>1e-06)
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 90N
south: 90S
west: 0
east: 180E
nsres: 0:05
ewres: 0:05
rows: 2160
cols: 2160

This needs to be fixed, lon needs to be able to go up to 360
(remember mars example...)

The previous code allowed you to go endlessly east or west on input,
so just rip out east/west boundary fixes? (ie only keep >90lat fix)
   
I have disabled the epsilon check for LL e-w in CVS.

Sigh, ok. It was hard to write.

Global wrapping is
much more important than accommodating a broken dataset.

Maybe we just need a better test:

if(fabs(180-lon) < GRASS_EPSILON) lon=180.0; sort of thing?

I don't really like that kind of trick much either.

Can you point to some test data?

Just use r.in.wms on the entire world with JPL and Blue Marble. The
resulting map is
exceeding the definition. Similar thing with "natural Earth" data which
are worse and
not even capturable by epsilon (use gdal_translate -projwin to fix
those). A few other
world maps are also broken.

Markus