[GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Blumentrath, Stefan]

Hei,

What about something like this (example converts from UTM33 to WGS84 and creates ):
r.stats -gn1 INPUTMAP | cs2cs -E -f "%.6f" +proj=utm +no_defs +zone=33 +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 +to +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs | tr '\t' ' ' | r.in.xyz --o --v z=6 input=- output=REPROJECTED_MAP separator=space

Or is cs2cs to slow or does it modify also z?

BTW, I think several modules would benefit from a -b do not build topology...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] On Behalf Of Moritz Lennert
Sent: 30. november 2016 19:36
To: Markus Metz <markus.metz.giswork at gmail.com>
Cc: grass-dev <grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data



Le 29 novembre 2016 22:33:39 GMT+01:00, Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>> a écrit :
> For
>reprojection, something like r.in<http://r.in>.xyz could work:

I'm currently going through this process and it raises a series of issues:


>
>1. convert raster cells to vector points with raster cell value as
>vector z
>value.

I use r.to<http://r.to>.vect for this. The -b flag allows +/- fast conversion, but it takes into account all cells. It would be great to have a flag telling it to only convert non-null cells. Or at least a hint to set a mask, which seems to have the desired effect.


>2. reproject these vector points to the target location

I locally modified v.proj to add a 'Don't build topology' flag.

Is there any indication against this ?

>3. export the vector points with v.out.ascii format=point
>4. import the exported points with r.in<http://r.in>.xyz method=sum

This works nicely.

Thanks ! If I find the time I will wrap this into a r.proj.aggregate (?) script...



>
>The method options of r.in<http://r.in>.xyz could be added to r.proj for spatial
>aggregation, but that would mean that most of the code of r.in<http://r.in>.xyz
>would
>need to be copied to r.proj, then adapted. That would be an interesting
>enhancement, also considering that gdalwarp offers as resampling
>methods
>near, bilinear, cubic, cubicspline, lanczos, average, mode, max, min,
>med,
>Q1, Q3.

But it doesn't offer sum....

Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161130/0b7f6744/attachment.html>