Thanks Alessandro, also for the funny example of the guy with his
personal computer server :)
The idea was to automate one or two processing steps on the server to
update an OWS service regularly.
I don't know how qgis_process is packaged but I don't see a reason why
it would not run under t
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
Hi,
I was quite surprised with the behavior of gdal_translate (in clip raster
by extent) and gdal_warp (reproject) when the user sets up an output nodata
value different from the original nodata value of the input files.
My intuition was telling me that by using that option, all the old nodata
pi
Try deleting everything in the {build}/python/analysis folder. Just
deleting the generated *.cpp files isn't enough.
I have been seeing a multiple definition sip_{module}part{n}
sip_{module}part{n+1} error about once every three months for awhile.
Deleting everything in {build}/python/{module}
Thanks for testing Werner. A few others on Telegram also reported that
things are building fine for them. I will try doing clean build tomorrow,
thanks!
Regards
Tim
On Thu, Jul 8, 2021 at 1:01 PM Werner Macho wrote:
> Hi Tim,
>
> Just updated master and also tried to build with no errors what
Hi Tim,
Just updated master and also tried to build with no errors whatsoever.
(Using ninja and ccache)
Maybe try a clean build?
regards
Werner
On Thu, Jul 8, 2021 at 1:10 PM Tim Sutton wrote:
> Hi All
>
> Just updated to master and getting a build error:
>
>
> Consolidate compiler generated
Hi All
Just updated to master and getting a build error:
Consolidate compiler generated dependencies of target
python_module_qgis__analysis
[ 68%] Linking CXX shared module ../output/python/qgis/_analysis.so
/usr/bin/ld:
CMakeFiles/python_module_qgis__analysis.dir/analysis/sip_analysispart13.cpp
Ok - that explains it.
It is quite confusing that QGIS uses a different internal ID than the
primary key column of the database. Is there a technical reason for this
behaviour?
Andreas
On Thu, 8 Jul 2021 at 11:43, Alexandre Neto wrote:
> As far as I remember @atlas_featureid has always retur
As far as I remember @atlas_featureid has always returned the same as the
$id in the attributes table, which is kind of the internal row number.
Alex
A quinta, 8/07/2021, 10:35, Andreas Neumann escreveu:
> HI Jürgen,
>
> Yes - I provided the primary key column
>
> Here is my data source string:
HI Jürgen,
Yes - I provided the primary key column
Here is my data source string:
service='edit' authcfg=sogis00 key='t_id' srid=2056 type=Polygon
checkPrimaryKeyUnicity='1'
table="alw_strukturverbesserungen"."projekt_aggregiert_v"
(geometrie_convex_hull) sql=geometrie_bbox IS NOT NULL
@atlas_f
Hi Andreas,
On Thu, 08. Jul 2021 at 10:30:08 +0200, Andreas Neumann wrote:
> attribute(@atlas_feature,'pkey_name'), but it is a little more complicated
> than @atlas_featureid - and I'm pretty sure that @atlas_featureid was using
> the pkey column in th past?
>
> My data source for the atlas cove
Hi,
I haven't worked on an Atlas for a while, now again in QGIS 3.16.
I was surprised to see that @atlas_featureid is not equal to the primary
key of the atlas coverage layer.
Is this expected or a bug? I know, I can access the primary key through
attribute(@atlas_feature,'pkey_name'), but i
12 matches
Mail list logo
