Re: [Qgis-user] QGIS 2.10 + GRASS - changes in behaviour?

[Jürgen E . Fischer]

Hi Alex,

On Tue, 11. Aug 2015 at 20:53:41 -0700, Alex Mandel wrote:
> Longer answer the QGIS+GRASS plugin is being rewritten to support GRASS
> 7 which is fairly new. 2.10 is somewhere in no mans land where it
> doesn't work with either 6 or 7 for the plugin (The grass functions in
> the toolbox are related only indirectly, so those working combos differ).

AFAIK the plugin works fine with GRASS 6.  I suspect the OSX package either
ships with GRASS 7 (hence no plugin), otherwise it might be a packaging problem
on OSX).


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] moving features in multiple layers at once by mouse

[Richard Duivenvoorde]

On 11-08-15 17:05, Mats Elfström wrote:
> Hi Richard!
> What is the point of the point in the polygon? Simplifying your data
> to one table only would save you a lot of work.

Hi Mats,

The actual usecase is that QGIS is actually used for drawing
(archeological) profiles. So on a (paper mimicking) grid, workers draw a
profile of some (say one meter) width, and somewhere in that profile
there is a 'special/measuring' point with totally different attributes
(then the profile).
So really two different entities, but only 'spatially' related as in:
this point is related to this profile drawing.

The actual QGIS project then is a list of those profiles (like a list of
profiles on a 'paper drawing'), but sometimes one have to 'insert' a new
profile, so you want to move the others (including those measuring
points)...

More clear like this? Do you agree with me then that these are two
tables/files instead of one?

I can think of some plugin which holds a handle to a one of the editing
layers, and listens to the mouse events on that one and translates those
to the other editing layer
But I was hoping that maybe people already had this..:-)

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10 + GRASS - changes in behaviour?

[Radim Blazek]

On Tue, Aug 11, 2015 at 11:23 PM, Carlos Grohmann
 wrote:
> Hi all,
>
> After upgrading to 2.10 (running kyngschaos pkgs on OS X), I noticed that
> the "add grass raster layer" and "add grass vector layer" button from the
> GRASS plugin are gone. Is this a bug or there were changes in 2.10 related
> to GRASS layers?

You can add layers from the QGIS browser (double click or
drag-and-drop). GRASS location item with GRASS icon is in the browser
tree under the location's directory, that is not new, GRASS is
supported in the browser since the browser was introduced.

The buttons were removed in favour of the browser and UI tidiness
after discussion on devel list:
http://lists.osgeo.org/pipermail/qgis-developer/2015-May/037827.html

You can visualize and manage GRASS 6 and 7 (if providers are compiled)
in QGIS 2.10. The plugin (mapsets, region, modules) is not yet
upgraded to GRASS 7 in QGIS 2.10, the upgrade of the plugin is
underway for QGIS 2.12. GRASS 6 plugin is available without changes.

Radim


> Suddenly I can't even visualize my GRASS layers anymore..
>
> best
>
> --
> Prof. Carlos Henrique Grohmann
> Institute of Energy and Environment - Univ. of São Paulo, Brazil
> - Digital Terrain Analysis | GIS | Remote Sensing -
>
> http://carlosgrohmann.com
> http://orcid.org/-0001-5073-5572
> 
> Can’t stop the signal.
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10 + GRASS - changes in behaviour?

[Radim Blazek]

On Wed, Aug 12, 2015 at 5:53 AM, Alex Mandel  wrote:
> On 08/11/2015 02:23 PM, Carlos Grohmann wrote:
>> Hi all,
>>
>> After upgrading to 2.10 (running kyngschaos pkgs on OS X), I noticed that
>> the "add grass raster layer" and "add grass vector layer" button from the
>> GRASS plugin are gone. Is this a bug or there were changes in 2.10 related
>> to GRASS layers?
>>
>> Suddenly I can't even visualize my GRASS layers anymore..
>>
>> best
>>
>
> Well known issue, downgrade back to previous version you had working if
> you need GRASS layers working in QGIS or the QGIS+GRASS Plugin.

It is not an issue, the buttons were removed after discussion on mailing list:
http://lists.osgeo.org/pipermail/qgis-developer/2015-May/037827.html
Layers may be added from browser.

> Expect QGIS 2.12 to likely work with GRASS 7.
> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/

QGIS 2.10 compiled with GRASS 7 can visualize and manage GRASS 7
layers, plugin upgrade is scheduled for 2.12.

> Longer answer the QGIS+GRASS plugin is being rewritten to support GRASS
> 7 which is fairly new. 2.10 is somewhere in no mans land where it
> doesn't work with either 6 or 7 for the plugin

GRASS 6 provider and plugin should work as before, apart that plugin
browser and 'add layer' buttons were substituted by standard QGIS
browser. Have you found bugs in GRASS 6 plugin introduced in 2.10?

The GRASS plugin is not yet upgraded to GRASS 7, but the provider is
already upgraded. It means that people using GRASS 6 can use the GRASS
provider and plugin while people using GRASS 7 can use the provider,
which has much richer functionality, it allows to manage layers
(rename,delete,copy) or import data to GRASS using drag-and-drop,
which supports on-the-fly reprojection or creation of link to external
data (r.external) if CRS are the same (optional) via QGIS browser.

> (The grass functions in
> the toolbox are related only indirectly, so those working combos differ).

What do you mean exactly?

Radim


