Re: [QGIS-Developer] QGIS Processing "R" Provider -- 3.x beta available

[Alex Mandel]

Nyall,

I can confirm the plugin loads without error on QGIS 3.4.1, Ubuntu 16.04
I'll need to find an R script or two to test with.

Thanks this is very appreciated,
Alex

On 11/15/18 14:34, Nyall Dawson wrote:
> Hi lists,
> 
> Just a quick announcement that the Processing provider for R scripts
> in QGIS, which was dropped for QGIS 3.0, is now available as a beta
> for QGIS 3.4. It's now published as a standalone plugin which must be
> manually installed (together with manual installation of the
> underlying R software!).
> 
> This is a pre-release beta version only -- the script syntax may
> change in the final release, so be warned that you may need to update
> scripts as a result. But the good news is that this should be 100%
> compatible with Processing R scripts from 2.x, with no change required
> to the scripts!
> 
> To reflect its beta status, the plugin is currently only available via
> manual download from GitHub, and isn't (yet) available via the
> standard QGIS plugin repository. To install, download the zip release
> from https://github.com/north-road/qgis-processing-r/releases/tag/v0.0.2,
> and then install via the Plugins -> Manage and Install Plugins >
> Install from ZIP tab. After the plugin is installed you'll need to
> enable the provider via the Settings > Options > Processing >
> Providers > R > Activate checkbox.
> 
> Testing feedback is sought and very welcome -- just file issues on
> https://github.com/north-road/qgis-processing-r/issues with a detailed
> description of any issues you encounter.
> 
> This release was made possible thanks to a funding grant by QGIS.org.
> 
> Regards,
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin repository latency

[Alex Mandel]

On 06/06/2016 08:05 AM, Alessandro Pasotti wrote:
> 2016-06-06 16:50 GMT+02:00 Matthias Kuhn :
> 
>> Thanks a lot.
>>
>> Did someone look into gzip as well? This reduces the download size from 1M
>> to 100K, a noticeable performance improvement.
>>
> 
> I think it is already configured.
> 
> 

Not necessarily if the web server is applying the the gzip the savings
is only in the transfer, after a delay on the server to compress. Also
note this may not be a good idea if we want to move to https due to a
known flaw in some web servers where gzip makes secret keys predictable.

When you made the cache, did you put the cached copy in RAM? Using
something like memcached here might make sense. The other easy fix when
available (might not be on this particular machine) is a to put the
cache on solid state disks.

I've also been thinking that at some point the plugins lookup and
downloads should be mirrored and load balanced for performance. Note
just the download aspect, I think running the website/upload out of one
place works fine. So just some sort of backend rsync cron could do.

Thanks,
Alex

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Different GeoJson results from QgsVectorFileWriter.writeAsVectorFormat() on different systems

[Alex Mandel]

On 04/20/2016 09:02 AM, Even Rouault wrote:
> Le mercredi 20 avril 2016 17:37:21, Tom Chadwin a écrit :
>> My system (QGIS 2.14.1 Win7x64):
>>
>> { "type": "Feature", "properties": { "ID": "1" }, "geometry": { "type":
>> "Point", "coordinates": [ -162.97528075057517, 67.562080385426 ] } }
>>
>> Travis (QGIS ?2.8.?, Ubuntu Trusty):
>>
>> { "type": "Feature", "properties": { "ID": 1.00 }, "geometry": {
>> "type": "Point", "coordinates": [ -162.975280750575166, 67.562080385426 ]
>> } }
>>
>> The ID field in QGIS says it is:
>>
>> Type: qlonglong
>> Type name: Integer64
>> Length: 10
>> Precision: 0
>>
>> What could cause one system to export as an int delimited by quotes, and
>> the other to generate 6 decimal places, but not delimit with quotes?
>>
>>
> 
> Answer is there :-)
> https://github.com/qgis/QGIS/blob/master/src/core/qgsvectorfilewriter.cpp#L364
> 

Ah so you're saying it's the GDAL version, Windows being 2.0+ and Linux
being likely 1.11.x?

Thanks,
Alex
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Different GeoJson results from QgsVectorFileWriter.writeAsVectorFormat() on different systems

[Alex Mandel]

On 04/20/2016 08:37 AM, Tom Chadwin wrote:
> My system (QGIS 2.14.1 Win7x64):
> 
> { "type": "Feature", "properties": { "ID": "1" }, "geometry": { "type":
> "Point", "coordinates": [ -162.97528075057517, 67.562080385426 ] } }
> 
> Travis (QGIS ?2.8.?, Ubuntu Trusty):
> 
> { "type": "Feature", "properties": { "ID": 1.00 }, "geometry": { "type":
> "Point", "coordinates": [ -162.975280750575166, 67.562080385426 ] } }
> 
> The ID field in QGIS says it is:
> 
> Type: qlonglong
> Type name: Integer64
> Length: 10
> Precision: 0
> 
> What could cause one system to export as an int delimited by quotes, and the
> other to generate 6 decimal places, but not delimit with quotes?
> 
> 
>

Seems one system (Windows) treated it as a string not a number. Could
this be locale related?

Thanks,
Alex

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Which menu to put LiteratureMapper (New) Plugin in?

[Alex Mandel]

We're about to upload a new plugin. Before we do, we wanted to ask
people's opinion on which menu to add it to.

In short it's a plugin that works with an online Zotero bibliography to
georeference literature in a way that lets you create web maps (embeds
geojson).

For more details see:
http://micheletobias.github.io/maps/LiteratureMapper.html

Any opinions on best placement?

Web seemed like a possible location but might be hard for users to
realize that's where it's filed.

It just occurred to me that it would be really slick if the plugin
manager told you which menu the plugin shows up under.

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

Re: [Qgis-developer] Certificate update QGIS servers

[Alex Mandel]

On 08/06/2015 09:51 AM, Alex Mandel wrote:
> On 08/06/2015 03:29 AM, Richard Duivenvoorde wrote:
>> Hi,
>>
>> FYI we updated the certificates for
>> hub.qgis.org
>> plugins.qgis.org
>>
>> While I was pretty sure we scored an A on
>> https://www.ssllabs.com/ssltest/index.html
>>
>> Now hub (on osgeo) scores a C, while plugins (qgis2) still scores an A...
>> both apache servers share the same config (but different versions of Apache)
>>
> 
> Are you sure it's the same config? It might be just a few extra ciphers
> in the SSL config that should be disabled for known security reasons.
> The SSL lab test usually tells you exactly why you scored low.
> 

Looking at the report I am correct, it's just some tweaks to be made to
the SSL config on apache. The newer sites don't have this issue because
the defaults on newer Debian versions are safer.

"
This server supports weak Diffie-Hellman (DH) key exchange parameters.
Grade capped to B.   MORE INFO »
The server supports only older protocols, but not the current best TLS
1.2. Grade capped to C.  MORE INFO »
The server does not support Forward Secrecy with the reference browsers.
 MORE INFO »
"


I'll try to make some fixes to it this weekend.

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

Re: [Qgis-developer] Certificate update QGIS servers

[Alex Mandel]

On 08/06/2015 03:29 AM, Richard Duivenvoorde wrote:
> Hi,
> 
> FYI we updated the certificates for
> hub.qgis.org
> plugins.qgis.org
> 
> While I was pretty sure we scored an A on
> https://www.ssllabs.com/ssltest/index.html
> 
> Now hub (on osgeo) scores a C, while plugins (qgis2) still scores an A...
> both apache servers share the same config (but different versions of Apache)
> 

Are you sure it's the same config? It might be just a few extra ciphers
in the SSL config that should be disabled for known security reasons.
The SSL lab test usually tells you exactly why you scored low.

> I think we need to make a plan for migrating to a newer Debian/Trac
> version...
> 

The new OSGeo6 machine is now operational. If you would like to provide
a docker instance, or want a fresh VM we can now accommodate. I'd think
it might also be good to load balance plugins requests that come from
QGIS across multiple servers to increase the reliability of getting and
checking plugins (2 frontends, 1 db, or just mirror some directories
where the plugin files are actually stored and not mirror any super
dynamic part).

Thanks,
Alex

> Regards,
> 
> Richard Duivenvoorde
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

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

[Alex Mandel]

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

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.
> 
> Thanx for you attention
> Bernd
> 
> 
> 
>>
>> Both are Ubuntu 14.04 based.
>>
>> I'm not sure if this is a bug in Processing, or in packaging. I recall
>> in OSGeoLive 8.5 that we had custom packages with a patch. Note, you can
>> get those versions for your Ubuntu system from
>> https://launchpad.net/~osgeolive/+archive/ubuntu/release-8.5
>>
>> We freeze a copy of the working versions in our own ppa for long term
>> history.
>>
>> Thanks,
>> Alex
>>
>>
>> On 2015-08-02 03:32, Bernd Vogelgesang wrote:
>>> Hi Alex,
>>>
>>> Am 02.08.2015, 01:22 Uhr, schrieb Alex Mandel
>>> :
>>>
>>>> It's not a Windows/Ubuntu/Mac/OS thing, it's a QGIS + GRASS version
>>>> change thing.
>>>>
>>>> Please indicate which version of QGIS and GRASS you are trying to get
>>>> working.
>>>
>>> Actually I do not mind any more what version I would like to get
>>> working. I would have preferred the 2.8-LTR branch with no-matter-what
>>> GRASS version.
>>>
>>> I just would like to be able to finish my project, and there is
>>> unfortunately no alternative to the GRASS algos in my model.
>>>
>>>> QGIS 2.6 and older works with GRASS 6, 2.8+ sometimes is built to work
>>>> with GRASS 7 (though possibly also with GRASS 6).
>>>
>>> Mhm, reverting to 2.6 ... Lets see if this still possible at all ...
>>>
>>>> If you want a guaranteed working setup ASAP download a copy of OSGeo
>>>> Live Virtual Machine, we made sure that it works in that.
>>>> http://live.osgeo.org
>>>
>>> Will give it a try. Download will take another 1.5 hours ...
>>>
>>> So does that mean that even your do not have a working GRASS in a recent
>>> QGIS by "normal" means but the osgeo VM?
>>>
>>>
>>>>
>>>> Thanks,
>>>> Alex
>>>
>>> Cheers
>>> Bernd
>>>
>>>>
>>>> On 2015-08-01 14:41, Bernd Vogelgesang wrote:
>>>>> Hi guys,
>>>>> is it just bad karma, that I seem not to able to get a working
>>>>> GRASS in
>>>>> QGIS? Or did I miss the big advertisement "GRASS out of order"
>&g

Re: [Qgis-developer] Query performance in QGIS using psycopg2

[Alex Mandel]

Start by using Explain SELECT ...
And compare to see if the query planner is running the same way.

Thanks,
Alex

On 05/12/2015 02:33 AM, McDonaldR wrote:
> Hello list
> 
> I have a question about how QGIS (specifically the pgRouting Layer plugin) 
> uses psycopg2 and a connection to PostgreSQL to run a query and return a 
> result.
> 
> I am using pgRouting with Ordnance Survey's Open Roads network for the UK.  
> It is a large network with over 3 million links and 2.6 million nodes.   
> Using the pgRouting Layer plugin in QGIS 2.6.1 and 2.8.2 to interact with the 
> network.  It is really slow to solve routes ~ 1m20s per solution.  I am also 
> using PgAdmin3 to run the same queries against the same network and they are 
> also slow (~1m20s) but I can speed them up using a bounding box in the query 
> (in some cases by 400x!).  In the pgRouting Layer plugin I have updated the 
> djikstra.py file to use the query with a bounding box but the result is still 
> returned in ~ 1m20s.  Running the same query in the SQL pane in DB Manager 
> returns the result in ~ 100ms.
> 
> So, I guess the question is "Is psycopg2 (or python) the bottleneck in 
> running queries in the pgRouting Layer plugin?" and maybe a secondary 
> question is "how does DB Manager connect to the database and run the query so 
> quickly?"
> 
> The queries
> 
> Without bounding box ~ 1m20s
> SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_dijkstra('
> SELECT gid AS id,
>  source::integer,
>  target::integer,
>  cost_len::double precision AS cost,
>  rcost_len::double precision AS reverse_cost
> FROM or_network',
>1190869, 586365, false, true);
> 
> With a bounding box ~ 200ms
> SELECT seq, id1 AS node, id2 AS edge, cost FROM pgr_dijkstra('
> SELECT gid AS id,
>  source::integer,
>  target::integer,
>  cost_len::double precision AS cost,
>  rcost_len::double precision AS reverse_cost
> FROM or_network
> WHERE geometry && ST_Expand(
> (SELECT ST_Collect(the_geom) FROM 
> or_network_vertices_pgr WHERE id IN (1190869, 586365)),2000)',
> 1190869, 586365, false, true);
> 
> Thanks in advance
> 
> Ross
> 
> 
> Ross McDonald | GIS Data Coordinator | Resources Department, IT Division | 
> Angus Council, Angus House, Orchardbank Business Park, Forfar, DD8 1AT
> T: 01307 476419 | F: 01307 476401 | E: 
> mcdona...@angus.gov.uk
> 
> 
> 
> This message is strictly confidential. If you have received this in error, 
> please inform the sender and remove it from your system. If received in error 
> you may not copy, print, forward or use it or any attachment in any way. This 
> message is not capable of creating a legal contract or a binding 
> representation and does not represent the views of Angus Council. Emails may 
> be monitored for security and network management reasons. Messages containing 
> inappropriate content may be intercepted. Angus Council does not accept any 
> liability for any harm that may be caused to the recipient system or data on 
> it by this message or any attachment.
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Running QGIS and plugins on cluster

[Alex Mandel]

On 04/14/2015 06:43 AM, Alexander Bruy wrote:
> Hi,
> 
> it is not a secret that running analysis tasks on a large datasets
> may be time consuming. One of the possible solutions if to run
> analysis in parallel.
> 
> So I'm wondering is it possible and makes sense to run QGIS plugin
> on cluster to speed-up analysis. For example using MPI (through pypar
> or mpi4py)? Anyone has such experience?
> 

No reason you can't do something with MPI. Though that is a more
complicated cluster setup.

Plenty of work has been done in the past on using GRASS in a cluster
http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs

If you have access to a cluster then the answer might depend on what
kind of compute cluster. I would actually try to abstract it behind
something like a WPS server and have QGIS just talk to the WPS server
that then uses GRASS, SAGA, Python(Shapely etc) or whatever cluster
computations you want in the background.

Also consider what you might actually want on a single compute node is
simply local parallel processing using the built in python multi core
support tools. Keep in mind that splitting jobs in a map/reduce way only
works for some types of computation.

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

Re: [Qgis-developer] Transfer plugin ownership

[Alex Mandel]

On 03/29/2015 04:01 PM, Chris Crook wrote:
> Hi
> 
> Could someone remind me who to contact about transferring ownership of a 
> plugin on plugins.qgis.org please?
> 
> Thanks
> Chris
> 
>
This list generally works. If you have permission from the existing
author just forward that. If you're adopting an abandoned one state
that. Also mention your id.

I suppose Richard Duivenvoorde is officially in charge of the web
presence but all the admins read this list.

Thanks,
Alex

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

Re: [Qgis-developer] Project Idea For GSoc

[Alex Mandel]

Nancy,

We did see your 1st email message, I suspect the slow response is due to
the weekend and many people not having an opinion on the topic.

Looking around a little I would say the focus of the project should be
to get existing pansharpen tools into QGIS. Looking in the toolbox Orfeo
methods are already available. However i.pansharpen from GRASS does not
appear to be there. Also there's this great set of gdal scripts from
https://github.com/gina-alaska/dans-gdal-scripts that includes a
pansharpen (not sure which algorithms). Having all of these in the
Processing toolbox in QGIS would be really nice.

If you really want to work on additional algorithms not already in those
tools I would suggest you work with either the GDAL or GRASS projects
directly. Implementing in those tools leads to them being available in
QGIS and likely being more maintainable and useful as they can be then
also be scripted, which makes sense when you have huge amounts of images
to fix.

Thanks,
Alex


On 03/14/2015 11:20 AM, Nancy wrote:
> Hi all,
> 
> My name is Nancy. I am a dual degree Computer Science student at IIIT-H and 
> pursuing Masters in the field of Spatial Informatics.
> 
> I have been an avid user of QGIS for the past year as my interests lies in 
> it.I would like to introduce to you this project idea for GSoC 2015, in which 
> I am interested. 
> 
> The idea of the project is Pan Sharpening in QGIS.The main idea of pan 
> sharpening is to combine registered high spatial resolution panchromatic 
> (pan) and lower spatial resolution multispectral imagery to synthesize higher 
> resolution multispectral imagery.The degree of misregistration between bands 
> and the correlation of intensity values are key factors in generating 
> radiometrically accurate and visually crisp output images. 
> 
> There are many algorithm for Pan Sharpening :- 
> 1>Projective
> 2>Multiplicative
> 3>High Pass Filter
> 4>Hue, Saturation, Intensity
> 
> But I would like to work on Projective method as it provides better results 
> in terms of preserving the color of the multispectral image. The other 
> algorithms all cause a color shift of one type or another from the original 
> multispectral image. 
> 
> There are two components to the projective pan sharpening algorithm. The 
> first component determines the linear radiometric relationship between the 
> pan and multispectral bands and the second processes pixels to produce the 
> sharpened product.
> 
> Benefit of this project will be that by increasing the spatial resolution of 
> the high spectral resolution multispectral image,many other image processing 
> tasks which are performed on the multispectral image are enhanced.We will be 
> able get clear boundaries for clear extraction of features from the image and 
> better vectorisation.
> 
> We have this functionality in GRASS and other softwares so we are trying to 
> implement it in QGIS.
> 
> Regards
> Nancy
> IIIT-Hyderabad.


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

Re: [Qgis-developer] Upgrading qgis

[Alex Mandel]

On 02/22/2015 11:42 PM, Paolo Cavallini wrote:
> Hi all,
> when upgrading qgis from 2.7 to 2.8 on Debian sid, python-qgis is not
> upgraded automatically, so python support is disabled.
> All the best.
> 
This seems to be a perpetually unresolved bug. Had this same issue
upgrading to 2.6 on ubuntu systems. I'm not sure what needs to change in
the Debian control file to do this right.

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

Re: [Qgis-developer] Python 2.6 and QGIS version

[Alex Mandel]

On 02/17/2015 12:01 PM, Andre Joost wrote:
> Am 17.02.2015 um 20:10 schrieb Alex Mandel:
>> On 02/17/2015 10:15 AM, Marc Ducobu wrote:
>>>
>>>
>>>> Am 17.02.2015 um 16:37 schrieb Marc Ducobu:
>>>>> /  Hello QGIS devs,
>>>> />/
>>>> />/  I think that QGIS contains it own python version. My QGIS 2.6 has
>>>> the
>>>> />/  2.7.9 version of python. Which version of QGIS has the 2.6
>>>> version of
>>>> />/  python ?
>>>> /
>>>> QGIS 1.8 Lisboa is the oldest version I have running, and that had
>>>> already Python 2.7. I guess you would not like to work with versions
>>>> older than that.
>>>>
>>>> Greetings,
>>>> André Joost
>>> Thanks a lot for the response.
>>>
>>> This is very strange because I saw on a mac a QGIS 2.0 with python 2.6
>>> in the QGIS console. Maybe it depends on which version of python is
>>> installed during the installation ?
>>>
>>> Greetings,
>>>
>>> Marc
>>>
>>
>> QGIS on Mac does not contain it's own python. It uses the system default
>> python. Only on Windows do we include python as the OS provides none.
>>
>> That said, is the real question, at which version did we move to only
>> Python 2.7+ working?
>>
> According to this ticket: https://trac.osgeo.org/osgeo4w/ticket/219
> Osgeo4w moved from Python 2.5 to 2.7 three years ago.
> 
> https://trac.osgeo.org/osgeo4w/wiki/RequiresPython mentiones QGIS 1.7.3
> as stable and 1.8.0 as dev version at that time.
> 
> HTH,
> André Joost

That does not mean it won't compile against 2.6 though. The question is
when was the Python API modified in a way that 2.6 no longer works.
Finding out the last release for a Mac OS that had 2.6 is probably the
best indicator.

http://www.kyngchaos.com/software/archive

Makes me think OS X 10.6 (I think 10.7 had python 2.7), so any version
of QGIS for 10.6 probably still worked with python 2.6.

Or a dev who knows the Python api can tell us when and if python 2.6
compatibility was broken.

Thanks,
Alex

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

Re: [Qgis-developer] Python 2.6 and QGIS version

[Alex Mandel]

On 02/17/2015 10:15 AM, Marc Ducobu wrote:
> 
> 
>> Am 17.02.2015 um 16:37 schrieb Marc Ducobu:
>> >/  Hello QGIS devs,
>> />/
>> />/  I think that QGIS contains it own python version. My QGIS 2.6 has
>> the
>> />/  2.7.9 version of python. Which version of QGIS has the 2.6
>> version of
>> />/  python ?
>> /
>> QGIS 1.8 Lisboa is the oldest version I have running, and that had
>> already Python 2.7. I guess you would not like to work with versions
>> older than that.
>>
>> Greetings,
>> André Joost
> Thanks a lot for the response.
> 
> This is very strange because I saw on a mac a QGIS 2.0 with python 2.6
> in the QGIS console. Maybe it depends on which version of python is
> installed during the installation ?
> 
> Greetings,
> 
> Marc
> 

QGIS on Mac does not contain it's own python. It uses the system default
python. Only on Windows do we include python as the OS provides none.

That said, is the real question, at which version did we move to only
Python 2.7+ working?

Thanks,
Alex

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

Re: [Qgis-developer] hub.qgis under heavy load?

