Made a map in Australia, and wanted to use r.horizon on it.
Nothing special, a srtm map and default conditions.
This is the output:
(Sat Jun 20 16:51:57 2009)
r.horizon elevin=dem25m@PERMANENT horizonstep=30 bufferzone=200
maxdistance=2000 horizon=horangle
G_set_window(): Illegal latitude for North
(Sat Jun 20 16:51:57 2009) Command finished (0 sec)
I can recreate this from a single Lat/Lon srtm file. Works fine if you
reproject it into a planimetric map projection. --->
from the man page:
"At the moment the elevation and maximum distance must be measured in meters, even if you use geographical coordinates (longitude/latitude). If your projection is based on distance (easting and northing), these too must be in meters. The buffer parameters must be in the same units as the raster coordinates."
i.e. for a lat/lon location bufferzone=200 makes the buffer 200 degrees
in all directions, not 200m.
otherwise, man page indicates it should work ok with lat/lon.
rows: 52968
cols: 39853
cells: 2110933704
I hope you have a fast computer!
aside- perhaps the code should use G_distance() instead of its own
semi-baked distance() function??
Made a map in Australia, and wanted to use r.horizon on it.
Nothing special, a srtm map and default conditions.
This is the output:
(Sat Jun 20 16:51:57 2009)
r.horizon elevin=dem25m@PERMANENT horizonstep=30 bufferzone=200
maxdistance=2000 horizon=horangle
G_set_window(): Illegal latitude for North
(Sat Jun 20 16:51:57 2009) Command finished (0 sec)
I can recreate this from a single Lat/Lon srtm file. Works fine if you
reproject it into a planimetric map projection. --->
from the man page:
"At the moment the elevation and maximum distance must be measured in meters, even if you use geographical coordinates (longitude/latitude). If your projection is based on distance (easting and northing), these too must be in meters. The buffer parameters must be in the same units as the raster coordinates."
i.e. for a lat/lon location bufferzone=200 makes the buffer 200 degrees
in all directions, not 200m.
OK, I'll try modifying this.
otherwise, man page indicates it should work ok with lat/lon.
rows: 52968
cols: 39853
cells: 2110933704
I hope you have a fast computer!
... Sigh! Definitely not, but it will have to do, as usual.
aside- perhaps the code should use G_distance() instead of its own
semi-baked distance() function??
Would be good for homogeneity of the code.
Hamish
Thanks a lot Hamish.
--
Yann Chemin
Mobile: +33 (06) 10 11 39 26
Home: +33 (02) 35 27 08 20,
Address: Gite de Mortagne,
16 rue de la chenaie,
76110 Bec de Mortagne,
France