> Thanks,
> Alex
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10 + GRASS - changes in behaviour?

[Radim Blazek]

On Wed, Aug 12, 2015 at 9:20 AM, Jürgen E.  wrote:
> Hi Alex,
>
> On Tue, 11. Aug 2015 at 20:53:41 -0700, Alex Mandel wrote:
>> Longer answer the QGIS+GRASS plugin is being rewritten to support GRASS
>> 7 which is fairly new. 2.10 is somewhere in no mans land where it
>> doesn't work with either 6 or 7 for the plugin (The grass functions in
>> the toolbox are related only indirectly, so those working combos differ).
>
> AFAIK the plugin works fine with GRASS 6.  I suspect the OSX package either
> ships with GRASS 7 (hence no plugin), otherwise it might be a packaging 
> problem
> on OSX).

Since QGIS 2.10, the GRASS plugin may be compiled with GRASS 6 or 7 or
with both at the same time (all binaries have different file names for
GRASS 6 and 7). It is on packagers which version(s) of GRASS they
choose. OSGeo4W, for example supports both GRASS 6 and 7.

Radim

>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Cumulative count cut on rasters

[Radim Blazek]

On Tue, Aug 11, 2015 at 3:09 PM, Andrea Peri  wrote:
> Hi,
> trying the rendering of a raster floating point using the cumulative count 
> cut.
> I see it is quite good if I set the values 2.0,100.0% (not 98%) and
> use the accuracy at value "estimate".
> Instead always with the same values for cumulative count cut, but
> using the accuracy "actual".
> The result is really poor. The image became totally black with only
> few isles of grey.
>
> This is a surprise for me because the accuracy "actual" take a long
> time and the name seem to say more precision.
>
> I like to know what is the strategy used for actual: estimate and the
> strategy for accuracy: actual.

Actual takes all pixels, estimate takes 25 pixels (whole data
extent with resolution giving approximately 25 pixels). Some
providers may use different approach to get estimated values, e.g.
GDAL provider may use approximated values returned by GDAL, IIRC.

Radim


>
> Many thx.
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Issues to building QGIS-2.10.1 on linux using Qt5.5

[Spartucus]

hi all,
I'm trying to build QGIS-2.10.1 on my linux from source. I want to build
QGIS API for developmenting.
I consulted the Matthias Kuhn's article: here
  .
CMAKE is OK regardless of some warning, but MAKE break down.

The OS I'm using is Neokylin3.2.2, a Chinese linux OS. I'm not quite
familiar with the OS, here is some system info:


Here are the CMAKE logs:


And here are parts of MAKE logs:


As you can see, it breaks down at 5%. It seems like that I didn't set the
Qt's include path, but should it be done on CMAKE process?

what should I do? any advice would be appreciated!



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Issues-to-building-QGIS-2-10-1-on-linux-using-Qt5-5-tp5219515.html
Sent from the Quantum GIS - User mailing list archive at Nabble.com.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Issues to building QGIS-2.10.1 on linux using Qt5.5

[Richard Duivenvoorde]

On 12-08-15 13:32, Spartucus wrote:
> hi all,
> I'm trying to build QGIS-2.10.1 on my linux from source. I want to build
> QGIS API for developmenting.
> I consulted the Matthias Kuhn's article: here
>   .
> CMAKE is OK regardless of some warning, but MAKE break down.
> 
> The OS I'm using is Neokylin3.2.2, a Chinese linux OS. I'm not quite
> familiar with the OS, here is some system info:
> 
> Here are the CMAKE logs:
> 
> And here are parts of MAKE logs:
> 
> As you can see, it breaks down at 5%. It seems like that I didn't set the
> Qt's include path, but should it be done on CMAKE process?
> 
> what should I do? any advice would be appreciated!

Hi Spartucus,

as you can see above, Nabble eat all your logs.

but the Pull Request of Matthias is about compiling QGIS specifically
for Qt5

'normal' compiles do Qt4, and it is best to follow the info from
https://github.com/qgis/QGIS/blob/master/INSTALL
for that

but if I google NeoKylin, it seems to be a FreeBSD derivative... see
http://qgis.org/en/site/forusers/alldownloads.html#freebsd

Which (I think is harder to get help for as most of dev's are Linux
users...).

Regards,

Richard Duivenvoorde





___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Issues to building QGIS-2.10.1 on linux using Qt5.5

[Spartucus]

thanks Richard. 
Yeah, it is harder to using yum to install QGIS(so many dependencies) rather
than building from source.
I compiling QGIS for QT5 only.
Only add the MAKE log again this time see if it is OK in nabble:




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Issues-to-building-QGIS-2-10-1-on-linux-using-Qt5-5-tp5219515p5219527.html
Sent from the Quantum GIS - User mailing list archive at Nabble.com.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Issues to building QGIS-2.10.1 on linux using Qt5.5

[Matthias Kuhn]

Hi Spartucus,

Fedora also uses yum and it is as easy as typing

yum install qgis

and all dependencies are installed automatically.

Still straightforward is building against Qt4 because it has been well
tested and known for a good user experience.

Building against Qt5 is possible but needs technical know-how and has
some flaws (most important, I would not know of any Qt5 build that
supports python plugins so far).

Hint: you can use http://pastebin.com/ to paste code and send us the link.

Cheers,
Matthias