[Alex Mandel]

Tags are an oversimplification, as you have to use them for area or
subareas topic as well as severity and status.

Can you search Github's issues for tags on topic rendering, of severity
blocker, against milestone 2.8, that are open?

There's an API right? Maybe we build a custom search tool to github issues?


No idea if Redmine is the issue, I have never run a Redmine with this
much load. It was running well last year after a Ruby upgrade but not
sure if anyone has upgraded Redmine itself.


As for the hardware story, OSGeo is now looking at buying a new machine
to replace the one QGIS Hub is currently on. QGIS' input on this buy
would be useful, and we could even beef it up if QGIS wants to help out
financially. The likely setup will be software raid5 and docker,
learning from previous issues.
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014#Hardware

Also there's discussion of implementing GitLab on the new hardware,
which is very similar to Github but would allow OSGeo Logins and Github
logins.

PS: there are a couple of pure Django Issue trackers out there. No VCS
integrated but that doesn't matter if the code is on Github.

Thanks,
Alex

On 02/12/2015 05:23 AM, Denis Rouzaud wrote:
> I agree that Github is easier and faster to use than our current Redmine.
> I find the approach in Redmine over-engineered.
> Searching/filtering is indeed the worst.
> 
> What feature in Redmine would we loose (which could not be replaced by
> tags) in Github?
> 
> 
> On 12.02.2015 14:08, Paolo Cavallini wrote:
>> Il 12/02/2015 13:03, Jürgen E. Fischer ha scritto:
>>
>>> Another thing nice to know would be if those issues would go away if
>>> we move
>>> redmine to our server (but we might not be able to see the issues in
>>> a test
>>> setup without doing a full switch).
>>>
>>> But I haven't worked with github tracking either.  My guess is that
>>> redmine is
>>> more sophisticated.  Keeping it in our hand is/could looks like a
>>> plus to me -
>>> and also would avoid migration.
>> I may add, on the other hand, that search in Redmine is currently rather
>> ugly.
>> BTW, do we really need all these sophisticated features?
>> All the best.
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

[Qgis-developer] Browser tab crashes QGIS

[Alex Mandel]

Not sure if anyone else has noticed this.
QGIS 2.6.x on Ubuntu 14.04

If you click the Browser tab as your 1st click inside a fresh run of
QGIS it crashes. Click anything else and then Browser and it's fine.

I've gotten it to work on several machines.

I'm not sure it's in master, but someone should probably check.

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

Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1

[Alex Mandel]

Right, python 3 has been around long enough the much of the python world
has finally caught up. For those that can't get python 3 they'll just
need to use the last QGIS 2.x release a little longer (there are still
people running 1.8). Please file a ticket now with OSGeo4w to start
preparing to include it, since there will be a time when both python 2
and 3 will be installed side-by-side.

I'll suggest a Google Summer of Code proposal/call for student interns
in OSGeo ICA labs for a project on porting plugins to python 3, and/or
providing tools to plugin authors to help them port.

Thanks,
Alex

On 01/17/2015 10:12 AM, Werner Macho wrote:
> Oh - sorry - I did not think of that but:
> 
> Numpy Scipy
> http://www.scipy.org/scipylib/faq.html#do-numpy-and-scipy-support-python-3-x
> 
> matplotlib
> http://matplotlib.org/users/whats_new.html
> 
> I guess unless you use a _very_ specific module you are safe.
> 
> At least I could not find any module I use which is not available in python3
> 
> regards
> Werner
> 
> On Sat, Jan 17, 2015 at 7:06 PM, Anita Graser  wrote:
>> Thanks Werner,
>> I was actually thinking of dependencies such as Numpy, Matplotlib, and
>> other Python packages and whether they will be available for Python 3.
>> Best wishes,
>> Anita
>>
>> On Sat, Jan 17, 2015 at 6:02 PM, Werner Macho  wrote:
>>> Hi!
>>> Depending on the plugin there will surely be a lot of which will not
>>> operate after an update to python3.
>>> And depending on the developer they will be updated or abandoned.
>>> Some will be easy to update - some will be harder to update.
>>>
>>> But you are right - if the plugin will NOT be updated we would "loose"
>>> it for python3.
>>>
>>> regards
>>> Werner
>>>
>>> On Sat, Jan 17, 2015 at 5:28 PM, Anita Graser  wrote:
 Would the switch to Python 3 mean that we would loose access to all
 the useful Python modules which don't update?

 Thanks for taking the time to try clarify the situation!

 Best wishes
 Anita

 On Sat, Jan 17, 2015 at 4:16 PM, Alexander Bruy
  wrote:
> If I'm not wrong, support for Qt5 already added by Matthias.
> Regarding Python 3, I'm not sure about time plan, as in this
> case we depends on OSGeo4W update for Windows platform.
>
> 2015-01-17 16:27 GMT+02:00 Anita Graser :
>> On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy
>>  wrote:
>>> Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5,
>>> or we will have QGIS 4 very soon after QGIS 3
>>
>> Can you estimate a realistic time plan for these switches to new Python 
>> and Qt?
>>
>> Best wishes,
>> Anita
>
>
>
> --
> Alexander Bruy
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Can qgis be started with python disabled ?

[Alex Mandel]

On 12/17/2014 11:48 AM, Alex Mandel wrote:
> On 12/16/2014 10:30 AM, Sandro Santilli wrote:
>> Can I start qgis with no python support even if it is compiled in ?
>> I'd use it to reduce load while running under valgrind...
>>
>> To the same extent, can it be started with no plugins from an environment
>> variable or similar?
>>
>> --strk; 
>>
>>  ()  ASCII ribbon campaign  --  Keep it simple !
>>  /\  http://strk.keybit.net/rants/ascii_mails.txt  
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> 
> qgis --no-plugins
> 
> Not exactly no python, but should load faster.
> 

--noplugins

Sorry typo no - in the middle

-Alex

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

Re: [Qgis-developer] Can qgis be started with python disabled ?

[Alex Mandel]

On 12/16/2014 10:30 AM, Sandro Santilli wrote:
> Can I start qgis with no python support even if it is compiled in ?
> I'd use it to reduce load while running under valgrind...
> 
> To the same extent, can it be started with no plugins from an environment
> variable or similar?
> 
> --strk; 
> 
>  ()  ASCII ribbon campaign  --  Keep it simple !
>  /\  http://strk.keybit.net/rants/ascii_mails.txt  
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

qgis --no-plugins

Not exactly no python, but should load faster.

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

Re: [Qgis-developer] hub issues?

[Alex Mandel]

On 12/15/2014 11:11 PM, Paolo Cavallini wrote:
> Hi all. I'm told redmine temporarily throws an error Application 
> error Rails application failed to start properly (now it's ok, 
> however). BTW, do we have any plan to change the bug tracking 
> system? After years of use I still find it rather cumbersome, and 
> especially the search is inefficient, and encourages filing 
> duplicate issues. I believe this discourages newcomers from filing
>  tickets, and adding info to the existing ones. Thougths? All the 
> best.


Change it to what?
Upgrading and perhaps tacking on Solr for searching?

Generally I think these discussions require someone having a
suggestion for something that will work better.

If you can get a screenshot or paste when the Rails error comes up
that would be helpful. I upgraded the part that connects apache and
ruby last year (Phusion) and it's behaved much better since then.

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

Re: [Qgis-developer] Reading a new type of file natively in QGIS

[Alex Mandel]

Yes, that's not foreign to me.

I think for QGIS you would likely want to undo the matrix in to long
format rows.
Dest, Orig, Value

With data in that format in a db it would work fine to query out and
display the data in various ways. Also Dest and Origin could then be
joined to Points and you could do things like give me all end points
from Dest A where dist or time is less than x miles or 1 hour.

I could chat with my colleagues who do more transportation analysis to
see what they think.

Without understanding how you want to actually use the data it's hard to
know where to start. But the format you have is familiar to many of us
as a Distance Matrix (though the value can be anything).

Perhaps a plugin to transform it on the fly using Numpy?

Thanks,
Alex

