Hi,
in the GRASS community, we're thinking about to phase out winGRASS 32bit
versions in 2020, see [1].
in [2] Upgrade Qt version to latest 5.12.x LTR, I saw following comment:
The current idea is to switch to 5.14 and use the occasion to upgrade
compilers and drop 32bit (according
>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
>> I could do a test compilation with OSGeo4W testing/experimental mode and issue a
>>
>> grass-7.8.1RC1-2.tar.bz2
>>
>> with test in setup.hint.
>
>Thanks.
now locally switched to gdal3/proj6 for compiling winGRASS, see
###
C:\>gdalinfo --version
GDAL 3.0.2, released
?!
regards
Helmut
Gesendet: Dienstag, 05. November 2019 um 18:56 Uhr
Von: "Jürgen E. Fischer"
Betreff: Re: Re: WinGRASS build up (WIP)
Hi Helmut,
On Tue, 05. Nov 2019 at 18:30:18 +0100, Helmut Kudrnovsky wrote:
> >Any idea when GRASS will be updated with the new dependencies?
>Any idea when GRASS will be updated with the new dependencies?
see https://github.com/OSGeo/grass/pull/136#issuecomment-547497328
"Sure it is still GDAL2"
is OSGeo4W still default in gdal2/proj5? is gdal3/proj6 still in OSGeo4W
experimental/testing?
in #136, environment is pointing to
a"
Cc: grass-u...@lists.osgeo.org, qgis-developer@lists.osgeo.org,
osgeo4w-...@lists.osgeo.org, "Helmut Kudrnovsky"
Betreff: Re: WinGRASS build up (WIP)
Hi Martin,
I added "experimental" packages to OSGeo4W (ie. only available if you tick Exp
in the OSGeo4W installer):
- PROJ 6.2
Dear OSGeo community,
the GRASS GIS dev team is working on a python 3-support/transition [1] of the
source code in trunk [2].
winGRASS GIS 7.7svn daily builds with python 3 are already available as
standalone installers [3] or in OSGeo4W [4]; see:
System Info
Dear OSGeo community,
It is time for *GSoC* [1] this year, so this is our starting information to get
involved!
If you are willing to act as a mentor [2], fill in this form:
< https://goo.gl/forms/njL27YLWBVensZ3m1 >
If you want to participate proposing ideas, you just need
to send us
>I'm struggling to work out where the difference lies between the code
>paths. Do you mind sharing the values from the st state struct when
>G_ellipsoid_polygon_area is called for this polygon?
>
>Nyall
delivered by Markus Metz, GRASS dev:
st->AE: 40408299984661.4
st->QA: 0.00446291999342754
Helmut Kudrnovsky wrote
>>[...]
>>Caris LOTS: 14.737 km^2
>>ArcMap: 14.727,446 km^2
>>MapInfo:14.727,352 km^2
>>GeoMedia: 14.726,443 km^2
>>Planimeter: 14.722,522 km^2
>>QGIS 3.2: 14.652,181 km^2
>>QGIS 2.8: 14.652,181 km^2
>>[.
>[...]
>Caris LOTS: 14.737 km^2
>ArcMap: 14.727,446 km^2
>MapInfo:14.727,352 km^2
>GeoMedia: 14.726,443 km^2
>Planimeter: 14.722,522 km^2
>QGIS 3.2: 14.652,181 km^2
>QGIS 2.8: 14.652,181 km^2
>[...]
>My suspicion is that the geodesic algorithm used by QGIS (and apparently
GRASS) is
pcav wrote
> Il 05/02/2018 22:03, Helmut Kudrnovsky ha scritto:
>> and see here for a follow up in the GRASS community:
>>
>> http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
>> http://osgeo-org.1560.x6.nabble.com/Re-G
As a follow-up of the long discussion how to proceed with alg providers in
QGIS, have a look at:
https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3
It should be seen as an starting point to collect ideas, and to sharpen the
technical interface and requirements for such an
Hi Paolo,
pcav wrote
> Il 05/02/2018 22:03, Helmut Kudrnovsky ha scritto:
>> and see here for a follow up in the GRASS community:
>>
>> http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
>> http://osgeo-org.1560.x6.nabbl
of specific parameter class for OTB is not included in this PR.
>
> Thanks for feedback
>
> On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky
> hellik@
> wrote:
>
>> >Otherwise if we don't care and just want to enable others to have QGIS
>> >intgration
>Otherwise if we don't care and just want to enable others to have QGIS
>intgration, they'll have to adopt the plugins. That might work better if
there
>is real interest. But I think they usally prefer their tools to be used in
>their own environment and don't care that much about whether it
Paolo Cavallini wrote
Il 23/02/2015 00:06, Pedro Venâncio ha scritto:
QGIS GRASS plugin (qgis-plugin-grass) still depends on the 6.4.4, so it
will no longer be available for those who upgrade to GRASS 7.0.0.
GRASS 6.4 in Processing has 168 algorithms, GRASS 7 has 153, are a few
less, but
see http://lists.osgeo.org/pipermail/grass-dev/2012-May/058487.html
[GRASS-dev] Re: [Qgis-developer] GRASS regions [grass topology inside
PostGIS2.0]
again FYI from the qgis-dev-ml:
http://lists.osgeo.org/pipermail/qgis-developer/2012-May/019894.html
On Fri, Apr 27, 2012 at 02:36:41PM +0200,
18 matches
Mail list logo
