>I am using standalone winGRASS, but installed it with OSGeo4W because I also
>use QGIS.
I don't understand this. How do you install standalone winGRASS with OSGeo4W?
But that's another question.
Jürgen re-packaged now winGRASS 8.3.0 in OSGeo4W version 2 including the
Rbatch-files.
have a
>>Is it best to go back to the previous versions for the meantime?
>
>yes, that would be an option.
>
>are you using OSGeo4W or standalone winGRASS?
>
>these R-batch-files are living also in the source:
>
>https://github.com/OSGeo/grass/tree/main/mswindows/external/rbatch
>
>and are integrated
>Is it best to go back to the previous versions for the meantime?
yes, that would be an option.
are you using OSGeo4W or standalone winGRASS?
these R-batch-files are living also in the source:
https://github.com/OSGeo/grass/tree/main/mswindows/external/rbatch
and are integrated into
>ok, I misunderstood. I'm getting a similar response.
>C:\Users\haarlooj\Documents>Rscript -e "sessionInfo()"
>'Rscript' is not recognized as an internal or external command,
>operable program or batch file.
the reason is that the Rbatch-files from OSGeo4W version 1
>When I used d.mon start=wx0 grass told me it could not find a numpy for
>python-2.7.x.
why not, as Anna already suggested in an earlier reply, _fix_ your operating
system by removing python 2.x from your linux box and keep only python 3 there.
for a long time now, GRASS GIS 8.x switched to
>Is there a way to rasterize a 3d line to get altitude on raster cells
>crossed by the line ?
not quite sure what are you trying to do?
maybe:
v.drape:
Converts 2D vector features to 3D by sampling of elevation raster map.
(https://grass.osgeo.org/grass82/manuals/v.drape.html)
Additional
>later on I'll post a screenshot of the not patched r.sun in 8.2.1
here are
*comparison side by side
https://pasteboard.co/I3NLbdrhkhsg.png
*patched minus non patched
https://pasteboard.co/GZxvEUCPe2wM.png
there are not much differences in steep south oriented mountain slopes, though
in
Hi Anna,
>This could be potentially a problem described in
>https://github.com/OSGeo/grass/pull/2534.
>Could you try to run this with the changes in the PR?
I hopefully correctly applied this PR now here locally in my winGRASS. ;-)
DEM: Airborne Laser Scan 1 x 1 m
projection: 99 (MGI /
Hi Anna,
>This could be potentially a problem described in
>https://github.com/OSGeo/grass/pull/2534.
yes, it seems to be similar.
>Could you try to run this with the changes in the PR?
no chance to test the PR at the moment.
Best
Helmut
___
hi,
given a a mountain area with a high relief energy based upon an ALS DEM with a
1x1m resolution
and system: winGRASS GIS 8.2.1
g.region -p
projection: 99 (MGI / Austria Lambert)
zone: 0
datum: hermannskogel
ellipsoid: bessel
north: 358599.5
south: 345055.5
west:
>I'm trying to identify specific points on the centerline of a river channel
>by "river mile" , that is, points along a path at specified distances from
>a starting point — not at regular intervals. Any suggestions how I might
>go about this?
have a look at
>Hello Wolfgang,
>
>In our PSC meeting, Martin commented on this (last bullet point here:
>https://trac.osgeo.org/grass/wiki/PSC/Minutes/PSC_Meeting_20220513). Are
>you by chance using the standalone installer? Would it be possible for you
>to test GRASS installed through the OSGeo4W installer?
>
v
Thanks a lot
Best regards
Atentamente,
Enrique Torres Moya
Cel: 3102495375
El dom, 8 may 2022 a las 1:12, Helmut Kudrnovsky
(mailto:hel...@web.de]>) escribió:>v.in.ascii --overwrite
>input=/home/etorresm/Desktop/Vajont_Export_res_integer.csv
>output=voxel_res_int separato
>v.in.ascii --overwrite
>input=/home/etorresm/Desktop/Vajont_Export_res_integer.csv
>output=voxel_res_int separator=comma skip=1 x=2 y=3 z=4 cat=5
[...]
>UNIQUE constraint failed: voxel_res_int.int_5
>DBMI-SQLite driver error:
>Error in sqlite3_step():
>UNIQUE constraint failed:
>Just writing to inquire if the GRASS GIS Windows Binary Stand-Alone Builds are
>using the –with-openmp >Build Configuration flag to enable multithreading
>across all applicable modules.
see
https://github.com/OSGeo/grass/blob/main/mswindows/osgeo4w/package.sh#L154
and
Dear GRASS GIS community,
under
*Future of rgrass - meeting minutes* -
https://github.com/rsbivand/rgrass/issues/34
a discussion about the future of R/GRASS GIS coupling has started.
contribution by the community is welcome. :-)
kind regards
Helmut
osgeo |
lon,lat,depth <==
7719886.85,702082.80,21
7719910.22,702014.88,21
>v.in.ascii -r
>input=/home/rshepard/projects/washington/project/data/bathymetry/coe/CL_34_WSHX_20210720_CS.xyz
> >output=wash_sounding_pts separator=comma
>Scanning input for column types...
>Skipping 452 of 1211 rows falling
>and click the 'GO' button nothing changes; displayed is the entire list
>starting with Aruba.
Without registering/login in www.epsg.org, by typing Washington in the search
field and pressing the go button, I get CRSs: 385, starting with 4267,
26730,..., 32048, etc.
If the epsg.org Website
>Am I
>missing an option?
nothing obvious.
try the same steps as I've done (with adjusted paths) and _post the command and
the command output_ here.
- grass78/grass80 -e -c columbia_2010_e_dtm_35.tif \grassdata\rastertest
- enter into the location just created
- g.region -p
- r.in.gdal
>Then the issue is with 8.0.dev.
just tested with 8.0.dev.; it works here the same as in 7.8
Helmut
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
>Where can I download the 7.8.x source so I can build it here? Following
>links from the web site's download for gneric linux
>https://grass.osgeo.org/grass78/binary/linux/snapshot/> I find a zip file
>and an install shell script, but not the source that allows me to build it
>on this
>>The data file sizes are all in the low 100Ks. I could upload an example to
>>fileconvoy.com if that's helpful.
>
>could you make one of the data files available?
>
>Helmut
for me it works
Driver: GTiff/GeoTIFF
Files: columbia_2010_e_dtm_35.tif
Size is 10745, 15264
Coordinate System is:
>The data file sizes are all in the low 100Ks. I could upload an example to
>fileconvoy.com if that's helpful.
could you make one of the data files available?
Heelmut
___
grass-user mailing list
grass-user@lists.osgeo.org
>The problem occurs using GRASS 7.8 but NOT using 7.6. Likewise, there is
>no problem under Linux, only Windows 10.
>
>It might be related to some Windows environmental variables, but I don't
>have a clue which ones. As the older version works, I wonder if it is
>due to any changes from GRASS 7.6
mail below was sent on Wed Apr 14 2021 => no reaction, no one a minute to test?
if no one of the community has a minute to test winGRASS, then I guess it's
time to propose to the PSC dropping winGRASS at all
kind regards
Helmut
dear GRASS GIS community,
testing of winGRASS is a important piece of puzzle to guarantee a stable and
useable software on the MS windows platform in the future.
For this, we would need the help of the community now. :-)
background is an _error in g.extension while installing i.fusion.hpf in
>Helmut ... thank you for your example however I think there is a misunderstanding of what I am trying to do.
>I am using >GRASS on Linux (on a cluster) and the issue I am experiencing is overlaying two polygon maps (layers in Arc-speak).
>Points and lines on top of ONE set of polygons works fine
>So the solution in the meantime is to:
>
>1. download the zip file from
>https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/latest/
>2. unzip and remove the __pychache__ folder
>3. copy everything to C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\
yes; the contents of following folders
>that's the reason of g.extension failing
>
>downloading the zip-file (see link above) and copying the files into the
>corresponding folders in
>
>C:\Users\YourUserName\AppData\Roaming\GRASS7\addons\
>
>should help.
now tested in this way:
g.region -p -a raster=lsat7_2002_80@PERMANENT
>I know well the issue(s). I don't run a WinBox currently.
as already mentioned in an earlier mail, the culprit is not with the script
itself, though with some leftovers in the pre-compiled zip files used by
g.extension in winGRASS, see
>What surprises me a bit:
>
>file *
>constants.py:Python script, UTF-8 Unicode text executable
>high_pass_filter.py: Python script, ASCII text executable
>i.fusion.hpf.html: HTML document, ASCII text
>i_fusion_hpf_lsat7_hpf_rgb.png: PNG image data,
>I don't see anything immediately wrong. Maybe it is a specific MS
>Windows issue I cannot reproduce here in GNU/Linux.
>
>@Helmut any ideas ?
tested here in the following way in OSGeo4W-winGRASS 7.8.5
(1) changing the working directory via GUI > change working directory
cd
taken from the OSGeo4W ML
[https://lists.osgeo.org/pipermail/osgeo4w-dev/2021-February/004050.html]
Hi there,
I'm happy to announce that the QGIS packages of 3.16.4 (LTR) 'Hannover' and
the
our latest release 3.18.0 'Zürich' are ready on
now testing here with the standalone winGRASS installer 7.8.5
C:\Users\myuser>echo %PATH%
C:\Program Files\GRASS GIS 7.8\lib;C:\Program Files\GRASS GIS
7.8\bin;C:\Users\myuser\AppData\Roaming\GRASS7\addons\bin;{app};C:\Program
Files\GRASS GIS 7.8\extrabin;C:\Program Files\GRASS GIS
>- set PATH=%PATH%;C:\Program Files\R\R-4.0.3\bin has been included
start winGRASS and type into the console:
C:\>ECHO %PATH%
here in OSGeo4W-winGRASS, it's something like:
Moritz Lennert wrote
> [Online version of this announcement:
> https://grass.osgeo.org/news/2021_02_05_new_grass_psc/
> https://grass.osgeo.org/news/2021_02_05_new_grass_psc/;]
>
>
> New GRASS GIS Project Steering Committee
>
> By the end of last year, the GRASS GIS project called for
Jean-Roc Morreale (ml) wrote
> Hi,
>
> I would to know if there is a Windows installer built with OpenMP
> support, the need is to use v.surf.rst parallelization (nprocs) to
> produce a DTM using (without this support, only one cpu core out of
> 48).
>
> Neither osgeo4w's build or wingrass is
See
https://github.com/OSGeo/grass/issues/1218
> from win32file import ReadFile, WriteFile
{ImportError: DLL load failed: The specified procedure could not be >found.
This issue should be solved with winGRASS 7.8.5-2 standalone installer.
-
best regards
Helmut
--
Sent from:
Dear GRASS GIS community,
since the release of GRASS GIS 7.8.5, there have been several complaints
that the standalone winGRASS installer has an startup issue; see [1].
in a shared effort, we've found the reason of the startup issue, fixed it
and published now an updated standalone
dag.lit wrote
> I am working only on one user on the computer (I don't have more usuers).
> Everything was normally working and one day it stops. I alredy tried to
> uninstall and install QGIS but it didn't help :(
It could be a region setting issue.
QGIS shows the used GRASS commands. you
dag.lit wrote
> Hello Everyone
> I have a problem with Grass tools in QGIS (QGIS Desktop 3.16.3 with Grass
> 7.8.5). When I try to use r.clump or any other tool from grass I have a
> message 'Warning: Concurent mapset locking is not supported on Windows'.
> Does anyone know how to fix this
>Now I am getting an error :
>
>--> configure: error: *** Unable to locate lex.
>
>I did some googling and found out that i should download and install FLEX.
>So I did, but still got the same error. Can anyone help on this?
it's part of the msys2 framework
Dear GRASS GIS community,
I'm honored to be nominated for the PSC of this wonderful free and open
source GIS project.
For preparing this statement, I've done some archaeology work to find out
since when I'm part of and contribute to the community. :-)
it seems I'm around there in the mailing
>is it clear now what were the problems?
Yes it's clear now what the issue(s) was:
- the winGRASS-R-bridge looks for R installations in windows standard drive
and folders, i.e. C:\Program; R installations in non standard drives,
e.g. D:\Program... are not reckognized => standard R
>Ok got it, I just had to run R as administrator and download it then. >I
think everything works now. Helmut, I don't know how I can thank >you. I
hope we meet one day so that I can invite you to a coffee or >whatever you
wish
you're welcome. yes you have to install R packages as administrator to
It's an R issue, not a GRASS issue.
Open R in a normal way.
library("MuMIn")
What does it report?
>The packages can also be found in the directory
That's only the temporary download folder, not the R package folder
-
best regards
Helmut
--
Sent from:
Looks good so far! R/RScript is found and work
>Package MuMIn not found
What I have asked already in a previous mail. A needed R package isn't
installed.
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
>the R path is: D:\Programme\R-4.0.3
Is it really D:\ and not C:\ ?
The winGRASS-R-bridge looks for R in C:\.
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing
What is the content of C:\OSGeo4W64\etc\ini and C:\OSGeo4W64\Apps?
What is the path to your R installation?
Not sure what's going on as tested here on several win 10 boxes, and it
works on all of them.
-
best regards
Helmut
--
Sent from:
[a hint to save message size:
- just open a windows command console,
- change to the relevant folder: e.g.
C:\Users\your user>cd C:\OSGeo4W64\etc\ini
C:\OSGeo4W64\etc\ini>
- do dir /b
C:\OSGeo4W64\etc\ini>dir /b
gdal.bat
libgeotiff.bat
libjpeg.bat
liblas.bat
msvcrt.bat
msys.bat
proj.bat
>for a workaround:
we're working to bring the R-winGRASS-bridge back to OSGeo4W
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
>run o-help for a list of available commands
>C:\>R
>Der Befehl "R" ist entweder falsch geschrieben oder
>konnte nicht gefunden werden.
>
>C:\>Rscript
>Der Befehl "Rscript" ist entweder falsch geschrieben oder
>konnte nicht gefunden werden.
>
>(that means it's been typed wrong or couldn't be
>It is still not working and the error message is still the same.
install.packages(c("MuMIn", "lme4", "optparse", "rgrass7")) done?
I got a similar error message when MuMIn wasn't installed.
have you tried in OSGeo4W to switch to an earier rbatch version. then R
should be added automatically
>local R version: 4.03
and tested in
System Info
GRASS Version: 7.8.4
Code revision: d8fbd49af
Build date:
>regarding OSGeo4W-winGRASS, unfortunately there was a change in the rbatch
package recently which >breaks adding R to %PATH%
>
>*start OSGeo4W in advanced mode, type rbatch in the search window on the
top left
>* open the tree of "Command_Utilities" and "Libs" and choose version 149-4
instead of
vailable here.
kind regards
Helmut
Gesendet: Freitag, 11. Dezember 2020 um 10:19 Uhr
Von: "Tom Hackbarth"
An: "Helmut Kudrnovsky"
Betreff: Re: [GRASS-user] r.futures not working
Hi Helmut,
I tried it now on mac as well. I get to the same point.
C
Tom Hackbarth wrote
> Dear grass users,
>
> I am trying to work my way through the r.futures workshop (
> https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel),
> but as soon as I get to the point of using the first r.futures module -
>
do: gdalinfo your-UTM-projected-DEM
>I am trying to use it inside of QGIS 3.12.
GRASS GIS is bundled with QGIS 3.12. start GRASS GIS itself.
- create location based upon your-UTM-projected-DEM
- g.proj -p
- r.external input=your-UTM-projected-DEM output=linked_dem
- g.region -p -a
Eric Eagle wrote
> Hi GRASS users,
>
> Longtime GIS'er but newbie to GRASS. I've never been able to get it to
> work properly on my workstation and have always fallen back on Esri or,
> QGIS built-in functions. Now I am in a situation where I have to get
> GRASS to work because it seems like
SBL wrote
> Hello Hernán,
>
> Best place to look for the source code of the different releases is
> probably here:
> https://github.com/OSGeo/grass/releases
>
> @website-devs: I see that Download source code shows up as an option on
> the landing page (https://grass.osgeo.org/download/), but not
[in a windows console/osgeo4w console you can mark the content with the mouse,
then press return on the keybord, then you
can paste the content as normal text into a mail, no screenshot needed}
>When I run the where from the windows console I get this:
there is a sqlite dll hell caused by
>I am getting this error:
>
>Process ended with non-zero return code 3221225785. See errors in the
(error)
it's a dll mixing/mismatch due to more of the same dll in your %PATH%.
which library errored the message above? (sqlite? gdal?)
Mira Kattwinkel wrote
> Dear list,
>
>
> in GRASS 7.8 v.to.db creates a new column in contrast to previous
> versions where it column had to exist before.
>
> According to the manual "If the /column/ exists, the *--overwrite* flag
> is required to overwrite it". However, this flag does not
>ERRORS WHEN I RUN THE SCRIPT FOR A SECOND TIME :
>
> - FROM WINDOWS : g.region.exe : the procedure entry point
> GEOSMakeValid_r could not be located in the dynamic link library
> C:\Program Files\GRASS GIS 7.8\extrabin\gdal300.dll
this looks like a dll mismatch. more than one GDAL seems to
>there is somewhere an old ticket in trac.
see
https://trac.osgeo.org/grass/ticket/3432
https://trac.osgeo.org/grass/ticket/2919
[...]
My guess - input.d8cut->answer contains extra chars (CR/LF issue?) and thus
changing line to read:
if
>I am trying to establish a workflow to gapfill temporal maps using r.hants
>and r.series.lwr. It is important that the solution also works in windows
>for the teaching.
>
>The issue I am encountering is that both r.hants and r.series.lwr are
>returning 0 values in Windows with a majority of the
Rich Shepard wrote
> On Sun, 31 May 2020, Helmut Kudrnovsky wrote:
>
>> it seems the projection of your data (+proj=merc) doesn't correpond to
>> the
>> Enterprise Office's projections you mentioned (+proj=lcc, +proj=lcc,
>> +proj=longlat)
>
> Helmut,
Rich Shepard wrote
> On Sun, 31 May 2020, Helmut Kudrnovsky wrote:
>
>> is it
>> EPSG:3857 [1] [2]
>> ?
>
> Helmut,
>
> I've no idea. This dataset was downloaded from the Oregon Geospatial
> Enterprise Office (clever name, eh?). The introductory page is h
Rich Shepard wrote
> On Sun, 31 May 2020, Markus Neteler wrote:
>
>> I didn't confirm at all :-) It was just an information or warning.
>
> Markus,
>
> Using ogr2ogr was what Moritz suggested.
>
>> I'd stick to submeter but I don't know what data you are working with
>> nor what their
Maria Cecilia Zalazar wrote
> Hello. In previous (win)grass versions I was able to work with
> r.landscape.evol addon. Now with 7.8.2 wingrass version appears a python
> NameError:
>
>
>
> *r.landscape.evol elev=DEM_21x21@PERMANENT initbdrk=0 smoothing=no
> prefx=levol_test
Maria Cecilia Zalazar wrote
> Hello. In previous (win)grass versions I was able to work with
> r.landscape.evol addon. Now with 7.8.2 wingrass version appears a python
> NameError:
>
>
>
> *r.landscape.evol elev=DEM_21x21@PERMANENT initbdrk=0 smoothing=no
> prefx=levol_test
ivan.marchesini wrote
> Dear Grass friends,
>
> I prepared a simple python3 script that runs correctly using Grass 7.8
> on GNU/Linux.
>
> I put the module in the script folder of /usr/lib/grass78. The parser
> is able to open the interface and the module runs.
>
> Someone asked me to run
Valter Albino wrote
> Hi Helmut,
> Same problems
> See attached pdf file:
> https://drive.google.com/open?id=1k-Ki6uIOPunHlRuCDQTesWKtM4HsKbB2
in the first error messages:
postinstall/qgis-rel-dev.bat
^^
postinstall/qgis-common.bat
^^^
these
>Should post some discussion there?
see
https://lists.osgeo.org/pipermail/osgeo4w-dev/2020-February/003868.html
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
>Don't understand the presence of 1, he is absent in the formula. >Neither
the choice of number 50.
you're right, the ultimative authority is the source code :-)
https://github.com/OSGeo/grass/tree/master/raster/r.flow
someone more familiar with these lines of code will probably have a better
Valter Albino wrote
> Good afternoon
>
> From the function "r.flow" (
> https://grass.osgeo.org/grass78/manuals/r.flow.html), can some expert
> explain me what is the meaning of: "val-th" and the meaning of: "max(1,
> in elevation>
> /50,
>
> /50)."
no expert here on my side, though, from
qgis-common.bat exit code error isn't a GRASS error; this should be reported
in QGIS and OSGeo4W.
OTOH, just tested it here locally on my 64bit OSGeo4W in a win 10 box,
OSGeo4W updating and working with it (GRASS version: 7.8.2 , GRASS version:
7.9.dev, QGIS version 3.10.2-A Coruña) is ok.
eased 2020/01/08
>
> C:\Users\Particular\Desktop>
> "
>
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H / Riscos ambientais / OT
> www.valteralbino.wixsite.com/hydrodynamics
>
>
> Helmut Kudrnovsky
> hellik@
> escr
it needs - twice, I.e.
gdalinfo --version
p.s. you don't need to add screenshots, you can copy/paste from the windows
console by marking the windows console with the mouse and and press return
on the Keyboard and then paste it in your mail.
-
best regards
Helmut
--
Sent from:
>And what does gdalinfo --version on the OSGeo4W shell say?
?
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
try to type into the OSGeo4W shell:
C:\>where gdal300.dll
And what does gdalinfo --version on the OSGeo4W shell say?
-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
Valter Albino wrote
> OK, thanks,
> It opens but i'm not able to enter.
> I will erase all and start to install all over again
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H / Riscos ambientais / OT
> www.valteralbino.wixsite.com/hydrodynamics
>
but didn't give error, so can run GRASS
> GIS with no problems.
> I didn't change the language
>
>
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H / Riscos ambientais / OT
> www.valteralbino.wixsite.com/hydrodynamics
>
>
> Helmut Kudrnovs
Valter Albino wrote
> Regarding the issue, this message is also important (during instalation):
>
> [image: ScreenHunter_31 Feb. 01 20.04.gif]
>
>
> Cumprimentos,
> *Valter Albino -* Geógrafo Físico, M.Sc.
> Modelação H / Riscos ambientais / OT
> www.valteralbino.wixsite.com/hydrodynamics
>
>
>Postinstall script errors
try to re-install, it could be there was an qgis repackaging in OSGeo4W with
an updated gdal library.
>Details: not enough values to unpack (expected 2, got 1)
It's an issue already reported. Did you change the language between english
and yours in the wxgui?
try to
>I'm using Grass 7.4.1 on a WIndows
7.4.1 is really old; not sure that winGRASS addons are still built for 7.4.1
anymore.
from GRASS download website:
GRASS GIS 7.6.1 (old stable)
GRASS GIS 7.8.2 (new stable)
any chance to update to 7.8.2?
-
best regards
Helmut
--
Sent from:
FrankD wrote
> Hello,
>
> I cannot remove vector object and attribute data from the right-clic
> menu on attribute box in the gui (as I was used to do) with grass 7.9
> (on debian buster)
>
> But "v.edit tool=delete map=mymap where="mycolum=myvalue" and db.execute
> "sql=DELETE FROM mymap
>"The program cant start because api-ms-win-crt-runtime-l1-1-0.dll is missing
from your computer.."
which operating system are you using?
during installation by the standalone installer, there is an option to
install Microsoft Visual C/C++ Runtimes.
activate this option, then Microsoft Visual
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
>> --
>
>
nik wrote
> Hi
>> which GRASS version and operating system are you using?
> I also use:
> GRASS Version: 7.8.2
>
> Code revision: 3900fb114
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
>
Helmut Kudrnovsky wrote
> Hi GRASS community,
>
> as stated e.g. in:
>
>
> [GRASS-dev] [release planning] GRASS GIS 7.8.2
> https://lists.osgeo.org/pipermail/grass-dev/2019-December/093846.html
> ##
> ne 8. 12. 2019 v 0:33 odesílatel napsal:
Hi GRASS community,
as stated e.g. in:
[GRASS-dev] [release planning] GRASS GIS 7.8.2
https://lists.osgeo.org/pipermail/grass-dev/2019-December/093846.html
##
ne 8. 12. 2019 v 0:33 odesílatel napsal:
> winGRASS 7.8.2RC2 64bit is available for testing in OSGeo4W 64bit when the
>
> ignore the warning and use GRASS with PROJ6, granted that authority name
(e.g. EPSG) and authority code (e.g. 2932) are known for both CRS's in case
of reprojection
this issue is already by GRASS with PROJ6, see
GRASS version: 7.8.1
Markus Neteler wrote
> Hi,
>
> On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei
> zoltans@.co
> wrote:
>>
>> Hi,
>> I'm using EPSG 2932 and QGIS etc all are OK with it.
>>
>> I have installed everything using OSGeo4W64, so how come Grass does not
>> use the same projections database (as QGis
Markus Neteler wrote
> Hi,
>
> On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei
> zoltans@.co
> wrote:
>>
>> Hi,
>> I'm using EPSG 2932 and QGIS etc all are OK with it.
>>
>> I have installed everything using OSGeo4W64, so how come Grass does not
>> use the same projections database (as QGis
Markus Neteler wrote
> Hi,
>
> On Mon, Dec 2, 2019 at 9:49 AM Zoltan Szecsei
> zoltans@.co
> wrote:
>>
>> Hi,
>> I'm using EPSG 2932 and QGIS etc all are OK with it.
>>
>> I have installed everything using OSGeo4W64, so how come Grass does not
>> use the same projections database (as QGis
Alessandro Sebastiani wrote
> Hello to evenyone,
> i have exactly the same problem that Eric Patton had. This morning
> suddenly
> I got the same error message. I read the conversation and kind understood
> that there is a file in grass78 that should be edited in order to fix the
> error, however
>next daily builds (32/64bit) should be built against GDAL3/PROJ6.
daily build 78:
https://wingrass.fsv.cvut.cz/grass78/x86_64/logs/log-r9c8923eb9-9/package.log
##
[...]
checking for location of External PROJ includes... /c/OSGeo4W64/include
checking for proj.h... yes
Jürgen:
>> not sure how ready Martin's build environment is to switch also to build
>> addons ?!
>
>No clue about that.
Martin [1]:
>> not sure how ready Martin's build environment is to switch also to build
>> addons ?!
>
>next daily builds (32/64bit) should be built against GDAL3/PROJ6.
>
>We
1 - 100 of 931 matches
Mail list logo