On 12/12/2014 04:14 PM, Pedro Camargo wrote:
> Hi Alex,
>  This matrix is a transportation demand matrix, where the
> indices represent the node of origin and the node of destination in the
> network. They could be interpreted as vectors, I think, if you think in the
> sense that both the origin and the destination do have coordinates, but
> representing them as lines do not make any physical sense.
> 
>Did my explanation help at all?
> 
> THanks,
> 
> Pedro
> 
> On Fri, Dec 12, 2014 at 2:46 PM, Alex Mandel 
> wrote:
> 
>> On 12/11/2014 08:21 PM, Pedro Camargo wrote:
>>> Hi group,
>>> During my discussions with people from the transportation
>>> modeling world, some people pointed out a few features that would be nice
>>> to have in order to use QGIS more intensively by our group.
>>>
>>> The most important issue, however, was the possibility of
>>> open matrices in a very efficient way (reading matrices that are
>>> 10.000x10.000 in dbf format means reading 10e8 lines, which takes a VERY
>>> long time and defeats the purpose of using QGIS for some things.
>>>
>>> A very good alternative would be using an open source
>>> format from the project "open model data"  (
>>> https://sites.google.com/site/openmodeldata/) which is based on HDF5.
>>>
>>> I see that QGIS can already open raster data in HDF5
>>> format, but in this case, the data would be a matrix with indices and
>> all.
>>>
>>>I regret to say that my programming skills, specially in
>>> C/C++ are not nearly good enough to evaluate the effort that it would
>> take
>>> include such support and have, inside QGIS, a possibility of viewing such
>>> matrices, which would allow people from the transportation world (and I
>> am
>>> the first volunteer) to develop the necessary plugins to manipulate the
>>> matrices and generate the commonly used statistics.
>>>
>>>   Can anybody tell me what type of effort it would take and
>> if
>>> it is at all of interest of the QGIS community?
>>>
>>> Thanks a lot,
>>>
>>> Pedro
>>
>> This is more a question for GDAL/OGR I think.
>> How do your matrix values relate to map objects? Is your matrix a vector
>> or a raster?
>> What do you want to do with the data inside QGIS?
>>
>> Thanks,
>> Alex
>>
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Reading a new type of file natively in QGIS

[Alex Mandel]

On 12/11/2014 08:21 PM, Pedro Camargo wrote:
> Hi group,
> During my discussions with people from the transportation
> modeling world, some people pointed out a few features that would be nice
> to have in order to use QGIS more intensively by our group.
> 
> The most important issue, however, was the possibility of
> open matrices in a very efficient way (reading matrices that are
> 10.000x10.000 in dbf format means reading 10e8 lines, which takes a VERY
> long time and defeats the purpose of using QGIS for some things.
> 
> A very good alternative would be using an open source
> format from the project "open model data"  (
> https://sites.google.com/site/openmodeldata/) which is based on HDF5.
> 
> I see that QGIS can already open raster data in HDF5
> format, but in this case, the data would be a matrix with indices and all.
> 
>I regret to say that my programming skills, specially in
> C/C++ are not nearly good enough to evaluate the effort that it would take
> include such support and have, inside QGIS, a possibility of viewing such
> matrices, which would allow people from the transportation world (and I am
> the first volunteer) to develop the necessary plugins to manipulate the
> matrices and generate the commonly used statistics.
> 
>   Can anybody tell me what type of effort it would take and if
> it is at all of interest of the QGIS community?
> 
> Thanks a lot,
> 
> Pedro

This is more a question for GDAL/OGR I think.
How do your matrix values relate to map objects? Is your matrix a vector
or a raster?
What do you want to do with the data inside QGIS?

Thanks,
Alex

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

Re: [Qgis-developer] Huge TIFF files - problem

[Alex Mandel]

On 12/08/2014 04:39 PM, Giovanni Manghi wrote:
>> Hi,
>> I have got a problem with TIFF files.
>> Today I was performing a rastercalculation ? two smaller files was suddenly 
>> 122 GB ? and my computer ran out of free space.
>> And this afternoon my students georeferenced a jpg, and ended up with 24 GB 
>> map.
>>
>> What am I doing wrong?
> 
> 
> Hi Lene,
> I'm not sure if it is enough to justify such huge output files, but
> most of the tools in the "raster" menu just output always float64
> tiffs, that certainly contribute to make often bigger than the
> necessary. This has been fixed in Processing where most of the gdal
> tools now have an option to choose the type of geotiff for the output.
> 
> cheers
> 

That probably is the answer, not only float64 but no compression.
GeoTiff ideally would be a more appropriate storage based on the inputs
and calculation but also use Deflate or LZW compression. Seems to me a
reasonable default to use one of the lossless compression methods. Not
much to be done about the storage type though other than offer users
options when saving Tiffs where possible.

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

Re: [Qgis-developer] Module dependencies

[Alex Mandel]

On 09/23/2014 08:22 AM, Trevor Wiens wrote:
> I agree with earlier comments that this is largely a distribution problem
> and that automatic functionality creates some risks.
> 
> I posted yesterday about how Windows installs having their own versions of
> python installed makes using tools like pip or easy_install challenging.
> 
> I can see two possible ways forward:
> 1. Use a generic python install rather than installing its own version.
> This way pip and other tools will work fine.
> 2. Provide a tool to execute pip for the QGIS specific version of python
> for Windows installs (I don't know what happens under Max OS)
> 
> It seems to me that option 1 would be the most obvious choice making
> Windows installs similar to Linux installs and simpler to add and remove
> libraries as needed. I think that adding more and more stuff to the OSGeo4W
> install doesn't make sense.
> 

There's a reason OSGeo4w installs it's own Python. Unlike Mac and Linux,
Windows does not ship with Python. There are other common GIS
applications that do ship Python and it often conflicts with OSGeo4w
Python (Version, Compiler, and OSGeo GDAL/OGR namespace). Many python
libraries actually require compiling of C modules, which isn't handled
by pip (binary files have to be in pypi). So in part it's really hard to
rely on the Windows Python if there at all to be the right version, and
multiple versions of Python on Windows fight for the registry entry
(last installed wins). So someone installing Python 3 can easily break
QGIS if relying on system python.

I'll also note that several people have had success using pip within
OSGeo4w. See previous posts on qgis and osgeo4w lists. Making pip easier
to use in OSGeo4w is likely a better choice.

Several of us on IRC have discussed this topic in depth before, at least
in regards to external python deps. My leaning is to just wrap pip
functionality to help users.

As for python plugin deps, I say, only allow deps on core python plugins
and on plugins in the official repo. As is, if someone loads python
code, it can always download whatever from some url using pure python.
Hard to hide it when the code is open and available, but we don't
heavily check it either. On that note, we should also consider moving
the python plugin repo to https.

Thanks,
Alex


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

Re: [Qgis-developer] How can I change status to "Open" in redmine?

[Alex Mandel]

On 09/19/2014 07:55 PM, Nyall Dawson wrote:
> Unless I'm missing something obvious, there doesn't seem to be any way
> to change a report from "Feedback" back to "Open". The only options I
> see in the feedback field are "In Progress" or "Closed". I don't want
> to set issues to "In Progress" if they're not actively being worked
> on, and obviously closing them isn't the right move.
> 
> Is there any way to clear a feedback flag and reset a report back to being 
> open?
> 
> Nyall

I think under the default work flow in Redmine, the answer is no.
However it is customizable. I can make this change if the devs want this.

The workflow settings are per user group by ticket type, ie Developers
can move back to open but not Reporters and only for Bugs not Features,
etc... It can also be fine grained that you can get back to Open status
only from specific other status.

Let me know what the devs want and I'll modify.

Thanks,
Alex

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

Re: [Qgis-developer] Topology for PGD

[Alex Mandel]

On 08/27/2014 10:17 PM, thiruvikrama...@cognizant.com wrote:
> Hi,
> 
>Is it possible to run topology for personal geodatabase instead of 
> shapefiles like in ArcGIS?
> 
> Regards,
> 
> 
> 
> S. Thiruvikraman(449668)
> 


It might be possible with Spatialite, Postgis or GRASS layers.

Thanks,
Alex

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

Re: [Qgis-developer] Attending FOSS4G in Portland?

[Alex Mandel]

I will be there too. When we pick a day/time we should send it to the
QGIS-US mailing list (I can do that) to announce.

Alex

On 08/16/2014 03:28 AM, Horst Düster wrote:
> 
> Hi Larry
> 
> +1 I will attend as well and I'm looking forward to meet you in Portland.
> 
> All the best
> Horst
> 
> Dr. Horst Düster
> Managing Director
> Sourcepole AG - Linux & Open Source Solutions
> Weberstrasse 5, 8004 Zürich, Switzerland
> Tel: +41 (0)44 440 77 11
> Direkt: +41 (0)44 515 67 70
> horst.dues...@sourcepole.ch  http://www.sourcepole.ch
> 
> www.sourcepole.ch/kurse - Das Kursangebot Herbst 2014
> 
> 
> 
> Am 16.08.2014 um 10:26 schrieb Larry Shaffer:
>> Hi,
> 
>> Are you attending FOSS4G in Portland? If so, do developers/users want to
>> get together at some point during the week to discuss QGIS, or maybe just
>> have a beer, etc.?
> 
>> I will be there all week, but have to leave early on Saturday (day of Code
>> Sprint Open).
> 
>> https://2014.foss4g.org/about/calendar/
> 
>> Regards,
> 
>> Larry Shaffer
>> Dakota Cartography
>> Black Hills, South Dakota
> 

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

Re: [Qgis-developer] Grass, QGIS, and Ubuntu 14.04

[Alex Mandel]

On 08/13/2014 07:32 AM, Randal Hale wrote:
> I received an update yesterday and didn't pay attention. I updated the
> second machine today. It seems like I've seen this on the list early
> this week or last - but I've cleaned out email.
> 
> The last ubuntu update breaks the QGIS Grass Plugin - the plugin wants
> grass 6.4.3 but grass has went to 6.4.4 at some point. Since I didn't
> pay great attention I'm not entirely sure if grass upgraded or the
> plugin downgraded. I'm not 100% sure it was this upgrade - but
> regardless this last one finished things breaking (if it started earlier).
> 
> Randy
> 

You did see some emails about this.

The plugin was removed, GRASS upgraded. When a new version of GRASS gets
added to the repo the main QGIS package has to be rebuilt for the
qgis-grass-plugin to match. That hasn't happened yet.

I'm not sure if there's an option with Launchpad to force rebuild of
QGIS whenever GRASS gets uploaded. Forwarding to the Ubuntugis group.

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

Re: [Qgis-developer] save as & symbology

[Alex Mandel]

On 08/02/2014 12:46 PM, Martin Landa wrote:
> Hi all,
> 
> a dialog for 'saving vector layer as' offers possibility to store also
> symbology (feature/symbol layer). I haven't find any output format for
> which this functionality would work (simple point layer with
> categorized symbols). Does it suppose to work and for which formats?
> 
> Thanks for clarification, Martin
> 

I think it works for spatialite and expect it will work for geopackage
when that becomes available.

Does it work for KML that would be the other logical layer type that
might include styling.

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

[Qgis-developer] UI Tab placement

[Alex Mandel]

I was tinkering around with various plugins that have dockable windows
today and realized when you snap 2 content areas into one it makes tabs.
Great, tabs work for switching between things and you don't lose a ton
of space. But then I realized the tabs are counter-intuitively at the
bottom. Not only is this odd in the context of top down UI, but it uses
double the space and the active tab is listed both at the top and the
bottom.

I've heard another common GIS software does tabs this way too, but it
seems at odds with everything else: browswers, email programs, inkscape.
You name it, tabs are at the top.

The extra space is really helpful too, QGIS Browser's biggest limitation
right now seems to be vertical space. You can drag and drop but not if
one folder is off screen. (A different ticket)

If others agree I can file a ticket for this. If it's controversial
could we make it an option to put the tab at the top instead of bottom?

Thanks,
Alex

PS: This is with 2.4, I believe it was the same way in 2.2 but I've only
recently started using a lot of docks (Browser, Processing, etc).
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Navigation toolbar

[Alex Mandel]

On 07/02/2014 12:44 AM, Paolo Cavallini wrote:
> Il 02/07/2014 09:40, Andreas Neumann ha scritto:
> 
>> What do people think?
> 
> I'm in favour of heavily simplifying the GUI. IMHO, the main area where this 
> can
> happen is consolidating all the loading (vector, raster, etc.) buttons in the
> Browser, adding what is missing there.
> All the best.
> 

I'm fine with simplification of the default toolbars, but the tools
should exist to be re-added by the user for customization.

Reason: when you have a specific workflow, making a custom toolbar with
the 5 buttons you need is much faster than digging through menus and
context menus.

In fact I tend to subscribe to the idea that all sensible functions
should be available to be added to a toolbar (there may be some
functions which just don't make any sense on the toolbar)
Without such customization a user would need to create custom plugins or
scripts for seemingly simple functions.


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

Re: [Qgis-developer] Processing: module duplications

[Alex Mandel]

On 06/24/2014 03:21 AM, G. Allegri wrote:
> The tagging system would be great, and in the future we can imagine a
> system to let a user groups algorithms under its own groups (like favorites
> links in the browser).
> 
> Vector and raster menus should at least point to the Processing tool
> window, in case the algorithm is there too...
> 

Yes I agree, the bottom choice in the Vector and Raster menus should be
something like:
More tools and batch... and clicking it opens the Processing window.

Thanks,
Alex

> I still miss the semantics of the "normal" group. This word doesn't mean
> anything to me as a grouping, but I see I'm the only one with this doubt :)
> 
> giovanni
> Il 24/giu/2014 10:10 "Alex Mandel"  ha scritto:
> 
>> I disagree, the Vector and Raster menus are the Basic algorithms.
>> Opening Processing is the Normal+Experimental as Paolo described.
>>
>> Moving everything to Processing just makes it harder to find the simple
>> stuff. Another major GIS project many of us know took this approach and
>> it's extremely annoying to sift through 300 methods when you just want a
>> Clip. 1. Finding and remembering where the tool you want becomes harder,
>> 2. Searching gets challenging with many similarly named things - wait is
>> that the raster clip or the vector clip?
>>
>> Not saying a level filter in the Processing box won't be good, just
>> don't eliminate the simple menus even if it is a duplicate.
>>
>> Thanks,
>> Alex
>>
>> On 06/23/2014 10:06 AM, G. Allegri wrote:
>>> I've given a look to the list of Processing QGIS geoalgorithms and I've
>>> seen that all the tools from fTools seem to be there. I remembered that
>>> someone was missing, but it seems not to be true anymore. I wonder if it
>>> wouldn't be the case to drop fTools algorithms from Vector menu. It would
>>> help in avoiding confusion, imho.
>>>
>>> giovanni
>>>
>>>
>>> 2014-06-23 18:50 GMT+02:00 G. Allegri :
>>>
>>>> Hi Paolo,
>>>> I agree with you, a cleaner organization of Processing tools is
>> advisable
>>>> to reduce the confusion in users.
>>>> It's rather difficult to teach them in a clear way too! :)
>>>>
>>>> IMHO this reorganization should consider also the integration of other
>>>> sparse analysis/processing tools, like the ones under the Vector menu. I
>>>> know it depends on their implemention (and its feasibility in the
>> present
>>>> Processing model), but it's one of the major sources of confusions or
>>>> users. A typical question: why we have the Processing toolbox and a
>> Vector
>>>> menu, where some tools overlap, while other are only available under
>> Vector
>>>> menu, and so not usable inside a Processing model/workflow?
>>>>
>>>> I hope we will find time (=money) to close this gap and, hopefully, have
>>>> most of the analysis tools under the same structure. Well... all but the
>>>> C++ ones :(
>>>>
>>>> giovanni
>>>>
>>>>
>>>> 2014-06-23 18:42 GMT+02:00 Paolo Cavallini :
>>>>
>>>> Hi all.
>>>>> We are thinking about the future of Processing framework. The
>> duplication
>>>>> shown among
>>>>> modules is certainly a good thing, as it allows richer analyses and
>> more
>>>>> control and
>>>>> verification, but can be intimidating even for skilled GIS users.
>>>>> We have been discussed this before, but I came up with the conclusion
>>>>> that a
>>>>> reasonable approach would be to have three levels:
>>>>> * basic - only one choice, no overly complex modules
>>>>> * normal - all well tested modules, minimizing duplication
>>>>> * experimental - out in the wild, all modules.
>>>>> This would improve the user experience, and would require less
>>>>> maintenance by core devs.
>>>>> Of course the selection of the modules for the second category is
>> rather
>>>>> complex, and
>>>>> would require much thinking.
>>>>> Opinions?
>>>>> All the best.
>>>>> --
>>>>> Paolo Cavallini - www.faunalia.eu
>>>>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
>>>>> ___
>>>>> Qgis-developer mailing list
>>>>> Qgis-developer@lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>>
>>>>
>>>
>>
>>
> 

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

Re: [Qgis-developer] Processing: module duplications

[Alex Mandel]

I disagree, the Vector and Raster menus are the Basic algorithms.
Opening Processing is the Normal+Experimental as Paolo described.

Moving everything to Processing just makes it harder to find the simple
stuff. Another major GIS project many of us know took this approach and
it's extremely annoying to sift through 300 methods when you just want a
Clip. 1. Finding and remembering where the tool you want becomes harder,
2. Searching gets challenging with many similarly named things - wait is
that the raster clip or the vector clip?

Not saying a level filter in the Processing box won't be good, just
don't eliminate the simple menus even if it is a duplicate.

Thanks,
Alex

On 06/23/2014 10:06 AM, G. Allegri wrote:
> I've given a look to the list of Processing QGIS geoalgorithms and I've
> seen that all the tools from fTools seem to be there. I remembered that
> someone was missing, but it seems not to be true anymore. I wonder if it
> wouldn't be the case to drop fTools algorithms from Vector menu. It would
> help in avoiding confusion, imho.
> 
> giovanni
> 
> 
> 2014-06-23 18:50 GMT+02:00 G. Allegri :
> 
>> Hi Paolo,
>> I agree with you, a cleaner organization of Processing tools is advisable
>> to reduce the confusion in users.
>> It's rather difficult to teach them in a clear way too! :)
>>
>> IMHO this reorganization should consider also the integration of other
>> sparse analysis/processing tools, like the ones under the Vector menu. I
>> know it depends on their implemention (and its feasibility in the present
>> Processing model), but it's one of the major sources of confusions or
>> users. A typical question: why we have the Processing toolbox and a Vector
>> menu, where some tools overlap, while other are only available under Vector
>> menu, and so not usable inside a Processing model/workflow?
>>
>> I hope we will find time (=money) to close this gap and, hopefully, have
>> most of the analysis tools under the same structure. Well... all but the
>> C++ ones :(
>>
>> giovanni
>>
>>
>> 2014-06-23 18:42 GMT+02:00 Paolo Cavallini :
>>
>> Hi all.
>>> We are thinking about the future of Processing framework. The duplication
>>> shown among
>>> modules is certainly a good thing, as it allows richer analyses and more
>>> control and
>>> verification, but can be intimidating even for skilled GIS users.
>>> We have been discussed this before, but I came up with the conclusion
>>> that a
>>> reasonable approach would be to have three levels:
>>> * basic - only one choice, no overly complex modules
>>> * normal - all well tested modules, minimizing duplication
>>> * experimental - out in the wild, all modules.
>>> This would improve the user experience, and would require less
>>> maintenance by core devs.
>>> Of course the selection of the modules for the second category is rather
>>> complex, and
>>> would require much thinking.
>>> Opinions?
>>> All the best.
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
> 

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

Re: [Qgis-developer] Please give us more time for testing and bugfixing

[Alex Mandel]

On 06/20/2014 01:33 AM, Luca Manganelli wrote:
> On Fri, Jun 20, 2014 at 9:43 AM, Martin Dobias  wrote:
>> I agree with Andreas. Can we postpone the release for a few days?
>> There is still quite steady flow of new bug reports worth addressing.
>> I would suggest max. 7 days (without affecting the schedule of the
>> next release).
> 
> +1. Stability of QGis 2.4 should be a priority of first class. There's
> no hurry to release it soon, since many people will go in holiday in
> these days :-)

Actually there is a reason. This release is timed to meet the OSGeo Live
feature freeze to ensure that 2.4 makes it onto the version for Foss4g.
That includes the version given to attendees and used in some workshops.

That said, while the freeze is the end of this month, as long as the
release is out in early July we should have no issue getting it in.
So yes please take another week to fix more bugs, but hopefully not much
beyond that.

For the record, previous Foss4g version ended up with 1.8 instead of 2.0
which is what we're trying to avoid this time around.

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

Re: [Qgis-developer] How to install PostgreSQL , PostGIS , pgAdmin and QGIS on ubuntu 12.04 LTS

[Alex Mandel]

On 06/21/2014 05:29 AM, otmane yazidi alaoui wrote:
> hello every body
> i have a question
> 
> 
> *What are the most stable version of (PostgreSQL, PostGIS and pgAdmin QGIS)
> and compatible to install on Ubuntu 12.04 LTS*
> 
> thank you a lot
> 


Just use the UbunutGIS unstable PPA, despite it's name.
You'll use stock Postgres/PgAdmin from Ubuntu + whatever the newest
Postgis is 2.1.3 I think.

It's not necessarily more or less stable than other recent combos just
quite easy to install.

Enjoy,
Alex

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

Re: [Qgis-developer] Four month cycle too fast

[Alex Mandel]

On 06/18/2014 11:34 PM, Andreas Neumann wrote:
> Hi,
> 
> At the Swiss QGIS user meeting yesterday there were some discussions
> whether people can cope with the 4 month release schedule and there were
> a number of users who said that this way too fast for them. By the time
> they could properly test a release, the next release is already there.
> 
> Bigger organizations (government organizations and bigger companies)
> have to test a release, package it with IT, test again. They often can't
> install QGIS themselves (don't have installation privileges) but have to
> ask IT to do it for them. This is a time-consuming process.
> 
> I would propose to try a six month release cycle with two months feature
> freeze for testing (see also my previous mail about a request for more
> time for testing/bug fixing). Even a yearly release cycle would be fine,
> if there could be a bug-fix release.
> 
> PostgreSQL has a yearly release cycle and it works really well I think -
> both for them as a project and for us as customers.
> 
> Andreas
> 

Except Postgis does bugfix releases and doesn't cram as many new
features. As discussed in great length in previous threads, it's the
pace of new features that makes bugfix releases somewhat inplausible.

I'm not saying that 4 months is right, what about alternating
stable/experimental like GRASS? So that big orgs only think about every
8 months? Really a big org can decide to skip a release if they want.

Every 6 is also possible, the key is timing, right now is a very good
time to release to be ready for FOSS4g.

Thanks for the feedback, since this the first attempt at the 4 month
it's good to get some information from users.

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

Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

[Alex Mandel]

You are assuming a new deployment and one where QGIS is not used on the
desktop, where some groups may decide to use it for both in order to cut
down on IT staffing requirements. You are also assuming the choice is as
simple as picking a new one, there is plenty of people time involved in
deploying a different strategy and redo-ing all the styling to fit the
new way. Sure QGIS can push to geoserver now but running geosever means
running a JAVA stack. Switching to Mapserver would be more similar with
an apache setup but the QGIS export to Mapserver has long since fallen
into disrepair so now you'd need to make separate style rules for 2
programs.

I completely agree, QGIS should maintain compliance. My argument is that
organizations that are shifting money from proprietary licenses should
invest in ensuring an open source product meets their needs. To not do
so means at any time there be no options that fit their requirements.

I think I've also provided the links that show QGIS can be WMS compliant
and still have extra options, the spec provides for how to do it, we
just need to make the modifications and test it.

Thanks,
Alex

On 06/07/2014 02:40 PM, Maurizio Trevisani wrote:
> Hello,
> you say
> 
> "As to why fund it? If QGIS provides other value to your organization in
> some other way, total cost of operation may be lower to simply ensure
> it's compliant rather than to switch software or have to use multiple
> software."
> 
> but as long you, Public Administration, can choose among several
> GFLOSS to implement your OGC services (that must be completely
> interoperable with all the potential clients and other PA), why should
> you choose a product that has choosen not to be interoperable?
> 
> The problem is not the product, but the people who doesn't mind to
> write interoperable code: they are not reliable - so why a PA should
> fund them and their products?
> 
> Qgis is an important product in the GFLOSS reality, but now more than
> ever should take care to complethely adhere to all the international
> standards, especially those which are at the basis for
> interoperability.
> 
> Bye.
> 
> 2014-06-07 22:17 GMT+02:00, Alex Mandel :
>> On 06/07/2014 01:06 PM, Andrea Peri wrote:
>>> Yes also this is possible,
>>> but pay attention to use it correctly.
>>> I guess it is no really simple to use (ie to define the extension).
>>
>> It looks really simple to use according to the docs. If it works and
>> cascading WMS works with other WMS servers, and it passes the schema
>> check I see no issue.
>>
>>
>>> In the SLD world this was allowed and a unfortunately and worst
>>> understanding of it will born a lot of incompatible dialects.
>>> Also in the metadata world (iso19115) the possibility to extend the specs
>>> will produce incompatibility monster.
>>> :)
>> This exists in the html world, over time there are winners. If you don't
>> care to use the extra features you are always welcome to use the base
>> which is 100% compliant. The winners or some compromise variant end up
>> in the next version of the spec.
>>
>>> I guess surely better and easy is put the new functions in in a distinct
>>> and new kind of request.
>>>
>>
>> After reading the WMS doc I believe using the tags I mention is the
>> correct way to do it. Technically the result is WMS 1.3.0 compliant.
>> Clients are free to ignore the extra functions as not using them does
>> not remove any required features.
>>
>> As to why fund it? If QGIS provides other value to your organization in
>> some other way, total cost of operation may be lower to simply ensure
>> it's compliant rather than to switch software or have to use multiple
>> software.
>>
>> Thanks,
>> Alex
>>
>>
>>> Andrea.
>>>
>>>
>>>
>>> 2014-06-07 21:56 GMT+02:00 Alex Mandel :
>>>
>>>> I just checked the WMS 1.3.0 specification document
>>>> http://portal.opengeospatial.org/files/?artifact_id=14416
>>>>
>>>> Extended optional features are allowed. There is a specific way to
>>>> include them. See section 6.9.5 "Extended capabilities and operations"
>>>> <_ExtendedCapabilities> or <_ExtendedOperations>
>>>>
>>>> So perhaps we just need to wrap those extra options in a specific tag
>>>> for them to pass schema testing.
>>>>
>>>> Thanks,
>>>> Alex
>>>>
>>>> On 06/07/2014 12:35 PM, Alex Mandel wrote:
>>>>> I understand the issue now. In order to be WMS 1.3 

Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

[Alex Mandel]

Please add your specific list of current non-compliant issue to:
http://hub.qgis.org/issues/6520

I'll add in a note about the WMS 1.3 tags specifically created for
non-standard features.

I think this issue can be resolved.

Thanks,
Alex

On 06/07/2014 01:17 PM, Alex Mandel wrote:
> On 06/07/2014 01:06 PM, Andrea Peri wrote:
>> Yes also this is possible,
>> but pay attention to use it correctly.
>> I guess it is no really simple to use (ie to define the extension).
> 
> It looks really simple to use according to the docs. If it works and
> cascading WMS works with other WMS servers, and it passes the schema
> check I see no issue.
> 
> 
>> In the SLD world this was allowed and a unfortunately and worst
>> understanding of it will born a lot of incompatible dialects.
>> Also in the metadata world (iso19115) the possibility to extend the specs
>> will produce incompatibility monster.
>> :)
> This exists in the html world, over time there are winners. If you don't
> care to use the extra features you are always welcome to use the base
> which is 100% compliant. The winners or some compromise variant end up
> in the next version of the spec.
> 
>> I guess surely better and easy is put the new functions in in a distinct
>> and new kind of request.
>>
> 
> After reading the WMS doc I believe using the tags I mention is the
> correct way to do it. Technically the result is WMS 1.3.0 compliant.
> Clients are free to ignore the extra functions as not using them does
> not remove any required features.
> 
> As to why fund it? If QGIS provides other value to your organization in
> some other way, total cost of operation may be lower to simply ensure
> it's compliant rather than to switch software or have to use multiple
> software.
> 
> Thanks,
> Alex
> 
> 
>> Andrea.
>>
>>
>>
>> 2014-06-07 21:56 GMT+02:00 Alex Mandel :
>>
>>> I just checked the WMS 1.3.0 specification document
>>> http://portal.opengeospatial.org/files/?artifact_id=14416
>>>
>>> Extended optional features are allowed. There is a specific way to
>>> include them. See section 6.9.5 "Extended capabilities and operations"
>>> <_ExtendedCapabilities> or <_ExtendedOperations>
>>>
>>> So perhaps we just need to wrap those extra options in a specific tag
>>> for them to pass schema testing.
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 06/07/2014 12:35 PM, Alex Mandel wrote:
>>>> I understand the issue now. In order to be WMS 1.3 complaint you can
>>>> only use what's in the spec.
>>>>
>>>> Looking at an analogy with html specs I find this limitation appalling
>>>> short-sighted. It means there can be no innovation testing new features
>>>> with the spec unless you manage to get it into the future spec. I find
>>>> it hard to comprehend that clients don't just skip tags that fail to
>>>> match a known tag. In html land its very common for some browsers to
>>>> know some non-standard tags, which are new features in testing to be
>>>> proposed or reworked into future standards. IE's policy of only adhering
>>>> to the spec and including no experimental tag support has been seen be
>>>> web designers as discouraging to any change. Why, because their is no
>>>> way to publicly test new ideas.
>>>>
>>>> So from the QGIS side, in order to comply we would need to reply with
>>>> only allowed tags if a user requests WMS=1.3.0, we can reply with more
>>>> stuff like GetPrint if they don't specify that version. Or perhaps we
>>>> have to invent a 1.3.0+ variant specifically for when a user knows it's
>>>> QGIS server.
>>>>
>>>> Anyone more familiar with WMS that can shed more light on the best way
>>>> to work around this issue and have both compliance and the ability to
>>>> add extra features that have no standard equivalent yet.
>>>>
>>>> My point still stands, that EU agencies with this concern should be
>>>> funding compliance efforts, not removing funding for lack of compliance.
>>>>
>>>> Thanks,
>>>> Alex
>>>>
>>>> On 06/07/2014 12:23 PM, Andrea Peri wrote:
>>>>> Hi,
>>>>> I need to be more clear.
>>>>> My english is tremendous.
>>>>> :)
>>>>>
>>>>> The Interoperability mean to have a small set of operation euals on
>>> EVERY
>>>&g

Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

[Alex Mandel]

On 06/07/2014 01:06 PM, Andrea Peri wrote:
> Yes also this is possible,
> but pay attention to use it correctly.
> I guess it is no really simple to use (ie to define the extension).

It looks really simple to use according to the docs. If it works and
cascading WMS works with other WMS servers, and it passes the schema
check I see no issue.


> In the SLD world this was allowed and a unfortunately and worst
> understanding of it will born a lot of incompatible dialects.
> Also in the metadata world (iso19115) the possibility to extend the specs
> will produce incompatibility monster.
> :)
This exists in the html world, over time there are winners. If you don't
care to use the extra features you are always welcome to use the base
which is 100% compliant. The winners or some compromise variant end up
in the next version of the spec.

> I guess surely better and easy is put the new functions in in a distinct
> and new kind of request.
> 

After reading the WMS doc I believe using the tags I mention is the
correct way to do it. Technically the result is WMS 1.3.0 compliant.
Clients are free to ignore the extra functions as not using them does
not remove any required features.

As to why fund it? If QGIS provides other value to your organization in
some other way, total cost of operation may be lower to simply ensure
it's compliant rather than to switch software or have to use multiple
software.

Thanks,
Alex


> Andrea.
> 
> 
> 
> 2014-06-07 21:56 GMT+02:00 Alex Mandel :
> 
>> I just checked the WMS 1.3.0 specification document
>> http://portal.opengeospatial.org/files/?artifact_id=14416
>>
>> Extended optional features are allowed. There is a specific way to
>> include them. See section 6.9.5 "Extended capabilities and operations"
>> <_ExtendedCapabilities> or <_ExtendedOperations>
>>
>> So perhaps we just need to wrap those extra options in a specific tag
>> for them to pass schema testing.
>>
>> Thanks,
>> Alex
>>
>> On 06/07/2014 12:35 PM, Alex Mandel wrote:
>>> I understand the issue now. In order to be WMS 1.3 complaint you can
>>> only use what's in the spec.
>>>
>>> Looking at an analogy with html specs I find this limitation appalling
>>> short-sighted. It means there can be no innovation testing new features
>>> with the spec unless you manage to get it into the future spec. I find
>>> it hard to comprehend that clients don't just skip tags that fail to
>>> match a known tag. In html land its very common for some browsers to
>>> know some non-standard tags, which are new features in testing to be
>>> proposed or reworked into future standards. IE's policy of only adhering
>>> to the spec and including no experimental tag support has been seen be
>>> web designers as discouraging to any change. Why, because their is no
>>> way to publicly test new ideas.
>>>
>>> So from the QGIS side, in order to comply we would need to reply with
>>> only allowed tags if a user requests WMS=1.3.0, we can reply with more
>>> stuff like GetPrint if they don't specify that version. Or perhaps we
>>> have to invent a 1.3.0+ variant specifically for when a user knows it's
>>> QGIS server.
>>>
>>> Anyone more familiar with WMS that can shed more light on the best way
>>> to work around this issue and have both compliance and the ability to
>>> add extra features that have no standard equivalent yet.
>>>
>>> My point still stands, that EU agencies with this concern should be
>>> funding compliance efforts, not removing funding for lack of compliance.
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 06/07/2014 12:23 PM, Andrea Peri wrote:
>>>> Hi,
>>>> I need to be more clear.
>>>> My english is tremendous.
>>>> :)
>>>>
>>>> The Interoperability mean to have a small set of operation euals on
>> EVERY
>>>> Server WMS.
>>>>
>>>> Equals mena same reqeust , same response.
>>>>
>>>> So when a Cleit WMS send a Request of GetCapabilities, The response
>> should
>>>> be the same from QGIS-server or from GeoServer or From Mapserver.
>>>>
>>>> The same response mean that every product use the same dialect the same
>>>> tags and so on.
>>>>
>>>>
>>>> The XSD OGC is the dictionary that every wms client and server should
>> use
>>>> to know the right language and tags.
>>>>
>>>> When the QGIS_Server response to a

Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

[Alex Mandel]

I just checked the WMS 1.3.0 specification document
http://portal.opengeospatial.org/files/?artifact_id=14416

Extended optional features are allowed. There is a specific way to
include them. See section 6.9.5 "Extended capabilities and operations"
<_ExtendedCapabilities> or <_ExtendedOperations>

So perhaps we just need to wrap those extra options in a specific tag
for them to pass schema testing.

Thanks,
Alex

On 06/07/2014 12:35 PM, Alex Mandel wrote:
> I understand the issue now. In order to be WMS 1.3 complaint you can
> only use what's in the spec.
> 
> Looking at an analogy with html specs I find this limitation appalling
> short-sighted. It means there can be no innovation testing new features
> with the spec unless you manage to get it into the future spec. I find
> it hard to comprehend that clients don't just skip tags that fail to
> match a known tag. In html land its very common for some browsers to
> know some non-standard tags, which are new features in testing to be
> proposed or reworked into future standards. IE's policy of only adhering
> to the spec and including no experimental tag support has been seen be
> web designers as discouraging to any change. Why, because their is no
> way to publicly test new ideas.
> 
> So from the QGIS side, in order to comply we would need to reply with
> only allowed tags if a user requests WMS=1.3.0, we can reply with more
> stuff like GetPrint if they don't specify that version. Or perhaps we
> have to invent a 1.3.0+ variant specifically for when a user knows it's
> QGIS server.
> 
> Anyone more familiar with WMS that can shed more light on the best way
> to work around this issue and have both compliance and the ability to
> add extra features that have no standard equivalent yet.
> 
> My point still stands, that EU agencies with this concern should be
> funding compliance efforts, not removing funding for lack of compliance.
> 
> Thanks,
> Alex
> 
> On 06/07/2014 12:23 PM, Andrea Peri wrote:
>> Hi,
>> I need to be more clear.
>> My english is tremendous.
>> :)
>>
>> The Interoperability mean to have a small set of operation euals on EVERY
>> Server WMS.
>>
>> Equals mena same reqeust , same response.
>>
>> So when a Cleit WMS send a Request of GetCapabilities, The response should
>> be the same from QGIS-server or from GeoServer or From Mapserver.
>>
>> The same response mean that every product use the same dialect the same
>> tags and so on.
>>
>>
>> The XSD OGC is the dictionary that every wms client and server should use
>> to know the right language and tags.
>>
>> When the QGIS_Server response to a request GetCapbility with an XML that
>> contains the GetPrint tags.
>> The client wms say "hey what is this ? It is not in the XSD OGC. This mean
>> your response is wrong."
>>
>> Of course there are some client wms that don0t do a validation of response,
>> they HOPE that the response will be exactly as they exected.
>> If this is not true. They go in crash or other bad situation.
>>
>> Again the resence of a Tag not compliant with XSD OGC will create
>> incompatibility.
>>
>> Think to a client that will parse the xml response and say:
>>
>> ok the GetLegendGraphics tag is passed now there is "this well know tag".
>>
>> Instead arrive a GetPrint tags.
>>
>> The client wms become crazy.
>>
>> Of course QGIS will understand it.
>> But this is because you (qgis group) manage it to work.
>>
>> But other clients don't know that tag and so they are not able to extract
>> all the information from Capabilities response.
>> This is a bad practice also because create artiiciosally an incopatibility
>> with other products.
>> Instead Inspire ask for INteroperability from every product.
>>
>> Interoperability don't mean use all the same unique product. (This is the
>> microsoft philosophy)
>> Interoperability mean All the product must use the same little set of
>> command and the response at these command should be compatible
>> (interoperable) between all of them
>>
>> Actulally this is not true for the response xml of qgis-server at a
>> getcapability request.
>>
>> Hope to be better explain, now.
>>
>> Andrea.
>>
>>
>> 2014-06-07 20:49 GMT+02:00 Andrea Peri :
>>
>>> Hi Alex,
>>>
>>> The question is not the print capability.
>>>
>>> The question is to LOST THE INTEROPERABILITY
>>>
>>> If qgis response an xml that is not OGC complaint it is not 

Re: [Qgis-developer] [Qgis-user] A discussion: is qgis still affordable in Europe if it violate the Inspire directive ?

[Alex Mandel]

I understand the issue now. In order to be WMS 1.3 complaint you can
only use what's in the spec.

Looking at an analogy with html specs I find this limitation appalling
short-sighted. It means there can be no innovation testing new features
with the spec unless you manage to get it into the future spec. I find
it hard to comprehend that clients don't just skip tags that fail to
match a known tag. In html land its very common for some browsers to
know some non-standard tags, which are new features in testing to be
proposed or reworked into future standards. IE's policy of only adhering
to the spec and including no experimental tag support has been seen be
web designers as discouraging to any change. Why, because their is no
way to publicly test new ideas.

So from the QGIS side, in order to comply we would need to reply with
only allowed tags if a user requests WMS=1.3.0, we can reply with more
stuff like GetPrint if they don't specify that version. Or perhaps we
have to invent a 1.3.0+ variant specifically for when a user knows it's
QGIS server.

Anyone more familiar with WMS that can shed more light on the best way
to work around this issue and have both compliance and the ability to
add extra features that have no standard equivalent yet.

My point still stands, that EU agencies with this concern should be
funding compliance efforts, not removing funding for lack of compliance.

Thanks,
Alex

On 06/07/2014 12:23 PM, Andrea Peri wrote:
> Hi,
> I need to be more clear.
> My english is tremendous.
> :)
> 
> The Interoperability mean to have a small set of operation euals on EVERY
> Server WMS.
> 
> Equals mena same reqeust , same response.
> 
> So when a Cleit WMS send a Request of GetCapabilities, The response should
> be the same from QGIS-server or from GeoServer or From Mapserver.
> 
> The same response mean that every product use the same dialect the same
> tags and so on.
> 
> 
> The XSD OGC is the dictionary that every wms client and server should use
> to know the right language and tags.
> 
> When the QGIS_Server response to a request GetCapbility with an XML that
> contains the GetPrint tags.
> The client wms say "hey what is this ? It is not in the XSD OGC. This mean
> your response is wrong."
> 
> Of course there are some client wms that don0t do a validation of response,
> they HOPE that the response will be exactly as they exected.
> If this is not true. They go in crash or other bad situation.
> 
> Again the resence of a Tag not compliant with XSD OGC will create
> incompatibility.
> 
> Think to a client that will parse the xml response and say:
> 
> ok the GetLegendGraphics tag is passed now there is "this well know tag".
> 
> Instead arrive a GetPrint tags.
> 
> The client wms become crazy.
> 
> Of course QGIS will understand it.
> But this is because you (qgis group) manage it to work.
> 
> But other clients don't know that tag and so they are not able to extract
> all the information from Capabilities response.
> This is a bad practice also because create artiiciosally an incopatibility
> with other products.
> Instead Inspire ask for INteroperability from every product.
> 
> Interoperability don't mean use all the same unique product. (This is the
> microsoft philosophy)
> Interoperability mean All the product must use the same little set of
> command and the response at these command should be compatible
> (interoperable) between all of them
> 
> Actulally this is not true for the response xml of qgis-server at a
> getcapability request.
> 
> Hope to be better explain, now.
> 
> Andrea.
> 
> 
> 2014-06-07 20:49 GMT+02:00 Andrea Peri :
> 
>> Hi Alex,
>>
>> The question is not the print capability.
>>
>> The question is to LOST THE INTEROPERABILITY
>>
>> If qgis response an xml that is not OGC complaint it is not interoperable
>> with other product.
>>
>> As example:
>>
>> if an public Administration will eed to do a cascading wms with the server
>> wms of another public administration.
>> The server before of all call for a GetCapability.
>>
>> If the response has a tag proprietary. If fail.
>> This need Not Interoperable.
>>
>> I dont say do not do a getprint.
>>
>> I say remove tha tag GetPrint from the GetCapabilities response.
>> It is not a OGC tag and so that response is not interoperable as requested
>> from Inspire specification.
>>
>> Regards,
>>
>>
>>
>> 2014-06-07 20:36 GMT+02:00 Alex Mandel :
>>
>> On 06/07/2014 11:19 AM, Andrea Peri wrote:
>>>> Hi,
>>>>
>>>> AFAIK the qgis server is not complaint with Inspi

