> And at this stage in the life of the LTR I just
> don't see the risks of regressions outweighing anything but
> crash/corruption fixes.
"Stage" is the keyword here. Number of software vendors have generally several
stages during the lifetime of the product they support, generally a first one
w
On vendredi 18 octobre 2019 12:28:12 CEST Alessandro Pasotti wrote:
> Hi,
>
> I was thinking about how to better implement this feature for QGIS server
> (but it does not need to be restricted to the server).
>
> The WFS3 specs covers pretty much all use cases: you can have features with
> a sing
On mercredi 30 octobre 2019 12:31:45 CET Bo Victor Thomsen wrote:
> Hi list -
>
> During a university lecture about QGIS and licensing (GPL) I got a
> question about QGIS projects.
>
> Can a project be copyrighted or licensed differently from QGIS ? We are
> not talking about plugins - they are a
> > A very small nibble: What about python code embedded in the project ?
>
> That is a good question where I don't know the answer. It might be
> subject to the GPL license - but not sure. I would be interested to hear
> other people's opinion on this particular case.
Huh, that becomes involved.
On vendredi 1 novembre 2019 11:49:11 CET Rahkonen Jukka (MML) wrote:
> Hi,
>
> It seems to me that if I edit the settings of the OGC API Features
> connection the changes do not have any effect but I must delete and
> re-create the connection instead.
If you modify it from the Browser right ? I c
On jeudi 7 novembre 2019 17:40:08 CET Alessandro Pasotti wrote:
> Hi,
>
> I'm running into an issue with OAPIF and blob/binary fields, the
> QgsJsonExporter does not currently handle that kind of field and just
> convert them to string (whatever that means).
>
> This is clearly wrong in case the
> Are you talking about the schema ?
yes,"contentEncoding": "base64" would be for the JSON Schema
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https:/
> If I'm not mistaken, we are still in the design phase for the schema
In OAPIF ? Well, not really. rel=describedBy is a possibility already offered
by the core.
Used by a few implementations:
- JSON schema for:
http://databio.spacebel.be/eo-features/collections/datasets
- XML schema for
> Thanks for the links, I suppose that the quickest way for QGIS Server will
> be to forward to WFS XML schema like geoserver does.
>
> JSON schema is waaay harder to implement from scratches.
Yes, it is non trivial. That said for a flat structure, you probably might
have most of it more or les
> So this means it must be a windows \
> OSGeo4W thing, no?
Yes, Windows thing. Already reported at
https://github.com/OSGeo/gdal/issues/1428
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
On vendredi 22 novembre 2019 08:43:23 CET Jürgen E. Fischer wrote:
> Hi Nyall,
>
> On Fri, 22. Nov 2019 at 17:17:07 +1000, Nyall Dawson wrote:
> > But I'd love a couple of days to keep digging, if that's at all
> > possible
> Black friday? Ok.
Trying to reproduce on my side in isolated way w
> QGIS LTR in Windows has also switched from proj 5.x and gdal 2.x to
> proj 6.x and gdal 3.x which has resulted in some new bugs.
I see 2 different situations:
- 3.10 was intended to work with GDAL 3 & PROJ 6 (work started with 3.8 if I
remember). OSGeo4W received a late upgrade to them because
On samedi 23 novembre 2019 12:23:12 CET Paolo Cavallini wrote:
> Hi Tim,
>
> Il 23/11/19 11:22, Tim Sutton ha scritto:
> > For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
> > standalone installers but then we have an LTR that is not getting bug
> > fixes. As I read Jürgen’
On samedi 23 novembre 2019 17:44:15 CET Jürgen E. Fischer wrote:
> Hi Even,
>
> On Sat, 23. Nov 2019 at 17:36:52 +0100, Even Rouault wrote:
> > But for the future, I can imagine we could have:
> > qgis3_10 depending on gdal3 (or possibly even gda
> I'd also like to extend Tim's thanks here and publicly state my
> appreciation to Jürgen for an extremely difficult, thankless job which
> you've done SO well, SO consistently and for SO long.
I "third" this appreciation !
> Regarding 3.4: One option we should explore is just freezing the
> Win
> Ok, thanks to a **marathon** debugging effort from Even, we have a fix
> inbound -- https://github.com/OSGeo/PROJ/pull/1746
Now merged in PROJ master.
Cherry-picked in PROJ 6.2 branch per
https://github.com/OSGeo/PROJ/commit/bce4b158ab5f7d146de8e8fc98df4612dc8c2c9e
>
> Looks like we'll need to
di 25 novembre 2019, 13:46:37 CET
From: Even Rouault
To: p...@lists.osgeo.org
Hi,
As announced last week, you'll find a RFC describing two new capabilities,
remote access to grids and a GeoTIFF-based format for grids, in
https://github.com/OSGeo/PROJ/pull/1747
You can get an (almost correct) pre
> I think the issues are deeper then the crashes/projection failures
> fixed by the GDAL/proj cherry-picked commits.
Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it
uses the old pj_transform() API with doesn't trigger that code path at all.
But it *is* affected by expo
Jürgen,
> I've been "playing" with appveyor (doesn't work - hits the 1h timeout),
> azure-pipelines (which kind of works) and github workflows (which does not
> yet work) to implement the Windows CI many people are keen on. Progress is
> very slow - every single step takes ages… A successful ru
On jeudi 28 novembre 2019 20:19:10 CET Shane Carey wrote:
> Hi,
>
> I'm doing some processing with Pyqgis and after processing, the file
> remains locked and eventually I get:
> ERROR: Too many connections: max 64
All I can say is that this error messages comes from Spatialite that can only
hand
William,
> I must then build and include both PROJ 6 and PROJ.4 in the QGIS package.
Caution...
> There is no option to build SAGA without PROJ, but I could hack the
> makefiles to skip it. Or I could build it with the old PROJ and just not
> include those modules in the QGIS package.
From htt
> @Jürgen Fischer: is there a change that you could "cherry-pick" the
> corresponding pull requests and patch them into the existing PROJ release
> used by osgeo4w for the upcoming pointrelease?
Just wants to note that a PROJ 6.3.0 release, with the
accompanying proj-datumgrid- backages, is sc
> > Great work!!
+1 !
>
> Thanks. GDAL 2 and prøj 5 are now separate packages - prøj 5 being built
> statically and shipping with it's own files, although it's actually using
> the files from prøj 6 at runtime (as that's where also the grids are) - but
> those are identical except for ITRF2005
On mardi 10 décembre 2019 20:36:22 CET Stefan Keller wrote:
> Hi,
>
> As I already talked about elsewhere I'm implementing a "minimal OGC-API
> Features Server".
>
> Now I'd like to test this service with QGIS as client. And I also
> tested QGIS with the "kataster" service [1] the mentioned in th
> Finally, did I understood you correctly regarding the QGIS client options:
>
> At 10. Dec. 2019 20:48 Even Rouault wrote:
> > > Question 1: Any idea what QGIS makes it's OGC-API-Features reader to
> > > add limit=10?
> >
> > Because that's th
> Any news from GDAL team?
I was floating the idea of having a GDAL 3.0.3 release somewhere in January,
but that's dependent on a volunteer taking on that. Someone was willing to
give his first try at releasing GDAL, but I'm not sure if he's still
available, and if that can be done before Jan 1
On jeudi 19 décembre 2019 13:09:38 CET Even Rouault wrote:
> > Any news from GDAL team?
>
> I was floating the idea of having a GDAL 3.0.3 release somewhere in January,
> but that's dependent on a volunteer taking on that. Someone was willing to
> give his first try at rele
GDAL 3.0.3 has just been released.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscri
Regarding
> prohibit the use of QGIS to the fossil-fuels industry.
and
> ...may I suggest to add GLOBAL PEACE & WAR issues to this QGIS
> discussion on environmental questions ?
That's not a good idea IHMO. Don't mix licensing & ethics. Free software
licenses explicitly don't discriminate agai
Hi,
Just read this:
https://www.phoronix.com/scan.php?page=news_item&px=Qt-Going-More-Commercial
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: ht
On lundi 27 janvier 2020 17:35:22 CET Paolo Cavallini wrote:
> Thanks Even. As I read it, this essentially means we are more or less
> forced to use the latest version, not the LTS (or to stick to an older
> one). This could mean more bugs.
QGIS sources aren't bound to a particular QT version. Cur
Nadia,
Thanks for investigating QGIS server security. However, I would expect a
vulnerability report to go a bit beyond than just using a generic security
scanner that can have false positives, especially here as all components
involved are open source so it is possible to look at the code, instru
> For example, is it possible to compromise QGIS Desktop via a
> opening/connecting to a compromised shapefile/Geopackage/web-service/CSV
> etc etc? I have no idea, but it'd definitely be a useful thing to
> investigate.
For file formats, part of the security/insecurity would fall on GDAL (and
un
On vendredi 20 mars 2020 19:26:03 CET Jeremy Palmer wrote:
> > On Fri, 20. Mar 2020 at 08:12:35 +0100, Andreas Neumann wrote:
> > > Isn't that potentially a quite large amount of data? Most QGIS users
> >
> > that I
> >
> > > know mainly work in one country or region and only need one gridshift
>
On jeudi 9 avril 2020 21:30:02 CEST Martin Dobias wrote:
> Hi Vincent
>
> On Thu, Apr 9, 2020, 18:32 Vincent Picavet (ml)
>
> wrote:
> > Hi all, PSC,
> >
> > Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday
> > about a
> > really concerning situation regarding the OpenSour
Richard,
>
> Probably not important, but I get the following output when running my
> build:
>
> $ ninja install
> [0/1] Re-running CMake...
> -- QGIS version: 3.13.0 Master (31300)
> ...
> -- Found Proj: /usr/lib/x86_64-linux-gnu/libproj.so version 7 (7.0.0)
> ...
> -- Using PROJ 6 srs database
> * The fid requirement
>
>I sometimes want my features to be identified by uuids or others.
> They also tend to accumulate if derived datasets are created (through
> processing etc). If I need some pseudo stable primary key there is a
> rowid builtin into sqlite, we don't need a second one.
>
> > *The requirement for a single geometry column per table
> >
> >I just don't see a good reason to forbid that
> >
> >Possible mitigation: a) alter the standard. b) ignore the standard
> >
> > and patch the ogr implementation.
>
> I don't think the Geopackage OGC SWG would be keen
On samedi 9 mai 2020 08:54:06 CEST Matthias Kuhn wrote:
> Hi Richard,
>
> On 5/8/20 5:24 PM, Richard Duivenvoorde wrote:
> > About Tobias' flatgeobuf: instead of a shp/gpkg file alternative, would
> > this not be a very good candidate to store our intermediate processing
> > steps in (which was sh
Andreas,
> I am struggling with libspatialite. What libspatialite versions are you
> guys using? I am trying to compile libspatialite-4.3.0a, but it
> complains about not finding "proj_api.h" (although this file is
> available at /usr/local/include). I tried both with proj-6.3.2 and
> proj-7.0.1.
> No transform is available between EPSG:3763 - ETRS89 / Portugal TM06 and
> Unknown CRS: GEOGCRS["unknown",DATUM["unknown",ELLIPSOID["GRS 1….
> proj_create_operations: cannot build geodeticCRS 4326: SQLite error on
> SELECT name, ellipsoid_auth_name, ellipsoid_code, prime_meridian_auth_name,
> pri
On mardi 2 juin 2020 15:58:38 CEST Olivier Dalang wrote:
> Hi !
>
> About WAL related issues :
>
> I just tried to reproduce the original issue that lead to using WAL on
> local files (https://github.com/qgis/QGIS/issues/23283) but could not
> reproduce it (recent master, Windows 10). Does the is
On vendredi 5 juin 2020 11:13:09 CEST Thomas Schüttenberg wrote:
> Hi all!
>
> Because I better should not roll out QGIS with the afore mentioned premanent
> ballpark-warning in place, I investigatetd further and stumbled across an
> "allowFallback"-setting:
>
> By placing a default datum transfo
> Yes, I already thought of that, too. Can the extend be derrived
from a
> gsb-file? Otherwise I have to estimate.
Command line with "gdalinfo Minden.gsb" and look at Corner
Coordinates
Or just open the gsb file in QGIS as a raster and look at the
properties.
Even
--
Spatialys - Geospatial p
On vendredi 5 juin 2020 21:44:22 CEST Denis Rouzaud wrote:
> Hi all,
>
> After digging a bit more, it seems that the cache invalidation is not
> working on the WFS layer.
>
> If I call emitDataChanged on any of its layers dependencies, or call
> emitDataChanged on this layer or even call triggerR
> After some Q&A, it appeared that he had opened the shapefile
from a ZIP...
Not addressing your general concern, but upgrading to GDAL 3.1.0
will fix that particular point: update of .shp.zip is now supported.
(performance will probably not be rocketting if the .shp.zip is too
big)
Even
--
Matthias,
thanks for the analysis. There are however a few unexpected results.
1) I'd expect gpkg pyramid_JPEG and COG_JPEG to have very similar sizes, even
COG_JPEG
being potentially slightly smaller.
And I'd also expect COG_JPEG to be slighly faster (but with less confidence
that my
stateme
On mardi 23 juin 2020 15:34:58 CEST Raymond Nijssen wrote:
> My python plugin should create a table without geometry in a gpkg to
> store some additional (meta) info about the layers. I could use python
> bindings for sqlite of course, but the plugin users might not have that
> installed.
>
> What
On mercredi 24 juin 2020 11:53:37 CEST Peter Petrik wrote:
> Hi,
>
> As building on iOS already works (
> https://github.com/lutraconsulting/input-sdk/tree/master/ios), I imagine it
> would be possible to run another architecture build for MacOS with a
> similar approach. It is in Apple's interes
Julien,
> I was looking to create an empty GPKG layer and try the solution Even
> provide, but it creates an invalid file.
>
> fields=QgsFields()
> fields.append(QgsField("note", QVariant.Double))
> QgsVectorFileWriter.create("/tmp/test.gpkg", fields,
> QgsWkbTypes.MultiLineString, QgsProject.ins
On mardi 30 juin 2020 14:20:50 CEST Rizky Maulana Nugraha wrote:
> Hi Olivier,
>
> Maybe this helps. You can run build in debug mode in travis. I usually just
> make a private repo with a minimum script to run that said tests. Then
you
> can ssh into the build.
Slightly more convenient is to use
Hi Sandro,
I hope this emails finds you, and you are doing well. We had a few exchanges in
private over
past months about a next Spatialite release, but I'm still unclear on when a
next release will
materialize, hence this public call, with the Spatialite list, and GDAL and
QGIS communities
On mardi 28 juillet 2020 17:06:05 CEST Andreas Neumann wrote:
> Thanks for sharing this discussion.
>
> So when you load an old project in QGIS master, the average method would
> be replaced with bilinear now?
>
> Is "bilinear" the closest method to the previous "average"?
This is just a label c
> E.g. GDAL has a flag if a
> datetime is UTC or "not utc/unknown", and that's it.
Small precision: it also has support for explicit timezones
(like UTC+0200)
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer
Hi,
I want to report about the outcome of
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/172
"Use of FileGeodatabase spatial index in OpenFileGDB driver"
This work has been successfully completed into GDAL master (for upcoming GDAL
3.2) per
https://github.com/OSGeo/gdal/pull/2771 , a
On mardi 29 septembre 2020 11:55:40 CEST Alessandro Pasotti wrote:
> Looks like cppcheck is not smart enough...
Yeah, it hardly understands C++ (it doesn't need to be able to fully compile a
file to analyze it,
if I remember correctly)
>
> const double factor { std::pow( 10, - mPrecisionSpinBo
d actually.
When things go bad you can add a suppression
// cppcheck-suppress {name_of_cppcheck_diagnostic}
Or we can disable a category in scripts/cppcheck.sh if it is too unreliable
Even
>
>
> On Tue, Sep 29, 2020 at 12:11 PM Even Rouault
>
> wrote:
> > On mardi 29 s
Andreas,
> Can QGIS 2.18 be built against GDAL 3.x?
Hum, I guess it would build, although definitely not a vetted combination. I
wouldn't expect
datum transformations to work very well, since QGIS would be dependent on
towgs84
coming in PROJ.4 strings, and GDAL 3 / PROJ >= 6 will not populate
Hi Nyall,
> - The type constraint on the fid column makes it really hard to
> translate datasets with an existing, non-numeric "fid" column into
> geopackage. Eg. GML files often have a textual fid string, and
> attempting to convert these to gpkg results in a string of errors
> about string value
> Well -- here's an example file:
> https://github.com/qgis/QGIS/blob/master/python/plugins/processing/tests/tes
> tdata/dissolve_polys.gml
>
> Not sure how that file was created in the first place, but I've seen
> many like it!
Ah ok, this is a GML2 file, which reports indeed a 'fid' field (comi
> I think this is a great idea -- we could retain any compliant fid
> values without change, but as soon as we hit a duplicate fid or
> non-integer fid value then we discard it and generate a new one.
>
> What do you think Even?
Are you talking about the addFeatures() method of the provider ?
Th
> The way I see it, fid can be seen very similarly to rowid or shapefile
> fids. A semi-stable unique identifier. Just - and that's the big difference
> - those are not part of the data hence the system can transparently deal
> with duplicates and can fill holes once in a while (shp -> repack, sqli
On jeudi 15 octobre 2020 17:48:30 CEST Matthias Kuhn wrote:
> If there is a managed database where there has been a conscious decision to
> have an integer id column (postgres case) and workflows are built around
> this: filling the id on insert, building foreign keys against it etc, that
> works j
Hi Nyall,
> But I can't explain this. In both cases the resultant gpkg has a
> spatial index. Does anyone know why one of the methods is so much
> slower than the other? (And ultimately, can we fix
> QgsVectorLayerExporter so it uses the same fast approach!)
Candidate fix and explanations at:
htt
On dimanche 18 octobre 2020 15:35:11 CEST Nyall Dawson wrote:
> On Sat, 17 Oct 2020 at 20:02, Even Rouault
wrote:
> > Hi Nyall,
> >
> > > But I can't explain this. In both cases the resultant gpkg has a
> > > spatial index. Does anyone know why one of th
> Wow, great! So now Tim's screencast has directgly lead to a bunch of
> improvements from GDAL up :D
For clarity I didn't turn on automatically PRAGMA synchronous = OFF for
existing databases.
For current GDAL version, this can be done by setting the
OGR_SQLITE_SYNCHRONOUS configuration option
On mardi 20 octobre 2020 16:12:56 CEST Pedro Venâncio wrote:
> Hi Joaquim Luís,
>
> This is an IPMA NetCDF, it was working before the update.
>
> And I think it is in fact a HDF5 library version problem:
> > gdalinfo AROME_OPER_001_FC_SP_PT2_025_RH_2-HTGL_2020102000.nc
>
> Warning 1: Recode from
Of potential interest. "Develop a logical model for GeoPackage so that future
implementations can be separated from the current requirement to use SQLite."
is intriguing
-- Forwarded Message --
Subject: [TC-Announce] OGC Geopackage Standards Working Group updates its
Charter;
Hi,
I was pointed to
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
If my understanding is correct (which I'm not completely sure given all the
subtelties), QGIS builds will now have a initial credit of 1000 minutes of
build time (so only 17 hours), and then we'd have to beg for mo
> QGIS might not be affected by this since we don't have more than 5
> concurrent builds.
That's not my understanding. The 1, 2 or 5 concurrent builds plans are paying
plans if you look at https://travis-ci.com/organizations/qgis/plan .
The free plan of QGIS is subject to the 10,000 credits syste
On jeudi 7 janvier 2021 18:18:03 CET Vincent Picavet (ml) wrote:
> Hi,
>
> On 07/01/2021 10:43, Nyall Dawson wrote:
> > On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov wrote:
> [..]
>
> >> So if this really is a requirement, should this be enforced somehow and
> >> checked when plugins are accepted t
On mardi 19 janvier 2021 09:55:46 CET Jorge Gustavo Rocha wrote:
> Hi,
>
> Just an additional comment. The GDALAutoCreateWarpedVRTEx is there, as
> far as I can see.
>
> nm -g libqgis_core.so.3.16.3 | grep GDALAutoCreateWarpedVRTEx
> U GDALAutoCreateWarpedVRTEx
>
> But if the sy
Andreas,
if you've built yourself PROJ on a system that has older proj versions, I'd
suppose that one of the QGIS dependency links against that older proj (might
be spatialite for example), and at runtime you get a clash between it and
7.2.x
Check the output of:
ldd /home/an/dev/QGIS/build/out
but the question I have is whether a vector layer were saved to
something like a GPKG would the timezone even be preserved?
Short answer: not by default
Longer answer:
- see https://github.com/opengeospatial/geopackage/issues/530
- and https://github.com/OSGeo/gdal/issues/3423#issuecomment
| Also I wonder if it would be possible to work with the GPKG developers
to provide better timezone support there as well.
This is more about finding how to convince the GeoPackage spec
maintainers that it is worth adding it than a technical one. I guess
they wouldn't want to break compatibili
Jeferson,
yes, you can sell plugins, but you'll have to distribute the source code
of it, or make a written offer to have access to it, to your customers
under the GPL v2+ license of QGIS (which mean they could also
potentially redistribute the source code freely, in all meaning of the
word,
Hi Alessandro,
Isn't it just the bump of version numbers after the release and stale
.so.3.19.* files in output/lib ? (but that caused for me crashes for the
qgis application)
Even
Le 23/06/2021 à 19:36, Alessandro Pasotti a écrit :
Hi,
I really don't know what I have changed but since yes
By design, only speaking about behaviour of the GDAL utilities themselves:
- gdal_translate -a_nodata just modifies the nodata metadata, and
doesn't alter pixel values
- gdalwarp [-srcnodata xxx] -dstnodata yyy modifies the nodata metadata
and pixel values
Le 09/07/2021 à 01:02, Alexandre N
Le 15/07/2021 à 21:51, Andrea Giudiceandrea a écrit :
Il 15/07/2021 20:51, Andrea Giudiceandrea ha scritto:
Instead, QGIS imports correctly XLSX files as UTF-8 encoded, while
XLS files are wrongly imported as "system" encoded, even selecting
UTF-8 [3] encoding in the Data Source Manager vector
Le 15/07/2021 à 22:30, Nyall Dawson a écrit :
On Fri, 16 Jul 2021, 4:52 am Andrea Giudiceandrea,
mailto:andreaer...@libero.it>> wrote:
> Isn't this limitation ultimately that GDAL isn't reading the
encoding
> correctly? (Or perhaps it's a limitation in the underlying freexl
SQLite, which is the underneath database engine for GeoPackage, doesn't
support ILIKE. The SQLite LIKE operator is actually case insensitive for
ASCII characters. See paragraph 5 "The LIKE, GLOB, REGEXP, and MATCH
operators" of https://www.sqlite.org/lang_expr.html
Le 28/07/2021 à 21:43, C Ham
Andreas
Several things to check:
- Is your GDAL build a clean one ? That is is it from a fresh build
directory, or are you rebuilding in a directory where a previous build
was done. If the later, make sure to "make clean" before rebuilding
- Is your GDAL build using your custom GEOS one ? Ot
Hi,
Probably a topic that can raise passions and on which I'm moderately
legitimate to speak, but shouldn't we seriously consider leveraging the
Conda / Conda-Forge (https://conda-forge.org/) ecosystem for QGIS
packaging, especially on the Windows and Mac platforms ? QGIS depends on
a lot of
Petro,
I've queued https://github.com/OSGeo/gdal/pull/4908 which will "fix"
that particular case (more precisely anything based on ETRS89). I'm not
super satisfied with this, and I believe there's no miracle solution for
all potential use cases. What GDAL returns in both 2.4.0 and 3.4.0 is
ac
I meant "Pedro", sorry for the typo.
Le 27/11/2021 à 20:38, Even Rouault a écrit :
Petro,
I've queued https://github.com/OSGeo/gdal/pull/4908 which will "fix"
that particular case (more precisely anything based on ETRS89). I'm
not super satisfied with this, an
Hi Tim,
> - Implement support for WCS as a native QGIS raster driver
Just curious : has levering and/or improving the GDAL WCS driver been considered
?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinf
> Yes - Radim already made a first pass implementation using GDAL WCS
> though he said there were some problems with it - I think the most
> critical being that it doesn't support proxy access (I am speaking
> under correction here as I haven't looked into it in that much detail
> myself).
This s
Hi Radim,
> - (I know that OS people don't like to here it and they will argue
> that is is not a way ahead.) WCS is not widespread yet and there are
> various issues with implementation in UMN Mapserver (and other
> servers) and GDAL. Combination of that issues made it for example
> impossible t
> Yes, requests must be somehow assigned to layers/providers so that
> progress may be emitted from the right place. It could be maybe done
> using GDALDatasetH pointer? Just another hack.
I've no ideal solution for this. Your suggestion could be indeed a possibility :
adding 2 methods GDALDatas
Le mercredi 25 juillet 2012 20:03:16, Chris Crook a écrit :
> Hi .. yes I don't like masking the FID field and I'm not thinking this is a
> long term solution, even before the problem in my implementation with the
> field index issue (which I think I will be able to fix). I'm looking at a
> couple
Le jeudi 26 juillet 2012 21:41:57, Chris Crook a écrit :
> Hi Even
>
> Thanks for the suggestion and code examples - very helpful. I haven't
> followed up on this yet partly because this has prompted me to look at
> other storage formats for the data (something I'd been putting off).
>
> If I und
Le jeudi 26 juillet 2012 22:52:47, Chris Crook a écrit :
> Hi Even
>
> Sorry .. lost wasn't quite correct. The point is that my code for saving
> some users data and then reloading needs to take account of whether they
> have a field called fid or not if I want the list of fields unchanged
> afte
Selon Radim Blazek :
> On Wed, Aug 22, 2012 at 12:29 PM, haubourg
> wrote:
> >
> > Radim Blazek-2 wrote
> >>
> >>
> >> QGIS is using GDALRasterIO() which reads a single pixel on original
> >> resolution. AFAIK, ECW is using tiles internally so it should be all
> >> very fast. I can imagine 2 prob
Le mercredi 22 août 2012 20:13:39, Radim Blazek a écrit :
> Even,
> thanks for exhaustive explanation and testing.
>
> On Wed, Aug 22, 2012 at 2:37 PM, Even Rouault
>
> wrote:
> >> I found in GDAL ecwdataset.cpp that it is treating single row
> >
> >&
> Until it get fixed in GDAL we can use
>
> if ( GDALGetDriverShortName() == "ECW")
>
> and once you fix that
>
> #if defined(GDAL_VERSION_NUM) && GDAL_VERSION_NUM < x.x
> if ( GDALGetDriverShortName() == "ECW")
Seems reasonnable. Except I suggest using a string comparison function and
Le mercredi 22 août 2012 20:13:39, Radim Blazek a écrit :
> Even,
> thanks for exhaustive explanation and testing.
>
> On Wed, Aug 22, 2012 at 2:37 PM, Even Rouault
>
> wrote:
> >> I found in GDAL ecwdataset.cpp that it is treating single row
> >
> >&
Selon Marco Bernasocchi :
> hi every body, updating to th letest android qt version is being tougher
> than planned ... I got all the dependencies ok now but building qgis gives
> me this errors below. any Ideas? this is using android ndk 8b with gcc 4.4.3
>
> thanks a lot
>
> /home/marco/dev/Quan
Hi,
I'm running QGIS master with a GDAL trunk built with a mechanism to detect
unbalanced use of VSIMalloc() and VSIFree().
To enable it, edit gdal/port/cpl_vsisimple.cpp and uncomment the //#define
DEBUG_VSIMALLOC line at the beginning of the file. When this is enabled, the
pointer returned b
Le samedi 29 septembre 2012 12:58:09, Paolo Cavallini a écrit :
> Il 28/09/2012 22:45, Even Rouault ha scritto:
> > Hi,
> >
> > I'm running QGIS master with a GDAL trunk built with a mechanism to
> > detect unbalanced use of VSIMalloc() and VSIFree().
>
>
Le samedi 29 septembre 2012 15:24:59, Etienne Tourigny a écrit :
> Hi,
>
> my opinion is that VSIMalloc/VSIFree should be used mainly by the
> gdal/ogr providers, and if needed elsewhere (e.g. when calling
> gdal/ogr code)
This is even not needed for code that interact with GDAL/OGR. GDAL/OGR
fu
1 - 100 of 428 matches
Mail list logo