On 08/12/2015 02:46 PM, Spartucus wrote:
> thanks Richard. 
> Yeah, it is harder to using yum to install QGIS(so many dependencies) rather
> than building from source.
> I compiling QGIS for QT5 only.
> Only add the MAKE log again this time see if it is OK in nabble:
>
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Issues-to-building-QGIS-2-10-1-on-linux-using-Qt5-5-tp5219515p5219527.html
> Sent from the Quantum GIS - User mailing list archive at Nabble.com.
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] QGis server project files stored in DB?

[lars lingner]

Hello,

I'm looking for a solution for storing QGis project files (qgs) in a
PostgreSQL database. Storing the files in a table isn't actually the
problem, but getting it out and feeding it to QGis server.

Did anyone had this need already? Would this be a good idea?

In my use case the project files are generated, based on a default
project file. Having the file in the DB would give more flexibility.

Since saving the style in DB is already supported by QGis, I'm just
curious of opinions of other users or developers.

Thanks in advance for any feedback

Lars
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Cumulative count cut on rasters

[Andrea Peri]

Hi Radim, thx for explain.
Your explanation of extimated strategy could explain why the extimated
is more precise rather than the actual strategy.
I guess are the null values to produce a wrong "actual" results.

Can you say me in which file I can found the code for the extimate and
actual strategy
to verify my hypotesis.?

Thx.



2015-08-12 11:22 GMT+02:00 Radim Blazek :
> On Tue, Aug 11, 2015 at 3:09 PM, Andrea Peri  wrote:
>> Hi,
>> trying the rendering of a raster floating point using the cumulative count 
>> cut.
>> I see it is quite good if I set the values 2.0,100.0% (not 98%) and
>> use the accuracy at value "estimate".
>> Instead always with the same values for cumulative count cut, but
>> using the accuracy "actual".
>> The result is really poor. The image became totally black with only
>> few isles of grey.
>>
>> This is a surprise for me because the accuracy "actual" take a long
>> time and the name seem to say more precision.
>>
>> I like to know what is the strategy used for actual: estimate and the
>> strategy for accuracy: actual.
>
> Actual takes all pixels, estimate takes 25 pixels (whole data
> extent with resolution giving approximately 25 pixels). Some
> providers may use different approach to get estimated values, e.g.
> GDAL provider may use approximated values returned by GDAL, IIRC.
>
> Radim
>
>
>>
>> Many thx.
>>
>> --
>> -
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[Andrea Peri]

I don't guess is more flexible.
Infact usually the teting environment is never exactly exals to the
publish environmnet.

A file allw to open and correct the paths from develop and publish environment.
Also the svg symbols could be not exactly with the same path from
develop and publish environment.

So having a same project in a db is more complex becasue need to have
two environment exactly the same.
And this is not possible.
.

I guess the db storing for project could be more flexible only if the
paths to the layers and relative paths of svg was not stored in the
project file but instead in other files.

My 2ct.

A.


2015-08-12 15:06 GMT+02:00 lars lingner :
> Hello,
>
> I'm looking for a solution for storing QGis project files (qgs) in a
> PostgreSQL database. Storing the files in a table isn't actually the
> problem, but getting it out and feeding it to QGis server.
>
> Did anyone had this need already? Would this be a good idea?
>
> In my use case the project files are generated, based on a default
> project file. Having the file in the DB would give more flexibility.
>
> Since saving the style in DB is already supported by QGis, I'm just
> curious of opinions of other users or developers.
>
> Thanks in advance for any feedback
>
> Lars
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[Nathan Woodrow]

Hey Lars,

It has been a long time goal of mine to add this as a core feature, in fact
that is why I renamed the File menu to Project a few versions back, but I
have never quite got there yet. In theory I don't think it would be too
hard but just time and effort really.

For a current solution you could always just dump them from the db to the
disk at intervals or something like that. Bit of Python or bash scripting
would do it pretty easy.

Regards,

On Wed, Aug 12, 2015 at 11:06 PM, lars lingner 
wrote:

> Hello,
>
> I'm looking for a solution for storing QGis project files (qgs) in a
> PostgreSQL database. Storing the files in a table isn't actually the
> problem, but getting it out and feeding it to QGis server.
>
> Did anyone had this need already? Would this be a good idea?
>
> In my use case the project files are generated, based on a default
> project file. Having the file in the DB would give more flexibility.
>
> Since saving the style in DB is already supported by QGis, I'm just
> curious of opinions of other users or developers.
>
> Thanks in advance for any feedback
>
> Lars
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[James Keener]

I was also looking for this a bit back and never found a solution. I ended
up using other software, unfortunately.

As for being less flexible, it is exactly as flexible as a qgs file would
be, it's just that they could be manipulated and created more easily.  I
would love to see the parts of the file broke out in the database and not
just using a single text blob, though.

Also, setting up identical-enough is fairly trivial, especially if most of
the layers are already coming from a database, or known cache of shapefiles.

Jim

On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri  wrote:

> I don't guess is more flexible.
> Infact usually the teting environment is never exactly exals to the
> publish environmnet.
>
> A file allw to open and correct the paths from develop and publish
> environment.
> Also the svg symbols could be not exactly with the same path from
> develop and publish environment.
>
> So having a same project in a db is more complex becasue need to have
> two environment exactly the same.
> And this is not possible.
> .
>
> I guess the db storing for project could be more flexible only if the
> paths to the layers and relative paths of svg was not stored in the
> project file but instead in other files.
>
> My 2ct.
>
> A.
>
>
> 2015-08-12 15:06 GMT+02:00 lars lingner :
> > Hello,
> >
> > I'm looking for a solution for storing QGis project files (qgs) in a
> > PostgreSQL database. Storing the files in a table isn't actually the
> > problem, but getting it out and feeding it to QGis server.
> >
> > Did anyone had this need already? Would this be a good idea?
> >
> > In my use case the project files are generated, based on a default
> > project file. Having the file in the DB would give more flexibility.
> >
> > Since saving the style in DB is already supported by QGis, I'm just
> > curious of opinions of other users or developers.
> >
> > Thanks in advance for any feedback
> >
> > Lars
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10 + GRASS - changes in behaviour?

[Carlos Grohmann]

Thanks for the info, Radim.

Indeed using the Browser is very convenient for GRASS data. I wasn't really
used to use it but will now.

It looks like 2.12 will be very interesting! Looking forward to it.

best

Carlos



On Wed, Aug 12, 2015 at 5:43 AM, Radim Blazek 
wrote:

> On Tue, Aug 11, 2015 at 11:23 PM, Carlos Grohmann
>  wrote:
> > Hi all,
> >
> > After upgrading to 2.10 (running kyngschaos pkgs on OS X), I noticed that
> > the "add grass raster layer" and "add grass vector layer" button from the
> > GRASS plugin are gone. Is this a bug or there were changes in 2.10
> related
> > to GRASS layers?
>
> You can add layers from the QGIS browser (double click or
> drag-and-drop). GRASS location item with GRASS icon is in the browser
> tree under the location's directory, that is not new, GRASS is
> supported in the browser since the browser was introduced.
>
> The buttons were removed in favour of the browser and UI tidiness
> after discussion on devel list:
> http://lists.osgeo.org/pipermail/qgis-developer/2015-May/037827.html
>
> You can visualize and manage GRASS 6 and 7 (if providers are compiled)
> in QGIS 2.10. The plugin (mapsets, region, modules) is not yet
> upgraded to GRASS 7 in QGIS 2.10, the upgrade of the plugin is
> underway for QGIS 2.12. GRASS 6 plugin is available without changes.
>
> Radim
>
>
> > Suddenly I can't even visualize my GRASS layers anymore..
> >
> > best
> >
> > --
> > Prof. Carlos Henrique Grohmann
> > Institute of Energy and Environment - Univ. of São Paulo, Brazil
> > - Digital Terrain Analysis | GIS | Remote Sensing -
> >
> > http://carlosgrohmann.com
> > http://orcid.org/-0001-5073-5572
> > 
> > Can’t stop the signal.
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-user
>



-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[Andrea Peri]

So you assume to have grants to write in the table where is stored the
published informazioni.
This is not always true. The dba amministratore of a published environment
not like to have some cowboy to write into its DBMS.

Instead in low profile environment where there is 1 user only and it is
webadmin , qgis user and perhaps also publisher. Not always it ha also  the
capability to admin a DBMS like postgres.

I feat that this option increasing complexity will reduce the installation
of qgis-server.

A.
Il 12/ago/2015 03:29 PM, "James Keener"  ha scritto:

> I was also looking for this a bit back and never found a solution. I ended
> up using other software, unfortunately.
>
> As for being less flexible, it is exactly as flexible as a qgs file would
> be, it's just that they could be manipulated and created more easily.  I
> would love to see the parts of the file broke out in the database and not
> just using a single text blob, though.
>
> Also, setting up identical-enough is fairly trivial, especially if most of
> the layers are already coming from a database, or known cache of shapefiles.
>
> Jim
>
> On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri  wrote:
>
>> I don't guess is more flexible.
>> Infact usually the teting environment is never exactly exals to the
>> publish environmnet.
>>
>> A file allw to open and correct the paths from develop and publish
>> environment.
>> Also the svg symbols could be not exactly with the same path from
>> develop and publish environment.
>>
>> So having a same project in a db is more complex becasue need to have
>> two environment exactly the same.
>> And this is not possible.
>> .
>>
>> I guess the db storing for project could be more flexible only if the
>> paths to the layers and relative paths of svg was not stored in the
>> project file but instead in other files.
>>
>> My 2ct.
>>
>> A.
>>
>>
>> 2015-08-12 15:06 GMT+02:00 lars lingner :
>> > Hello,
>> >
>> > I'm looking for a solution for storing QGis project files (qgs) in a
>> > PostgreSQL database. Storing the files in a table isn't actually the
>> > problem, but getting it out and feeding it to QGis server.
>> >
>> > Did anyone had this need already? Would this be a good idea?
>> >
>> > In my use case the project files are generated, based on a default
>> > project file. Having the file in the DB would give more flexibility.
>> >
>> > Since saving the style in DB is already supported by QGis, I'm just
>> > curious of opinions of other users or developers.
>> >
>> > Thanks in advance for any feedback
>> >
>> > Lars
>> > ___
>> > Qgis-user mailing list
>> > Qgis-user@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>>
>> --
>> -
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Cumulative count cut on rasters

[Radim Blazek]

On Wed, Aug 12, 2015 at 3:07 PM, Andrea Peri  wrote:
> Hi Radim, thx for explain.
> Your explanation of extimated strategy could explain why the extimated
> is more precise rather than the actual strategy.
> I guess are the null values to produce a wrong "actual" results.
>
> Can you say me in which file I can found the code for the extimate and
> actual strategy
> to verify my hypotesis.?