Re: [Qgis-developer] Qgis server is really compliant OGC?

[Alex Mandel]

On 06/07/2014 12:30 AM, Andrea Peri wrote:
> Hi,
> 
> I open a ticket for this.
> http://hub.qgis.org/issues/10489
> 
> Also I do some tests.
> Comparing the qgis-server response with the MapServer response.
> The images I attach to the ticket show clearly where is the bug in the qgis
> response.
> 
> Is wrong the position of GetLegendGraphics tag.
> 
> I need to resolve this because this mean that qgis-server is not compliant
> with OGC spcs, and this mean also that it is not working with other client
> rather than qgis itself This mean also that qgis wms client will not do a
> test of validation and perhaps this explain because something it will crash
> or dont'work perfectly.
> ;)
> 
> More important for me, this mean that qgis-server surely is not usable for
> Inspire liek infrastructure, and this is a blocking question for any
> european organization that plan to fund on qgis as a server for its
> infrastructure (like us). I geuss this could be important also for other
> european and inspire menbers of europe.
> 

Hmm, it works with OpenLayers, including GetLegendGraphic. I'm not
doubting that you may have found a validation flaw that should be fixed.
What version are you testing?

Thanks,
Alex


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

Re: [Qgis-developer] spatial joins and select by location should not consider polygons than only touch

[Alex Mandel]

On 06/04/2014 09:42 AM, G. Allegri wrote:
> I've done some testing with fTools' spatial join and select by location
> tools.
> Whatever the geometry type it uses the "intersects" operator, which is true
> even if geometries only touch.
> 
> I've patched my own version to distinguish the case the input layer (to be
> selected) is a linear or polygonal layer. In that case I check if
> "overlaps" or "contains" are true, but I reject the case the geometries
> only touch. I keep the single intersects operator in case of points.
> 
> If you agree with the logic (I don't want to select or join geometries that
> only touch) I will submit a pull request.
> 
> giovanni
> 
> 

Both options should exist. Perhaps a checkbox to exclude those that only
touch?

Thanks,
Alex

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

Re: [Qgis-developer] QGIS Server reference server

[Alex Mandel]

Merely suggesting 2 places we could host it. Happy to facilitate someone
else doing the setup.

Thanks,
Alex

On 06/03/2014 10:33 AM, Anita Graser wrote:
> Hi Alex,
> Was that a yes? :-D
> 
> On Tue, Jun 3, 2014 at 6:35 PM, Alex Mandel  
> wrote:
>> On 06/03/2014 06:46 AM, Anita Graser wrote:
>>> Hi,
>>>
>>> Would anyone be willing to setup and host a QGIS Server reference
>>> server which could be used e.g. for official OpenLayers3 demo
>>> examples? Especially with WFS & WFS-T?
>>>
>>> Thanks and best wishes,
>>> Anita
>>
>> Why not on QGIS2 or Adhoc.osgeo (that's where the mapserver demo also
>> lives).
>>
>> Thanks,
>> Alex
>>

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

Re: [Qgis-developer] QGIS Server reference server

[Alex Mandel]

On 06/03/2014 06:46 AM, Anita Graser wrote:
> Hi,
> 
> Would anyone be willing to setup and host a QGIS Server reference
> server which could be used e.g. for official OpenLayers3 demo
> examples? Especially with WFS & WFS-T?
> 
> Thanks and best wishes,
> Anita

Why not on QGIS2 or Adhoc.osgeo (that's where the mapserver demo also
lives).

Thanks,
Alex

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

Re: [Qgis-developer] Fwd: request to revert "deprecated" tag for my plugin "SimpliPy"

[Alex Mandel]

On 06/01/2014 05:28 AM, Albert Ferràs wrote:
> Hi,
> 
> My plugin http://plugins.qgis.org/plugins/simplipy/ has the tag "This
> plugin is deprecated" and I don't know why. What can I do to fix this?
> 
> Thanks
> 

I agree that action seems odd. Maybe you accidentally got hit by a
recent audit. Your plugin does not appear to violate any of the rules
though.

Thanks for reporting, hopefully one of the repo managers will read this
and look into fixing.

Thanks,
Alex

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

Re: [Qgis-developer] [Qgis-user] [Plugin presentation] LayerBender

[Alex Mandel]

On 05/27/2014 01:41 PM, MORREALE Jean Roc wrote:
> Le 27/05/2014 17:44, Alex Mandel a écrit :
>> I was also thinking about filing a ticket to ask for vector to be added
>> to the core Georeferencer, since gdal 1.10 ogr2ogr can take a gcp list
>> and apply polynomial 1,2 or 3 to a vector and reproject it.r
> 
> thanks for this information alex ! I did not knew that ogr had this
> feature, it's going to save me a lot of time so congratulations to the
> ogr devs behind it :)
> 
> Olivier > congratulation for this plugin, I've the same user cases
> (people having vectorized napolenian maps on illustrator)

It's not working in Processing right now (I've reported it to Victor).

I think I got it from Andre Joost's post
http://gis.stackexchange.com/a/93021

A little research shows as of gdal 1.10+ use can use this method.

Thanks,
Alex

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

Re: [Qgis-developer] [Qgis-user] [Plugin presentation] LayerBender

[Alex Mandel]

On 05/27/2014 09:15 AM, Paolo Cavallini wrote:
> Il 27/05/2014 18:09, Olivier Dalang ha scritto:
>> I'd also find it nice to unify all georeferencing tools under one UI. But to 
>> me, the
>> current georeferencer is a bit annoying to use (you always have to move the 
>> window
>> around, and can't use all the normal qgis tools on the points pairs), still 
>> I don't
>> believe the UI of VectorBender will convince everyone neither...
> 
> Agreed. The raster georef is oldish, and would need some love. The 
> rater+vector
> unification would be a good chance for it.
> All the best.
> 

Right I was actually hoping you could make your method an option for
Rasters too. We should still retain the current window but it should be
optional to switch between the methods since there's are positives to
both ways of doing it. But I agree that it should be easier to dock the
window for side by side comparisons, or use your method where the
unreferenced image can be free floated next to the real data.

I expect for ogr2ogr that you can start with a wrapper the same way
gdaltools works. Long run of course it should be possible via the API to
use GDAL more directly.

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

Re: [Qgis-developer] [Qgis-user] [Plugin presentation] LayerBender

[Alex Mandel]

Might also want to merge in the
https://plugins.qgis.org/plugins/qgsAffine/ which provides direct user
control over an affine transformation. Possibly as an alternate middle
step or a way to save the transformation parameters in case you want to
apply them in batch.

I was also thinking about filing a ticket to ask for vector to be added
to the core Georeferencer, since gdal 1.10 ogr2ogr can take a gcp list
and apply polynomial 1,2 or 3 to a vector and reproject it. So after the
previous mentioned mergers it would be good to see how the core
georeferencing tool could be enhanced by these slightly different
workflows and be allowed to do either vector or raster.

Thanks,
Alex

On 05/27/2014 12:03 AM, G. Allegri wrote:
> AFAIK vectGeoRef does an affine transformation.
> It would be great if the two tools would merge into a single plugin,
> bringing thir different solutions.
> 
> giovanni
> Il 27/mag/2014 08:55 "Tim Sutton"  ha scritto:
> 
>> Hi
>>
>>
>>
>> On Mon, May 26, 2014 at 9:18 PM, Olivier Dalang 
>> wrote:
>>
>>> Dear lists,
>>>
>>> I'm happy to present my new plugin called "LayerBender".
>>>
>>> It's purpose is to allow to align/distort vector layers to match a
>>> source, very much like georefencer does for raster. It seems ArcGIS and
>>> OpenJump call this feature "Rubber sheeting".
>>>
>>> Demonstration video : https://vimeo.com/96142479
>>>
>>> I needed this in a project I'm working on to align some already digitized
>>> historical maps.
>>>
>>> Please note that the plugin is still experimental and not much tested yet
>>> (and only under windows)... So please be understanding in case of problems !
>>>
>>> All feedback is welcome, either here or on
>>> https://github.com/olivierdalang/VectorBender
>>>
>>> Hope you like it !
>>>
>>>
>> Wow thats awesome man - thanks for sharing!
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>
>>> Best,
>>>
>>> Olivier
>>>


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

Re: [Qgis-developer] Auto increment field for shapefiles?

[Alex Mandel]

On 05/17/2014 07:07 AM, Andrea Peri wrote:
> The dbf spec has a type serial ?
> 
> I don't remenber , but not sure of this.
> 
It does but not in dbf IV which is what shapefiles use (from a little
online poking) only in later versions like dbf 7.

> If the dbf has not a serial type.
> 
> This enhance will mena to produce a new kind of shapfile
> readable only from QGIS.
> 
> I guess should be avoided to produce incompatible new formats.
> 
> Andrea.
> 
I think what's being proposed is that the QGIS project is the only thing
that tracks that's serial, in the dbf field definition would stay
Integer. Of course editing the file in another program can easily break it.

I'd rather see effort into making other formats 1st class to help move
people off of shapefiles. Note ArcGIS does now support Spatialite
http://blog.geomusings.com/2013/08/07/spatialite-and-arcgis-10-dot-2/
And we expect Geopackage adoption to follow in the next few years.

Course if this really bugs someone, by all means implement something
just don't break the compatibility of the files.

-Alex

> 
> 2014-05-17 11:02 GMT+02:00 Paolo Cavallini :
> 
>> Il 17/05/2014 00:38, mmekuria ha scritto:
>>> I am not sure what you mean, Paulo. But there is already the Feature Id
>>> (Object Id in ArcGIS) in QgsFeature. Do you mean having that a mandatory
>>> field that gets populated every time a feature is created within a
>>> shapefile?
>>
>> Almost: I mean let the user define a field as SERIAL
>> http://www.postgresql.org/docs/9.3/static/datatype-numeric.html
>> also for non-database data types (especially shp).
>> It does not seem too difficult, now that we have a record number function
>> in the
>> expressions.
>> All the best.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> 
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Report bug/feature on homepage

[Alex Mandel]

There's a reason some projects choose to call them issues and not bugs
(translations vary). I agree you can put a link on the front page to
info about issues, but I would avoid a comment box - that will get hit
by spam bots and then becomes another places people have to check.

Thanks,
Alex

On 05/01/2014 11:50 PM, Zoltan Szecsei wrote:
> Hiya,
> What about a link saying "Think you've found a bug?"
> That then sends the user to a separate page which gives guidance that
> you want to give the user, AND also a box saying "Paste a short error
> message here"
> This is then sent off to google for them.
> 
> Regards,
> Zoltan
> 
> 
> On 2014/05/02 08:44, Anita Graser wrote:
>> My main objections to having a "report bugs" button on the main page:
>>
>> - I think users who are not too familiar with the workings of open
>> source projects will be alarmed why we think it necessary to add a
>> "report bugs" button right next to the "download" button. They want
>> (the illusion? of) bug-free software (even if there is no such thing).
>> - I want to avoid cluttering of the homepage.
>> - I also think Randal has a point when he says that some small hurdle
>> can help keep the number of not-so-helpful bug reports down.
>>
>> +1 for top of "get involved" page.
>>
>>
>>
>>
>>
>> On Fri, May 2, 2014 at 7:26 AM, Nathan Woodrow 
>> wrote:
>>> What is the main objection to having it on the main page?
>>>
>>> But if that doesn't feel right then I think we should raise it to the
>>> top of
>>> get involved page.
>>>
>>> Nathan
>>>
>>> On May 2, 2014 3:22 PM, "Anita Graser" 
>>> wrote:
 Hi,
 I saw the discussion you had. I would prefer not to add a report bugs
 button on the first page of qgis.org but we could make it more
 prominent on
 get involved.
 It's not that long since I added the report a bug section to get
 involved.
 Many users might only remember the old page.
 Best wishes
 Anita

 On May 2, 2014 1:24 AM, "Nathan Woodrow"  wrote:
> Hi all,
>
> After talking to some users one concern they raised was it was a bit
> tricky to get find how to report a bug or feature.  I was thinking
> it might
> be a good idea to have a report bug/feature on the homepage. It
> would fit
> quite nice between the Download and Support
>
> I am aware that you can just click Get Involved, and scroll to the
> bottom
> but it still feels a bit hidden.
>
> Does anyone else feel that same way?
>
> Regards,
> Nathan
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 

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

Re: [Qgis-developer] Report bug/feature on homepage

[Alex Mandel]

Too many vague or un-researched bug reports. People filing bugs instead
of googling the problem or even reading the manual. Lets just go with
the average user might not understand when the right place is the
mailing or stackexchange vs filing a bug. Those other methods of
communication allow true bugs to filter through. It also allows for the
collection of all relevant evidence to make a bug testable or at least
an attempt at it.

It's a signal to noise issue.

Thanks,
Alex

On 05/01/2014 10:26 PM, Nathan Woodrow wrote:
> What is the main objection to having it on the main page?
> 
> But if that doesn't feel right then I think we should raise it to the top
> of get involved page.
> 
> Nathan
> On May 2, 2014 3:22 PM, "Anita Graser"  wrote:
> 
>> Hi,
>> I saw the discussion you had. I would prefer not to add a report bugs
>> button on the first page of qgis.org but we could make it more prominent
>> on get involved.
>> It's not that long since I added the report a bug section to get
>> involved.  Many users might only remember the old page.
>> Best wishes
>> Anita
>> On May 2, 2014 1:24 AM, "Nathan Woodrow"  wrote:
>>
>>> Hi all,
>>>
>>> After talking to some users one concern they raised was it was a bit
>>> tricky to get find how to report a bug or feature.  I was thinking it might
>>> be a good idea to have a report bug/feature on the homepage. It would fit
>>> quite nice between the Download and Support
>>>
>>> I am aware that you can just click Get Involved, and scroll to the bottom
>>> but it still feels a bit hidden.
>>>
>>> Does anyone else feel that same way?
>>>
>>> Regards,
>>> Nathan
>>>
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Report bug/feature on homepage

[Alex Mandel]

There's an interesting question. Should step one be get on the mailing
list and verify bug? Or will the onerous nature of having to get an
account keep out people who don't want to put in enough effort for a
good bug report?

Trade-offs, but +1 on making it more obvious how to start on the path to
bug reports, I mean issues or maybe tickets...

Thanks,
Alex


On 05/01/2014 04:35 PM, Randal Hale wrote:
> +eleventy
> 
> I spent a while trying to figure out how to report a bug. Which is good -
> it probably keeps down frivolous bug reports...but bad because some
> probably give up and it could be something important.
> 
> 
> Sent from my Mobile Device
> 
> On May 1, 2014 7:24 PM, "Nathan Woodrow"  wrote:
> 
>> Hi all,
>>
>> After talking to some users one concern they raised was it was a bit
>> tricky to get find how to report a bug or feature.  I was thinking it might
>> be a good idea to have a report bug/feature on the homepage. It would fit
>> quite nice between the Download and Support
>>
>> I am aware that you can just click Get Involved, and scroll to the bottom
>> but it still feels a bit hidden.
>>
>> Does anyone else feel that same way?
>>
>> Regards,
>> Nathan
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Plugin tags

[Alex Mandel]

On 04/28/2014 04:38 AM, Paolo Cavallini wrote:
> Hi all.
> Currently, plugins are tagged in a rather inefficient way. The list of
> tags as displayed in the webapp (unsure whether tags used <3 times are
> included) is:
> 
> analysis cad cadastre calculator centroid composer database dem
> digitizing ecology export feature field geometry google html import
> inspire labeling land cover legend line load map metadata network
> analysis openlayers openstreetmap osm point polygon polyline postgis
> processing profile project python raster remote sensing routing sample
> search selection service shape shapefile spatialite statistics style
> time transparency vector web wkt wms
> 
> Some of them are very little informative, and some plugin miss what is
> apparently their most appropriate tag.
> I would suggest all authors to rethink their tagging strategy, and
> converge on the most useful ones.
> Maybe someone could suggest a list of preferred tags?
> 
> All the best.
> 

I would suggest we look for a way to allow the community to refine the
tags on a given plugin. Upvote good tags, suggest new tags.

Haven't checked but does the tagging system match as you type?

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

Re: [Qgis-developer] hub.qgis.org and storing plugin source code repositories

[Alex Mandel]

On 04/22/2014 11:46 AM, Paolo Cavallini wrote:
> Il 20/04/2014 19:47, Alex Mandel ha scritto:
> 
>> Some will suggest we move everything to github. My personal opinion is
>> that the github issue tracker is still quite inadequate for the
>> complexity of QGIS and it would force users to a 3rd party service which
>> they may or may not want to use. I can elaborate on my dissent if this
>> option starts to gain traction.
> 
> IMHO we should suggest plugin dev a reasonable, simple and effective
> default way of sharing code and tickets. Of course, if one cooses a
> different strategy, no problem for us.
> If we can fix the redmine issue, all the better (having the tickets in
> the same location would be good), otherwise the most likely candidate
> currently seems GH.
> Could we reach an agreement on this?
> I'm willing to fix the howto page once we decided.
> Thanks.
> 

This alleviates some of my concern, as there is a viable exit strategy now.
http://codetheory.in/export-your-issues-and-wikis-from-github-repo-and-import-to-bitbucket-migration/

It would be really cool if we could wrap the api's into our own search
tool, then we could auto search plugin repos hosted on bitbucket or
github from the plugins.qgis site.

Even encouraging all uses onto github doesn't solve how to search the
main QGIS and Plugins tickets together at the same time.

We need a good discussion of the topic here since it affects more than
just devs. I'm not sure how to come to a definitive decision.

FYI, bitbucket support OpenID, github does not. OpenID might be a way
for us to make things easier for new users. I can see implementing
Django OpenID for plugins.qgis.


To throw in a twist, we could run these:
https://www.gitlab.com/gitlab-ce/
https://www.gitlab.com/gitlab-ci/

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

Re: [Qgis-developer] [OSGeo-Discuss] Downtime Notice for some OSGeo Hosted sites

[Alex Mandel]

All services are now restored. Please report if something isn't working
as expected.

Thanks,
Alex
OSGeo System Admin Committee

On 04/25/2014 10:51 AM, Alex Mandel wrote:
> The following sites will be down later today for hardware maintenance
> starting at approximately
> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140425T2000
> Outage will likely take an hour or less.
> 
> All OSGeo hosted Trac & SVN instances. OSGeo based Logins will also
> likely by down.
> 
> osgeo.org
> downloads.osgeo.org
> live.osgeo.org
> wiki.osgeo.org
> trac.osgeo.org
> svn.osgeo.org
> 
> 
> Additional sites not listed may also be down.
> Please forward announcement to relevant project lists.
> 
> We'll be on IRC #osgeo during the outage.
> 
> Thanks,
> Alex
> 
> OSGeo System Admin Committee
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
> 

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

[Qgis-developer] Downtime Notice for some OSGeo Hosted sites

[Alex Mandel]

The following sites will be down later today for hardware maintenance
starting at approximately
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140425T2000
Outage will likely take an hour or less.

All OSGeo hosted Trac & SVN instances. OSGeo based Logins will also
likely by down.

osgeo.org
downloads.osgeo.org
live.osgeo.org
wiki.osgeo.org
trac.osgeo.org
svn.osgeo.org


Additional sites not listed may also be down.
Please forward announcement to relevant project lists.

We'll be on IRC #osgeo during the outage.

Thanks,
Alex

OSGeo System Admin Committee
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] hub.qgis.org and storing plugin source code repositories

