On lundi 27 avril 2020 19:29:54 CEST Greg Troxel wrote:
> Even Rouault writes:
> > Bas, you can likely just use the plain tarball. We got confirmation from
> > Planet Federal (ex Boundless) that their boundless_rtd theme, from which
> > gdal_rtd is derived, can be licensed under MIT:
> >
On Tue, 28 Apr 2020 at 03:21, Even Rouault wrote:
> One year between feature versions is quite a lot. Perhaps 6 months would be a
> good compromise between having enough time to mature a complex feature and
> faster delivery of it to people not directly consuming master. A consequence
> of
Even Rouault writes:
> Bas, you can likely just use the plain tarball. We got confirmation from
> Planet
> Federal (ex Boundless) that their boundless_rtd theme, from which gdal_rtd is
> derived, can be licensed under MIT:
> https://github.com/planetfederal/sphinx-theme/blob/master/LICENSE
Even Rouault writes:
> I was wondering if we should not reconsider the length of our release cycles.
Comments from the packaging peanut gallery.
> One year between feature versions is quite a lot. Perhaps 6 months would be a
> good
> compromise between having enough time to mature a complex
On 2020-04-27 3:57 p.m., Even Rouault wrote:
>
> Note for packagers: the /doc/build/ output is ~112 MB (GDAL 2.4.4
> /bin/html output was 1.6 MB)
Actually, "only" 62 MB if you consider only /doc/build/html
True! To clarify: my post of size was not a complaint but was for
packagers
Alright, since jni_md.h was referenced from jni.h, I tried copying jni_md.h
into the same directory as jni.h, which seems to have helped. Or at least
got to the next error:
gnm_wrap.cpp:471:21: warning: unused function 'SWIG_JavaArrayOutDouble'
[-Wunused-function]
static jdoubleArray
Andrew:
That's what I thought. I do have the JDK (OpenJDK 11.0.2).
Ah, found it. I think I may have both a JRE and JVM confusing things
(confusing me, at least). Both appear to be the same version, at least.
I've changed my JAVA_HOME in java.opt to reflect where my JDK is
installed. Also
On Mon, Apr 27, 2020 at 10:20 AM Even Rouault
wrote:
>
>
> One year between feature versions is quite a lot. Perhaps 6 months would be a
> good compromise between having enough time to mature a complex feature and
> faster delivery of it to people not directly consuming master. A consequence
>
>
> Note for packagers: the /doc/build/ output is ~112 MB
(GDAL 2.4.4
> /bin/html output was 1.6 MB)
Actually, "only" 62 MB if you consider only /doc/build/html
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev
RC1 builds ok on Windows in VC2017, but, there were errors during the
building of the docs. I've created a pull request that fixes these
errors on Windows (running MS4W's Python 3.7.5) :
https://github.com/OSGeo/gdal/pull/2446
Note for packagers: the /doc/build/ output is ~112 MB (GDAL
On Mon, 27 Apr 2020, David Rush wrote:
Ivan:
Thanks! That worked. On to the next error (with make in gdal/swig/java)
...
gdalconst_wrap.c:154:10: fatal error: 'jni.h' file not found
#include
^~~
1 error generated.
make: *** [gdalconst_wrap.lo] Error 1
Where *should* jni.h come
Hi,
I was wondering if we should not reconsider the length of our release cycles.
One year between feature versions is quite a lot. Perhaps 6 months would be a
good
compromise between having enough time to mature a complex feature and faster
delivery of
it to people not directly consuming
First, I apologize if I am using this mailing list improperly. This is my
first time here.
I am trying to iterate over some shapefiles (109 shapefiles to be exact)
and append them to a *single* feature class in an output geodatabase, but
the resulting output geodatabase is one with 100 feature
On lundi 27 avril 2020 16:18:39 CEST Even Rouault wrote:
> Bas,
>
> > The embedded RTD theme (especially its fonts) and logo images are a
> > PITA. I'm tempted to just drop the libgdal-doc package are exclude the
> > entire doc/ subdirectory when repacking the tarball to make license &
> >
Ivan:
Thanks! That worked. On to the next error (with make in gdal/swig/java)
...
gdalconst_wrap.c:154:10: fatal error: 'jni.h' file not found
#include
^~~
1 error generated.
make: *** [gdalconst_wrap.lo] Error 1
Where *should* jni.h come from? I can't find it anywhere in my
Bas,
> The embedded RTD theme (especially its fonts) and logo images are a
> PITA. I'm tempted to just drop the libgdal-doc package are exclude the
> entire doc/ subdirectory when repacking the tarball to make license &
> copyright review less of a pain.
As using plain sphinx_rtd_theme gives
Hi David,
I am in the process of refreshing my GDAL building process in a Mac, so I might
be able to help with that question.
You need to install SWIG in your machine. And one way to do that is using the
HomeBrewer [brew.sh] another is Anaconda [anaconda.com]
$ brew install swig
or
$ conda
Thank you, Evan. That got me to the next error:
/bin/sh: swig: command not found
make: *** [gdal_wrap.cpp] Error 127
Where/how does the "swig" script or binary come from?
David
On Mon, Apr 27, 2020 at 7:11 AM Even Rouault
wrote:
> On lundi 27 avril 2020 07:03:28 CEST David Rush wrote:
>
> >
On 4/27/20 3:37 PM, Even Rouault wrote:
> Packagers: note that the documentation has been revamped to use Sphinx. If
> you want to
> build html and man pages, in addition to Doxygen, on top of my head, you need
> at least the
> following Python packages: sphinx, breathe, sphinx_rtd_theme (the
Hi,
I have prepared a GDAL/OGR 3.1.0 release candidate.
Pick up an archive among the following ones (by ascending size):
https://download.osgeo.org/gdal/3.1.0/gdal-3.1.0rc1.tar.xz
https://download.osgeo.org/gdal/3.1.0/gdal-3.1.0rc1.tar.gz
On lundi 27 avril 2020 07:03:28 CEST David Rush wrote:
> All:
>
> I think I finally found some instructions for building the Java stuff I
> need:
>
> https://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix
>
> That includes some notes for MacOS. Yay.
>
> I've set up my java.opt
All:
I think I finally found some instructions for building the Java stuff I
need:
https://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix
That includes some notes for MacOS. Yay.
I've set up my java.opt per this link referenced in the above link:
I'm importing data from multiple .gml files using a .gfs template.
I provide a MyName in the .gfs that corresponds to the
MyName
Using a connection to Oracle I am then populating a matching table called
'MyName' - this works fine. My question is how can I change the path to a
different table
Hi Craig,
Maybe your GDAL build uses libPoppler, which references the Freetype
lib; you could disable that from your GDAL build and retry.
-jeff
--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/
On 2020-04-25 4:40 p.m., Craig Delancy wrote:
(Windows
24 matches
Mail list logo