https://github.com/qgis/QGIS/blob/master/src/core/raster/qgsrasterinterface.cpp#L395
https://github.com/qgis/QGIS/blob/master/src/providers/gdal/qgsgdalprovider.cpp#L1323
https://github.com/qgis/QGIS/blob/master/src/core/raster/qgsrasterinterface.cpp#L510

Radim


> Thx.
>
>
>
> 2015-08-12 11:22 GMT+02:00 Radim Blazek :
>> On Tue, Aug 11, 2015 at 3:09 PM, Andrea Peri  wrote:
>>> Hi,
>>> trying the rendering of a raster floating point using the cumulative count 
>>> cut.
>>> I see it is quite good if I set the values 2.0,100.0% (not 98%) and
>>> use the accuracy at value "estimate".
>>> Instead always with the same values for cumulative count cut, but
>>> using the accuracy "actual".
>>> The result is really poor. The image became totally black with only
>>> few isles of grey.
>>>
>>> This is a surprise for me because the accuracy "actual" take a long
>>> time and the name seem to say more precision.
>>>
>>> I like to know what is the strategy used for actual: estimate and the
>>> strategy for accuracy: actual.
>>
>> Actual takes all pixels, estimate takes 25 pixels (whole data
>> extent with resolution giving approximately 25 pixels). Some
>> providers may use different approach to get estimated values, e.g.
>> GDAL provider may use approximated values returned by GDAL, IIRC.
>>
>> Radim
>>
>>
>>>
>>> Many thx.
>>>
>>> --
>>> -
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[lars lingner]

Hi,

thanks for the feedback so far. If feel I have to explain my usecase a
little bit more. It is basically a  "well designed server setup" (TM)
which provides map services via QGis Server. The configuration and
project files are tested and can only be changed by authorized users.

Other users are working with QGis Desktop developing project files.
These files are deployed on the server and being used there for the map
services. So there is a barrier which filters out most of faulty project
files like not accessible host names or user credentials. That is why I
didn't think about the problems regarding access rights, permissions and
environment settings.

My simple thought was, if I have a working project file consumed by QGis
Server, couldn't I use a DB as source of it. There is already a DB sync
for the data in place. Handling QGis project files now, I'm already
responsible that all resources mentioned are accessible. I wouldn't
expect QGis to do this job.

But of course, these questions arise and more are likely to come. I
wouldn't expect a feature like this being useful for _all_ QGis users,
OTOH which feature does? :)

One problem I could see is the overhead getting the file out of the DB.
When a server process is spawned, the project file is processed. I can
imagine checking if the project has changed and respawning the server
process if needed would add some amount of overhead.

For now I'm trying to work with a wrapper script. This is selecting the
right "QGis file row" and writing it in a file which is than consumed by
QGis server.


Thanks for listening :)

Lars


On 12.08.2015 16:03, Andrea Peri wrote:
> So you assume to have grants to write in the table where is stored the
> published informazioni.
> This is not always true. The dba amministratore of a published environment
> not like to have some cowboy to write into its DBMS.
> 
> Instead in low profile environment where there is 1 user only and it is
> webadmin , qgis user and perhaps also publisher. Not always it ha also  the
> capability to admin a DBMS like postgres.
> 
> I feat that this option increasing complexity will reduce the installation
> of qgis-server.
> 
> A.
> Il 12/ago/2015 03:29 PM, "James Keener"  ha scritto:
> 
>> I was also looking for this a bit back and never found a solution. I ended
>> up using other software, unfortunately.
>>
>> As for being less flexible, it is exactly as flexible as a qgs file would
>> be, it's just that they could be manipulated and created more easily.  I
>> would love to see the parts of the file broke out in the database and not
>> just using a single text blob, though.
>>
>> Also, setting up identical-enough is fairly trivial, especially if most of
>> the layers are already coming from a database, or known cache of shapefiles.
>>
>> Jim
>>
>> On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri  wrote:
>>
>>> I don't guess is more flexible.
>>> Infact usually the teting environment is never exactly exals to the
>>> publish environmnet.
>>>
>>> A file allw to open and correct the paths from develop and publish
>>> environment.
>>> Also the svg symbols could be not exactly with the same path from
>>> develop and publish environment.
>>>
>>> So having a same project in a db is more complex becasue need to have
>>> two environment exactly the same.
>>> And this is not possible.
>>> .
>>>
>>> I guess the db storing for project could be more flexible only if the
>>> paths to the layers and relative paths of svg was not stored in the
>>> project file but instead in other files.
>>>
>>> My 2ct.
>>>
>>> A.
>>>
>>>
>>> 2015-08-12 15:06 GMT+02:00 lars lingner :
 Hello,

 I'm looking for a solution for storing QGis project files (qgs) in a
 PostgreSQL database. Storing the files in a table isn't actually the
 problem, but getting it out and feeding it to QGis server.

 Did anyone had this need already? Would this be a good idea?

 In my use case the project files are generated, based on a default
 project file. Having the file in the DB would give more flexibility.

 Since saving the style in DB is already supported by QGis, I'm just
 curious of opinions of other users or developers.

 Thanks in advance for any feedback

 Lars
 ___
 Qgis-user mailing list
 Qgis-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>>
>>> --
>>> -
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>
>>
> 

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Conversion from World to Geo coordinates