[Alex Mandel]

On 04/20/2014 02:48 AM, Ricardo Filipe Soares Garcia da wrote:
> Hi list
> 
> hub.qgis.org seems to be broken for people who want to use it as a
> repository for plugin's source code.
> 
> I'm having problems with it since almost a year:
> 
> http://osgeo-org.1560.x6.nabble.com/using-hub-qgis-org-git-repository-td5057063.html
> 
> and there are also several tickets related to it:
> 
> http://hub.qgis.org/issues/9741
> http://hub.qgis.org/issues/5969
> http://hub.qgis.org/issues/4890
> 
> Currently there isn't even a way to manage SSH keys on the GUI, so it is
> impossible to use it as a source code repository.
> 
> What is the word on this? Is hub.qgis.org no longer the preferred place to
> store plugin's source code?
> 

You are correct, SSH key management broke (the redmine plugin for it). I
asked the maintainer, and the short answer is it was intentionally
removed because it was causing problems. Unless someone else can figure
out what's wrong with it, or replace it with something that works it
will never be fixed. Current system is based on redmine_gitosis, which
is no longer maintained. An alternative is redmine_gitolite, but that
requires work to move repos from gitosis to gitolite (can all be done by
server admin). A slightly more complicated move would be to upgrade
Redmine or migrate to it's fork Chili-project in addition to switching
to gitolite. I went this way on my own server years ago when it was
clear that combo is more popular and maintained.

The plugin documentation has not been updated to reflect that this
prevents uploading of source to hub. So yes, the unofficial
recommendation is external hosting of code. Alternative hosting
suggested includes any of the free vcs hosting out there: bitbucket,
google code, github, sourceforge, etc...

The bigger question for the whole developer community, if we're not
hosting code on hub anymore should we transition to hosting tickets
somewhere/something else?

The original intent of hub, and reason Redmine was picked, was to be
able to put multiple project trackers all in one spot. This enables
users to not have to guess or track down where an issue tracker for a
plugin can be found. It also means the whole community can easily see
when a particular plugin author is being completely unresponsive, and
the community can turn it over to adoptive devs.

One option I've done a little research on would be to move tickets to a
django based issue tracker and integrate it directly with the plugins
pages. We clearly don't have a strong set of Ruby sys admins so anything
python related might be easier to maintain. There's even a fork of Trac
called Bloodhound, either of which now supposedly do multi-project.

Some will suggest we move everything to github. My personal opinion is
that the github issue tracker is still quite inadequate for the
complexity of QGIS and it would force users to a 3rd party service which
they may or may not want to use. I can elaborate on my dissent if this
option starts to gain traction.

Thanks,
Alex




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

[Qgis-developer] Downtime Notice for many OSGeo Hosted sites

[Alex Mandel]

The following sites will be down later today for hardware maintenance
starting at approximately
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140418T2000
Outage will likely take a couple of hours.

All OSGeo hosted mailing lists will also likely be down. Messages sent
during that time will likely be delayed but not lost.


docs.geotools.org
featureserver.org
geos.osgeo.org
geotools.org
grass.osgeo.org
grasswiki.osgeo.org
mapserver.org
openlayers
pycsw.org
spatialreference.org
tilecache.org
www.gdal.org
www.remotesensing.org
demo.mapserver.org
mapbender
demo.pycsw.org
oam
qgis.org
hub.qgis.org

Additional sites not listed may also be down.
Please forward announcement to relevant project lists.

We'll be on IRC #osgeo during the outage since mailing lists will be down.

Thanks,
Alex

OSGeo System Admin Committee
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Removing project from hub

[Alex Mandel]

On 04/10/2014 05:33 AM, Alexander Bruy wrote:
> Hi all,
> 
> is it possible to remove project from QGIS Hub? For example we
> decided to move issues of some plugins to GitHub and don't need
> projects at QGIS hub anymore.
> 
> How such requests handled?
> 
> Thanks
> 

Name the project in question. I think we can disable it so it doesn't
show up publicly anymore.

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

Re: [Qgis-developer] hub.qgis.org

[Alex Mandel]

Looks up to date now. What I'm really wondering, is if upgrading Phusion
would help with the weird out of control memory usage. I've been kicking
manually every day, for some reason the cron job doesn't work anymore,
though the weigh-passengers script does.

It looks like a newer version is available and their is also an option
to run a standalone, reverse proxied behind another server.

I'll suggest we give upgrading a shot from the phusion repos. That
should just work and is much simpler than a redmine upgrade.

Anyone want to help?

Thanks,
Alex

On 04/01/2014 02:07 AM, Werner Macho wrote:
> hmmm
> 
> I've seen we've 41 security updates on that server pending
> and 11 package updates including apache2
> 
> among security updates there are mysql and postgis..
> 
> I don't know if it safe to just upgrade them (as I don't know if one
> of the installed software requires a specific version)
> But probably updating could help?
> I am not sure
> 
> regards
> Werner
> 
> On Tue, Apr 1, 2014 at 11:00 AM, Alex Mandel  
> wrote:
>> It's a combination of disk filling and a ruby memory leak/stuck process.
>>
>> Concerning the disk, cleanup began last week of various things including
>> moving the plugins site. Not sure why it filled up again so fast.
>>
>> Concerning the ruby issue. There is a cron job that is supposed to be
>> killing out of control processes but it doesn't seem to work anymore.
>> I don't know who wrote it:
>> /usr/local/sbin/weigh-passengers
>> But we can probably make it more aggressive, or someone can make sure
>> it's actually running like its supposed to. The cron job does not appear
>> to be running every 5 minutes like used to.
>>
>> Richard is working on longer term balancing.
>>
>> Thanks,
>> Alex
>>
>> On 04/01/2014 01:37 AM, Andreas Neumann wrote:
>>> Hi,
>>>
>>> I am trying to report a bug, but http://hub.qgis.org/ does not work.
>>>
>>> I get:
>>>
>>> 
>>>
>>> Application error
>>>
>>> Rails application failed to start properly
>>>
>>> 
>>>
>>> Already last week at the hackfest I had troubles with hub.qgis.org -
>>> sometimes it worked, sometimes it fails. Can we do something so that
>>> this becomes more reliable?
>>>
>>> Thanks a lot,
>>> Andreas
r
> 

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

Re: [Qgis-developer] Performance Tuning qgis.org

[Alex Mandel]

On 04/05/2014 12:44 PM, Richard Duivenvoorde wrote:
> On 05-04-14 20:59, Alex Mandel wrote:
>> I realized that we're no longer running any php based websites. Can
>> someone verify that?
>>
>> If true we can try switching off Apache prefork for worker which is
>> multi-threaded and might perform better.
> 
> Hi Alex,
> 
> I think you are right... but others, please let us know if we are wrong!
> 
> Other point: although qgis.org website is as responsive as before,
> actually doing something on the server is awfully slow (currently trying
> to start a sphinx buildscript... it looks like it takes seconds for
> every file to write)?? Also opening a file in vim takes a long time??
> 
> Is this related to the problems with the other server, or are we sharing
> resources now or os?
> 
> Regards,
> 
> Richard Duivenvoorde
> 


Disk I/O is the current issue on the underlying hardware. Raid card
batteries are in the mail already, which we believe is the root cause. A
few days ago it was the raid rebuild causing it with the replacement
disk in. So please avoid heavy disk usage for a few days.

My comments above are actually all about reducing the I/O to make it
perform better.
http://blog.phusion.nl/2013/03/12/tuning-phusion-passengers-concurrency-settings/

We've also been making tweaks to kernel scheduling, disk read ahead,
swapiness, etc. All of this is actually helping make page serving even
faster despite the disk bottleneck.

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

[Qgis-developer] Performance Tuning qgis.org

[Alex Mandel]

I realized that we're no longer running any php based websites. Can
someone verify that?

If true we can try switching off Apache prefork for worker which is
multi-threaded and might perform better.

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

Re: [Qgis-developer] Plugin sync across machines via web file?

[Alex Mandel]

On 04/05/2014 11:20 AM, AntonioLocandro wrote:
> Hi is it possible to sync the plugins from one machine across all the
> machines I use QGIS? Here is the situation
> 
> I normally work with QGIS on my personal laptop, I have downloaded and
> tested several plugins and I have kept the ones I want. When I go to my
> office I work on my workstation but I then have to remember what plugins I
> use or I think I have a plugin installed while that isn't true. What I would
> like is some way for QGIS to sync plugin from a web file I have shared on a
> public accessible place be that github, dropbox, etc.
> 
> Ideas? I would love to have an automatic solution that doesn't involve
> copy/paste some file each time I need to sync plugins since that would be
> error prone
> 

I think you already found the answer, symlink a folder that you keep in
dropbox (or other sync service). Or just add the Dropbox subfolder to
the plugin search path - I just noticed the dialog in the QGIS options
says it's only for C++ plugins, so maybe an enhancement request.


Note you may want to exclude .pyc files as those are not platform
independent.

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

Re: [Qgis-developer] Adding plugins to core?

[Alex Mandel]

Perhaps the proposal is really, which plugins to ship by default?
Which sounds the same but is slightly different or could be interpreted
differently as add the plugins to core.

I'm +1 for adding a few more default plugins to the distribution,
especially if they are very common in usage. Remember though, there is a
trade-off, putting too many things in the default interface is
overwhelming for some levels of users. It makes GIS more daunting than
it needs to be.

Thanks,
Alex

PS: Hotmail is known to reject osgeo mailing lists. Wondering if that
magically got fixed.

On 04/05/2014 09:13 AM, Etienne Tourigny wrote:
> On Sat, Apr 5, 2014 at 1:00 AM, Nathan Woodrow  wrote:
> 
>> I agree that adding the plugins to core would be a good idea however I
>> don't feel that we should just add them in their current state.  The plugin
>> repository has the benefit of of being able to update things faster then
>> the release of QGIS itself if you find bugs, etc, you can also add features
>> for older QGIS versions.
>>
> 
> the processing/sextante plugin is both in core and also can be updated.
> Same thing for ftools and gdaltools.
> 
> 
>>
>> I think these features in the plugins are great but we should really
>> integrate them into the core project itself as new features rather then
>> just a plugin.   Having Python plugins in core can also raise issue for
>> users because they still look like normal plugins but you can't update them
>> because they are no longer in the repository.  Having to enable handy
>> features also feels a bit hap hazard to me.
>>
>> Something like the value tool could easily be integrated into the identify
>> tool for instance.
>>
> 
> I agree, more or less - I thought about integrating it into the main
> identify tool, but as it works with raster layers only, how would you
> display raster and vector layers?
> 
> 
>> There are also some other concepts floating around the idea of bring CAD
>> functions into core so I think it's best to just focus on making those
>> stronger.
>>
>> So +1 for adding the functions but -1 for just bringing the plugins into
>> core.
>>
> 
> Not sure they would make it into core then, as development cost fof
> integrating into core is much higher than adding them as core python
> modules. For instance, the openlayer plugin would probably need quite a lot
> of work to be ported to c++.
> 
> On the other hand, anything that relies on qwt would be better handled.
> Butanthing that uses python plotting libraries would obviously not work.
> 
> cheers
> Etienne
> 
> 
>>
>> - Nathan
>>
>>
>> On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro <
>> antoniolocan...@hotmail.com> wrote:
>>
>>> I think it's a great idea, I was actually thinking about this the other
>>> day
>>> and glad you brought the topic.
>>>
>>> Although we can install plugins certainly it becomes evident when a plugin
>>> should really become a core feature, example the Openlayers Plugin, I bet
>>> almost all people using QGIS downloads it before doing anything with QGIS.
>>> Plugins extend QGIS functionality beyond what initially was thought but in
>>> many cases plugins become a must to be able to work efficiently
>>>
>>> If the plugins are added to core I would vote for blending the functions
>>> coherently with the rest of the interface in the appropriate menus. A good
>>> example would be CAD tools which I would say be called Advanced Editing or
>>> something.
>>>
>>> I would add
>>>
>>> http://plugins.qgis.org/plugins/zoomtocoordinates/
>>> http://plugins.qgis.org/plugins/numericalDigitize/  - needs to add case
>>> for
>>> geographic coordinates
>>>
>>>
>>>
>>>

> 

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

Re: [Qgis-developer] deleting features on master: no confirmation

[Alex Mandel]

On 04/01/2014 10:53 AM, Giovanni Manghi wrote:
> Hi all,
> 
> is this a new behavior or is a bug?
> 
> cheers!

There was a big thread a few weeks ago. I think the discussion ended at
no confirmation, with an undo system?

Still searching for the right thread... sure someone has it handy.

Thanks,
Alex

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

Re: [Qgis-developer] hub.qgis.org

[Alex Mandel]

It's a combination of disk filling and a ruby memory leak/stuck process.

Concerning the disk, cleanup began last week of various things including
moving the plugins site. Not sure why it filled up again so fast.

Concerning the ruby issue. There is a cron job that is supposed to be
killing out of control processes but it doesn't seem to work anymore.
I don't know who wrote it:
/usr/local/sbin/weigh-passengers
But we can probably make it more aggressive, or someone can make sure
it's actually running like its supposed to. The cron job does not appear
to be running every 5 minutes like used to.

Richard is working on longer term balancing.

Thanks,
Alex

On 04/01/2014 01:37 AM, Andreas Neumann wrote:
> Hi,
> 
> I am trying to report a bug, but http://hub.qgis.org/ does not work.
> 
> I get:
> 
> 
> 
> Application error
> 
> Rails application failed to start properly
> 
> 
> 
> Already last week at the hackfest I had troubles with hub.qgis.org -
> sometimes it worked, sometimes it fails. Can we do something so that
> this becomes more reliable?
> 
> Thanks a lot,
> Andreas
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Postgis Caching - Enhancement

[Alex Mandel]

This really applies to non-local data sources. Network latency can be
huge issue, it can also be problematic if a bbox strategy isn't in use.
You are right this is not Postgis specific. Database servers are more
likely to be remote (shapefiles on a network share are a terrible idea
in almost all cases). Maybe the recommendation is that people pipe
Postgis through a WFS service when they want to use it this way? If I
think about it that way WMS or WMTS would actually be a good way to get
speed - but you can't really see attribute tables that way. Wonder if
there's some way to hybridize it. Of course this assumes said users have
the ability to setup such services in house quickly for new layers.

I've experienced this with DB tables from 1-100+ GB, it's not as big an
issue with non DB (Oracle, MSSQL, etc) formats because they don't get as
large. The problem is that most people forget to zoom in before turning
on the layer, or if they need to see the whole extent the whole data is
transferred before the renderer can simplify it. It's almost like a set
of postgis views used similar to pyramids in rasters with simplification
algorithms applied before transmission would be a way to handle it. Not
QGIS specific but I could see a plugin in QGIS to build the views in
Postgis.

Panning/Zooming requests data if the data isn't already cached. So if
you start panning then go back to a spot you've been before you already
have it.

I agree that always on caching is bad, hence my suggestion for a user
toggle per layer. When doing cartography work you just need to be able
work a little faster with the rendering for it to not be frustrating.
Same for digitizing (assuming the postgis layer in question is reference).

Thanks,
Alex

On 03/31/2014 11:19 PM, Bernhard Ströbl wrote:
> Hi Alex,
> 
> we are using a PostGIS database here with several clients connected at
> any point in time (geoserver and QGIS users). I am always impressed how
> fast QGIS draws even layers with many features and complex rules. Even
> when working on my old laptop with a local postgreSQL instance (base
> configuration) it is impressively fast. So I would not say that the
> PostGIS provider _in general_ is slow (as [1] suggests). Looking at
> OpenJump: are there configurations where caching really improves speed?
> If I understood the explanations right only those features intersecting
> the viewport are cached, so any panning/zooming results in a database
> request, too.
> Still speed improvements are always welcome, but if a layer is read-only
> for one user this does not neccessarily mean that it is read-only for
> others, too, so care must be taken when to activate caching. Although
> there are definitely layers for which changes cannot be expected during
> one QGIS session, so caching (in memory) might improve performance.
> Looking at other providers I know that shape files from network drives
> are slwww. So I would opt for a generic approach that works with any
> provider.
> 
> my 2 cts
> 
> Bernhard
> 
> [1] http://gis.stackexchange.com/q/46967/3183
> 
> Am 01.04.2014 06:51, schrieb Alex Mandel:
>> Searching tickets I don't see this one, but wanted to check that it
>> wasn't on the roadmap.
>>
>> Often when working with Postgis layers, it's a read-only relationship
>> directly to a table or view that is not expected to change anytime soon.
>> To speed up panning/zooming etc we should implement and optional caching
>> mechanism (maybe this is a general feature for all vector providers?).
>>
>> It's one of the only things I've seen OpenJump do that QGIS doesn't do
>> at all. See the Check box in the add table dialog - Cache Features
>> http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Working_with_Databases
>>
>>
>> Topic comes up often:
>> http://gis.stackexchange.com/q/46967/3183
>> There are plenty of previous conversations like this around.
>>
>> If it's not anywhere in the plans I'll be happy to open a ticket.
>>
>> Thanks,
>> Alex
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> __ Information from ESET Security, version of virus signature
>> database 9619 (20140331) __
>>
>> The message was checked by ESET Security.
>>
>>  part000.txt - is OK
>>
>> http://www.eset.com
>>
>>
> 

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

