Markus M wrote:
If the latlon region crosses the 180E/W border, this is an
inherent bug
note for raster modules -180 to +360 are supported. that way
both -180 to +180 and 0 to 360 are supported. (platenary
scientists like to work in 0-360)
A goal is that vector modules should be lat/lon wrap aware and
suppot the same (this largely lags behind lat/lon support in
raster libs/modules).
Hamish
Hamish wrote:
Markus M wrote:
If the latlon region crosses the 180E/W border, this is an
inherent bug
note for raster modules -180 to +360 are supported. that way
both -180 to +180 and 0 to 360 are supported. (platenary
scientists like to work in 0-360)
A goal is that vector modules should be lat/lon wrap aware and
suppot the same (this largely lags behind lat/lon support in
raster libs/modules).
Hmm, I thought raster cellhd entries are limited to 180E/W, but in
latlon it is allowed that East < West in cellhd. The display can show
lon beyond 180E/W and wraps rasters as necessary.
There are a few problems with latlon wraparound in vectors, i.e. chop
areas in pieces so the boundary coordinates are within 180E/W, what to
do with lines, split them too but then what happens with network
analysis, how to select features by bounding box?
Anyway, I don't think that this was the problem of v.proj that Timmie
observed. There was a problem in the spatial index while splitting
nodes, without the problem vector and a lot of patient debugging it is
impossible to tell why (at least for me knowing just a bit about RTree
node splitting methods). There is probably an easy fix but I'm not sure
if that fix would not introduce a new bug.
Markus M