[Alex Mandel]

On 08/11/2015 01:39 PM, Tudorache, Marian wrote:
> Hi everyone,
> 
> I currently have some GIS data using the world format x and y where those 
> were obtained by approximate the Earth with a modified GRS80 datum where the 
> Semi-major axis = Semi-minor axis = 6381711.641389.
> I would like to know if there is a plugin in QGIS which can convert 
> automatically back to lat and long of any standard or custom datum.
> 
> Thank you,
> Marian
> 

You can define custom projections in the Settings. Then any tools such
as reprojection/Save as can be used to convert it to any other projection.

-Alex

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[James Keener]

> So you assume to have grants to write in the table where is stored the
published informazioni. This is not always true. The dba amministratore of
a published environment not like to have some cowboy to write into its DBMS.

It depends on the access you need. If you're in an environment with an
actual dba, they can give you the rights you need and no more.  The more
widespread case is when you're acting as your own DBA and in which case you
can have the rights you need.  The user QGIS Server uses doesn't need to be
the same user that has update access.  There are many solutions.

It also depends on the application, and a billion other things that make it
difficult to say "you can't do that".  It _can_ be done, it's just a matter
of making it happen.


> Instead in low profile environment where there is 1 user only and it is
webadmin , qgis user and perhaps also publisher. Not always it ha also  the
capability to admin a DBMS like postgres.

I'm not sure what you're getting at. No one is saying that the db-based
projects should be the only, or even the default, method.

> I feat that this option increasing complexity will reduce the
installation of qgis-server.

Again, no one is talking about removing the current method.  I'm not sure
what your problem is with people discussing a more complex, but
also extremely flexible, needed, and wanted method of storing projects.  If
you don't want it, don't use it.  No one is taking away file-based projects.

Jim

On Wed, Aug 12, 2015 at 10:03 AM, Andrea Peri  wrote:

> So you assume to have grants to write in the table where is stored the
> published informazioni.
> This is not always true. The dba amministratore of a published environment
> not like to have some cowboy to write into its DBMS.
>
> Instead in low profile environment where there is 1 user only and it is
> webadmin , qgis user and perhaps also publisher. Not always it ha also  the
> capability to admin a DBMS like postgres.
>
> I feat that this option increasing complexity will reduce the installation
> of qgis-server.
>
> A.
> Il 12/ago/2015 03:29 PM, "James Keener"  ha scritto:
>
>> I was also looking for this a bit back and never found a solution. I
>> ended up using other software, unfortunately.
>>
>> As for being less flexible, it is exactly as flexible as a qgs file would
>> be, it's just that they could be manipulated and created more easily.  I
>> would love to see the parts of the file broke out in the database and not
>> just using a single text blob, though.
>>
>> Also, setting up identical-enough is fairly trivial, especially if most
>> of the layers are already coming from a database, or known cache of
>> shapefiles.
>>
>> Jim
>>
>> On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri  wrote:
>>
>>> I don't guess is more flexible.
>>> Infact usually the teting environment is never exactly exals to the
>>> publish environmnet.
>>>
>>> A file allw to open and correct the paths from develop and publish
>>> environment.
>>> Also the svg symbols could be not exactly with the same path from
>>> develop and publish environment.
>>>
>>> So having a same project in a db is more complex becasue need to have
>>> two environment exactly the same.
>>> And this is not possible.
>>> .
>>>
>>> I guess the db storing for project could be more flexible only if the
>>> paths to the layers and relative paths of svg was not stored in the
>>> project file but instead in other files.
>>>
>>> My 2ct.
>>>
>>> A.
>>>
>>>
>>> 2015-08-12 15:06 GMT+02:00 lars lingner :
>>> > Hello,
>>> >
>>> > I'm looking for a solution for storing QGis project files (qgs) in a
>>> > PostgreSQL database. Storing the files in a table isn't actually the
>>> > problem, but getting it out and feeding it to QGis server.
>>> >
>>> > Did anyone had this need already? Would this be a good idea?
>>> >
>>> > In my use case the project files are generated, based on a default
>>> > project file. Having the file in the DB would give more flexibility.
>>> >
>>> > Since saving the style in DB is already supported by QGis, I'm just
>>> > curious of opinions of other users or developers.
>>> >
>>> > Thanks in advance for any feedback
>>> >
>>> > Lars
>>> > ___
>>> > Qgis-user mailing list
>>> > Qgis-user@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>>
>>> --
>>> -
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>
>>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGis server project files stored in DB?

[Vincent Picavet (ml)]

Hi,

On 12/08/2015 16:03, Andrea Peri wrote:
> So you assume to have grants to write in the table where is stored the
> published informazioni.

On top of what has already been said, do not forget that the database
you save the project(s) configuration(s) to, can be a local Spatialite
database.
This gives a path towards having a project + data file format.

One of the difficulties I find would be the project format changes, as
well as storing plugin configuration items. We would have to design a
clever model for that, and to use versioning for the DB schema.

Project Schema version would maybe allow to use DB migration tools to
convert projects from one QGIS version to another, which could be
convenient.

Vincent

