Hi,
(sorry to top post, just subscribed to the list)
A few notes w.r.t this thread:
- there's no universally "good" nodata value for GDAL. In the GDAL API, it is
a double value, but the way it is stored is highly dependant of formats. Might
be binary, or text (like in GeoTIFF with the GDAL_NOD
Forwarding to a few lists that might be interested in the below proposal as
metacrs is perhaps not widely followed. But please keep the discussion to
metacrs to avoid cross postings.
-- Forwarded Message --
Subject: [MetaCRS] Common SQLite-based dictionaries
Date: Sunday 02 Au
> -L/misc/fluo6/andre/projekte/custom_gfz_python/tmp/grass/grass-7.0.2/dist.x
> 86_64-unknown-linux-gnu/lib
> -L/misc/fluo6/andre/projekte/custom_gfz_python/tmp/grass/grass-7.0.2/dist.
> x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic
> -Wl,-rpath-link,/misc/fluo6/andre/projekte/custom_gfz_python
Le lundi 25 avril 2016 22:02:20, Paul Kelly a écrit :
> Hi Markus, Even,
>
> On 04/24/2016 10:29 PM, Markus Neteler wrote:
> > Hi Paul,
> >
> > you are probably the person with most insights into lib/proj/convert.c.
> >
> > I try to debug why the North Carolina Location cannot be generated
> >
Vincent,
I'm CC'ing the grass-dev list as gdaldem shares the same formula with the
GRASS r.shaded.relief utility and I also think they are affected (I've only
compared the code, not tested r.shaded.relief, so I could be wrong of course)
I think your analysis is right. To check, I've created an
Hamish,
I've taken some time to experiment a bit with GRASS and GRASS behaviour is
correct of course, so sorry for the noise.
I've finally identified why gdaldem (and initially Matt's hillshade utility)
got it wrong. GRASS r.mapcalc atan(x,y) function has its parameters reversed
in comparison
Le mardi 18 octobre 2016 16:42:25, Markus Neteler a écrit :
> On Tue, Oct 18, 2016 at 2:54 PM, Luca Delucchi wrote:
> > Hi devs,
> >
> > do you know if a geocoding module for GRASS already exists ?
>
> Hi Luca,
>
> a tool using an address database such as OSM nominatim?
> Not that I am aware of
Le mardi 25 octobre 2016 12:02:01, Vincent Bain a écrit :
> Hi Maciek,
>
> thanks for your suggestion. In fact, the script runs without error or
> warning but it does not change anything :
>
> gdalinfo Rasterlite:my_db.sqlite,table=my_raster
> [...]
> AUTHORITY["EPSG",
.osgeo.org/geotiff/
changeset/2747 and
https://trac.osgeo.org/gdal/changeset/37080
Even
(*) From libgeotiff ChangeLog:
2017-01-10 Even Rouault
* csv/datum_shift_pref.csv: add overrides for PCS 2065
(S-JTSK (Ferro) / Krovak)
Fixes https://trac.osgeo.org/gdal/ticket/4762 and
> You can use v.in.ogr directly for OSM PBF files (
> http://gdal.org/drv_osm.html).
>
> BTW, with GDAL 2.2.1, using OGR_INTERLEAVED_READING=YES does not
work for
> me (empty vector).
Caution: you cannot just specify OGR_INTERLEAVED_READING=YES and
loop over layers as usual. See the "Interleave
On jeudi 24 août 2017 15:34:11 CEST Markus Metz wrote:
> On Thu, Aug 24, 2017 at 11:15 AM, Even Rouault
>
> wrote:
> > > You can use v.in.ogr directly for OSM PBF files (
> > >
> > > http://gdal.org/drv_osm.html).
> > >
> > >
> >
On dimanche 15 octobre 2017 21:28:24 CEST Markus Neteler wrote:
> On Sun, Oct 15, 2017 at 7:47 PM, Markus Metz
>
> wrote:
> > What do you mean with "a more direct GRASS GIS integration" regarding
> > cloud
> > storage and/or Cloud Optimized GeoTIFF?
>
> Well, I tought of r.external and r.externa
On mercredi 18 octobre 2017 12:28:36 CEST Jachym Cepicky wrote:
> Hi,
>
> I would like to submit following commit to GRASS GIS - master
>
> Index: vector/v.out.ogr/args.c
> ===
> --- vector/v.out.ogr/args.c (revision 71566)
> +++ vec
On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote:
> On Thu, Oct 26, 2017 at 9:25 AM, Markus Metz
>
> wrote:
> > On Wed, Oct 25, 2017 at 10:40 PM, Markus Neteler wrote:
> >> Hi devs,
> >>
> >> while playing with the SRTM 30m world I see that there is a difference
> >> of 66GB in size
On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote:
> On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky wrote:
> > it seems there is an issue with winGRASS:
> >
> > 32 bit:
> >
> > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log
> >
> > GRASS GIS 7.3.svn r71641 comp
> If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ),
My hypothesis might be wrong, but if it is true, then it *wrongly* evaluates to
GDALSetCacheMax64 ( int ) when currently called by GRASS. If you define
HAVE_LONG_LONG before including cpl_port.h or any other GDAL include files,
On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote:
> Stupid question: such a #define has only effect on compile time. If
GDAL
> has been compiled without HAVE_LONG_LONG being defined, and then
we define
> HAVE_LONG_LONG when compiling against GDAL, is this creating a big
mess?
With MS
> -->
> Index: port/cpl_port.h
> ===
> --- port/cpl_port.h(revision 40701)
> +++ port/cpl_port.h(working copy)
> @@ -219,7 +219,7 @@
> /* 64bit support */
> /* --
On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote:
> On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault
>
> wrote:
> > > -->
> > >
> > > Index: port/cpl_port.h
> > >
> > > ===
Hi,
I've updated to the EPSG v9.2 database.
The relevant tickets/commits are:
* libgeotiff: https://trac.osgeo.org/geotiff/changeset/2802
* GDAL: https://trac.osgeo.org/gdal/ticket/7125
* proj.4: https://github.com/OSGeo/proj.4/issues/711
* postgis: https://trac.osgeo.org/postgis/ticket/3944 (pat
On lundi 5 février 2018 10:04:25 CET Anna Petrášová wrote:
> Hi,
>
> I ran into a weird problem with KML with 3D line, v.import failed when
> reprojecting it:
>
> WARNING: pj_transform() failed: latitude or longitude exceeded limits
>
> This happened with GRASS 7.4.0 64bit (GDAL 2.2.3) on Window
On mercredi 23 mai 2018 09:21:21 CEST Markus Neteler wrote:
> Hi devs,
>
> perhaps it would be worthwhile to submit GRASS GIS to Google's
> OSS-FUZZ [1] like GDAL (of course we don't know it we would be
> accepted).
>
> To get it done, we may learn from GDAL:
> * related GDAL ticket: https://trac
Note that OSS-Fuzz only supports C/C++ libs. Not Python
Fuzzed binaries must statically link all their dependencies:
https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md
Even
> Hi,
>
> here an idea for https://trac.osgeo.org/grass/wiki/GSoC/2019
>
> Since I am not the right
On samedi 23 février 2019 15:59:28 CET Markus Neteler wrote:
> Hi devs,
>
> there is some discussion about packages that need to be patched to use
> proj_api.h or proj.h which will no longer be available in recent PROJ.
>
> Is there anything to do in GRASS GIS (trunk)?
From what I can see in
ht
On lundi 25 février 2019 15:10:10 CET Markus Metz wrote:
> Hi all,
>
> GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL
> 2.5
>
> The plain text file "share/proj/epsg" no longer exists. This file is
> currently required by the GUI location wizard to retrieve a list of kno
On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote:
> > Since rgdal::make_EPSG() is facing the same problems of listing tabulated
> > EPSG fields as g.proj -l, I was very happy to see Markus' code in
> > g.proj/main.c mentioned in this thre
On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 12:41 PM Even Rouault
>
> wrote:
> > On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
> > > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand
>
> wrote:
> > > > S
On vendredi 8 mars 2019 18:22:42 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 5:56 PM Even Rouault
>
> wrote:
> > On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:
> > > My question is, what should GRASS do with a SRS without proj string? The
> > >
> I'm assuming there is no error handler to hook onto, to divert errors to
> R's error handler.
Actually you can install your own error handler with proj_log_func()
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gras
On mercredi 20 mars 2019 13:26:40 CET Markus Neteler wrote:
> Hi devs,
>
> See below for cool new stuff.
> I guess we also want such a Backport bot...
You also need tweaking the travis.yml/appveyor.yml to avoid useless builds to
be triggered, to save some carbon emissions and time.
The bot creat
On lundi 22 avril 2019 17:27:06 CEST Markus Neteler wrote:
> On Thu, Apr 18, 2019 at 10:22 PM Markus Neteler wrote:
> > PSC members,
> >
> > RFC6 [1] about the migration from OSGeo SVN and tickets on trac to
> > github under the OSGeo organization
Hi,
Congrats for the decision t move to git !
On mercredi 22 mai 2019 21:30:58 CEST Markus Metz wrote:
> Hi git gurus,
>
> when I modify my local copy and do git commit + git push, I sometimes get
> an error:
> "failed to push some refs"
> and a hint:
> "Updates were rejected because the remote contains work that you do not
> have locally. Th
On dimanche 26 mai 2019 16:31:04 CEST Markus Neteler wrote:
> Hi,
>
> we activated the backport bot also for GRASS GIS in the Gihub OSGeo
> organization.
> As far as I understood from Even's email
>
> https://lists.osgeo.org/pipermail/gdal-dev/2019-March/049928.html
>
> the system is fairly stra
>
> Patches in svn tickets sometimes got old too. When no one cares (or has
> time), then it doesn't matter if we use svn or github. I would say PRs on
> github are easier to find and track than what we used before,
> although seem
> harder to test, but that's what we signed up for.
Given a pul
On mercredi 25 septembre 2019 22:47:21 CEST Markus Metz wrote:
> Several different methods might be available to reproject from one CRS to
> another CRS. PROJ6 can select the most appropriate method if a bounding box
> is provided. This means that the selected method depends on the bounding
> box a
> The (my) idea is that proj suggests reasonable paths to store grids, search
> paths should be available in PJ_INFO. Otherwise applications may decide for
> a directory specific to that application, not generally valid for proj used
> by different applications. Applications can then check the exis
On jeudi 7 novembre 2019 19:50:33 CET Markus Metz wrote:
> On Thu, Nov 7, 2019 at 6:47 PM Martin Landa wrote:
> > Hi,
> >
> > čt 7. 11. 2019 v 15:17 odesílatel Markus Metz
> >
> > napsal:
> > > PROJ 6 support is not yet finished in GRASS. Currently it sort of works
>
> in master and relbr78, b
> Indeed messy. Look at the WKT2 representation of projinfo -o WKT2_2018
> EPSG:3857: projection on the ellipsoid "WGS 84", not on a sphere.
as does the authority says:
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857
> I don't understand "lying on the ellipsoid definition
On mardi 12 novembre 2019 17:43:56 CET Markus Neteler wrote:
> On Tue, Nov 12, 2019 at 5:08 PM Markus Metz
>
> wrote:
> > Regarding GDAL 3 support, we still need to add the new GDAL library
> > versions to lib/raster/gdal.c for r.external to work.
> Which .so and .dll names need to be registered
> > Regarding PROJ, some critical changes are coming for the PROJ 7.2.0
> > release on 1st November (a lot has to do with network/SSL/CA bundle,
> > which is important these days), and then another release 7.2.1 is set
> > for 1st January, which could work nicely with your planned early 2021
> > ti
It might be possible that your GDAL build is linking against libgeotiff
and/or libspatialite built against libproj.so.15
Le 12/08/2021 à 19:00, Thomas Adams a écrit :
Hi Māris,
Thank you. I did earlier find that I did have two proj libraries, so I
removed libproj.so.15. I also ran sudo ldconf
Hi,
(writing to both GDAL and GRASS lists)
Working on the transition to CMake as the GDAL build system, the
particular status of the GRASS driver in GDAL raised my attention.
(The following is based on my understanding. It has been ages since I
didn't try this...)
This driver is a bit odd
number of projects use the GDAL
GRASS driver. Feedback from any affected projects would be helpful.
Markus M
On Thu, Nov 18, 2021 at 7:13 PM Even Rouault
wrote:
Hi,
(writing to both GDAL and GRASS lists)
Working on the transition to CMake as the GDAL build system, the
particular
this week.
Even
Le 28/04/2022 à 22:31, Markus Neteler a écrit :
Hi Even,
(back to your wish)
On Thu, Nov 18, 2021 at 7:12 PM Even Rouault wrote:
Hi,
(writing to both GDAL and GRASS lists)
Working on the transition to CMake as the GDAL build system, the
particular status of the GRASS drive
Hi,
just wanted to point that if you are interested in a "framework" for
submit jobs to a thread pool, I can point to
https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/thread.h
https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/thread.c
which is a port in C I'v
For the backport bot
(https://github.com/OSGeo/gdal/blob/master/.github/workflows/backport.yml)
to work, I believe the label must be exactly "backport {git_branch_name}"
Le 22/11/2022 à 18:47, Nicklas Larsson via grass-dev a écrit :
I think this is a splendid idea!
Would be good to keep the l
Le 22/11/2022 à 19:51, Nicklas Larsson a écrit :
Looks like a clever little bot. In case that is the way the community choose to
go then the label will have to be “backport releasebranch_8_2”, which is very
long…
I also wonder how useful it would be at the moment for GRASS, e.g. wide ranging
Markus,
maybe try with the command line:
"git push --delete origin 7.8.8RC3"
Even
Le 16/12/2022 à 22:46, Markus Neteler a écrit :
Hi devs,
Seems we (I) am not releasing not often enough.
Unfortunately I created this tag on "main" rather than
"releasebranch_7_8".
:-((
Any chance to delete
I'd suggest you use pre-commit so that clang-format is automatically run
on git commit operations like we have done with GDAL. Then it is a
no-brainer to do changes.
You need to add a .pre-commit-config.yaml at the root of the repository
(only the part referencing clang-format at
https://gith
FYI I see this thread referencing the GDAL github team organization. As
far as I know, nobody has "designed" it with deep thoughts. It has the
current structure most likely as an accident of history... If I were to
design it, I would keep it simple and stupid. With git workflows, the
concept of
Hi,
this is quite typical of a program linking to 2 different version of
libproj at the same time, often when mixing repositories, where some
components of one haven't been rebuilt against updated components of the
other one
Check the output of "ldd /path/to/g.proj"
Even
Le 24/04/2024 à 18
: [PROJ] PROJ was not updated in Zenodo
Date : Tue, 4 Jun 2024 16:25:42 +0200
De :Even Rouault via PROJ
Répondre à :Even Rouault
Pour : Peter Löwe , Javier Jimenez Shaw
Copie à : proj
Hi,
I've posted the following message through Zenodo support form at
https://zenod
Le 04/06/2024 à 17:38, Vaclav Petras a écrit :
Thanks Even. This is not clear to me. I see OSGeo/grass enabled. I
can't manage that because it says that it is managed by another user
of my org. Screenshot attached.
yeah, just after I posted my message, I refreshed the page and GRASS
magicall
53 matches
Mail list logo