3
I've done some hacking on r.proj:
4
- aborts if the input map is outside current region
5
- trims the output map to the current region or smaller
6
- does not allocate more memory than necessary for projecting the
7
overlapping parts of the input map and output region
8
- aligns cell edges and centers of the output map exactly to those
10
- matches (unless changed explicitly) resolution exactly to that
12
- during overlap checks, passes cell centers to PROJ instead of
13
edges (which are invalid in many projections, causing
14
'Error in do_proj' aborts)
15
- allows projecting azimuthal, conical etc maps even if north is
16
not upward or east is not rightward (no more 'north must be
17
greater than south' or 'east must be greater than west' errors)
19
The question about overlapping cells in projections from adjacent maps that
20
have no overlaps (e.g. DEM30 slices): They can't be avoided. E.g. some of
21
the right (east) column cells of one DEM30 map and some of the left (west)
22
column cells of the afjacent DEM30 map will eventually be projected into the
23
same cell of a conical or azimuthal region. Simply because meridians get
24
closer to each other when you approach the poles. But what is worse is that
25
these overlapping cells will probably have different values, because these
26
values were resampled from nearest neighbours in different input maps. So
27
it's better to r.patch the input maps first, and then do the projection (if
28
you have the memory necessary to read in a large input map.)
30
Most of Martin Schroeder's original code is left untouched. Basically I just
31
added a function, boardwalk(), that makes the checks for overlapping parts
32
of input map and output region. Plus I moved the memory allocation routine
33
forward in the main code, and made some other smaller changes. There are
34
some comments in boardwalk.c, and under Changes in main.c
36
----------------------
37
Error message comments:
39
'Error in pj_do_proj' can happen in any module that uses the proj routines,
40
for a variety of reasons:
42
-user is trying to project something where source and destination
43
are in the same projection already (like LL->LL). Perhaps the error message
44
could be more descriptive in this case, or the module should abort earlier
45
(i.e. immediately after checking the PROJ_INFO of source and destination. I
46
think m.proj does this, exits with 'No projection needed' message)
48
-stepping on a no-no point. This cannot be prevented because in
49
both raster and vector maps there is always a small chance that a node/cell
50
falls on a co-ordinate that is a reference point for the projection in
51
question, resulting in a division by zero error. (we had an earlier
54
Morten Hulden <morten@ngb.se>
added
removed
raster/r.proj/COMMENT