> This is not always true. The dba amministratore of a published
> environment not like to have some cowboy to write into its DBMS.
> 
> Instead in low profile environment where there is 1 user only and it is
> webadmin , qgis user and perhaps also publisher. Not always it ha also 
> the capability to admin a DBMS like postgres.
> 
> I feat that this option increasing complexity will reduce the
> installation of qgis-server.
> 
> A.
> 
> Il 12/ago/2015 03:29 PM, "James Keener"  > ha scritto:
> 
> I was also looking for this a bit back and never found a solution. I
> ended up using other software, unfortunately.
> 
> As for being less flexible, it is exactly as flexible as a qgs file
> would be, it's just that they could be manipulated and created more
> easily.  I would love to see the parts of the file broke out in the
> database and not just using a single text blob, though.
> 
> Also, setting up identical-enough is fairly trivial, especially if
> most of the layers are already coming from a database, or known
> cache of shapefiles.
> 
> Jim
> 
> On Wed, Aug 12, 2015 at 9:13 AM, Andrea Peri  > wrote:
> 
> I don't guess is more flexible.
> Infact usually the teting environment is never exactly exals to the
> publish environmnet.
> 
> A file allw to open and correct the paths from develop and
> publish environment.
> Also the svg symbols could be not exactly with the same path from
> develop and publish environment.
> 
> So having a same project in a db is more complex becasue need to
> have
> two environment exactly the same.
> And this is not possible.
> .
> 
> I guess the db storing for project could be more flexible only
> if the
> paths to the layers and relative paths of svg was not stored in the
> project file but instead in other files.
> 
> My 2ct.
> 
> A.
> 
> 
> 2015-08-12 15:06 GMT+02:00 lars lingner  >:
> > Hello,
> >
> > I'm looking for a solution for storing QGis project files
> (qgs) in a
> > PostgreSQL database. Storing the files in a table isn't
> actually the
> > problem, but getting it out and feeding it to QGis server.
> >
> > Did anyone had this need already? Would this be a good idea?
> >
> > In my use case the project files are generated, based on a default
> > project file. Having the file in the DB would give more
> flexibility.
> >
> > Since saving the style in DB is already supported by QGis, I'm
> just
> > curious of opinions of other users or developers.
> >
> > Thanks in advance for any feedback
> >
> > Lars
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org 
> > http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Conversion from World to Geo coordinates

[Tudorache, Marian]

Hi Alex,

Thank you for your answer.
It seem to work. I was able to re-project the maps.

marian

-Original Message-
From: Alex Mandel [mailto:tech_...@wildintellect.com]
Sent: August-12-15 11:43 AM
To: Tudorache, Marian; qgis-user@lists.osgeo.org
Subject: Re: [Qgis-user] Conversion from World to Geo coordinates

On 08/11/2015 01:39 PM, Tudorache, Marian wrote:
> Hi everyone,
>
> I currently have some GIS data using the world format x and y where those 
> were obtained by approximate the Earth with a modified GRS80 datum where the 
> Semi-major axis = Semi-minor axis = 6381711.641389.
> I would like to know if there is a plugin in QGIS which can convert 
> automatically back to lat and long of any standard or custom datum.
>
> Thank you,
> Marian
>

You can define custom projections in the Settings. Then any tools such as 
reprojection/Save as can be used to convert it to any other projection.

-Alex


This electronic message, as well as any transmitted files included in the 
electronic message, may contain privileged or confidential information and is 
intended solely for the use of the individual(s) or entity to which it is 
addressed. If you have received this electronic message in error please notify 
the sender immediately and delete the electronic message. Any unauthorized 
copying, disclosure or distribution of the electronic message is strictly 
forbidden. NAV CANADA accepts no liability for any damage caused by any virus 
and/or other malicious code transmitted by this electronic communication.

Le présent message électronique et tout fichier qui peut y être joint peuvent 
contenir des renseignements privilégiés ou confidentiels destinés à l’usage 
exclusif des personnes ou des organismes à qui ils s’adressent. Si vous avez 
reçu ce message électronique par erreur, veuillez en informer l’expéditeur 
immédiatement et supprimez le. Toute reproduction, divulgation ou distribution 
du présent message électronique est strictement interdite. NAV CANADA n’assume 
aucune responsabilité en cas de dommage causé par tout virus ou autre programme 
malveillant transmis par ce message électronique.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [Qgis-developer] Any working GRASS in QGIS available? - Processing Bug?

[Andrew]

Sure thing.  Open the .qgis2/python/plugins/processing/algs/grass7/ folder
and open the Grass7Algorithm.py file in a text editor. You can see the
changes that you'll need to make on GitHub:

https://github.com/qgis/QGIS/commit/2a14ffd281d0a0e99a0a899622a29ca0efdb0852

It is just a couple small changes.  I suppose alternately you could just
download the Grass7Algorithm.py file from GitHub and replace the one in the
above mentioned folder.

Andrew

On Tue, Aug 11, 2015 at 12:29 PM, Bernd Vogelgesang <
bernd.vogelges...@gmx.de> wrote:

