Michael wrote:
> Does this mean that we are abandoning the idea to
> have -g determine *how* out put is printed (i.e.,
> shell-script style) and use other flags to
> determine *what* is printed?
no/yes/in practice it doesn't matter &/or resolves
itself with a natural solution so we are just
argui
Does this mean that we are abandoning the idea to have -g determine *how* out
put is printed (i.e., shell-script style) and use other flags to determine
*what* is printed?
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropolog
> Anna,
>
> thank you for backporting wxnviz, I just compiled it and it runs great, even
> with some highly specialized data
> (e.g. terrestrial lidar scans at 0.01m resolution).
> There are few things that still have issues (mostly features that never
> really worked in nviz and may be only Ma
> There can be a significant performance hit for doing this. Checking
> whether the result of an addition overflowed is actually more
> expensive than the addition itself. Checking whether a multiplication
> overflowed can be even worse (particularly if you don't have a 64-bit
> integer type availa
Martin:
> current situation is
>
> r.info
> -g Print raster array information only
[in shell script style!]
> -e Print extended metadata information only
[also in shell script style!]
> v.info
> -g Print region info in shell script style
> -e Print extended metadata info in she
Hi,
2011/11/18 Hamish :
> Hamish wrote:
>> simple, clean, consistent, and doesn't stop others
>> from working the way they want to work.
>
> well, maybe "consistent" for all sets/perspectives is
> the part we're working on right now. :-)
current situation is
r.info
-g Print raster array info
2011/11/26 Michael Barton :
> While I understand the problems, if we revert it, it will be much worse. The
> initial z-exag will be set to 1000 for latlon and even a value of 1 will be
> enormously too big. This is why I tried to improve it.
>
> The previous way it was working was even more arbit
While I understand the problems, if we revert it, it will be much worse. The
initial z-exag will be set to 1000 for latlon and even a value of 1 will be
enormously too big. This is why I tried to improve it.
The previous way it was working was even more arbitrary than it is now. It is
making no
2011/11/26 Hamish :
> Helena wrote:
>> - in wxnviz to avoid the very small zexag for latlong,
>
> another idea for lat/lon z-exag: just figure out what is 20-25% of the canvas
> height (or ~15% of the north-south image width),
> and work backwards from there, rounding to the nearest nice
> round n
Thanks for the ideas Hamish. I'm pretty sure that there is a conversion from
geographic coordinates in xyz to arbitrary screen coordinates in the OGL code
section. I understand what Helena is hoping for, and this would indeed be the
ideal. To me, this 'natural' ratio between xy and z should have
Dear Helena,
Dne 26. listopadu 2011 5:15 Helena Mitasova napsal(a):
> thank you for backporting wxnviz, I just compiled it and it runs great, even
> with some highly specialized data
> (e.g. terrestrial lidar scans at 0.01m resolution).
> There are few things that still have issues (mostly featu
11 matches
Mail list logo
