Re: [GRASS-user] Do filters available in GRASS takes care of cell padding?
Thank you very much. It is much easy to understand the kernel function options now. Thanks once again. On Fri, Dec 4, 2015 at 1:44 PM, Glynn Clements wrote: > > Uttam Kumar wrote: > > > 4.) Which one of the above GRASS commands would be best suited to perform > > window operation (high pass filtering) along with cell padding? > > One caveat to my previous reply: > > Ignoring nulls often doesn't work so well for kernels with a zero sum > (e.g your high-pass filter). You can't use r.neighbors method=average > with weights which sum to zero (as that results in division by zero), > and method=sum introduces a bias if some weights are ignored (at the > edges, you'll have a single cell with a weight of 24 and fewer than 24 > cells with a weight of -1, meaning that a constant map would produce a > positive value near the edges). > > I would suggest using two passes, e.g. > > r.neighbors size=5 method=average input=band5 output=band5_average > r.mapcalc 'band5_highpassfilter = band5 - band5_average' > g.remove raster=band5_average > > This returns the value of the centre cell minus the average of the > surrounding non-null cells. The average value is still meaningful if > the filter window overlaps null cells or the edges. > > -- > Glynn Clements > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Do filters available in GRASS takes care of cell padding?
If I am trying to use r.mfilter input=band5 output=band5_highpassfilter filter=/Users/Uttam/high_pass_filter where high_pass_filter is TITLE 5x5 High Pass MATRIX 5 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 24 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 DIVISOR 25 TYPE P 1.) How do I ensure that cell padding is taken care using r.grow.distance? Do I need to apply r.grow.distance on the output of r.mfilter or it should be applied before r.mfilter on the input image (band5 in this case)? 2.) Will use of r.resamp.filter will do both - cell padding and apply filter in a single execution? However, I felt r.resamp.filter does not allow specifying the type of filter such as high pass filter coefficients in the input. r.resamp.filter input=band5 output=band5_resamp filter=box radius=1 How to specify the filter coefficients here? 3.) r.resamp.stats does not allow to specify the filter size (3 or 5)? I feel that in any case the number of rows should increase by 2 (1 top and 1 bottom) and number of columns should increase by 2 (1 left and 1 right) during cell padding. 4.) Which one of the above GRASS commands would be best suited to perform window operation (high pass filtering) along with cell padding? Any suggestions are appreciated and welcome. On Mon, Nov 30, 2015 at 6:11 PM, Glynn Clements wrote: > > Uttam Kumar wrote: > > > Do the filters available in GRASS GIS such as average, low pass, high > pass > > filters take care of cell padding automatically? > > "filters"? > > > By Cell paddding, I refer to duplicating the first row on top, > duplicating > > bottom row at the bottom, duplicating first column before the actual > first > > column and duplicating last column after the actual last column. > > None of the modules do this, although you can achieve that result by > by first using e.g. r.grow.distance with the value= option to replace > null cells with the nearest non-null cell. > > r.resamp.filter simply enlarges the source region by the kernel > radius. If this results in it reading nulls (because the enlarged > region extends beyond the area for which the map contains data), then > either > > a) the nulls will be propagated (if -n is used) or, > > b) the weighting will be adjusted, i.e. the result will be > > sum(weight * value)/sum(weight) > > where both sums are evaluated over the non-null inputs. > > r.resamp.stats behaves similarly (i.e. it either propagates nulls or > computes the aggregate over the non-null cells). > > r.neighbors always calculates the aggregate over the non-null cells. > > -- > Glynn Clements > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Do filters available in GRASS takes care of cell padding?
Hi, Do the filters available in GRASS GIS such as average, low pass, high pass filters take care of cell padding automatically? By Cell paddding, I refer to duplicating the first row on top, duplicating bottom row at the bottom, duplicating first column before the actual first column and duplicating last column after the actual last column. This may be required if we are trying to do any filter operation on the (1,1) of the image. The filter will search for pixels above and left of the center pixels. Can we do it using r.mapcalc? Please suggest how to do this? Thank you for any response. Uttam. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.cluster/i.maxlik question
As I understand GRASS can handle both conditions (i.e. the number of clusters (through the parameter classes) and "iterations" as the criteria to converge. The algorithm will stop as soon as any of the conditions are met first. https://grass.osgeo.org/grass64/manuals/i.cluster.html On Thu, Nov 26, 2015 at 1:03 PM, Michael Barton wrote: > I'm trying out GRASS's unsupervised classification functions. As I > understand it, it is a 2 step process. > > 1. run i.cluster to get cluster signatures > 2. run i.maxlik using the cluster signatures to generate the spatial > clusters > > I've varied the parameters several times, and AFAICT, setting the initial > number of clusters also determines the final number. In other unsupervised > clustering routines I've used, this is not the case. Because the clustering > iterates until the convergence value is reached, the final number of > clusters can be different from the initial number. Can anyone offer insight > on this for GRASS? > > Thanks > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Head, Graduate Faculty in Complex Adaptive Systems Science > Arizona State University > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) > www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu > > > > > > > > > > > > > > > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Does filters available in GRASS takes care of cell padding?
Hi, Do the filters available in GRASS GIS such as average, low pass, high pass filters take care of cell padding automatically? By Cell paddding, I refer to duplicating the first row on top, duplicating bottom row at the bottom, duplicating first column before the actual first column and duplicating last column after the actual last column. This may be required if we are trying to do any filter operation on the (1,1) of the image. The filter will search for pixels above and left of the center pixels. Can we do it using r.mapcalc? Please suggest how to do this? Thank you for any response. Uttam. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Need help in r.lake
Hello All, I have a raster map with several lakes. Each lake is filled with some water which I treat as a seed pixel. I want these lake to be filled with water until they reach the top that is there is no more increase in elevation. I can use r.lake but it accepts only one value for water level parameter and I have several lakes with different water levels. How can I assign multiple "water level" paramter for different lakes in the single rater map. Is there any functionality in GRASS GIS to support this analysis? Any help is appreciated. Uttam. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Is Watershed image segmentation program in GRASS GIS?
Hi Leonardo, I went through the paper " Semi-automated_mapping_of_burned_areas_in_semi-arid_ecosystems_using_MODIS_time-series_imagery <https://www.researchgate.net/publication/269692754_Semi-automated_mapping_of_burned_areas_in_semi-arid_ecosystems_using_MODIS_time-series_imagery>" and I am also trying to do something similar except that I want to separate water bodies. Is it possible for you to share the GRASS code on segmentation (based on Pratt, W.K., 2001. Digital Image Processing. NY: Wiley-Interscience, New York, pp. 491–556.) which you executed as an ad hoc function in r.mapcalc. Appreciate any help. Uttam. On Wed, Nov 11, 2015 at 8:48 AM, Leonardo Hardtke wrote: > Hi there... > > I used r.grow to segment dNBR images to map wildfires. See: > > > https://www.researchgate.net/publication/269692754_Semi-automated_mapping_of_burned_areas_in_semi-arid_ecosystems_using_MODIS_time-series_imagery > > Hope it helps... > > > 2015-11-11 3:47 GMT-03:00 Uttam Kumar : > >> >> >> Hi All, >> >> Is watershed image segmentation program or a similar module available in >> GRASS GIS? >> >> I understand that we have r.watershed, i.segment and r.grow in GRASS GIS. >> But I do not know which one best suits my problem. >> >> The problem is: >> >> I have two layers of raster data - >> 1.) a gradient image (obtained by applying a 3 x 3 sobel filter on a >> water index using r.mapcalc), and >> 2.) a seed image of 2 classes labelled as "1" and "2" and remaining >> pixels as "0". >> >> I want to use the seed image and the gradient image (which shows >> direction of change in intensity) information to perform segmentation using >> the watershed algorithm and label all "0" pixels as either 1 or 2. >> >> r.watershed does not use watershed segmentation algorithm. i.segment is >> something close but I am not sure. >> >> Please suggest. >> >> Any comment is appreciated. >> >> Uttam. >> >> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -- > Dr. Leonardo A. Hardtke > Laboratorio de Teledetección y S.I.G. > Centro Nacional Patagónico (CONICET) > Bvd. Brown 2825, 9120 > Puerto Madryn, Chubut, Argentina > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Is Watershed image segmentation program in GRASS GIS?
Hi All, Is watershed image segmentation program or a similar module available in GRASS GIS? I understand that we have r.watershed, i.segment and r.grow in GRASS GIS. But I do not know which one best suits my problem. The problem is: I have two layers of raster data - 1.) a gradient image (obtained by applying a 3 x 3 sobel filter on a water index using r.mapcalc), and 2.) a seed image of 2 classes labelled as "1" and "2" and remaining pixels as "0". I want to use the seed image and the gradient image (which shows direction of change in intensity) information to perform segmentation using the watershed algorithm and label all "0" pixels as either 1 or 2. r.watershed does not use watershed segmentation algorithm. i.segment is something close but I am not sure. Please suggest. Any comment is appreciated. Uttam. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Something wrong: Reprojection of raster maps in various platforms: projected coordinates are different
Thank you all for the suggestions. I could resolve the problem. GRASS gives me same projected coordinates as ENVI. On Fri, Oct 23, 2015 at 12:46 AM, Markus Neteler wrote: > > On Oct 23, 2015 2:22 AM, "Uttam Kumar" wrote: > > ... > > GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ > v.info -g Image_boundary_box > > > > north=823262.924419209 > > south=652223.643294404 > > east=-167210.022680164 > > west=-518209.054236328 > > top=0.00 > > bottom=0.00 > > > > > > I should have got this (This is correct): > > > > north:1638674.575 > > south:1481984.575 > > > > east:1157941.598 > > west:817651.598 > > > > Any clue, where am I wrong? > > You appear to compare the vector bounding box which easily leads to > misleading results in case of a rotated image. > The only correct way is to compare point wise (eg true corner points of > the image scene). > > Or generate a binary data/no data raster from a channel using r.mapcalc > and then r.to.vect to make it a vector polygon truly circumscribing the > image which can then be reprojected. > > Best > Markus > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Something wrong: Reprojection of raster maps in various platforms: projected coordinates are different
I could not reach the solution till now even after following the steps told in previous posts. I know I am making a silly mistake. This is the projection information of the target location: +proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs *GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ >g.proj -p* -PROJ_INFO- name : Lambert Azimuthal Equal Area proj : laea datum : nad83 ellps : grs80 lat_0 : 30 lon_0 : -96 x_0: 0 y_0: 0 no_defs: defined -PROJ_UNITS unit : Meter units : Meters meters : 1 *GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ > g.proj -w*PROJCS["Lambert Azimuthal Equal Area", GEOGCS["grs80", DATUM["North_American_Datum_1983", SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]], PROJECTION["Lambert_Azimuthal_Equal_Area"], PARAMETER["latitude_of_center",30], PARAMETER["longitude_of_center",-96], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["Meter",1]] *GRASS 7.1.svn (SanLuis_Reservoir_LAEA):~ > v.info <http://v.info> -g Image_boundary_box* north=823262.924419209 south=652223.643294404 east=-167210.022680164 west=-518209.054236328 top=0.00 bottom=0.00 *I should have got this (This is correct):north:1638674.575south:1481984.575east:1157941.598west:817651.598* *Any clue, where am I wrong?* On Tue, Oct 20, 2015 at 4:45 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 20/10/15 19:08, Uttam Kumar wrote: > >> >> >> I have been trying for a long time. Something wrong is going on. I >> appreciate if you can correct me. >> >> >> I have all my source images in sinusoidal projection in a location >> called "Landsat_sinu". >> >> My target locatoin is "Landsat_laea" I tried using the default option in >> GRASS GUI as follows: >> >> 1.) *Select coordinate system parameters from a list* >> >> 2.) Projection code: *laea* >> >> 3.) Datum with associated ellipsoid: >> Central parallel: *30* >> Central Meridian: *-96* >> False easting: *0* >> False northing: *0* >> >> 4.) Datum code: *nad83* >> 5.) Select from the list of datum transformation: *1 used in whole nad83 >> region* >> >> +proj=laea >> +lat_0=30 >> +lon_0=-96 >> +x_0=0 >> +y_0=0 >> +no_defs >> +a=6378137 >> +rf=298.257222101 >> +towgs84=0.000,0.000,0.000 >> to_meter=1 >> +datum=nad83 >> >> Finish. >> >> Is everything ok with this for the below (required) target definition? >> >> **PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 >> +units=m +no_defs '** >> >> Looks like at some point I am making a small mistake. I must get this as >> the projected coordinates. >> >> *north=1064601.38274499 >> south=830176.771464028 >> east=-1960125.15283348 >> west=-2265106.68066176* >> > > And what is wrong with these coordinates ? Those are exactly the ones I > get and they are very close to the ones you got from ENVI: > > > > Upper Left (-2265106.681W, 1064601.383N) > > > Lower Left (-2265106.681W, 830181.383N) > > > Upper Right (-1960126.681W, 1064601.383N) > > > Lower Right (-1960126.681W, 830181.383N) > > i.e. 4.6m difference for South and 1.5m difference for East. You would > have to check how the NAD83 conversion is done exactly to see if the > difference could come from there. > > Moritz > > > >> >> Any help is appreciated. >> >> Uttam. >> >> >> On Wed, Oct 14, 2015 at 4:52 PM, Moritz Lennert >> mailto:mlenn...@club.worldonline.be>> >> wrote: >> >> [Please keep conversations on the list] >> >> On 14/10/15 23:19, Uttam Kumar wrote: >> >> _ >> >> _ >> _*This information is for the original data (Source):*_ >> >> *PROJ.4 : '+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 >> +b=6371007.181 +units=m +no_defs '* >> >> >> Coordinate System is: >> PROJCS["Sinusoidal", >> GEOGCS["GCS_Unknown", >> DATUM["Unknown", >> SPHEROID["S_Unknown",6371007.181,0.0]], >>
[GRASS-user] Something wrong: Reprojection of raster maps in various platforms: projected coordinates are different
I have been trying for a long time. Something wrong is going on. I appreciate if you can correct me. I have all my source images in sinusoidal projection in a location called "Landsat_sinu". My target locatoin is "Landsat_laea" I tried using the default option in GRASS GUI as follows: 1.) *Select coordinate system parameters from a list* 2.) Projection code: *laea* 3.) Datum with associated ellipsoid: Central parallel: *30* Central Meridian: *-96* False easting: *0* False northing: *0* 4.) Datum code: *nad83* 5.) Select from the list of datum transformation: *1 used in whole nad83 region* +proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 to_meter=1 +datum=nad83 Finish. Is everything ok with this for the below (required) target definition? **PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs '** Looks like at some point I am making a small mistake. I must get this as the projected coordinates. * north=1064601.38274499 south=830176.771464028 east=-1960125.15283348 west=-2265106.68066176* Any help is appreciated. Uttam. On Wed, Oct 14, 2015 at 4:52 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > [Please keep conversations on the list] > > On 14/10/15 23:19, Uttam Kumar wrote: > >> _ >> >> _ >> _*This information is for the original data (Source):*_ >> >> *PROJ.4 : '+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 >> +b=6371007.181 +units=m +no_defs '* >> >> >> Coordinate System is: >> PROJCS["Sinusoidal", >> GEOGCS["GCS_Unknown", >> DATUM["Unknown", >> SPHEROID["S_Unknown",6371007.181,0.0]], >> PRIMEM["Greenwich",0.0], >> UNIT["Degree",0.0174532925199433]], >> PROJECTION["Sinusoidal"], >> PARAMETER["False_Easting",0.0], >> PARAMETER["False_Northing",0.0], >> PARAMETER["longitude_of_center",0.0], >> UNIT["Meter",1]] >> Origin = (-10801805.19769436736,4130102.07906977946) >> Pixel Size = (30.000,-30.000) >> >> * >> _This information is for the destination data (Target):_* >> >> *PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 >> +units=m +no_defs '* >> > > In your first mail you said: > > Lambert Azimuthal Equal Area, Datum: WGS84 > > but here the datum is NAD83. > > Using your projection info, I get almost exactly the same results in GRASS > as you report from ENVI: > > On 08/10/15 21:36, Uttam Kumar wrote:> Reprojected in ENVI (Lambert > Azimuthal Equal Area, Datum: WGS84) > > - > > Corner Coordinates: > > > > Upper Left (-2265106.681W, 1064601.383N) > > Lower Left (-2265106.681W, 830181.383N) > > Upper Right (-1960126.681W, 1064601.383N) > > Lower Right (-1960126.681W, 830181.383N) > > > GRASS 7.0.1 (test_LAEA):~ > v.info -g Image_Boundary_box > north=1064601.38274499 > south=830176.771464028 > east=-1960125.15283348 > west=-2265106.68066176 > > > Don't have the time now to explore the exact differences, but either it's > a question of definition of the bounding box, or it possibly be a question > of which specific NAD83 transformation parameters were used. > > Moritz > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Reprojection of raster maps in various platforms: projected coordinates are different
Thank you so much. Yes the datum should have been NAD83. This is perfect. Please summarize me how did you do this transformation from sinusoidal to Lambert Azimuthal Equal Area? I have all my source images in sinusoidal projection in a location called "Landsat_sinu". I want to create a target locatoin "Landsat_laea"? I tried using the default option in GRASS GUI and the options I selected was 1.) *Select coordinate system parameters from a list* 2.) Projection code: *laea* 3.) Datum with associated ellipsoid: Central parallel: *30* Central Meridian: *-96* False easting: *0* False northing: *0* 4.) Datum code: *nad83* 5.) Select from the list of datum transformation: *1 used in whole nad83 region* +proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 to_meter=1 +datum=nad83 Finish. Is everything ok with this for the below (required) target definition? *PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 +units=m +no_defs '* Looks like at some point I am making a small mistake. On Wed, Oct 14, 2015 at 4:52 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > [Please keep conversations on the list] > > On 14/10/15 23:19, Uttam Kumar wrote: > >> _ >> >> _ >> _*This information is for the original data (Source):*_ >> >> *PROJ.4 : '+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 >> +b=6371007.181 +units=m +no_defs '* >> >> >> Coordinate System is: >> PROJCS["Sinusoidal", >> GEOGCS["GCS_Unknown", >> DATUM["Unknown", >> SPHEROID["S_Unknown",6371007.181,0.0]], >> PRIMEM["Greenwich",0.0], >> UNIT["Degree",0.0174532925199433]], >> PROJECTION["Sinusoidal"], >> PARAMETER["False_Easting",0.0], >> PARAMETER["False_Northing",0.0], >> PARAMETER["longitude_of_center",0.0], >> UNIT["Meter",1]] >> Origin = (-10801805.19769436736,4130102.07906977946) >> Pixel Size = (30.000,-30.000) >> >> * >> _This information is for the destination data (Target):_* >> >> *PROJ.4 : '+proj=laea +lat_0=30 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD83 >> +units=m +no_defs '* >> > > In your first mail you said: > > Lambert Azimuthal Equal Area, Datum: WGS84 > > but here the datum is NAD83. > > Using your projection info, I get almost exactly the same results in GRASS > as you report from ENVI: > > On 08/10/15 21:36, Uttam Kumar wrote:> Reprojected in ENVI (Lambert > Azimuthal Equal Area, Datum: WGS84) > > - > > Corner Coordinates: > > > > Upper Left (-2265106.681W, 1064601.383N) > > Lower Left (-2265106.681W, 830181.383N) > > Upper Right (-1960126.681W, 1064601.383N) > > Lower Right (-1960126.681W, 830181.383N) > > > GRASS 7.0.1 (test_LAEA):~ > v.info -g Image_Boundary_box > north=1064601.38274499 > south=830176.771464028 > east=-1960125.15283348 > west=-2265106.68066176 > > > Don't have the time now to explore the exact differences, but either it's > a question of definition of the bounding box, or it possibly be a question > of which specific NAD83 transformation parameters were used. > > Moritz > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Reprojection of raster maps in various platforms: projected coordinates are different
You are right. The scene belongs to a small area near Central California region. I have available image boundary in SINUSOIDAL projection in vector format (shp file). How do I share this to grass users ? On Sat, Oct 10, 2015 at 1:56 PM, Markus Neteler wrote: > On Thu, Oct 8, 2015 at 9:36 PM, Uttam Kumar > wrote: > > Hi All, > > > > This is the projection information of a single Landsat scene in ENVI, > GRASS > > and using gdalwarp. GRASS and gdalwarp gave somewhat similar output but > ENVI > > is totally different. I have been informed that the projected image from > > ENVI is correct as verified from the earlier work. > > > > Original data (in Sinusoidal Projection) > > -- > > Corner Coordinates: > > Upper Left (-10801805.198W, 4130102.079N) > > Lower Left (-10801805.198W, 3971252.079N) > > Upper Right (-10642955.198W, 4130102.079N) > > Lower Right (-10642955.198W, 3971252.079N) > > So, I generated the upper left *corner* as a point: > echo "-10801805.198|4130102.079|1" | v.in.ascii input=- output=point > > It appears to be located in California. Right? > > > > > Reprojected in GRASS GIS (Lambert Azimuthal Equal Area, Datum: WGS84) > > Can you please give more information here? > > > > -- > > N:5564460 > > S:5185590| > > E: -5451390 > > W: -5762490 > > ... is this the upper box? > In EU LAEA (EPSG 3035), my SIN point becomes > > -674447.24192338|9862187.84799817 > > ... without data it is hard to say. Could you export your SIN box as a > SHAPE file and make available? > > Markus > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Reprojection of raster maps in various platforms: projected coordinates are different
Hi All, This is the projection information of a single Landsat scene in ENVI, GRASS and using gdalwarp. GRASS and gdalwarp gave somewhat similar output but ENVI is totally different. I have been informed that the projected image from ENVI is correct as verified from the earlier work. Original data (in Sinusoidal Projection) -- Corner Coordinates: Upper Left (-10801805.198W, 4130102.079N) Lower Left (-10801805.198W, 3971252.079N) Upper Right (-10642955.198W, 4130102.079N) Lower Right (-10642955.198W, 3971252.079N) Reprojected in GRASS GIS (Lambert Azimuthal Equal Area, Datum: WGS84) -- N:5564460 S:5185590| E: -5451390 W: -5762490 Reprojected in ENVI (Lambert Azimuthal Equal Area, Datum: WGS84) - Corner Coordinates: Upper Left (-2265106.681W, 1064601.383N) Lower Left (-2265106.681W, 830181.383N) Upper Right (-1960126.681W, 1064601.383N) Lower Right (-1960126.681W, 830181.383N) Reprojected using gdalwarp (Lambert Azimuthal Equal Area, Datum: WGS84) -- Corner Coordinates: Upper Left (-5148766.236W, 3000477.570N) Lower Left (-5148766.236W, 2724274.973N) Upper Right (-4826973.503W, 3000477.570N) Lower Right (-4826973.503W, 2724274.973N) Any comment is appreciated. Uttam. On Sun, Sep 27, 2015 at 1:48 AM, Markus Neteler wrote: > > On Sep 26, 2015 1:00 AM, "Uttam Kumar" wrote: > > > > Thank you all. It worked. > > > > However I noticed that the projected boundary values of N, S, W and E in > GRASS are not same as the values obtained from projecting the same image in > ENVI image processing software and in gdalwarp. > > > > Projection of the scene in Lambert Azimuthal Equal Area is similar (but > not exactly equal) in GRASS and gdal, but in ENVI it is totally different. > I just did the comparison to see if things are similar from different > softwares in case they have to be ported to other platforms. > > Can you print the projection information in both GRASS (g.proj -p or -w) > and ENVI? Are they really the same? > > Markus > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Need help in reprojecting raster images
Thank you all. It worked. However I noticed that the projected boundary values of N, S, W and E in GRASS are not same as the values obtained from projecting the same image in ENVI image processing software and in gdalwarp. Projection of the scene in Lambert Azimuthal Equal Area is similar (but not exactly equal) in GRASS and gdal, but in ENVI it is totally different. I just did the comparison to see if things are similar from different softwares in case they have to be ported to other platforms. Any comments is appreciated. Uttam. On Wed, Sep 23, 2015 at 12:35 PM, Veronica Andreo wrote: > Hi Uttam, > > you may want to first do v.in.region in your input location, this creates > a vector with the limits of your input location (set g.region to your > raster of interest first), then v.proj the output of v.in.region in your > target location, set region there with the imported vector and just then > try to reproject the raster image. > > so, steps would be: > > # in input_location > g.region raster=your_raster > > v.in.region output=vector_region_of_interest > > # in target location > v.proj location=input_location mapset=input_mapset > input=vector_region_of_interest output=projected_boundaries > > g.region vector=projected_boundaries > > r.proj location=input_location mapset=input_mapset input=input_raster > output=output_raster > > You may also wanna check r.import if you use grass7.1 ( > https://grass.osgeo.org/grass71/manuals/r.import.html) or as an add-on in > grass 7.0 (https://grass.osgeo.org/grass70/manuals/addons/r.import.html). > You can install it with g.extension r.import > > HTH, > Vero > > 2015-09-23 15:21 GMT-03:00 Uttam Sinha : > >> >> >> Hi, >> >> I tried the way you told. I created a new location in laea without >> setting the default boundary. Then from this mapset I used >> >> r.proj location*=input_location* mapset=*input_mapset* input=*input_raster >> name* output= >> >> *output_raster* >> I get an error: >> >> >> ERROR: Input raster map is outside current region >> >> Any suggestions. >> >> Uttam. >> >> >> On Tue, Sep 22, 2015 at 11:59 PM, sajid pareeth >> wrote: >> >>> Hi Uttam >>> >>> If I understand you correctly you want to reproject a landsat image from >>> sinusoidal to laea projection!! >>> You dont have to manually set the bounding box while reprojecting a >>> raster, as GRASS will take care of it. >>> >>> First you create a new location and mapset with desired output >>> projection , which in this case is Lamberts Azimuthal Equal Area. >>> Then get into this mapset, use the following r.proj command. >>> r.proj location*=input_location* mapset=*input_mapset* input=*input_raster >>> name* output= >>> *output_raster* >>> >>> More details here: https://grass.osgeo.org/grass70/manuals/r.proj.html >>> >>> If you then need to set your working area to a particular bounding box, >>> use g.region >>> >>> g.region raster=*output_raster* >>> >>> regards >>> >>> Sajid >>> >>> On Tue, Sep 22, 2015 at 11:07 PM, Uttam Sinha >>> wrote: >>> Hi All, I have a set of Landsat images in Sinusoidal Projection, WGS84 Datum. I know the north, south, east and west extent of the boundary of the image. I want to reproject the image to Lamberts Azimuthal Equal Area, WGS84 Datum. I do not know what will be the coordinates of the north, south, east and west bounds in this projection. 1.) How do I convert upper left coordinates and bottom right coordinates of Sinusoidal Projection to Lamberts Azimuthal Equal Area to create a new destination Location? 2.) How do I reproject the images from Sinusoidal to Lamberts without georeferencing the image at source location (in sinusoidal projection) Appreciate any reply. Uttam. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user >>> >>> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