> Hi Andrew
>
>
> Am 06.08.2015, 19:20 Uhr, schrieb Andrew :
>
> Victor,
>
> I edited the version of the processing plugin that i have installed (QGIS
> 2.8.3, processing 2.10.1) with the changes you made and now GRASS7 tools
> work as they should, thanks!
>
> Andrew
>
>
> Could you maybe describe a little bit what you have changed and how ?
>
> Bernd
>
>
>
> On Thu, Aug 6, 2015 at 5:59 AM, Victor Olaya  wrote:
>
>> A quick (but very relevant) note about GRASS7:
>>
>> It seems that, in one of the latest changes, I unintentionally left
>> out a code line where GRASS was actually being called. I was getting a
>> bit crazy wondering where the error might be and why GRASS7 was not
>> working in the latest releaseand finally found out that the reason
>> was that. So, in short, Processing was not running grass when running
>> a grass7 algorithm.
>>
>> I have added that line back and it should be fine now.
>>
>> If you can install the current master version, please test and let me
>> know if there are any issues or it is working correctly as before.
>>
>> Regards
>>
>>
>>
>> 2015-08-03 1:37 GMT+02:00 Bernd Vogelgesang :
>> > Hi Alex
>> >
>> > Am 03.08.2015, 01:20 Uhr, schrieb Alex Mandel <
>> tech_...@wildintellect.com>:
>> >
>> >> Ah but we're closer to finding a solution with all those details. It
>> may
>> >> be fixable in Processing, which can be pushed to the plugin repo for
>> >> update any time.
>> >>
>> >> Passing this along to devs who might have enough information now.
>> >>
>> >> Thanks,
>> >> Alex
>> >
>> >
>> >
>> > Thanks for taking care,
>> >
>> > by the way: by copying the gdal algorithms from processing 2.10.1 to the
>> > 2.9.3 folder (.qgis2/python/plugins/processing/algs/gdal), I gained
>> access
>> > to the new GDAL dissolve polygons :)
>> >
>> > Unfortunately, the model from before (GRASS6) didn't work anymore, and
>> all
>> > attempts to adjust it via diff of a test model failed. So reworking my
>> model
>> > (for the 10th time or so) in Ubuntu 2.8.3 from ubuntugis-ltr with
>> working
>> > GRASS7, SAGA and everything and a partially upgraded Processing 2.9.3
>> >
>> > I'm on my way ... finally .. hopefully ...
>> >
>> > Bernd
>> >
>> >
>> >
>> >> On 08/02/2015 03:07 PM, Bernd Vogelgesang wrote:
>> >>>
>> >>> Am 02.08.2015, 22:44 Uhr, schrieb Alex Mandel
>> >>> :
>> >>>
>>  After some brief testing, my OSGeoLive 8.5 VM with QGIS 2.6 and
>>  Processing 2.9.3, GRASS 7 works.
>> 
>>  My QGIS 2.8, GRASS 6/7, Processing 2.10.1 does not.
>> >>>
>> >>>
>> >>> Gave Windows another try: Removed everything, and installed the simple
>> >>> install OSGEO4W setup.
>> >>> QGIS 2.10.1 with Processing 2.10.1 and GRASS 6 working.
>> >>>
>> >>> switched back to Ubuntu, cause of a bug in the modeler version of GDAL
>> >>> Dissolve Polygons (which is crucial for me).
>> >>> https://hub.qgis.org/issues/13174
>> >>>
>> >>> Ubuntu: Now that I installed 2.8 with the debian repository only (so
>> >>> without ubuntis depencies), my GRASS 6 works (sorted out another
>> error,
>> >>> that GRASS takes a column name "OR" from shape as an sql-command or
>> >>> sth), update to Processing 2.10.1 worked as well.
>> >>>
>> >>> The drawback, no SAGA, which might come handy cause the now available
>> >>> algos do not really do what I expect ;)
>> >>>
>> >>> I think the problem is within Processing in combination with the
>> >>> packaging:
>> >>> When e.g. I install QGIS 2.8 with ubuntugis-ltr dependencies (where
>> >>> nobody on the install page claims I shouldn't do), GRASS7 and the
>> >>> modeler are working, but Processing version is 2.6. Updating
>> Processing
>> >>> to current Processing 2.10.1 (as recommended) seems to work.
>> >>> (Besides that v.clean in the modeler only returns a polygon layer from
>> >>> an polygon input, if I also set an output name for the error layer,
>> >>> otherwise I get an empty line shape)
>> >>>
>> >>> But: The next time I run QGIS and want to run an GRASS algo: Missing
>> >>> depencies
>> >>>
>> >>> I can now replace Processing 2.10.1 with the second latest 2.9.3 from
>> >>> https://plugins.qgis.org/plugins/processing/version/2.9.3/
>> >>> and there v.clean does what it should in Processing AND modeler.
>> >>>
>> >>> But: Now I do not have GDAL Dissolve polygons which is in Processing
>> >>> 2.10.1. Well, I could switch back to Windows QGIS 2.10, but, grr,
>> there
>> >>> is the bug in this algo ...
>> >>>
>> >>> You see, I'm trapped.
>> >>>
>>

Re: [Qgis-user] Issues to building QGIS-2.10.1 on linux using Qt5.5

[Spartucus]

thanks for replying.

It is hard to use yum in NeoKylin, because its yum repo is incomplete, I
tried before.

And the Qt5 thing is necessary. Because I  use QGIS  for developing in a
large system, other parts of system are built of QT5, so it is nicer to
building QGIS using Qt5 rather than Qt4. And I tried Qt4 in NeoKylin before,
the QtWebkit part of Qt4 is missing no matter how hard I work on it. So Qt4
miss some modules in Linux and QGIS's building fails because of that.

And the link of log is  here   .



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Issues-to-building-QGIS-2-10-1-on-linux-using-Qt5-5-tp5219515p5219615.html
Sent from the Quantum GIS - User mailing list archive at Nabble.com.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user