"GRASS' logical database structure (one projection
definition per LOCATION) is designed to avoid problems
such as the ones introduced with the "on-the-fly"
reprojection ability (typically problems caused by
mixed datums) which is present in most GISes."
I'm not sure I'd use the word "designed" that way, AFAIK that
structure was designed long before datum support was even thought
about for GRASS. it's just a matter of enforcing consistency
as a way to keep a complicated job from getting all muddled up.
fwiw in GRASS 5 there is some contrib code from Lockheed Martin
to change the projection of the display window at runtime.
also I don't mean to rag on other GISs too much, obviously we
are not some perfection and have many bugs and design issues too.
just that we should try to learn from mistakes we see around us.
Hamish
On Thu, 2009-07-02 at 06:59 -0700, Hamish wrote:
> "GRASS' logical database structure (one projection
> definition per LOCATION) is designed to avoid problems
> such as the ones introduced with the "on-the-fly"
> reprojection ability (typically problems caused by
> mixed datums) which is present in most GISes."
I'm not sure I'd use the word "designed" that way, AFAIK that
structure was designed long before datum support was even thought
about for GRASS. it's just a matter of enforcing consistency
as a way to keep a complicated job from getting all muddled up.
fwiw in GRASS 5 there is some contrib code from Lockheed Martin
to change the projection of the display window at runtime.
also I don't mean to rag on other GISs too much, obviously we
are not some perfection and have many bugs and design issues too.
just that we should try to learn from mistakes we see around us.
Good point! So, change "design" to ... OR Just remove the "design"
verb... !?
Nikos
Nikos:
> > "GRASS' logical database structure (one projection
> > definition per LOCATION) is designed to avoid problems
> > such as the ones introduced with the "on-the-fly"
> > reprojection ability (typically problems caused by
> > mixed datums) which is present in most GISes."
Hamish:
> I'm not sure I'd use the word "designed" that way, AFAIK that
> structure was designed long before datum support was even thought
> about for GRASS. it's just a matter of enforcing consistency
> as a way to keep a complicated job from getting all muddled up.
> fwiw in GRASS 5 there is some contrib code from Lockheed Martin
> to change the projection of the display window at runtime.
> also I don't mean to rag on other GISs too much, obviously we
> are not some perfection and have many bugs and design issues too.
> just that we should try to learn from mistakes we see around us.
Nikos:
Good point! So, change "design" to ... OR Just remove the "design"
verb... !?
Changed to:
"GRASS' logical database structure (one projection definition per
LOCATION) avoids problems such as the ones introduced with the
"on-the-fly" reprojection ability (typically problems caused by mixed
datums) which is present in most GISes."
Please correct if required. Thanks, Nikos
---
[1] http://grass.osgeo.org/wiki/Location_and_Mapsets