[Qgis-developer] Postgis Caching - Enhancement

[Alex Mandel]

Searching tickets I don't see this one, but wanted to check that it
wasn't on the roadmap.

Often when working with Postgis layers, it's a read-only relationship
directly to a table or view that is not expected to change anytime soon.
To speed up panning/zooming etc we should implement and optional caching
mechanism (maybe this is a general feature for all vector providers?).

It's one of the only things I've seen OpenJump do that QGIS doesn't do
at all. See the Check box in the add table dialog - Cache Features
http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Working_with_Databases

Topic comes up often:
http://gis.stackexchange.com/q/46967/3183
There are plenty of previous conversations like this around.

If it's not anywhere in the plans I'll be happy to open a ticket.

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

Re: [Qgis-developer] concurrent editions strategy

[Alex Mandel]

On 03/31/2014 11:26 AM, Giovanni Manghi wrote:
> Hi all,
> 
> I would like to know if anyone has a suggestion/advice on how to cope
> the right way with concurrent editions in qgis while using postgis
> layers.
> 
> thanks in advance
> 
> -- G --

One upon a time there was a plugin for this
http://hub.qgis.org/projects/pgvs

No idea if it's actively maintained. Could use some love. It had quite a
complex system, probably worth reviving or using for ideas.

There are some Postgis ways too
http://gis.stackexchange.com/questions/66784/version-editing-for-postgresql-9-2-4-postgis-2

Thanks,
Alex

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

Re: [Qgis-developer] Requirements for QGIS desktop

[Alex Mandel]

You haven't found min. requirements because QGIS can run on really old
hardware. I see it doing ok on netbooks (aside from occasional dialog
window size issues).

So short answer if it can run Win 7, Mac OS X, or Linux 2006+ then it's
probably fine for QGIS. In reality most Windows XP machines also work.
http://osgeo-org.1560.x6.nabble.com/Re-Is-Quantum-GIS-compatible-with-Windows-7-64-bit-td4133870.html


Of course if you want a machine that will run GIS well in everyday use
http://gis.stackexchange.com/questions/23300/specifications-for-gis-desktop-hardware

Quick summary for a GIS professional:
i5+, 4GB ram, discrete graphics not necessary with i5 HD4000+ but a 1 GB
card is nice or more ram if using the i5 built in, 100 GB - 1 TB free
space (GIS layers get big and you make lots of copies)

64 bit OS, pick your flavor.


Enjoy,
Alex

On 03/31/2014 08:11 AM, Carlos López PSIG wrote:
> Hello colleagues,
> 
> Last week the free GIS conference held in Girona has been much talk QGIS ...
>  
> http://www.sigte.udg.edu/jornadassiglibre/programa/talleres
> 
> On the other hand, some costumers want to do course about QGIS and they ask
> me the requirements for the
> computers
> in class
> to see if they need to replace or extend some computers.
> 
> I searched the web for www.qgis.org and I have not found a specification of
> minimum
> requirements that support QGIS.
> Exist
> s
> it?
> 
> I
> 'm
> th
> inking
>  something like this:
> - CPU: i3 or similar (i5 or i7 desirable), 2 cores or more
> - RAM: 2GB (8 Gb desirable)
> - Graphics: dedicated, 128 MB (256 MB desirable)
> - Hard disk: 1 GB available
> - OS
> :
> W7 (SP1), Linux, MacOS X.
> 
> What you think
> about this
> ?
> Thanks in advance
> !
> 
> Best regards,
> 
> 
> *  *
> 
> *Carlos López Quintanilla*
> 
> www.psig.es
> carlos.lo...@psig.es
> +34 699.680.261
> 


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

Re: [Qgis-developer] QGIS server space

[Alex Mandel]

On 03/30/2014 04:13 AM, Richard Duivenvoorde wrote:
> On 27-03-14 09:33, Alex Mandel wrote:
> 
>> Why not load balance 2 servers in different parts of the world?
>> Bandwidth at OSUOSL is unlimited, hardware is already paid for (It's
>> raid SAS drives, not cheap hardware).
> 
> that is the plan now: building on the (much stronger/faster qgis2),
> rsync to qgis server.
> 
Perceived faster, the drives are actually slower (OSGeo has 15k rpm SAS
drives in RAID6). RAM is non-ECC, CPU is probably faster (can't tell
what the new machine has but osgeo machine are actually 8 core).
Bandwidth from OSUOSL is likely Gigabit.

It's probably performance overhead from older ganeti, and limited cpu
allocation to a particular VM.

It may not actually be faster with the same load per allocated resource.

Just minor points to keep in mind when trying to figure out the balance.

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

Re: [Qgis-developer] Next Code Sprint?

[Alex Mandel]

On 03/28/2014 02:28 AM, Anita Graser wrote:
> Hi,
> 
> Am 27.03.2014, 14:30 Uhr, schrieb Paolo Cavallini :
>> Since most of us are from Europe, I guess moving _en masse_ to USA will
>> not be an option, both because of logistic and financial constraints.
> 
> I think you're right Paolo. Flights and hotels to the US - even for only
> the core developers - would probably quite quickly reduce our project
> budget.
> 
>> An alternative will be to participate, but also having "satellite"
>> simultaneous HFs in other locations, investing more heavily in efficient
>> communication (videoconferencing, etc.).
> 
> +1 Having video conferencing available - at least in one room - would
> also allow us to connect with developers all over the rest of the world
> and with interested users.
> It would be great if anyone knows somebody experienced in
> videoconferencing who could help in setting things up.
> 
> Best wishes,
> Anita
> 
> 
> 
It's been on my idea list for a while:
http://bigbluebutton.org/

Though sometimes it's just easier to do a ustream
OR for the super simple but still meeting style, Google Hangout.

If the EU devs can't make the US, the Pacific Northwest might be a good
location - since there is interest from Alaska. Lets see how the DC QGIS
user meeting coming up goes and play with the ideas some more.

Also, don't forget about the possibility for a few people to face to
face at FOSS4g in Portland this year (Code sprint room provided).

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

Re: [Qgis-developer] [GRASS-dev] GRASS & QGIS: the future

[Alex Mandel]

On 03/27/2014 08:05 AM, Saber Razmjooei wrote:
> Hi all,
> 
> Here is my wish list:
> 
> - To be able to access GRASS data within QGIS. Similar to PostGIS and other
> GDAL/OGR data sources, it should be up to users to create GRASS
> geodatabase/location/mapsets. QGIS will be able to simply add layers for
> viewing and editing 
>

I have actually always created my locations/mapsets in QGIS. Just made
more sense for some reason.


> - Having access to GRASS shell. It will be a very handy shortcut to run
> GRASS modules without the need to open GRASS. GRASS modules which are
> available in Processing toolbox can use the same UI. Otherwise, user has to
> run it in shell.
> 
Then once in GRASS usually went directly to using GRASS commands in a
Terminal. But I can see for non-Linux the shell inside the plugin would
be much more obvious. Perhaps a GRASS Launcher in QGIS would take it's
place.

> - Simple import data to the mapsets...similar approach as drag-n-drop for
> PostGIS databases. Right-click and save as... in QGIS does a great work for
> Export.
> 

And as others have mentioned, 99.9% of the time my cartography work with
GRASS layers is done in QGIS, including intermediary viewing of results
before additional steps.


Some of the other discussion about how to chain GRASS functions in
Processing without having to dump to file outside GRASS actually gets at
the biggest downside to Processing. If one has big data in GRASS or
Postgis, it needs to stay inside those tools - shapefile is not an
option. If we can some up with some way to encourage the various makers
of tools that end up in Processing to implement all GDAL/OGR drivers,
then we can pipe between things without having to drop to intermediary
formats outside of ram.

Thanks,
Alex

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

Re: [Qgis-developer] QGIS server space

[Alex Mandel]

FYI, you just need to give Martin Spott the IPs that we need to
whitelist for OSGeo LDAP. Also it would be nice to get access to help
out. We can easily provide our ssh public keys.

Thanks,
Alex

On 03/27/2014 01:38 AM, Werner Macho wrote:
> I also agree with Alex when it comes to ssh ..
> That's still a big issue ..
> 
> load balancing would be nice too ..
> 
> regards
> Werner
> 
> On Thu, Mar 27, 2014 at 9:33 AM, Alex Mandel  
> wrote:
>> Eggs in one basket?
>>
>> Why not load balance 2 servers in different parts of the world?
>> Bandwidth at OSUOSL is unlimited, hardware is already paid for (It's
>> raid SAS drives, not cheap hardware).
>>
>> Sharing people time also helps. I was the only one awake when this issue
>> came up because I'm in the western US. I'd also rather see SAC and QGIS
>> admins work together, not just divide into territories.
>>
>> I got involved with SAC as my way to contribute to QGIS originally, but
>> now find myself guessing and without the ability to help on the new
>> servers at all. So I'm all for experimenting with the right balance, and
>> hope we can collaborate. Part of the point of the shared hosting is that
>> QGIS server admins benefit all OSGeo projects if there's an incentive to
>> work together.
>>
>> I'd prioritize upgrading Redmine and fixing the missing ssh key
>> management over moving any other sites. That's the site that cause the
>> most trouble in terms of hosting. Then there's things like CDN/DOS
>> protection, SPDY optimization, https for all downloads, caching. All
>> sorts of better ways to spend time than just shuffling static
>> html/sphinx all over the place.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> On 03/27/2014 12:11 AM, Paolo Cavallini wrote:
>>> Why not moving also the website to the new server?
>>> All the best.
>>>
>>> On 27 marzo 2014 08:03:35 CET, Richard Duivenvoorde  
>>> wrote:
>>>> On 27-03-14 03:45, Alex Mandel wrote:
>>>>> So Nathan noticed the website wasn't coming up. Specifically
>>>>> "The requested URL /en/site/ was not found on this server."
>>>>>
>>>>> I believe the issue is disk space. I'm guessing the sphinx is built
>>>>> elsewhere and transferred in on a schedule without checking how much
>>>>> space is left on the server. I got to this conclusion by noticing
>>>> that
>>>>> other languages are working fine.
>>>>
>>>> Yep disk was full again. Site is still being build on the same server,
>>>> and ends with a move/relink/remove-old step (apparently even when the
>>>> build process died in the middle)... Have to fix that.
>>>>
>>>> Fact that only english was affected was because only english and polish
>>>> (new) was being rebuild...
>>>>
>>>>> Looking at the space:
>>>>> There are 10G of backups in various places, all current
>>>>> There's also 6G of apache logs of various sorts. We should find
>>>>> somewhere to archive things over a few months old.
>>>>
>>>> Thanks for that. Untill now we moved plugins.qgis.org to new server,
>>>> but
>>>> are waiting for some time to remove old one.
>>>> I'm also trying to clean up now.
>>>>
>>>>> Temporarily I'm moving all *.gz files in /var/log/apache2 over to the
>>>>> osgeo downloads machine in my user home folder. Frees up 1.5 GB,
>>>> leaves
>>>>> last 2 logs for all services intact (ie log and log.1)
>>>>
>>>> Thanks again, we need a plan for this.
>>>>
>>>>> I did not touch the www_qgis.org folder inside apache2.
>>>>
>>>> English is up again now.
>>>>
>>>> Thanks.
>>>>
>>>> Regards,
>>>>
>>>> Richard
>>>> ___
>>>> Qgis-developer mailing list
>>>> Qgis-developer@lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] QGIS server space

[Alex Mandel]

Eggs in one basket?

Why not load balance 2 servers in different parts of the world?
Bandwidth at OSUOSL is unlimited, hardware is already paid for (It's
raid SAS drives, not cheap hardware).

Sharing people time also helps. I was the only one awake when this issue
came up because I'm in the western US. I'd also rather see SAC and QGIS
admins work together, not just divide into territories.

I got involved with SAC as my way to contribute to QGIS originally, but
now find myself guessing and without the ability to help on the new
servers at all. So I'm all for experimenting with the right balance, and
hope we can collaborate. Part of the point of the shared hosting is that
QGIS server admins benefit all OSGeo projects if there's an incentive to
work together.

I'd prioritize upgrading Redmine and fixing the missing ssh key
management over moving any other sites. That's the site that cause the
most trouble in terms of hosting. Then there's things like CDN/DOS
protection, SPDY optimization, https for all downloads, caching. All
sorts of better ways to spend time than just shuffling static
html/sphinx all over the place.

Thanks,
Alex



On 03/27/2014 12:11 AM, Paolo Cavallini wrote:
> Why not moving also the website to the new server?
> All the best.
> 
> On 27 marzo 2014 08:03:35 CET, Richard Duivenvoorde  
> wrote:
>> On 27-03-14 03:45, Alex Mandel wrote:
>>> So Nathan noticed the website wasn't coming up. Specifically
>>> "The requested URL /en/site/ was not found on this server."
>>>
>>> I believe the issue is disk space. I'm guessing the sphinx is built
>>> elsewhere and transferred in on a schedule without checking how much
>>> space is left on the server. I got to this conclusion by noticing
>> that
>>> other languages are working fine.
>>
>> Yep disk was full again. Site is still being build on the same server,
>> and ends with a move/relink/remove-old step (apparently even when the
>> build process died in the middle)... Have to fix that.
>>
>> Fact that only english was affected was because only english and polish
>> (new) was being rebuild...
>>
>>> Looking at the space:
>>> There are 10G of backups in various places, all current
>>> There's also 6G of apache logs of various sorts. We should find
>>> somewhere to archive things over a few months old.
>>
>> Thanks for that. Untill now we moved plugins.qgis.org to new server,
>> but
>> are waiting for some time to remove old one.
>> I'm also trying to clean up now.
>>
>>> Temporarily I'm moving all *.gz files in /var/log/apache2 over to the
>>> osgeo downloads machine in my user home folder. Frees up 1.5 GB,
>> leaves
>>> last 2 logs for all services intact (ie log and log.1)
>>
>> Thanks again, we need a plan for this.
>>
>>> I did not touch the www_qgis.org folder inside apache2.
>>
>> English is up again now.
>>
>> Thanks.
>>
>> Regards,
>>
>> Richard
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

[Qgis-developer] QGIS server space

[Alex Mandel]

So Nathan noticed the website wasn't coming up. Specifically
"The requested URL /en/site/ was not found on this server."

I believe the issue is disk space. I'm guessing the sphinx is built
elsewhere and transferred in on a schedule without checking how much
space is left on the server. I got to this conclusion by noticing that
other languages are working fine.

Looking at the space:
There are 10G of backups in various places, all current
There's also 6G of apache logs of various sorts. We should find
somewhere to archive things over a few months old.


Temporarily I'm moving all *.gz files in /var/log/apache2 over to the
osgeo downloads machine in my user home folder. Frees up 1.5 GB, leaves
last 2 logs for all services intact (ie log and log.1)

I did not touch the www_qgis.org folder inside apache2.

Thanks,
Alex

PS: Now that the osgeo backup server is in place, we can talk about
backing things up to it, and about reallocating more space to the qgis VM.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugins.xml slow

[Alex Mandel]

I've been seeing reports that the plugins.xml is slow
http://plugins.qgis.org/plugins/plugins.xml

I know there is work to move this to the Docker hosting.

But I had another idea. I'm assuming that it's currently generated out
of Django. I think we need to find a way to put a cache in place to make
the server response faster. Obviously a cache would be tricky if a new
plugin is uploaded. But the cache expire is say every 10 minutes, that's
still only 6 reloads of the view per hour instead of how many hits from
people checking plugins (100s-1000s per hour).

https://docs.djangoproject.com/en/dev/topics/cache/
FYI we should cache this file in RAM since it's 1 small file.

Looking at
https://github.com/qgis/QGIS-Django/blob/master/qgis-app/plugins/views.py

I see that it might be tricky because the server is trying to filter the
list before sending to the user. Maybe there's some way around that like
redirecting users to a slightly different url when they request 1.8
plugins. No change necessary on the desktop side if the fetch is allowed
to follow to a different url.

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

Re: [Qgis-developer] Qgis-Processing (former Sextante) has two bug trackers

[Alex Mandel]

It's really easy to move existing tickets. What I was looking for but
didn't find yesterday was a way in a New Issue to assign it to a
Sub-Project. If we do that it might be easier for tickets to end up in
the right place to start.

Thanks,
Alex

