Opened 12 years ago

Closed 10 years ago

#1825 closed defect (fixed)

r.tileset only returns one tile

Reported by: pvanbosgeo Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Raster Version: svn-trunk
Keywords: r.tileset Cc:
CPU: Unspecified Platform: Unspecified

Description

When using r.tileset in GRASS 70, only one tile is returned, irrespective of the number of rows and columns defined. It runs find in GRASS 64

Attachments (1)

r.tileset_bbox.diff (2.0 KB ) - added by neteler 11 years ago.
same patch but as diff to trunk main dir

Download all attachments as: .zip

Change History (9)

comment:1 by martinl, 12 years ago

Component: DefaultRaster
Keywords: r.tileset added

comment:2 by sbl, 11 years ago

Some variant of the same problem I guess:

On Ubuntu I get no tiles listed:

On my Windows box I get this error-message:

GRASS 7.0.svn> r.tileset sourceproj="+proj=utm +no_defs +zone=33 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1" maxcols=25000 maxrows=25000 overlap=10 sh: r.tileset: command not found

On my Ubunut box no tiles are printed at all:

GRASS 7.0.svn (Norge_33N_WGS84):~ > r.tileset sourceproj="+proj=utm +no_defs +zone=33 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1" maxcols=25000 maxrows=25000 overlap=10 Computing tiling... GRASS 7.0.svn (Norge_33N_WGS84):~ >

Looks like a declaration of floating type variables I necessary, when the tile_bbox w,s,e,n coordinates are calculated. Furthermore, the bboxesIntersect() method does not work properly.

The provided patch should fix these issues.

But there will be still a rounding oddity, because my regions n,s,e,w have no digits, while the tiles get some:

GRASS 7.0.svn (Norge_33N_WGS84):~ > g.region -up projection: 1 (UTM) zone: 33 datum: wgs84 ellipsoid: wgs84 north: 7972675 south: 6415595 west: -97865 east: 1165535 nsres: 10 ewres: 10 rows: 155708 cols: 126340 cells: 19672148720

GRASS 7.0.svn (Norge_33N_WGS84):~ > r.tileset1.py sourceproj="+proj=utm +no_defs +zone=33 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1" maxcols=25000 maxrows=25000 overlap=10 --v Projecting destination region into source... Projecting source bounding box into destination... Computing length of sides of source bounding box... Computing tiling... There will be 6 by 7 tiles each 21057 by 22244 cells -97864.9638333|6415594.9703|112801.679274|6638134.85547|21067|22254 -97864.9638333|6638034.85552|112801.679274|6860674.74064|21067|22254 -97864.9638333|6860474.74074|112801.679274|7083214.62581|21067|22254 -97864.9638333|7082914.62596|112801.679274|7305754.51097|21067|22254 ...

by neteler, 11 years ago

Attachment: r.tileset_bbox.diff added

same patch but as diff to trunk main dir

comment:3 by neteler, 11 years ago

Can a Python dev please review sbl's patch?

comment:4 by neteler, 11 years ago

Proposed patch submitted in r58782. Please test (and close ticket if issue is now fixed).

comment:5 by pvanbosgeo, 11 years ago

After update to the latest patch, running the function shows "computing tiling...", but seems to get stuck at that point.

(also tested in 6.4, where it works without problems).

comment:6 by sbl, 11 years ago

Tested in GRASS 7 revision 58670 (Ubuntu 12.04 32bit).

On my computer it works fine both with a full proj-string ("+proj=longlat +datum=WGS84 +no_defs") and with the proj-string from the example from the manual ("+init=epsg:4326").

However, the option "sourceproj" is case sensitive and improper projection strings are not caught by a user-readable error message...

in reply to:  6 comment:7 by sbl, 11 years ago

Sorry, 58670 was the Libgis Revision. SVN revision was: 59118

in reply to:  6 comment:8 by lucadelu, 10 years ago

Resolution: fixed
Status: newclosed

Replying to sbl:

Tested in GRASS 7 revision 58670 (Ubuntu 12.04 32bit).

I tested with 62902 and it works.

On my computer it works fine both with a full proj-string ("+proj=longlat +datum=WGS84 +no_defs") and with the proj-string from the example from the manual ("+init=epsg:4326").

However, the option "sourceproj" is case sensitive and improper projection strings are not caught by a user-readable error message...

I add some more check in r62923 and r62924 to return more understandable output.

I close this ticket, please reopen if needed

Note: See TracTickets for help on using tickets.