Hi developers,
since we are getting closer to the stable release of 5.0
we have to take another look on outstanding issues.
Here my proposal:
- m.proj/m.proj2 need to be updated to also perform the Nad/Nad
datum transformation. An inconsistency between the projection
tools is not acceptable for a stable release.
- r.proj needs a clean-up. The improvements coded by Morten Hulden
are partially disabled (region sensivity etc) which is a major
drawback. If no general solution is possible, we may introduce
optional flags.
- v.in.shape.pg/v.in.arc.pg: The v.in.shape.pg is outdated as it
is based on the old v.in.shape. The same functionality can be
achieved with pg.in.dbf. Suggestion (already discussed with Alex
Shevlakov) is to drop both v.in.shape.pg/v.in.arc.pg, using instead
v.in.shape/pg.in.dbf as well as v.in.arc/pg.in.dbf.
What else is missing?
Markus
Markus Neteler wrote:
- r.proj needs a clean-up. The improvements coded by Morten Hulden
are partially disabled (region sensivity etc) which is a major
drawback. If no general solution is possible, we may introduce
optional flags.
I've committed an update which makes the -n flag control both
bordwalk() calls; it also fixes the error handling.
AFAICT, the remaining issues for r.proj are:
1. Whether to forward-project the entire input map in order to
determine the boundaries of the output map. This code is currently
present (in main.c) but disabled.
2. Whether the sense of the "-n" switch is correct, i.e. whether
cropping should be on or off by default.
3. Whether an all-null output map should really be a fatal error.
While this may seem like a good idea for "typical" interactive use,
special-case behaviour such as this is usually a bad idea for a
"module" of a larger system.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, Jun 27, 2002 at 12:46:49PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> - r.proj needs a clean-up. The improvements coded by Morten Hulden
> are partially disabled (region sensivity etc) which is a major
> drawback. If no general solution is possible, we may introduce
> optional flags.
I've committed an update which makes the -n flag control both
bordwalk() calls; it also fixes the error handling.
AFAICT, the remaining issues for r.proj are:
1. Whether to forward-project the entire input map in order to
determine the boundaries of the output map. This code is currently
present (in main.c) but disabled.
2. Whether the sense of the "-n" switch is correct, i.e. whether
cropping should be on or off by default.
As a user, my preference would be for all of the input map per
current region settings be projected into the output. Seems to be the
most consistent with other GRASS raster operations. The output raster
size should be no larger than the minimum bounding box of the projected
input bounding box as adjusted for rectangularity.
3. Whether an all-null output map should really be a fatal error.
While this may seem like a good idea for "typical" interactive use,
special-case behaviour such as this is usually a bad idea for a
"module" of a larger system.
Probably there due to the non-intuitive output region handling.
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
> > - r.proj needs a clean-up. The improvements coded by Morten Hulden
> > are partially disabled (region sensivity etc) which is a major
> > drawback. If no general solution is possible, we may introduce
> > optional flags.
>
> I've committed an update which makes the -n flag control both
> bordwalk() calls; it also fixes the error handling.
>
> AFAICT, the remaining issues for r.proj are:
>
> 1. Whether to forward-project the entire input map in order to
> determine the boundaries of the output map. This code is currently
> present (in main.c) but disabled.
>
> 2. Whether the sense of the "-n" switch is correct, i.e. whether
> cropping should be on or off by default.
As a user, my preference would be for all of the input map per
current region settings be projected into the output. Seems to be the
most consistent with other GRASS raster operations. The output raster
size should be no larger than the minimum bounding box of the projected
input bounding box as adjusted for rectangularity.
1. This seems self-contradictory. For most GRASS raster commands, the
size of the output map is determined from the current region settings,
regardless of the portion which will be non-null.
2. Bear in mind that r.proj "works backwards". For each output cell,
it projects that cell's coordinates via the inverse projection
function to obtain the corresponding coordinates in the input map, and
copies the corresponding cell value from the input map to the output
map. Forward projection is only used to compute an optimal bounding
box.
3. There are two distinct bounding box calculations which are
performed. First, it inverse-projects the current region to the source
projection to determine the rectangular portion of the input map which
has to be read into memory. Second, it forward-projects that region
back to the output projection to determine the boundaries of the
output map.
4. When I say "computes", "guesses" may be a better term, as the
computation is fallible. It assumes that the boundary of the
projections of the cells is the projection of the boundary of the
cells. While this is likely to hold true for "almost affine"
transformations (i.e. projecting "small" regions), it can fail,
particuarly for creating "whole earth" maps from a lat-long source.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Jun 28, 2002 at 02:53:59AM +0100, Glynn Clements wrote:
1. This seems self-contradictory. For most GRASS raster commands, the
size of the output map is determined from the current region settings,
regardless of the portion which will be non-null.
Errm. I was mixed up... I never use r.proj due to its memory
requirements so was remembering it as being run from the input mapset.
Therefore, it's seems like it should be treated like an import/export
routine since it's run in the target location.
The problem I think most folks run into is setting the current region
for the projection but not having a good idea what it should be set at.
So, as a user, do I have to project some points or a vector box first
just to guess what the current region extents should be? Maybe the
behavior is what some users want, but I'd bank that in general users
would want to project the entire input at its data resolution into the
current mapset (much like any raster import). If I want/need to cut it
down or reduce the resolution, I'd make those modifications before or
after the projection (depending on what I'm using to make those
determinations).
2. Bear in mind that r.proj "works backwards". For each output cell,
it projects that cell's coordinates via the inverse projection
function to obtain the corresponding coordinates in the input map, and
copies the corresponding cell value from the input map to the output
map. Forward projection is only used to compute an optimal bounding
box.
As a user, I don't care how it works internally 
4. When I say "computes", "guesses" may be a better term, as the
computation is fallible. It assumes that the boundary of the
projections of the cells is the projection of the boundary of the
cells. While this is likely to hold true for "almost affine"
transformations (i.e. projecting "small" regions), it can fail,
particuarly for creating "whole earth" maps from a lat-long source.
Yea, a bit tricky there...
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
> 1. This seems self-contradictory. For most GRASS raster commands, the
> size of the output map is determined from the current region settings,
> regardless of the portion which will be non-null.
Errm. I was mixed up... I never use r.proj due to its memory
requirements so was remembering it as being run from the input mapset.
Therefore, it's seems like it should be treated like an import/export
routine since it's run in the target location.
The problem I think most folks run into is setting the current region
for the projection but not having a good idea what it should be set at.
So, as a user, do I have to project some points or a vector box first
just to guess what the current region extents should be? Maybe the
behavior is what some users want, but I'd bank that in general users
would want to project the entire input at its data resolution into the
current mapset (much like any raster import). If I want/need to cut it
down or reduce the resolution, I'd make those modifications before or
after the projection (depending on what I'm using to make those
determinations).
Two problems with that:
1 (Boundaries). Projecting an entire map may result in the output
being infinitely large (e.g. projecting a "global" lat/lon map to e.g.
Mercator), or at least infeasibly large (try applying one of the "Mod.
Stererographics" projections to a map which extends significantly
beyond the intended region).
2 (Resolution). Unless the transformation consists solely of scaling
and translation (and, if you're using r.proj, it probably doesn't),
there isn't a "magic" output resolution which results in no loss of
data.
> 2. Bear in mind that r.proj "works backwards". For each output cell,
> it projects that cell's coordinates via the inverse projection
> function to obtain the corresponding coordinates in the input map, and
> copies the corresponding cell value from the input map to the output
> map. Forward projection is only used to compute an optimal bounding
> box.
As a user, I don't care how it works internally
This isn't really "internal"; it's fundamental to what it means to
"project" a raster.
--
Glynn Clements <glynn.clements@virgin.net>
Hi developers,
since we are getting closer to the stable release of 5.0
(seems we are approximating it only) we have to take another look at
outstanding issues.
The same as earlier:
On Thu, Jun 27, 2002 at 11:45:51AM +0200, Markus Neteler wrote:
- m.proj/m.proj2 need to be updated to also perform the Nad/Nad
datum transformation. An inconsistency between the projection
tools is not acceptable for a stable release.
it is still unchanged, right?
- r.proj needs a clean-up. The improvements coded by Morten Hulden
are partially disabled (region sensivity etc) which is a major
drawback. If no general solution is possible, we may introduce
optional flags.
What is the status here?
Anything else except the remaining bugs and wishes 
?
Markus
Markus Neteler wrote:
> - r.proj needs a clean-up. The improvements coded by Morten Hulden
> are partially disabled (region sensivity etc) which is a major
> drawback. If no general solution is possible, we may introduce
> optional flags.
What is the status here?
Both calls to bordwalk() are now controlled by the "-n" switch.
The alternative computation of the destination region, which is more
robust[1] but significantly more expensive, is still disabled. It
should probably be removed; if the existing computation of the
destination rectangle doesn't produce the correct answer, the
computation of the source rectangle will probably be wrong also.
[1] Except that it has a bug. As proj_f() overwrites its input,
ycoord1 would need to be re-initialised on each pass of the inner
loop, along with xcoord1
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, 26 Jul 2002, Glynn Clements wrote:
Markus Neteler wrote:
> > - r.proj needs a clean-up. The improvements coded by Morten Hulden
> > are partially disabled (region sensivity etc) which is a major
> > drawback. If no general solution is possible, we may introduce
> > optional flags.
>
> What is the status here?
Both calls to bordwalk() are now controlled by the "-n" switch.
We probably should add some instructions for the the user on when the -n
switch could help. Working with global maps, for instance, bordwalk() does
not help because the whole input map has to be loaded into memory anyway
and there is nothing to trim from the output either.
To the error message 'Input area is outside current region' given by
bordwalk(), we could add something like 'Check your current region
settings, or if this is a global map, try the -n switch'
The message sometimes erronously is given by bordwalk() on global->global
projections (I should try to fix that). Sometimes the user (at least
happens to me) forgot that he has zoomed in on a smaller region in the
location and really is outside the input map. Sometimes the users's
default region borders are just guesswork and completely wrong.
Morten Hulden