On 03/26/2014 02:54 AM, Alexander Bruy wrote:
> Category in main QGIS tracker should be removed and all tickets
> moved into Processing subproject.
> 
> 2014-03-26 11:46 GMT+02:00 Filipe Dias :
>> Great, thanks Alex.
>>
>> I see a minor issue: users who are not aware of the Processing tracker will
>> probably open tickets in the main tracker with the general category
>> Processing/Sextante and won't be able to specify which is the affected
>> backend (the Processing bug tracker has a subcategory for each backend: SAGA
>> GIS, GRASS GIS etc).
>>
>> A possible workaround would be to replace the category Processing/Sextante
>> with Processing/SAGA GIS, Processing/R, Processing GRASS GIS etc.
>>
>> Thanks
>> Regards
>>
>>
>> On Wed, Mar 26, 2014 at 9:31 AM, Alexander Bruy 
>> wrote:
>>>
>>> Hi all,
>>>
>>> thanks to Alex, now Processing/SEXTANTE bugtracker is
>>> a subproject of QGIS. All Processing tickets should be visible
>>> inside main QGIS tracker, but for submitting issue one should
>>> use Processing tracker.
>>>
>>> Please test. If this solution will not work fine for us we can always
>>> restore previous state.
>>>
>>> 2014-03-25 17:08 GMT+02:00 Alexander Bruy :
>>>> +1 from me to make Processing/SEXTANTE subproject if
>>>> this keep all tickets categories and allow to see Processing
>>>> bugs among QGIS ones
>>>>
>>>> 2014-03-24 21:32 GMT+02:00 Alex Mandel :
>>>>> As a sub-project, it would show up in queries of the main QGIS ticket
>>>>> system, but at the same time be able to have it's own internal
>>>>> categories.
>>>>>
>>>>> This to me seems the best compromise. It's really a big plugin with a
>>>>> myriad of backends. That complexity is what makes it a little different
>>>>> from the others mentioned. The others mentioned could be sub-projects
>>>>> of
>>>>> the main QGIS too. In reality all of them are core plugins, but they
>>>>> are
>>>>> still plugins. None of them are required to make QGIS work (boot).
>>>>> Hence
>>>>> they each have their own category. The challenge here is
>>>>> Processing/Sextante(I always call it by both since I do the the
>>>>> possibility of Processing stuff that isn't sextante) needs it's own
>>>>> categories/sub-categories.
>>>>>
>>>>> Also it's really easy for use to try moving it to be a subproject and
>>>>> then reassess (Takes about 30 seconds to move it). If it's still not
>>>>> right then we can talk about how to move tickets.
>>>>>
>>>>> Thanks,
>>>>> Alex
>>>>>
>>>>> On 03/24/2014 12:05 PM, Filipe Dias wrote:
>>>>>> Hi
>>>>>> I think Processing tickets should be in the main bug tracker, since
>>>>>> GDAL
>>>>>> tools, fTools and Grass plugin tickets are also there.
>>>>>>
>>>>>> Also, Qgis-Processing is a really big (and great) feature, that
>>>>>> interests a
>>>>>> lot of users, so it makes sense to keep its tickets in the main
>>>>>> tracker.
>>>>>>
>>>>>> Regards
>>>>>> F.
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 24, 2014 at 6:02 PM, Alex Mandel
>>>>>> wrote:
>>>>>>
>>>>>>> On 03/24/2014 05:10 AM, Filipe Dias wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> QGIS-Processing (former Sextante) has open tickets on two
>>>>>>>> bugtrackers:
>>>>>>>>
>>>>>>>> - the plugin bug tracker, built when it was a plugin, but with a lot
>>>>>>>> of
>>>>>>>> active tickets -> http://hub.qgis.org/projects/sextante/activity
>>>>>>>>
>>>>>>>> - the main bug tracker with a few open tickets ->
>>>>>>>> http://hub.qgis.org/projects/quantum-gis/issues
>>>>>>>>
>>>>>>>> I understand those two can't be merged in one go, because the
>>>>>>>> plugin-bugtracker has categories (QGIS-Processing SAGA GIS,
>>>>>>> QGIS-Processing
>>>>>>>> GRASS GIS etc) that don't fit in the main bug tracker. But this
>>>>>>>> should be
>>>>>>>> solved ASAP, because the current situation is quite confusing
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> F.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I'm of the opinion that the tracker should continue to be the Plugin
>>>>>>> tracker, not the main QGIS tracker. So I'd propse moving any
>>>>>>> Sextante/Processing tickets from the main or linking them into the
>>>>>>> Plugin tracker.
>>>>>>>
>>>>>>> To me it's still a plugin, just a core plugin but big enough that
>>>>>>> it's
>>>>>>> really a subproject. If we wanted to move the Plugin tracker as a
>>>>>>> sub-project of QGIS that would also make sense.
>>>>>>>
>>>>>>> Also Processing bugs aside from Processing not loading aren't
>>>>>>> showstoppers for release.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alex
>>>>>>>
>>
>>
> 
> 
> 

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

Re: [Qgis-developer] Qgis-Processing (former Sextante) has two bug trackers

[Alex Mandel]

That's because it's a subproject of QGIS-Application
I don't think it can be in 2 places at once, so not sure on the solution
here.

Thanks,
Alex

On 03/26/2014 03:31 AM, Alexander Bruy wrote:
> Maybe someone with admin rights can fix this?
> 
> 2014-03-26 12:27 GMT+02:00 Anita Graser :
>> Am 26.03.2014, 10:31 Uhr, schrieb Alexander Bruy :
>>
>>
>>> Hi all,
>>>
>>> thanks to Alex, now Processing/SEXTANTE bugtracker is
>>> a subproject of QGIS. All Processing tickets should be visible
>>> inside main QGIS tracker, but for submitting issue one should
>>> use Processing tracker.
>>>
>>> Please test. If this solution will not work fine for us we can always
>>> restore previous state.
>>
>>
>>
>> One small issue: Sextante bug tracker/subproject is not listed on
>> http://hub.qgis.org/projects/qgis
>>
>> For those who have trouble finding it:
>> http://hub.qgis.org/projects/sextante/issues
>>
>> Best wishes,
>> Anita
>>
>>
>>
>> --
>> anitagraser.com
> 
> 
> 

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

Re: [Qgis-developer] public key on hub.qgis.org problem

[Alex Mandel]

Guess no one has looked into this since you last emailed about the
issue. I'm once again forwarding to the people who I think will know how
to fix.

Thanks,
Alex

On 03/25/2014 10:23 AM, Giuseppe De Marco wrote:
> I was trying to upload a plugin version on hub.qgis.org
> after updating my rss key on laptop, and I was asked for a password
> after entering  $ git push origin master
> 
> opening a terminal and issuing "ssh -v gito...@qgis.org "
> I get
> 
> OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to qgis.org [140.211.15.67] port 22.
> debug1: Connection established.
> debug1: identity file /home/joe/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/joe/.ssh/id_rsa-cert type -1
> debug1: identity file /home/joe/.ssh/id_dsa type -1
> debug1: identity file /home/joe/.ssh/id_dsa-cert type -1
> debug1: identity file /home/joe/.ssh/id_ecdsa type -1
> debug1: identity file /home/joe/.ssh/id_ecdsa-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.1
> debug1: Remote protocol version 2.0, remote software version
> OpenSSH_5.5p1 Debian-6+squeeze4
> debug1: match: OpenSSH_5.5p1 Debian-6+squeeze4 pat OpenSSH_5*
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-ctr hmac-md5 none
> debug1: kex: client->server aes128-ctr hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Server host key: RSA a7:05:f6:a5:02:ec:92:73:4a:0a:12:16:4c:11:e1:1c
> debug1: Host 'qgis.org' is known and matches the RSA host key.
> debug1: Found key in /home/joe/.ssh/known_hosts:1
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: Roaming not allowed by server
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /home/joe/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/joe/.ssh/id_dsa
> debug1: Trying private key: /home/joe/.ssh/id_ecdsa
> debug1: Next authentication method: password
> gito...@qgis.org's password:
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> gito...@qgis.org's password:
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
> gito...@qgis.org's password:
> debug1: Authentications that can continue: publickey,password
> debug1: No more authentication methods to try.
> Permission denied (publickey,password).
> 
> 
> So I went to my account looking for my public keys at:
> http://hub.qgis.org/my/public_keys
> but my browser tells me page not found error
> 
> anyone could help?
> 
> thank you
> 


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

Re: [Qgis-developer] Cleaning up the plugin queue

[Alex Mandel]

On 03/24/2014 02:22 PM, Paolo Cavallini wrote:
> Hi all.
> After a short talk with Richard, I feel it is important to clean up the
> unapproved plugin queue: we had about 40 plugins, some from 2012.
> I'm writing the authors to ask for missing info, then I
> approve/unapprove as I believe it is best for the project.
> Of course I may be wrong, please forgive me: I think it is better to
> approve a less than perfect plugin than leave dozens of potentially good
> ones in the shade, and frustrate their authors and potential users.
> Any suggestion and feedback welcome.
> 

Agreed, the point of approval isn't to vet the quality of the program -
"experimental" is always welcome. I'd say anything with less than
perfect information/quality just be flagged "experimental".

I understood the intent of approval process was to prevent distribution
of malicious code, spam and other nefarious purposes.

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

Re: [Qgis-developer] Qgis-Processing (former Sextante) has two bug trackers

[Alex Mandel]

As a sub-project, it would show up in queries of the main QGIS ticket
system, but at the same time be able to have it's own internal categories.

This to me seems the best compromise. It's really a big plugin with a
myriad of backends. That complexity is what makes it a little different
from the others mentioned. The others mentioned could be sub-projects of
the main QGIS too. In reality all of them are core plugins, but they are
still plugins. None of them are required to make QGIS work (boot). Hence
they each have their own category. The challenge here is
Processing/Sextante(I always call it by both since I do the the
possibility of Processing stuff that isn't sextante) needs it's own
categories/sub-categories.

Also it's really easy for use to try moving it to be a subproject and
then reassess (Takes about 30 seconds to move it). If it's still not
right then we can talk about how to move tickets.

Thanks,
Alex

On 03/24/2014 12:05 PM, Filipe Dias wrote:
> Hi
> I think Processing tickets should be in the main bug tracker, since GDAL
> tools, fTools and Grass plugin tickets are also there.
> 
> Also, Qgis-Processing is a really big (and great) feature, that interests a
> lot of users, so it makes sense to keep its tickets in the main tracker.
> 
> Regards
> F.
> 
> 
> On Mon, Mar 24, 2014 at 6:02 PM, Alex Mandel 
> wrote:
> 
>> On 03/24/2014 05:10 AM, Filipe Dias wrote:
>>> Hi
>>>
>>> QGIS-Processing (former Sextante) has open tickets on two bugtrackers:
>>>
>>> - the plugin bug tracker, built when it was a plugin, but with a lot of
>>> active tickets -> http://hub.qgis.org/projects/sextante/activity
>>>
>>> - the main bug tracker with a few open tickets ->
>>> http://hub.qgis.org/projects/quantum-gis/issues
>>>
>>> I understand those two can't be merged in one go, because the
>>> plugin-bugtracker has categories (QGIS-Processing SAGA GIS,
>> QGIS-Processing
>>> GRASS GIS etc) that don't fit in the main bug tracker. But this should be
>>> solved ASAP, because the current situation is quite confusing
>>>
>>> Regards
>>> F.
>>>
>>>
>>
>> I'm of the opinion that the tracker should continue to be the Plugin
>> tracker, not the main QGIS tracker. So I'd propse moving any
>> Sextante/Processing tickets from the main or linking them into the
>> Plugin tracker.
>>
>> To me it's still a plugin, just a core plugin but big enough that it's
>> really a subproject. If we wanted to move the Plugin tracker as a
>> sub-project of QGIS that would also make sense.
>>
>> Also Processing bugs aside from Processing not loading aren't
>> showstoppers for release.
>>
>> Thanks,
>> Alex
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Qgis-Processing (former Sextante) has two bug trackers

[Alex Mandel]

On 03/24/2014 05:10 AM, Filipe Dias wrote:
> Hi
> 
> QGIS-Processing (former Sextante) has open tickets on two bugtrackers:
> 
> - the plugin bug tracker, built when it was a plugin, but with a lot of
> active tickets -> http://hub.qgis.org/projects/sextante/activity
> 
> - the main bug tracker with a few open tickets ->
> http://hub.qgis.org/projects/quantum-gis/issues
> 
> I understand those two can't be merged in one go, because the
> plugin-bugtracker has categories (QGIS-Processing SAGA GIS, QGIS-Processing
> GRASS GIS etc) that don't fit in the main bug tracker. But this should be
> solved ASAP, because the current situation is quite confusing
> 
> Regards
> F.
> 
> 

I'm of the opinion that the tracker should continue to be the Plugin
tracker, not the main QGIS tracker. So I'd propse moving any
Sextante/Processing tickets from the main or linking them into the
Plugin tracker.

To me it's still a plugin, just a core plugin but big enough that it's
really a subproject. If we wanted to move the Plugin tracker as a
sub-project of QGIS that would also make sense.

Also Processing bugs aside from Processing not loading aren't
showstoppers for release.

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

Re: [Qgis-developer] [Qgis-user] Installing QGIS Server on RedHat EL 6.5

[Alex Mandel]

e...@lists.osgeo.org

That's who maintains it. At this point though you might need to compile
it yourself.

Thanks,
Alex

On 03/21/2014 04:08 AM, Olivier Dalang wrote:
> Hi,
> 
> I'm moving this discussion to the developers list.
> 
> It seems the repo for QGIS on RHEL is broken. Is there any chance to see it
> fixed soon ? Do you know who's maintaining it ?
> 
> Thanks !
> 
> Olivier
> 
> 
> 
> 2014-03-20 2:38 GMT+01:00 Olivier Dalang :
> 
>> Great that helped !
>>
>> With those two commands :
>>
>> rpm -Uvh
>> http://mirror.centos.org/centos/6/os/x86_64/Packages/qwt-5.1.1-4.1.el6.x86_64.rpm
>> yum install qwt
>>
>>
>> The package resolving went further... but only to give another error :
>>
>> Error Downloading Packages:
>>   qgis-2.0.1-1.el6.x86_64: failure: qgis-2.0.1-1.el6.x86_64.rpm from qgis:
>> [Errno 256] No more mirrors to try.
>>
>> I saw your second reply afterwards, but I don't seem to find how to
>> activate the optional channel.
>> Following [1], I tried
>>
>> rhn-channel --add --channel=rhel-x86_64-server-optional-6
>>
>>
>> But I get prompted for an user name/password...
>>
>> One more hint ?
>>
>>
>>  [1]
>> https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/1/html/Client_Tools_Installation_Guide/Installing_Using_the_Red_Hat_Enterprise_Linux_Optional_Channel.html
>>
>>
>>
>> 2014-03-20 2:20 GMT+01:00 Alex Mandel :
>>
>> On 03/19/2014 06:00 PM, Olivier Dalang wrote:
>>>> Dear List,
>>>>
>>>> I'm trying to install QGIS server on Red Hat Enterprise Linux Server
>>>> release 6.5 (Santiago) by following the instructions provided on
>>> QGIS.org.
>>>> Unfortunately, it doesn't work so far.
>>>>
>>>> Here's what I did :
>>>>
>>>> 1. Add the ELGIS repository (as said here
>>>> http://qgis.org/en/site/forusers/alldownloads.html#qgis-1-8 ).
>>>>
>>>> sudo rpm -Uvh
>>> http://elgis.argeo.org/repos/6/elgis-release-6-6_0.noarch.rpm
>>>>
>>>>
>>>>
>>>> 2. Run these (as said here
>>>> http://qgis.org/en/site/forusers/alldownloads.html#id6 , only I removed
>>>> qgis-grass which I don't need )
>>>>
>>>> sudo wget fedora.vitu.ch/EL/qgis.repo -P /etc/yum.repos.d/
>>>> sudo rpm --import http://fedora.vitu.ch/Fedora/RPM-GPG-Key-vitu
>>>> sudo yum update
>>>> sudo yum install qgis qgis-python qgis-mapserver
>>>>
>>>>
>>>>
>>>> But I get two errors and the installation does not complete :
>>>>
>>>> Error: Package: qwtpolar-0.1.0-5.el6.x86_64 (epel)
>>>>Requires: libqwt.so.5()(64bit)
>>>> Error: Package: qgis-2.0.1-1.el6.x86_64 (qgis)
>>>>Requires: libqwt.so.5()(64bit)
>>>>
>>>>
>>>>
>>>> Being no linux guru, I'm a bit lost about what to do... Any help would
>>> be
>>>> much appreciated !
>>>>
>>>> Thanks,
>>>>
>>>> Olivier
>>>>
>>>
>>> My guess:
>>> sudo yum install qwt
>>>
>>> Might need to find a repo for it, I don't know what the best place to
>>> get it is, here's some info:
>>> http://pkgs.org/centos-6/centos-x86_64/qwt-5.1.1-4.1.el6.x86_64.rpm.html
>>> That package supplies the libqwt.so.5 library
>>>
>>> Enjoy,
>>> Alex
>>>
>>>
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] What about QGis on Raspberry PI ... ?

[Alex Mandel]

The only barrier is QGIS compiling on ARM had some issues the last few
years. Might be fixed soon.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739029

There's no other reason it won't work.

If you're running Debian then it should just be a matter of waiting for
the packages to be available to try.

Thanks,
Alex

On 03/17/2014 05:35 PM, Geo DrinX wrote:
> This is also interesting :
> 
> http://qt-project.org/wiki/Qt-RaspberryPi
> 
> 
> 
> Roberto
> 
> 
> 2014-03-18 1:25 GMT+01:00 Geo DrinX :
> 
>> Hello,
>>
>>
>> I found that Grass ricompiled on Raspberry PI :
>>
>> http://grasswiki.osgeo.org/wiki/Raspberry_Pi
>>
>> :)
>>
>>
>> Roberto
>>
>>
>>
>> 2014-03-16 9:15 GMT+01:00 Geodrinx :
>>
>> Hello All,
>>>
>>> I am interested to know if it could be possible to think about a QGis
>>> recompiling for the Raspberry PI  Linux Debian (Raspbian LXDE).
>>>
>>> Somebody tried ?
>>>
>>> Thank you for any info about this
>>>
>>> Roberto
>>>
>>> Inviato da iPhone
>>
>>
>>
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Problem with GDAL_translate. REST Services, QGIS

[Alex Mandel]

Randy,

So it was working at some point? Is it possible the service has changed?

Thanks,
Alex

On 03/13/2014 11:21 AM, Randal Hale wrote:
> No worries at all!
> 
> I just need to figure out why it stopped working.
> 
> Randy
> 
> -
> Randal Hale, GISP
> North River Geographic Systems, Inc
> http://www.northrivergeographic.com
> 423.653.3611 rjh...@northrivergeographic.com
> twitter:rjhale
> http://about.me/rjhale
> 
> On 03/13/2014 01:55 PM, Lauri Kajan wrote:
>> Hi Randy,
>>
>> I'm really sorry and little embarrassed for my previous post.
>> You sure noticed that I don't have much knowledge in arcgis rest
>> services and especially in using those with gdal.
>>
>> In this case that json isn't a vector data. It is actually a
>> description of a raster service and therefore should be accetable for
>> gdal. This was totally my mistake.
>>
>>
>> -Lauri
>>
>>
>>
>>
>>
>> On Thu, Mar 13, 2014 at 7:28 PM, Alex Mandel
>> mailto:tech_...@wildintellect.com>> wrote:
>>
>> I wouldn't get on his case too hard he's following:
>> http://hub.qgis.org/wiki/quantum-gis/Arcgis_rest
>>
>> There's probably some clues in:
>>
>> http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#/The_ArcGIS_REST_API/02r3005400/
>>
>>
>> I think other workarounds could be to pull the layers in the
>> OpenLayers
>> plugin.
>>
>> Thanks,
>> Alex
>>
>> On 03/13/2014 09:50 AM, Lauri Kajan wrote:
>> > Hi Randy,
>> >
>> > You are requesting json format from arcgisonline. That is a
>> vector format
>> > and you are trying to use it as a raster image.
>> > Secondly you are trying to translate that into WMS with
>> gdal_translate.
>> > Gdal supports WMS-reading only, not creation (
>> > http://gdal.org/formats_list.html).
>> >
>> > I recommend for you some introduction to GIS and raster and
>> vector formats.
>> > http://www.qgis.org/en/docs/gentle_gis_introduction/index.html
>> >
>> >
>> > Regards,
>> >
>> > Lauri
>> >
>> >
>> >
>> >
>> > On Thu, Mar 13, 2014 at 4:51 PM, Randal Hale <
>> > rjh...@northrivergeographic.com
>> <mailto:rjh...@northrivergeographic.com>> wrote:
>> >
>> >> So I figured I would start here and work my way out...or up.
>> Sorry for the
>> >> cross posting. I'm hitting a little bit of everything on this
>> one. Same
>> >> action - different results (sorta). This is all of my attempts
>> at adding a
>> >> REST Service from ArcGISOnline to QGIS (using GDAL in some cases).
>> >>
>> >> On Ubuntu 12.04 LTS gdal 1.10
>> >> This command: gdal_translate "http://server.arcgisonline.
>> >>
>> com/ArcGIS/rest/services/USA_Topo_Maps/MapServer?f=json&pretty=true"
>> >> ESRITopographicLayer.xml -of WMS
>> >> Gives me a segmentation fault
>> >>
>> >> On windows 7 OSGEO4w 32 bit installer gdal 1.10.1
>> >> This command: gdal_translate "http://server.arcgisonline.
>> >>
>> com/ArcGIS/rest/services/USA_Topo_Maps/MapServer?f=json&pretty=true"
>> >> ESRITopographicLayer.xml -of WMS
>> >> Gives me:
>> >> ERROR 4: `/vsimem/http_1/file.dat' not recognised as a
>> supported file
>> >> format.
>> >> ERROR 4: `/tmp/file.dat' not recognised as a supported file
>> format.
>> >> GDALOpen failed - 4
>> >>
>> >> In QGIS 2.2  On windows (OSGEo4W installer) python console:
>> >> qgis.utils.iface.addRasterLayer("http://server.
>> >> arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/
>> <http://arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/>
>> >> MapServer?f=json&pretty=true","raster")
>> >> Gives me an error saying /tmp/file.dat is not a recognized format.
>> >>
>> >> On Ubuntu 12.04 QGIS 2.2 Python Console
>> >> qgis.utils.iface.addRasterLayer("http://server.
>> >> arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/
>> <http://arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/>
>> >> MapServer?f=json&pretty=true","raster")
>> >> Crashes QGIS.
>> >>
>> >> Once again my apologies for cross posting. I *think* it's all
>> related. I
>> >> think.
>> >>
>> >> Randy
>> >>
>> >> --
>> >> -
>> >> Randal Hale, GISP
>> >> North River Geographic Systems, Inc
>> >> http://www.northrivergeographic.com
>> >> 423.653.3611  rjh...@northrivergeographic.com
>> <mailto:rjh...@northrivergeographic.com>
>> >> twitter:rjhale
>> >> http://about.me/rjhale
>> >>
>>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problem with GDAL_translate. REST Services, QGIS

[Alex Mandel]

I wouldn't get on his case too hard he's following:
http://hub.qgis.org/wiki/quantum-gis/Arcgis_rest

There's probably some clues in:
http://resources.arcgis.com/en/help/arcgis-rest-api/index.html#/The_ArcGIS_REST_API/02r3005400/

I think other workarounds could be to pull the layers in the OpenLayers
plugin.

Thanks,
Alex

On 03/13/2014 09:50 AM, Lauri Kajan wrote:
> Hi Randy,
> 
> You are requesting json format from arcgisonline. That is a vector format
> and you are trying to use it as a raster image.
> Secondly you are trying to translate that into WMS with gdal_translate.
> Gdal supports WMS-reading only, not creation (
> http://gdal.org/formats_list.html).
> 
> I recommend for you some introduction to GIS and raster and vector formats.
> http://www.qgis.org/en/docs/gentle_gis_introduction/index.html
> 
> 
> Regards,
> 
> Lauri
> 
> 
> 
> 
> On Thu, Mar 13, 2014 at 4:51 PM, Randal Hale <
> rjh...@northrivergeographic.com> wrote:
> 
>> So I figured I would start here and work my way out...or up. Sorry for the
>> cross posting. I'm hitting a little bit of everything on this one. Same
>> action - different results (sorta). This is all of my attempts at adding a
>> REST Service from ArcGISOnline to QGIS (using GDAL in some cases).
>>
>> On Ubuntu 12.04 LTS gdal 1.10
>> This command: gdal_translate "http://server.arcgisonline.
>> com/ArcGIS/rest/services/USA_Topo_Maps/MapServer?f=json&pretty=true"
>> ESRITopographicLayer.xml -of WMS
>> Gives me a segmentation fault
>>
>> On windows 7 OSGEO4w 32 bit installer gdal 1.10.1
>> This command: gdal_translate "http://server.arcgisonline.
>> com/ArcGIS/rest/services/USA_Topo_Maps/MapServer?f=json&pretty=true"
>> ESRITopographicLayer.xml -of WMS
>> Gives me:
>> ERROR 4: `/vsimem/http_1/file.dat' not recognised as a supported file
>> format.
>> ERROR 4: `/tmp/file.dat' not recognised as a supported file format.
>> GDALOpen failed - 4
>>
>> In QGIS 2.2  On windows (OSGEo4W installer) python console:
>> qgis.utils.iface.addRasterLayer("http://server.
>> arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/
>> MapServer?f=json&pretty=true","raster")
>> Gives me an error saying /tmp/file.dat is not a recognized format.
>>
>> On Ubuntu 12.04 QGIS 2.2 Python Console
>> qgis.utils.iface.addRasterLayer("http://server.
>> arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/
>> MapServer?f=json&pretty=true","raster")
>> Crashes QGIS.
>>
>> Once again my apologies for cross posting. I *think* it's all related. I
>> think.
>>
>> Randy
>>
>> --
>> -
>> Randal Hale, GISP
>> North River Geographic Systems, Inc
>> http://www.northrivergeographic.com
>> 423.653.3611 rjh...@northrivergeographic.com
>> twitter:rjhale
>> http://about.me/rjhale
>>

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

Re: [Qgis-developer] Run stable and master versions of QGIS on Ubuntu

[Alex Mandel]

On 03/11/2014 01:10 PM, Bernd Vogelgesang wrote:
> Am 11.03.2014, 20:35 Uhr, schrieb Eric Goddard :
> 
>> You could try downloading the source package for gdal and modifying
>> the debian/rules file to add the necessary --with-FileGDB and
>> --with-MRSID=... lines. Installing the modified gdal with the package
>> manager should allow it to be used with the stable QGIS from the
>> ubuntuGIS repo and the development version from debian-nightly. I've
>> never actually done this with ubuntu/debian but I do the equivalent on
>> Arch Linux. For ubuntu you would do something like:
>>
>> mkdir ~/build
>> cd ~/build
>> sudo apt-get build-dep gdal
>> apt-get source gdal
>> cd gdal-1.10.0 # or whatever directory it unpacks...
>> nano debian/rules
>> ##edit file to include the necessary --with-FileGDB and --with-MrSID
>> lines and cd back to the main package directory and build the package:
>> cd ..
>> dpkg-buildpackage -us -uc -nc
>>
>> install the packages with something along the lines of
>> sudo dpkg -i gdal*
>>
>> Assuming that worked, you would then probably want to put a hold on
>> gdal so it doesn't get updated and lose your customizations.
>>
>> disclaimer: I have never tried this with ubuntu, but that appears to
>> be the general flow from a little bit of googling.
>>
>> Eric
> 
> Hi Eric,
> thanx a ton for your input.
> I'm still quite unfamiliar with building from source and how all these
> things play together.
> 
> What I still do not get is, why my requirements seem to be so "exotic",
> that there is no easier way for all this. But maybe I manage to solve
> all this and maybe post it somewhere.
> Lots of googling ahead ... after already googling a lot.
> 
>> Assuming that worked, you would then probably want to put a hold on
>> gdal so it doesn't get updated and lose your customizations.
> I assume that too, but how would I do "put a hold on gdal"?
> 
> 
> Cheers
> Bernd


It's called Pinning in the debian world. In synaptic you highlight the
package in the list, then to Package -> Lock Version

The command line fu way is to edit an apt file like this example (just
change the package names)
http://askubuntu.com/questions/23578/how-do-i-pin-a-particular-mysql-version-to-avoid-unnecessary-upgrades

Enjoy,
Alex
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Run stable and master versions of QGIS on Ubuntu

[Alex Mandel]

I run QGIS from ubuntugis repos and build master when the whim strikes
me, like I want to check a new feature.

With handmade GDAL, the answer is a maybe, since you will still get
pre-built geos, proj and QGIS, all of which will work with your custom
rolled GDAL. So that's compiling 1 things instead of 4+
I haven't kept up with how to keep Mrsid and FGDB working but does that
require a whole GDAL recompile? Mrsid used to just require a compile add-on.

The other neat thing is the apt-get build-dep qgis which pulls in all
the -dev libs you need for you.

I think a virtual machine is a good way to keep up on master (and you
can just use the qgis.org built ones) and still have a working stable
build. You can easily share data mounts between.

Thanks,
Alex


On 03/11/2014 10:45 AM, Bernd Vogelgesang wrote:
> Thanx Remi for bringing this up ... I didn't dare to ...
> 
> The problem with compiling the dev version imho is, that you will have
> to recompile it permanently if you are trying to be of any help with bug
> tracking, am I right? (Haven't compiled anything yet, cause I don't get
> rid of the knots in my brain)
> 
> On the other hand, to use QGIS "professionaly", I need GDAL with FGDB
> and MrSID support, so I will have to compile GDAL myself beforehand.
> But wanting to use it for work, I better not use the master version but
> the stable.
> 
> So, as I see it, it would be much better to compile the stable version
> and then get the master version for the candies and the testing from
> debian-nightly.
> But all guidelines propose it the other way round, which I do not really
> understand ...
> 
> Said this, when I want to compile the stable version instead of the
> master, but with a "handmade" GDAL, is there any way to take benefit
> from the ubuntugis-unstable repository (things I can install beforehand
> and then disabling the repository again)?
> 
> As I said, I have knots in my brain on this and never managed to have a
> nice and easy environment on Ubuntu as I have with Windows (which is
> sd)
> Can someone help me with the surgery?
> 
> Cheers
> Bernd
> 
> 
> 
> Am 11.03.2014 17:59, schrieb Alex Mandel:
>> The only non-compile way I can think of on an Ubuntu box would be to run
>> a virtual machine. Otherwise you have to compile to avoid package
>> manager conflicts.
>>
>> So up to you which is more time/hassle to setup.
>>
>> Enjoy,
>> Alex
>>
>> On 03/10/2014 01:26 PM, Etienne Tourigny wrote:
>>> AFAIK, you have to build your own version (preferrably master) with a
>>> different install prefix (e.g. /home/softdev/), and when you want to use
>>> that version you need to add relevant paths to PATH and LD_LIBRARY_PATH.
>>>
>>> I have a shell function that sets this up on demand:
>>>
>>> setup_softdev()
>>> {
>>> export SOFT_PREFIX=/home/softdev
>>> export LD_LIBRARY_PATH="/home/softdev/lib"
>>> export LIBRARY_PATH=/home/softdev/lib
>>> export LD_RUN_PATH=/home/softdev/lib
>>> export PATH=/home/softdev/bin:$PATH
>>> export CPLUS_INCLUDE_PATH=/home/softdev/include
>>> export C_INCLUDE_PATH=/home/softdev/include
>>> export CPPFLAGS=-I/home/softdev/include
>>> export PYTHONPATH=/home/softdev/lib/python2.7/site-packages/
>>> export GDAL_DATA=/home/softdev/share/gdal
>>> }
>>> export -f setup_softdev
>>>
>>>
>>>
>>> On Mon, Mar 10, 2014 at 5:19 PM, Rémi Bovard 
>>> wrote:
>>>
>>>> Hi list,
>>>>
>>>> I'm wondering if there is there a simple way to run stable and master
>>>> versions of QGIS on Ubuntu? By simple, I mean - if possible - without
>>>> compile QGIS from source.
>>>>
>>>> For now, as described in doc [1], I edit /etc/apt/sources.list to
>>>> define
>>>> which repository to use : http://qgis.org/debian or
>>>> http://qgis.org/debian-nightly. But doing like this, I cannot run
>>>> the two
>>>> versions at the same time.
>>>>
>>>> Thank you in advance for your answers.
>>>>
>>>> Rémi
>>>>
>>>> [1] http://qgis.org/en/site/forusers/alldownloads.html#ubuntu
>>>>
>>>>
>>>> ___
>>>> Qgis-developer mailing list
>>>> Qgis-developer@lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

Re: [Qgis-developer] Run stable and master versions of QGIS on Ubuntu

[Alex Mandel]

The only non-compile way I can think of on an Ubuntu box would be to run
a virtual machine. Otherwise you have to compile to avoid package
manager conflicts.

So up to you which is more time/hassle to setup.

Enjoy,
Alex

On 03/10/2014 01:26 PM, Etienne Tourigny wrote:
> AFAIK, you have to build your own version (preferrably master) with a
> different install prefix (e.g. /home/softdev/), and when you want to use
> that version you need to add relevant paths to PATH and LD_LIBRARY_PATH.
> 
> I have a shell function that sets this up on demand:
> 
> setup_softdev()
> {
> export SOFT_PREFIX=/home/softdev
> export LD_LIBRARY_PATH="/home/softdev/lib"
> export LIBRARY_PATH=/home/softdev/lib
> export LD_RUN_PATH=/home/softdev/lib
> export PATH=/home/softdev/bin:$PATH
> export CPLUS_INCLUDE_PATH=/home/softdev/include
> export C_INCLUDE_PATH=/home/softdev/include
> export CPPFLAGS=-I/home/softdev/include
> export PYTHONPATH=/home/softdev/lib/python2.7/site-packages/
> export GDAL_DATA=/home/softdev/share/gdal
> }
> export -f setup_softdev
> 
> 
> 
> On Mon, Mar 10, 2014 at 5:19 PM, Rémi Bovard  wrote:
> 
>> Hi list,
>>
>> I'm wondering if there is there a simple way to run stable and master
>> versions of QGIS on Ubuntu? By simple, I mean - if possible - without
>> compile QGIS from source.
>>
>> For now, as described in doc [1], I edit /etc/apt/sources.list to define
>> which repository to use : http://qgis.org/debian or
>> http://qgis.org/debian-nightly. But doing like this, I cannot run the two
>> versions at the same time.
>>
>> Thank you in advance for your answers.
>>
>> Rémi
>>
>> [1] http://qgis.org/en/site/forusers/alldownloads.html#ubuntu
>>

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

Re: [Qgis-developer] Common QGIS Plugin configuration accross multiple Linux users

[Alex Mandel]

Actually there is a way to handle this.
Puppet http://puppetlabs.com/

The computers running a puppet client will check the master at a given
time interval any files not matching the master conf will be reverted.
You can also use this to install plugins or QGIS itself and repair the
installation of them easily.

Enjoy,
Alex

PS: Yes windows machines can be puppet clients (server might need to be
a nix machine)

On 03/09/2014 02:19 PM, Zoltan Szecsei wrote:
> On 2014/03/09 22:48, Blumentrath, Stefan wrote:
>> Hi Richard,
>>
>> A platform independent solution would be an elegant solution.
>>
>> What we do (on Windows) is having a folder on a server containing QGIS
>> default settings (e.g. reg-files for DB-connections, Connections for
>> web services, but also, most popular plugins, map and print composer
>> templates). These default settings can be imported by the users by
>> executing a simple batch-script we produced for that purpose. If that
>> is of interest for somebody I could post the content of the .bat file...
>>
>>  From that starting point, colleagues can adjust the default settings
>> to their personal needs and preferences...
> This is great - the extra step that I would like to see is that it is
> not only built in and automated, but has controls whereby an
> administrator could "force" certain PCs on the network to only be able
> to use the configs stipulated by the master installation of QGIS.
> When one is managing 15+ PCs it is not trivial to make sure that you
> have copied identical configs to all of them, and to know when someone
> has kindly messed up one of your production PCs.
> Rgds,
> Zoltan
>>
>> Cheers
>> Stefan
>>
>>
>> -Original Message-
>> From: qgis-developer-boun...@lists.osgeo.org
>> [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Richard
>> Duivenvoorde
>> Sent: 9. mars 2014 20:28
>> To: Tim Sutton; Zoltan Szecsei
>> Cc: qgis-developer@lists.osgeo.org
>> Subject: Re: [Qgis-developer] Common QGIS Plugin configuration accross
>> multiple Linux users
>>
>>
>>> ~/.qgis2
>>> and
>>> ~/.config/QGIS
>>>
>>> You could e.g. rsync the user plugin dirs from a central one, or put
>>> them in an nfs mount (read only might have issues as plugins try to
>>> write .pyc files or even write data to the plugin dir).
>>>
>>> The ~/.config/QGIS/QGIS2.conf is a standard ini style config file so
>>> you should be able to pick through it and awk/sed/bash your way to
>>> nirvana :-)
>> I'm actually thinking about to make this OS independent, by creating a
>> 'save QSettings' as file option. Then with a command line option you
>> would be able to (just before reading the QSettings) actually
>> read/write this settings file back into user settings. Thereby making
>> it possible to for example transfer a certain setup across a class
>> room (as long as the plugins are available in .qgis2 off cours).
>>
>> Would this work? Or do I miss something?
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 

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

Re: [Qgis-developer] My God: plugin palette disappeared :(

[Alex Mandel]

On 03/07/2014 11:27 AM, Jürgen E. Fischer wrote:
> Hi Alex,
> 
> On Fri, 07. Mar 2014 at 10:52:42 -0800, Alex Mandel wrote:
>> Where to find the QGIS.conf file varies by OS and install method.
> 
> This might be better:
> 
> #!/usr/bin/python
> from PyQt4.QtCore import QSettings
> QSettings( "QGIS", "QGIS2" ).remove( "/UI/state" )
> QSettings( "QGIS", "QGIS2" ).remove( "/ComposerUI/state" )
> 
> 
> (for 1.8 it's QGIS instead of QGIS2 IIRC).
> 
> 
> Jürgen 
> 

Seems like adding a tool/plugin/command to reset GUI to defaults should
be easy.

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

Re: [Qgis-developer] My God: plugin palette disappeared :(

[Alex Mandel]

On 03/07/2014 09:54 AM, Larry Shaffer wrote:
> Hi Jeff,
> 
> Apologies for jumping into your conversation with Tim, but that issue with
> 1.8 was fixed before the 2.0 release [0]. I recommend, if possible, finding
> a means of your students running 2.0.1 or 2.2.0, where a user can now just
> select the items under the View menu. There are a couple workarounds for
> 1.8 listed on the issue page, however.
> 
> If it is some dialog disappearing in the main app, that is probably a
> separate issue.
> 
> [0] http://hub.qgis.org/issues/6125
> 
> Regards,
> 
> Larry
> 
> 
> On Fri, Mar 7, 2014 at 6:24 AM, Jeff McKenna
> wrote:
> 
>> On 2014-03-07, 9:07 AM, Tim Sutton wrote:
>>>
>>>
>>> What is a plugin palette? Do you mean the toolbar?
>>>
>>> Can you provide a screenshot of your running QGIS.
>>>
>>> Have you tried right clicking on the blank space in the toolbar area and
>>> checking if it is enabled.
>>>
>>> Did you maybe accidentally drag it and drop it somewhere and it is
>>> displaying in compressed mode?
>>>
>>> I'm not sure if your life will be any better in Arc* :-P
>>>
>>
>> Hi Tim,
>>
>> You mention something that awoke me here ha.  I teach intro to GIS at a
>> local college this term, and of course I am using QGIS (1.8, yes I know
>> old, but I am lucky to have anything installed in their locked down
>> environment).  The one problem that the students face constantly, and
>> the one problem I cannot solve, yet, is when they do something like you
>> just mentioned: they drag and drop a dialog somewhere, close it, undock
>> it, or I'm not sure what they are doing exactly...and then anytime they
>> start GIS on that same machine that dialog is no where to be found (and
>> for the life of me I cannot find how to turn it back on for them).  I
>> have struggled all term with this.  One example are the Properties
>> dialog windows in the Print Composer - students do something it seems to
>> close these, and they can never be seen ever again.
>>
>> I know, maybe this is solved in QGIS 2.2, but I just wanted to give you
>> this feedback.  I love QGIS, but this one thing keeps coming back to
>> bite me in the butt.  Ha.
>>
>> Talk soon my friend,
>>
>> -jeff
>>

This problem is some ways exists in both Arc and QGIS. Students make a
toolbar disappear and can't seem to get it back. Sometimes you just need
to re-enable it in the View->Toolbars

But often what you need to do is reset the GUI back to defaults which
can be done by clearing out the QGIS.conf file. Note doing this will
also destroy stored databases links and web service urls. Good news is
that you can save out those parts of the text and add them back in.

Where to find the QGIS.conf file varies by OS and install method.

Thanks,
Alex

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

Re: [Qgis-developer] uploading plugin files to hub.qgis.org

[Alex Mandel]

Are you trying to upload a release of your plugin or looking to host the
source code and bug tracker of the plugin?

Release of plugins is handled separately via plugins.qgis.org

What you've pointed out is a bug that the admins need to figure out why
something changed. I have a working repo key with hub as do many others,
so the interface was there at some point. I'm copying the person who
originally setup the site to see if they know what's going on.

Thanks,
Alex

On 03/05/2014 12:18 AM, Giuseppe De Marco wrote:
> Allright then what is the working procedure to upload a plugin
> other than having an external git repo.
> Besides given that you have to upload to an external
> server how can you modify your repository configuration
> inside hub.qgis.org to point to your external repo?
> 
> thank you!
> 
> 2014-03-04 21:21 GMT+01:00 Alex Mandel :
>> On 03/04/2014 04:33 AM, Giuseppe De Marco wrote:
>>> Hello,
>>> I have registered at hub.qgis.org and I have created 2 subprojects 
>>> activating
>>> the option repository in settings.
>>> I have some problems authenticating with git:
>>> 1) I cannot upload my public key because it says that
>>> http://hub.qgis.org/my/public_keys page not found
>>> 2) obviously when I try to git push origin it asks for a password..
>>>
>>> this is what I get
>>> joe@U36SD:~/.qgis2/python/plugins/SelectTools$ git remote -v
>>> origingito...@qgis.org:selecttools.git (fetch)
>>> origingito...@qgis.org:selecttools.git (push)
>>>
>>> can somebody help me out?
>>>
>>> Thank you
>>>
>>
>> You are right, something is amiss. I can't tell which Redmine plugin is
>> supposed to handle that. I expected to see something like the Gitosis
>> plugin but there's only a post-commit hook and a qgis customization
>> plugin. Neither of which integrate with git keys on the back end.
>>
>> Did someone change the configuration of Redmine?
>>
>> Thanks,
>> Alex
> 
> 
> 

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

Re: [Qgis-developer] uploading plugin files to hub.qgis.org

[Alex Mandel]

On 03/04/2014 04:33 AM, Giuseppe De Marco wrote:
> Hello,
> I have registered at hub.qgis.org and I have created 2 subprojects activating
> the option repository in settings.
> I have some problems authenticating with git:
> 1) I cannot upload my public key because it says that
> http://hub.qgis.org/my/public_keys page not found
> 2) obviously when I try to git push origin it asks for a password..
> 
> this is what I get
> joe@U36SD:~/.qgis2/python/plugins/SelectTools$ git remote -v
> origingito...@qgis.org:selecttools.git (fetch)
> origingito...@qgis.org:selecttools.git (push)
> 
> can somebody help me out?
> 
> Thank you
> 

You are right, something is amiss. I can't tell which Redmine plugin is
supposed to handle that. I expected to see something like the Gitosis
plugin but there's only a post-commit hook and a qgis customization
plugin. Neither of which integrate with git keys on the back end.

Did someone change the configuration of Redmine?

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

Re: [Qgis-developer] How to manage a centralized repository of plugins?

[Alex Mandel]

On 03/04/2014 07:29 AM, HAUBOURG wrote:
> Hi All,
> I'm currently installing QGIS 2.2 in my administration, and suddenly 
> discovered an (new ?) behaviour.
> We put some "mandatory" plugins on a network drive, and every client is open 
> with the environnement variable QGIS_PLUGINPATH to use that centralized place.
> Problem occurs when upgrading a plugin there. Default conf of the QGIS 
> clients activates the plugins, but it seems that the installer checks if the 
> version has changed, and if yes, deactivates the plugin.
> That means QGIS stores detailed informations about installed plugin 
> somewhere, but I couldn't find it in .ini (or registry key). Anyone knows how 
> it works?
> Secondly, this implies that I don't know how to manage those plugins, since 
> they will be unloaded by default... Any idea on how to do that?
> 
> Cheers
> Régis
> 

For a centralized repo its recommended to use a webserver with an xml
file like the one described here:
http://www.qgisworkshop.org/html/workshop/repositories.html

Then you just give QGIS the url to that xml file and it handles the
detection of newer versions whenever the server gets updates.

I'm not 100% sure but qgis might not check the version of current
plugins until you open the updater tool. Maybe one of the devs can chime
in if it's stored in a file somewhere, I guarantee it's not a registry
item since thats not cross platform. List of plugins is in QGIS.conf
(location varies by OS) with a true/false for activation but not the
version of the plugins.

Thanks,
Alex

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

Re: [Qgis-developer] Installing QGIS server

[Alex Mandel]

On 03/02/2014 08:09 PM, Richard Duivenvoorde wrote:
> 
> n 02-03-14 19:10, Tim Sutton wrote:
>> Hi Richard
>>
>>
>> On Sun, Mar 2, 2014 at 7:30 PM, Richard Duivenvoorde
>> mailto:rdmaili...@duif.net>> wrote:
>>
>>
>> I'm running Jessie here and there, and bumped upon the following thing:
>>
>> This stuff:
>> 2.2 configuration:
>> Order deny,allow
>> Deny from all
>> becomes
>> 2.4 configuration:
>> Require all denied
>>
>>
>> Yeah iirc I had done that but still wasnt getting it to work. I have to
>> revisit the test machine I was using to give more details.
> 
> now I remember some other Debian specific thing, that took me some time
> to find out: since a certain update the config files (or links in
> /etc/apache2/sites-enabled have to have the .conf extention. I had an
> old server which was upgraded, and my configs was named 'qgis.nl', I had
> to rename it to qgis.nl.conf (and the 'require' fix').
> 
> See: http://www.debianuserforums.org/viewtopic.php?f=56&t=2561
> 
> HTH
> 
> Richard Duivenvoorde
> 
> ps I know I've read it somewhere in

I think this was a change implemented in Apache 2.4 at least on
Debian/Ubuntu variants. I too have had to add the .conf to the end of
vhost config files.

Thanks,
Alex

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

Re: [Qgis-developer] Finding duplicate records

[Alex Mandel]

On 02/28/2014 02:46 AM, Paolo Cavallini wrote:
> Hi all.
> I can't recall of any function or plugin to find duplicate data ona
> table of attributes: am I right, or am I forgetting something?
> Thanks in advance.
> 

I always use Spatialite or Postgis so I can run a DISTINCT function in a
query, or GROUP BY what should be unique and get a count (if it's > 1
it's not unique). I'm not aware of any other way to check for duplicate
data.

Enjoy,
Alex
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer