Hello,
I am trying to project data from ll wgas84 location to custom
projection. I end up with: ERROR: Unable to open element file <> for
. Data were imported to wgs 84 location withou any problems
(r.in.gdal) and than I made smaller area using r.resample.
I am using Grass 7.8.2 on Ubuntu 1
On Mon, Jan 13, 2020 at 3:01 PM Nikolai Hafner wrote:
>
> I tested it from an other location too but it´s the same problem:
> r.proj location=ASTER_lat-long mapset=PERMANENT
> input=DHM_SRTM30m_Aut-plus-Umgebung output=dhm_30m_ASTER_dachstein
> method=bilinear resolution=30
> ERROR: Unable to open
Am 13.01.2020 um 14:23 schrieb Markus Metz:
Nik, have you set the current region correctly?
>
> for r.proj -g you don't need the pipeline, try just
>
> r.proj -g location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_austria
>
> see also example https://grass.osgeo.org/grass78/
On Mon, Jan 13, 2020 at 1:00 PM Helmut Kudrnovsky wrote:
>
> nik wrote
> >
--
> >
> > I downloaded and installed
> >
http://www.bev.gv.at/portal/page?_pageid=713,2157075&_dad=portal&_schema=PORTAL
> >
> > r
nik wrote
>> What does r.proj -g output? With PROJ: 6.2.1, a proj pipeline has to be
>> given in r.proj. it's not in your cmd
>>
>> Can you report all steps with g.proj, g.region,, r.proj in source and
>> target locations as I've done?
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>
> g.proj
What does r.proj -g output? With PROJ: 6.2.1, a proj pipeline has to be
given in r.proj. it's not in your cmd
Can you report all steps with g.proj, g.region,, r.proj in source and
target locations as I've done?
-
best regards
Helmut
--
g.proj -p
-PROJ_INFO
nik wrote
> Hi
>> which GRASS version and operating system are you using?
> I also use:
> GRASS Version: 7.8.2
>
> Code revision: 3900fb114
Hi
> which GRASS version and operating system are you using?
I also use:
GRASS Version: 7.8.2
Code revision: 3900fb114
On Sat, Jan 11, 2020 at 5:55 PM Helmut Kudrnovsky wrote:
[...]
> unknown id, Inverse of Austria Lambert + MGI to ETRS89 (5) + UTM zone 33N,
> 0.15 m, Austria, at least one grid missing
>
> PROJ string:
> +proj=pipeline +step +proj=axisswap +order=2,1 +step +inv +proj=lcc
> +lat_0=47.5 +lon_0=13.33
nik wrote
> Hi,
> I want to re-project DEM data from a lambert-location into ETRS89/utm zone
> 33N
> I did that many times before but now I get the following message:
>
> r.proj location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_au
Hi,
On Sat, Jan 11, 2020 at 2:28 PM nik wrote:
>
> Hi,
> I want to re-project DEM data from a lambert-location into ETRS89/utm zone
> 33N
> I did that many times before but now I get the following message:
>
> r.proj location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
> input=dhm_10m_ogd_austria
Hi,
I want to re-project DEM data from a lambert-location into ETRS89/utm zone
33N
I did that many times before but now I get the following message:
r.proj location=MGI2wgs84_Austria_Lambert mapset=PERMANENT
input=dhm_10m_ogd_austria output=dhm_10m_ogd
On Fri, 20 Sep 2019, Markus Neteler wrote:
Improved now in the source code:
master:
https://github.com/OSGeo/grass/commit/a69135a74fc5c2b2047aea627deaf22be6f7cf4f
relbranch78:
https://github.com/OSGeo/grass/commit/07229c7edb3b96f6a9d33130a1d4d49217182e1c
markusN,
Thank you.
Rich
_
On Fri, 20 Sep 2019, Markus Neteler wrote:
Improved now in the source code:
master:
https://github.com/OSGeo/grass/commit/a69135a74fc5c2b2047aea627deaf22be6f7cf4f
relbranch78:
https://github.com/OSGeo/grass/commit/07229c7edb3b96f6a9d33130a1d4d49217182e1c
markusN,
Thank you. I've wondered a
On Fri, 20 Sep 2019, Markus Metz wrote:
The first numbers correspond to the current region in the target location,
the numbers in parentheses correspond to the actual map to be reprojected.
Markus M,
Thanks very much for the explanation.
Regards,
Rich
___
On Fri, Sep 20, 2019 at 8:49 AM Markus Metz
wrote:
> On Thu, Sep 19, 2019 at 4:51 PM Rich Shepard wrote:
> >
> > When I run r.proj grass presents information about the source and target
> > maps; e.g.,
> >
> > Input:
> > Cols: 8 (8)
> > Rows: 15536 (15536)
> > North: 1515424.50 (15154
On Thu, Sep 19, 2019 at 4:51 PM Rich Shepard
wrote:
>
> When I run r.proj grass presents information about the source and target
> maps; e.g.,
>
> Input:
> Cols: 8 (8)
> Rows: 15536 (15536)
> North: 1515424.50 (1515424.50)
> South: 1468816.50 (1468816.50)
> West: 610354.500
When I run r.proj grass presents information about the source and target
maps; e.g.,
Input:
Cols: 8 (8)
Rows: 15536 (15536)
North: 1515424.50 (1515424.50)
South: 1468816.50 (1468816.50)
West: 610354.50 (610354.50)
East: 643708.50 (643708.50)
EW-res: 3.0
On Sun, 15 Sep 2019, Markus Metz wrote:
You should now use
r.proj loc=Oregon map=topography in=n45w121
and not r.unpack, that is a completely different workflow that has nothing
to do with reprojection.
Markus M,
I've tried two approaches to getting the 10m DEM (upper, left corner at 46N,
123
On Sun, Sep 15, 2019 at 8:39 PM Rich Shepard
wrote:
>
> On Sat, 14 Sep 2019, Markus Metz wrote:
>
> > gdalwarp estimates the target extents unless you use the -te option. In
> > contrast, r.proj uses the current region. r.proj can estimate the target
> > extents with the -p or -g flag. I suggest t
On Sat, 14 Sep 2019, Markus Metz wrote:
gdalwarp estimates the target extents unless you use the -te option. In
contrast, r.proj uses the current region. r.proj can estimate the target
extents with the -p or -g flag. I suggest to first check you current
region in the target location/mapset and c
On Sun, 15 Sep 2019, Markus Neteler wrote:
How do I copy maps from one location to another when the projection of both
is the same?
With r.pack/v.pack, then r.unpack/v.unpack.
Markus,
Well! I definitely missed recognizing these as the answer when I looked at
the list of modules. Perhaps be
Rich Shepard schrieb am So., 15. Sep. 2019,
01:47:
>
> How do I copy maps from one location to another when the projection of both
> is the same?
>
With r.pack/v.pack, then r.unpack/v.unpack.
Markus
___
grass-user mailing list
grass-user@lists.osgeo.
On Sat, 14 Sep 2019, Rich Shepard wrote:
Stepping away from the issue for a while often lets in the light of
understanding, as it did in this case.
Wrong. The source and destination locations have the same projections:
Input:
name: NAD83(HARN) / Oregon North
datum: nad83harn
ellps: grs80
proj
On Fri, 13 Sep 2019, Rich Shepard wrote:
Reprojecting a 10m DEM fails. Following are the command and input/output
projection and map description information. Screenshots of the input and
output maps are attached.
I need to understand why the output is wrong.
Stepping away from the issue for a
On Sat, Sep 14, 2019 at 1:15 AM Helmut Kudrnovsky wrote:
>
> Rich Shepard wrote
> > Reprojecting a 10m DEM fails. Following are the command and input/output
> > projection and map description information. Screenshots of the input and
> > output maps are attached.
> >
> > I need to understand why t
On Fri, 13 Sep 2019, Helmut Kudrnovsky wrote:
a good thing to see if reprojection of raster data works correctly, is
comparing before/after r.proj with gdalwarp (1) results.
(1) https://gdal.org/programs/gdalwarp.html#gdalwarp
Helmut,
I'll try gdalwarp. Scanning that web page suggests it does
Rich Shepard wrote
> Reprojecting a 10m DEM fails. Following are the command and input/output
> projection and map description information. Screenshots of the input and
> output maps are attached.
>
> I need to understand why the output is wrong.
>
> Command:
> r.proj loc=Oregon map=topography in
When I use r.proj to use a DEM in a different location the module shows the
number of cells such as this example:
Input:
Cols: 502 (80961)
Rows: 39234 (113148)
Output:
Cols: 500 (71702)
Rows: 39232 (50757)
In both the input and output locations the resolution is 1m x 1m. What do
the paranthetic
On Thu, 12 Sep 2019, Rich Shepard wrote:
I have a large DEM reprojecting from lon/lat to Lambert Conformal Conic and
specified the lanczos_f method to minimize smoothing (the west edge of the
DEM is at the coast).
I would like to learn how to minimize processing time when modules accept
a hig
I have a large DEM reprojecting from lon/lat to Lambert Conformal Conic and
specified the lanczos_f method to minimize smoothing (the west edge of the
DEM is at the coast).
With 32G RAM in the host I specified mem=4000 in the r.proj command line.
When I look at top I see that process consuming 97
On Mon, 9 Jul 2018, Helmut Kudrnovsky wrote:
gdalwarp - Warp an image into a new coordinate system
(http://www.gdal.org/gdalwarp.html)
try gdalwarp to see how the raster is re-projected there and then compare
the settings in GRASS.
...
the real strength of GRASS in raster is, that you can c
On Mon, 9 Jul 2018, Micha Silver wrote:
Yes, but you can change both anytime you need a different extent or resolution.
Thanks for clarifying, Micha.
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listi
On 07/09/2018 06:43 PM, Rich Shepard
wrote:
In the Notes section of the 7.5 r.proj manual the second and third
paragraphs read,
"To avoid excessive time consumption when reprojecting a map the
region and
>I'm working on understanding how to correct r.proj failures because the
>source map/location is outside the bounds of the target location.
gdalwarp - Warp an image into a new coordinate system
(http://www.gdal.org/gdalwarp.html)
try gdalwarp to see how the raster is re-projected there and then c
In the Notes section of the 7.5 r.proj manual the second and third
paragraphs read,
"To avoid excessive time consumption when reprojecting a map the region and
resolution of the target location should be set appropriately beforehand."
Isn't the target's location and region set when that loca
On 24.03.2015 17:00, Vaclav Petras wrote:
..
So I guess we miss a version of g.copy which would be able to copy
from
different Database/Location (with same-projection check)? (Even
implementation through r|v.pack and unpack would be possible.)
Nice idea! Shouldn't be difficult.
Nikos
___
On Tue, Mar 24, 2015 at 9:18 AM, Markus Neteler wrote:
> Hi Paul,
>
> On Tue, Mar 24, 2015 at 2:09 PM, Paul Shapley wrote:
> > Hi Users,
> >
> > Having some problems moving some landsat 8 composite images into a
> different
> > location/mapset with the same projection. Have tried r.proj (this
>
Hi Paul,
On Tue, Mar 24, 2015 at 2:09 PM, Paul Shapley wrote:
> Hi Users,
>
> Having some problems moving some landsat 8 composite images into a different
> location/mapset with the same projection. Have tried r.proj (this produces
.. please do not reproject, it will alter the data.
For simple
Hi Users,
Having some problems moving some landsat 8 composite images into a
different location/mapset with the same projection. Have tried r.proj (this
produces the 'ERROR: Input raster map is outside current region') and
v.in.region method (this produces a 'blank' map). Not sure if the
resolutio
On Tue, Apr 29, 2014 at 1:22 PM, Paul Shapley wrote:
> I am trying to re-project some landsat 8 bands in from one location into
> another location with the same Ordnance Survey Projection (epsg:27700) using
> r.proj.
Why do you use r.proj here? If the projection in the two locations are
the same
I am trying to re-project some landsat 8 bands in from one location into
another location with the same Ordnance Survey Projection (epsg:27700)
using r.proj. They should overlap but currently do not. Am i using the
correct module? The error message is:
-
Hi Markus
Thanks.
I suggest, if it is a know but, put this on manual page of GRASS while
not fixed :-)
Cheers
miltinho
2013/2/16, Markus Metz :
> On Sat, Feb 16, 2013 at 4:50 PM, Milton Cezar Ribeiro
> wrote:
>> Dear all,
>>
>> I have two grass spatial database, each on different directory a
On Sat, Feb 16, 2013 at 4:50 PM, Milton Cezar Ribeiro
wrote:
> Dear all,
>
> I have two grass spatial database, each on different directory and
> with different projection/datum.
>
> How can I import a raster map while reprojectingit?
>
> Just suppose I am connected on
> C:\Mydata\GrassSDB_target
Dear all,
I have two grass spatial database, each on different directory and
with different projection/datum.
How can I import a raster map while reprojectingit?
Just suppose I am connected on
C:\Mydata\GrassSDB_target
newLocation
PERMANENT
and the source data are on
C:\users\Gra
Hi Glynn,
Thanks for the reply. I will resample the largest one.
cheers
miltinho
2012/12/9, Glynn Clements :
>
> Milton Cezar Ribeiro wrote:
>
>> I have an Albers project within Grass, and anoter in LatLong WGS84.
>> I want to import the Albers data within the LatLong WGS84 mapset.
>>
>> But wh
Milton Cezar Ribeiro wrote:
> I have an Albers project within Grass, and anoter in LatLong WGS84.
> I want to import the Albers data within the LatLong WGS84 mapset.
>
> But when I try r.proj (see below) I get ERRO:Error seeking on segment file
> Any tip are welcome
> Input:
> Cols: 50750 (5401
Markus,
Checking the database connection helped me identify the actual problem, which a
bad VAR file in the location. Once I got rid of it and reconnected, r.project
was able to create a new table.
Dave
Dave Kindem
dkin...@gmail.com
616.402.0864
On Jan 1, 2012, at 2:47 PM, Markus Neteler wro
2012/1/1 Micha Silver :
...
> Probably you have to first create an empty sqlite database.
This should happen automatically. If not, I would consider it a bug.
Does any other Mac, OS X 10.6.8 user have such a problem that
the sqlite.db is not created automatically?
Markus
Thanks Micha. I can now create the table.
Dave
Dave Kindem
dkin...@gmail.com
On Jan 1, 2012, at 8:55 AM, Micha Silver wrote:
> On 01/01/2012 15:43, Dave Kindem wrote:
>>
>> Hello,
>>
>> I have created a vector layer from a database table in an XY location
>> (accidents_xy). Both the topol
On 01/01/2012 15:43, Dave Kindem wrote:
Hello,
I have created a vector layer from a database table in an XY
location (accidents_xy). Both the topology and a database table
(accidents_xy) seem to have been created correctly. When I try
to
Hello,
I have created a vector layer from a database table in an XY location
(accidents_xy). Both the topology and a database table (accidents_xy) seem to
have been created correctly. When I try to re-project the layer into a UTM
location using r.proj, I receive the following error:
> GRASS
Kirk wrote:
> I am trying to re-project a raster
> into a location, and I am getting an error about the region
> of the raster being outside the region of the new location.
>
>
> r.proj input=foresttype location=mnwimi_usfs
> mapset=PERMANENT output=foresttype
> Input Projection Parameters: +pro
I am trying to re-project a raster into a location, and I am getting an error
about the region of the raster being outside the region of the new location.
r.proj input=foresttype location=mnwimi_usfs mapset=PERMANENT output=foresttype
Input Projection Parameters: +proj=aea +lat_1=29.5 +lat_2=45
On Thu, Mar 17, 2011 at 4:18 PM, TimNorwey wrote:
> Hy!
>
> I´m trying to re-project a GEOTIFF using r.proj. When executing my command,
> I always get the message "Segmentation fault".
Which GRASS version do you use on what operating system?
>I tried to find something in the forum and I found th
Hy!
I´m trying to re-project a GEOTIFF using r.proj. When executing my command,
I always get the message "Segmentation fault". I tried to find something in
the forum and I found the post:
http://osgeo-org.1803224.n2.nabble.com/GRASSLIST-4255-Segmentation-fault-while-using-v-proj-r-proj-tc1851719.
On Wed, 2 Mar 2011, Hamish wrote:
The DEMs were originally in lat/lon (NAD83) and imported to that
location.
if the originals are lat/lon then they need to be imported to a lat/lon
location,
As stated.
ok, that looks good, although I wonder why the east and west have become
negative.
Rich wrote:
> I am trying to reproject all
> data to a single projection: Albers Equal
> Area (NAD83) and g.region is:
>
> projection: 99 (Albers Equal Area)
> zone: 0
> datum: nad83
> ellipsoid: grs80
> north: 43
> south: 34
> west: -121
> east: -112
> nsres:
I am trying to reproject all data to a single projection: Albers Equal
Area (NAD83) and g.region is:
projection: 99 (Albers Equal Area)
zone: 0
datum: nad83
ellipsoid: grs80
north: 43
south: 34
west: -121
east: -112
nsres: 1
ewres: 1
rows: 9
col
Bulent Arikan wrote:
> > Cubic interpolation can introduce overshoot, as can other forms of
> > spline interpolation. Linear and nearest-neighbor interpolation don't
> > have this issue.
> >
> > With r.resamp.rst, the problem can be alleviated to a degree by using
> > higher values for the tensio
Thanks Glynn.
That makes sense now. I did not know about the inherent problem of
overshooting in cubic interpolation. ASTER DEMs I have seem to be pretty
consistent in terms of data ranges and representation of values (based on
r.report), so I am not sure about the noise effect in my case. However
Bulent Arikan wrote:
> I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
> (Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and
> 'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
> cubic, I ended up having couple of cells (literall
Hi,
I might have found a solution to my problem, which I shared with you earlier
today. I am writing about it in case someone else has a similar issue and
this may be a way of solving the problem. However, I am not certain if this
is the easiest or the most practical way of getting the results.
T
Hi,
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
mill
On Wed, 23 Dec 2009, Glynn Clements wrote:
Provided that it wasn't blocked by a spam filter.
Shouldn't have been. I can grep the maillog, but I've changed the option
so this should be moot now.
I'm still running majordomo; keep meaning to move to mailman but cannot
make the time.
Thanks,
Rich Shepard wrote:
> > Otherwise, if someone replies to one of your posts with "reply to all"
> > (which was the case for Maciej's reply), mailman won't send you a copy. If
> > the copy which was sent directly to you then gets dropped by a spam
> > filter, you won't see the message at all.
>
>
On Tue, 22 Dec 2009, Glynn Clements wrote:
You may want to check your mailman preferences:
http://lists.osgeo.org/mailman/listinfo/grass-user
Ensure that the "Avoid duplicate copies of messages?" option is set to
"no".
Glynn,
That's interesting. I've never set that for any other m
Rich Shepard wrote:
>Trying to bring in the raster DEM to the project location, but r.proj
> fails because of a difference in false eastings:
>
> GRASS 6.4.0svn (beaver_lake):/usr4/grassbase > r.proj input=elevation10m
> location=dem10m_northwest output=DEM method=cubic
> Input Projection Pa
Rich Shepard wrote:
> >> Set the output location's region to the extent of your to-be-reprojected
> >> data, before running r.proj in the input location.
>
>This message never arrived here.
You may want to check your mailman preferences:
http://lists.osgeo.org/mailman/listinfo/gras
On Tue, 22 Dec 2009, Daniel Victoria wrote:
Could it be that the vector created by v.in.region is messed up, or
it's covering a larger area that you are not interested in?
Daniel,
Anything's possible at this point. I've apparently trashed the target
location's projection; trying to set it t
Could it be that the vector created by v.in.region is messed up, or
it's covering a larger area that you are not interested in?
Last time I used r.proj here is how I did it:
1) Go to source location and set the region to match the area I want to project
2) Create a bounding box (v.in.region)
3) Wr
On Tue, 22 Dec 2009, Daniel Victoria wrote:
So, in order to know where you projected raster will fall, you can use
the v.in.region trick. The command will create a bounding box in your
map and you can project the vector (using v.proj), and not wory about
the current region. Then you set your reg
Hi Rich,
I'm no expert in projection or Grass for that matter but this is what
I understand about the way Grass projects rasters and vectors. Hope
not to be making things worse :)
In order to project a raster you have to "bring it in" your current
location from another location that has a differe
On Tue, 22 Dec 2009, Hamish wrote:
tip: v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If there will bit a lot of rotation I try to set it even finer.
Hamish,
I'm missing something important whi
On Tue, 22 Dec 2009, Hamish wrote:
Maciej wrote:
Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
tip:
v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better
On Tue, 22 Dec 2009, Eric Patton wrote:
I've added an example to the r.proj man page in grass64_release, devbr6,
and trunk.
Thanks, Eric. That makes it consistent with other man pages.
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
ht
Rich Shepard wrote:
> Germane to that last point: the r.proj man page includes conceptual detail
> toward the end but no examples. The v.proj man page is the opposite. IMNSHO,
> the r.proj detail should be in the wiki or other instructional documentation
> and examples of usage should be on the m
On Tue, 22 Dec 2009, Hamish wrote:
Maciej wrote:
Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
This message never arrived here.
Can I assume that "output location" is the destination and "input
location" is the
Maciej wrote:
> Set the output location's region to the extent of your to-be-reprojected
> data, before running r.proj in the input location.
tip:
v.proj'ing over a v.in.region box can help there. Then I usually try
to set the resolution to be a tiny bit better than the source rows x cols.
If ther
Rich Shepard pisze:
r.proj fails because of a difference in false eastings:
Rather not.
ERROR: Input raster map is outside current region
Set the output location's region to the extent of your to-be-reprojected
data, before running r.proj in the input location.
Maciek
--
Maciej Sieczka
h
Trying to bring in the raster DEM to the project location, but r.proj
fails because of a difference in false eastings:
GRASS 6.4.0svn (beaver_lake):/usr4/grassbase > r.proj input=elevation10m
location=dem10m_northwest output=DEM method=cubic
Input Projection Parameters: +proj=lcc +lat_1=43 +la
Richard Feldman wrote:
> (Tue Jun 16 11:09:28 2009)
> r.proj in=elevation.dem location=spearfish60 mapset=PERMANENT
> out=elevation.dem
> (Tue Jun 16 11:09:31 2009) Command finished (3 sec)
I tried using the latest 6.4.0rc5 wingrass installer and that worked
fine for me on XP.
First I had to
Hi and thank you for the quick reply.
It still doesn't work. I tried r.proj with my destination location being
the one I've been working with and I tried it with a new location with a
lat/lon wgs84 projection. Both times, "r.proj has stopped working." (I
tried with both elevation.dem and densi
Richard wrote:
> I am trying to project a raster with r.proj. Although it
> seemed to work fine the other day, today it's not
> working. The function stops and in Windows Vista the message
> "r.proj has stopped working" pops up. I know there may be
> size limitations but I'm trying to project a r
Hello,
I am trying to project a raster with r.proj. Although it seemed to work fine
the other day, today it's not working. The function stops and in Windows Vista
the message "r.proj has stopped working" pops up. I know there may be size
limitations but I'm trying to project a raster that's on
Dear all,
I have two mapsets, and I get error (r.proj.exe crash) when trying
to reproject from one mapset to another.
I am running the compiled 6.4R4 under Vista 64 bits.
My mapsets looks like:
(1) With source data
PROJ_INFO-
name : Lambert Az
86 matches
Mail list logo
