Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
I guess what I'm getting at is what is it used for outside of, and not within 
qgis. Are they used for queries? (Also, ctid can change on vacuum, as such they 
can't be relied upon outside the query (with any guarantees.) How would the 
situation be different if qgis used an incremental, internal integer? It's a 
guaranteed unique value (can't be said for oid or any column without an actual 
unique constraint), it just can't be persisted (can't be said for the ctid or a 
windowed function).

As I mentioned, qgis will accept non-unique fields as the primary key for a 
view (after being loaded, I don't expect that to be checked beforehand), so 
qgis isn't attempting to store the primary key in a constrained data store? 
This is what I'm most confused about. Why am i , as a user, being (poorly) to 
give qgis the name of the pk, when a non-unique field is just as acceptable?

Jim

On September 1, 2015 12:09:28 PM EDT, Matthias Kuhn  wrote:
>On 09/01/2015 05:54 PM, James Keener wrote:
>> We also need to ask what qgis is doing with this and why we need to
>> bug the user about it at all.
>>
>> Why do we not big the user about tables without a primary key? If
>> tables can be loaded without a pk, why can't views.
>QGIS relies on feature ids for a lot of different things to
>unambiguously identify features.
>
>For tables there is a (also not optimal) ctid which can be used as
>feature id:
>http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
>For views there is none (see
>http://www.postgresql.org/docs/9.1/static/rules-views.html, section
>37.2.4)
>>
>> Why can I select non-unique columns as primary keys and after loading
>> the layer get no error?
>Because a lot of things in QGIS rely on feature ids and see above why
>the fallback which exists for tables does not work for views.
>Especially - but not only - editing. See my proposal #4.
>>
>> Are these also bugs? Should I make (or find?) tickets for them?
>>
>> Jim
>>
>> On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>>  wrote:
>>
>> Hi,
>>
>> I would like to second Andreas, what we need is an improvement in
>the UI
>> to make the user aware of the problem.
>>
>> My proposal (please review and improve)
>>
>> 1. Let the user choose whatever table/view he likes. Don't
>disable any
>> items.
>> 2. If there are tables without a PK open a second modal dialog
>with an
>> explanation of the problem and offer to select a pk from a
>combobox.
>>
>> -
>>
>> 3. Optional: Add a button "search suitable pk" which looks for a
>> suitable unique column.
>> 4. Optional: Add a selection "read-only" to the combobox and do
>some
>> row_number() or other black magic and warn the user with a big
>red
>> dialog that he's about to do something very dangerous, unreliable
>and
>> that his warranty is now very void.
>>
>> Best,
>> Matthias
>>
>> On 09/01/2015 05:36 PM, Andreas Neumann wrote:
>>
>> Hi, I would regard the loading of layers from a database
>> something "relatively advanced". Normally I prepare ready to
>> use QGIS project to my users who edit and query our GIS data
>> where they don't have to bother with loading layers. But you
>> are correct that it can be different persons - the one who
>> creates the view and the ones who are loading them. You are
>> welcome to improve the situation/GUI, but please don't go
>back
>> to the old behavior where it is an assumption that the first
>> column in the list is always the primary key. Andreas On
>> 01.09.2015 14:51, James Keener wrote:
>>
>> Why are you assuming the user who created the view is the
>> one using QGIS? Jim On 09/01/2015 08:50 AM, Andreas
>> Neumann wrote:
>>
>> Hi, I agree with Jürgen - better let the user choose
>> the pkey column. If the user knows how to create a
>> Postgis View he also knows how to select a primary
>key
>> column. Andreas On 01.09.2015 14:37, Jürgen E.
>Fischer
>> wrote:
>>
>> Hi Sandro, On Tue, 01. Sep 2015 at 13:48:33
>+0200,
>> Sandro Santilli wrote:
>>
>> I agree with Luca this should have been
>better
>> not backported to 2.8.3. Only proper bugs
>> should be backported, and this was a
>> (debatable) GUI enhancement, as far as I can
>> tell. 
>>
>> We intend to only backport fixes and not bugs. ;)
>> You were always supposed to select the key column
>> - preselecting the first column was the bug (also
>> debatable). And #11317 is a ticket that
>> demonstrates there were unaware users. That the
>> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Matthias Kuhn
PS: I'm sure a pull request for compound primary keys will gladly be
merged :-)

On 09/01/2015 07:15 PM, James Keener wrote:
> I don't disagree that it's a bad practice. However, is qgis a tool
> that you work with or around? Do we want to say "your data must have X
> as part of its schema or qgis can't use it" or will qgis make the best
> it can with poor data. Honestly, being loudly opinionated is a valid
> option if the developers feel it doesn't decrease the user experience
> drastically.
>
> I'd also like to point out that the primary key need not be a single
> field. For instance (state_fips, county_fips) could be a valid key for
> county-based metrics. Going back to the previous question I posed, do
> we want to tell users to conform to a single-field primary key or will
> qgis accept valid schema designs. Again, it comes down to dev time vs
> the cost to the user experience.
>
> Jim
>
> On September 1, 2015 12:42:56 PM EDT, "Leknín Řepánek"
>  wrote:
>
> Situation with a view without unique (and indexed) key is bad database
> model, or bad query. Using window function is unefficient, but i can't
> find another way to make unique column on query with duplicities in
> records. In query without duplicities is possible to use oid (but this
> needs tables with oids), or ctid (but ctid is slow).
>
> Sorting in row_number can be defined in (ORDER BY ...). But is
> unefficient (as you say). But works well for display smaller parts of
> data (thousands of features).
>
> Materialized view can be indexed. But this is about use case and it isnt
> a "pretty solution".  
>
> Je;
>
> On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
>
> Please stop saying this. It's fine for certain situations, but
> it is not a permanently unique identifier for a row. It may
> change when the underlying table is altered. Sure, it's unique
> if you read the results and keep them in memory and never talk
> about it again, but qgis does that on its own already.
> Moreover querying on it is extremely inefficient. Querying
> against it forces a sequence scan on the table. Depending on
> the table and version, it could also try to materialize the
> view fully in memory before doing the scan. Jim On September
> 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>  wrote: Workaround about primary key
> in view, i had use sever times is using window function
> "row_number() over()". It works in views and in query from
> database manager. Je; On Tue, Sep 01, 2015 at 04:09:49PM
> +0200, Sandro Santilli wrote: On Tue, Sep 01, 2015 at
> 02:37:22PM +0200, Jürgen E. Fischer wrote: Hi Sandro, On Tue,
> 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote: I agree
> with Luca this should have been better not backported to
> 2.8.3. Only proper bugs should be backported, and this was a
> (debatable) GUI enhancement, as far as I can tell. We intend
> to only backport fixes and not bugs. ;) You were always
> supposed to select the key column - preselecting the first
> column was the bug (also debatable). And #11317 is a ticket
> that demonstrates there were unaware users. Reading #11317 I
> looks to me that the reported bug was about "Add PostGIS
> Layer" not giving the user full detail of why a layer could
> not be loaded: "is an invalid layer - not loaded". In this I
> agree with Aren here: http://hub.qgis.org/issues/11317#note-6
> That the first column often happens to be the primary key and
> and the combobox is not lexically sorted is somewhat pure luck
> - and unless you avoid having the key verified (using "use
> estimated metadata"), keeping a wrongly select column will
> make the layer to insert invalid. I agree that the reported
> regression was based on the false expectation that QGIS would
> pick a primary key automatically, but in the (unlikely?) case
> a user was aware of that and properly coded the view to ensure
> primary key was first (or only) numeric the change was indeed
> a degradation of the experience. But I agree that the tooltip
> that you get on disabled lines (not only for the key
> selection, but also geometry type and srid) might not be
> visible enough (but that IMHO would be just a GUI
> enhancement). There should maybe be another rule about LTS
> backports being: debatable fixes/enhancement need to be
> debated more on list ? --strk;
> 
> ━━━
> Qgis-user mailing list Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
I don't disagree that it's a bad practice. However, is qgis a tool that you 
work with or around? Do we want to say "your data must have X as part of its 
schema or qgis can't use it" or will qgis make the best it can with poor data. 
Honestly, being loudly opinionated is a valid option if the developers feel it 
doesn't decrease the user experience drastically.

I'd also like to point out that the primary key need not be a single field. For 
instance (state_fips, county_fips) could be a valid key for county-based 
metrics. Going back to the previous question I posed, do we want to tell users 
to conform to a single-field primary key or will qgis accept valid schema 
designs. Again, it comes down to dev time vs the cost to the user experience.

Jim

On September 1, 2015 12:42:56 PM EDT, "Leknín Řepánek" 
 wrote:
>Situation with a view without unique (and indexed) key is bad database
>model, or bad query. Using window function is unefficient, but i can't
>find another way to make unique column on query with duplicities in
>records. In query without duplicities is possible to use oid (but this
>needs tables with oids), or ctid (but ctid is slow).
>
>Sorting in row_number can be defined in (ORDER BY ...). But is
>unefficient (as you say). But works well for display smaller parts of
>data (thousands of features).
>
>Materialized view can be indexed. But this is about use case and it
>isnt
>a "pretty solution".  
>
>Je;
>
>On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
>> Please stop saying this. It's fine for certain situations, but it is
>not a
>> permanently unique identifier for a row. It may change when the
>underlying
>> table is altered. Sure, it's unique if you read the results and keep
>them in
>> memory and never talk about it again, but qgis does that on its own
>already.
>> 
>> Moreover querying on it is extremely inefficient. Querying against it
>forces a
>> sequence scan on the table. Depending on the table and version, it
>could also
>> try to materialize the view fully in memory before doing the scan.
>> 
>> Jim
>> 
>> On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>>  wrote:
>> 
>> Workaround about primary key in view, i had use sever times is
>using
>> window function "row_number() over()". It works in views and in
>query
>> from database manager.
>> 
>> Je;
>> 
>> On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>>  On Tue, Sep 01, 2015 at 02:37:22PM +0200, Jürgen E. Fischer
>wrote:
>>  Hi Sandro,
>> 
>>  On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli
>wrote:
>>  I agree with Luca this should have been better not
>backported to 2.8.3.
>>  Only proper bugs should be backported, and this was
>a (debatable)
>>  GUI enhancement, as far as I can
>> tell.
>> 
>>  We intend to only backport fixes and not bugs. ;)
>> 
>>  You were always supposed to select the key column -
>preselecting the first
>>  column was the bug (also debatable).  And #11317 is a
>ticket that demonstrates
>>  there were unaware users.
>> 
>>  Reading #11317 I looks to me that the reported bug was about
>>  "Add PostGIS Layer" not giving the user full detail of why a
>>  layer could not be loaded: "is an invalid layer - not
>loaded".
>>  In this I agree with Aren here:
>http://hub.qgis.org/issues/11317#note-6
>> 
>>  That the first column often happens to be the primary
>key and and the combobox
>>  is not lexically sorted is somewhat pure luck - and
>unless you avoid having the
>>  key verified (using "use estimated metadata"),
>> keeping a wrongly select
>>  column will make the layer to insert invalid.
>> 
>>  I agree that the reported regression was based on the false
>expectation
>>  that QGIS would pick a primary key automatically, but in the
>>  (unlikely?) case a user was aware of that and properly coded
>the view
>>  to ensure primary key was first (or only) numeric the change
>was
>>  indeed a degradation of the experience.
>> 
>>  But I agree that the tooltip that you get on disabled
>lines (not only for the
>>  key selection, but also geometry type and srid) might
>not be visible enough
>>  (but that IMHO would be just a GUI enhancement).
>> 
>>  There should maybe be another rule about LTS backports
>being:
>>  debatable fixes/enhancement need to be debated more on list
>?
>> 
>>  --strk;
>>
>━━━
>> 
>>  Qgis-user mailing
>> list
>>  Qgis-user@lists.osgeo.org
>>  http://lists.osgeo.org/mailman/listinfo/qgis-user
>>

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Matthias Kuhn
Hi Jim,

Feature ids are used for communication with the data source, basic CRUD
operations.

* Want to change attribute X of feature F: update table set x = newvalue
where id = featureid
* Want to query a set of features? select* from table where id in (id1,
id2, id3)... (e.g. often used by plugins with selected features)
etc... you get the point.

Feature ids are used as temporary references inside qgis when using
forms, selections and tons of other things.

Ctids are definitely a bad choice (I see you read the docs :) ). But
they tend to work and are certainly more stable than anything you can
generate on a view at query time and faster as well.

QGIS does not enforce a unique column. But it expects it.
IMHO it's a question of communicating this expectation of QGIS to the
user at an appropriate time and *optionally* offering heuristics, tools
and checks to identify suitable columns (--> it all comes down to the
requirement of development time being contributed or contracted).

Unfortunately there is no simple "one-suits-all" solution to this.

Regards Matthias

On 09/01/2015 06:58 PM, James Keener wrote:
> I guess what I'm getting at is what is it used for outside of, and not
> within qgis. Are they used for queries? (Also, ctid can change on
> vacuum, as such they can't be relied upon outside the query (with any
> guarantees.) How would the situation be different if qgis used an
> incremental, internal integer? It's a guaranteed unique value (can't
> be said for oid or any column without an actual unique constraint), it
> just can't be persisted (can't be said for the ctid or a windowed
> function).
>
> As I mentioned, qgis will accept non-unique fields as the primary key
> for a view (after being loaded, I don't expect that to be checked
> beforehand), so qgis isn't attempting to store the primary key in a
> constrained data store? This is what I'm most confused about. Why am i
> , as a user, being (poorly) to give qgis the name of the pk, when a
> non-unique field is just as acceptable?
>
> Jim
>
> On September 1, 2015 12:09:28 PM EDT, Matthias Kuhn
>  wrote:
>
> On 09/01/2015 05:54 PM, James Keener wrote:
>
> We also need to ask what qgis is doing with this and why we
> need to bug the user about it at all. Why do we not big the
> user about tables without a primary key? If tables can be
> loaded without a pk, why can't views. 
>
> QGIS relies on feature ids for a lot of different things to
> unambiguously identify features.
>
> For tables there is a (also not optimal) ctid which can be used as
> feature id:
> http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html
>
> For views there is none (see
> http://www.postgresql.org/docs/9.1/static/rules-views.html, section 
> 37.2.4)
>
> Why can I select non-unique columns as primary keys and after
> loading the layer get no error? 
>
> Because a lot of things in QGIS rely on feature ids and see above why
> the fallback which exists for tables does not work for views.
> Especially - but not only - editing. See my proposal #4.
>
> Are these also bugs? Should I make (or find?) tickets for
> them? Jim On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>  wrote: Hi, I would like to second
> Andreas, what we need is an improvement in the UI to make the
> user aware of the problem. My proposal (please review and
> improve) 1. Let the user choose whatever table/view he
> likes. Don't disable any items. 2. If there are tables without
> a PK open a second modal dialog with an explanation of the
> problem and offer to select a pk from a combobox.
> - 3. Optional: Add a button "search suitable pk"
> which looks for a suitable unique column. 4. Optional: Add a
> selection "read-only" to the combobox and do some row_number()
> or other black magic and warn the user with a big red dialog
> that he's about to do something very dangerous, unreliable and
> that his warranty is now very void. Best, Matthias On
> 09/01/2015 05:36 PM, Andreas Neumann wrote: Hi, I would regard
> the loading of layers from a database something "relatively
> advanced". Normally I prepare ready to use QGIS project to my
> users who edit and query our GIS data where they don't have to
> bother with loading layers. But you are correct that it can be
> different persons - the one who creates the view and the ones
> who are loading them. You are welcome to improve the
> situation/GUI, but please don't go back to the old behavior
> where it is an assumption that the first column in the list is
> always the primary key. Andreas On 01.09.2015 14:51, James
> Keener wrote: Why are you assuming the user who created the
> view is the 

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread John Harrop
I personally like the geographic names and never thought about them as 
potentially problematic. They seem to fit the context and I always like to see 
the interesting maps that go with each. 

Perhaps a randomizing system like they do with hurricanes would help?

John

Sent from my iPhone

> On Sep 1, 2015, at 3:45 PM, Nathan Woodrow  wrote:
> 
> Hey,
> 
> I think we really should just stick to what we are already doing. Run though 
> all the names like Andreas said, even if we lock in the release names now.  
> There isn't going to be any harm in that.  If we run out of HF place names 
> another cool idea might be to use the place names of core developers home 
> towns, that would give us at least 30+ by the time that rolls around.
> 
> Regards,
> 
>> On Mon, Aug 31, 2015 at 6:24 PM, Anita Graser  wrote:
>> 
>> On Aug 31, 2015 9:22 AM, "Andreas Neumann"  wrote:
>> > Well - we are not running out to soon of dev-meeting locations
>> 
>> Thanks Andreas! I did check the meeting list. Please note that I'm not only 
>> asking for names but also splash materials since sourcing those can be very 
>> time consuming.
>> 
>> Best wishes 
>> Anita
>> 
>> 
>> 
>> 
>> 
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread James Keener
We could always use silly names.

Qgisor
Qgisisimo
Qgisinator
Qgisette
Qgisador
Qgis: a new hope
Qgis: the next generation
Qgis5
Qgis: or how I learned to stop worrying and love gis
Qgisamation
Qgisactica
Qgis: everywhere
Qgis 1138
Qgis 2001: a geospatial oddesy
Qgis who
Quails Gulls Iiwis and Sirysteses
Qgis fantastique
Qgis: what you will

(That's like 6 years of names!)

But in all seriousness, a bias in geographic locations based on where 
developers and users are isn't the worst bias. I also enjoy the old map imagery.

Jim


On September 1, 2015 5:02:47 PM EDT, "Jürgen E. Fischer"  wrote:
>Hi Mats,
>
>On Tue, 01. Sep 2015 at 17:06:23 +0200, Mats Elfström wrote:
>> Once, Qgis versions were named after planetary moons. We probably ran
>> out of those, at least those known to the public.
>
>Nope, there are probably plenty left.  But we stopped using them
>because there
>was a trademark claim on some of the moons we used by a company that
>already
>used it for their software product.
>
>> Place names can be biased, like: now it's time for a latin american
>name and
>> so on.
>
>We already had a latin american name: Copiapo.
>
>
>> May I suggest the periodic table of elements as base for the naming
>instead.
>> By cleverly using the groups one could even indicate major/minor
>version
>> changes.
>
>Not sure if that's safer than moons.
>
>
>Jürgen
>
>-- 
>Jürgen E. Fischer   norBIT GmbH Tel.
>+49-4931-918175-31
>Dipl.-Inf. (FH) Rheinstraße 13  Fax.
>+49-4931-918175-50
>Software Engineer   D-26506 Norden
>http://www.norbit.de
>QGIS release manager (PSC)  GermanyIRC: jef on
>FreeNode 
>
>
>
>
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread John Harrop
Any suggestions on how to "cloudify" PostGIS?  I would like to use it as well 
and shared across more than the local network. 

Cheers, 

John

Sent from my iPhone

> On Sep 1, 2015, at 9:38 AM, didier peeters  wrote:
> 
> Arni,
> 
> Postgis is certainly an excellent option.  
> Regarding the data sources, currently QGis cannot use relative paths to files 
> or photos (at least) but to svg's in styling (and maybe other, I don’t have 
> an exhaustive list). One option to bypass the files issue would be to use a 
> web server and store URL instead of internal paths.  For instance you could 
> have a web server, and whenever a file (or photo) is added generate with a 
> Postgresql trigger the corresponding url in another attribute, making the 
> file available to all the users, either through a form or through an action.  
> 
> Didier
> 
> 
>> Le 1 sept. 2015 à 17:45, Árni Geirsson  a écrit :
>> 
>> Thanks Jim
>> Your answer encourages me to try the PostGIS option - it obviously has some 
>> other useful advantages. But your reply also made me realize that the 
>> problem is really that much of the data I have is on another network share - 
>> hence the problem with the paths. I should simply move the data so that 
>> everything is on the same share and and then, relative paths will solve the 
>> problem.
>> Again, thank you for a very helpful answer.
>> 
>> Arni
>> 
>> 
>> Árni Geirsson
>> Alta ehf // +354 582 5000 // +354 897 9549
>> www.alta.is  // Alta á Twitter // Alta á Facebook
>> 
>>> On Tue, Sep 1, 2015 at 3:26 PM, James Keener  wrote:
>>> Re: postgresql in my experience it's neither cumbersome nor slow. Feel free 
>>> to email me for help if you would like to explore that route.
>>> 
>>> Are the paths in you qgs file relative or absolute? If their relative, is 
>>> the issue that the path separator is different? If that is the issue, I 
>>> would file a bug report. (If they are absolute, try saving them with 
>>> relative paths.)
>>> 
>>> Jim
>>> 
 On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson"  wrote:
 Hi
 I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as 
 well as the PCs) and accesses data on a shared drive. Now the problem 
 comes up that data sources have different paths to the shared drive in 
 each operating system, making cooperation difficult. On the other hand, 
 since the .qgs file is easy to edit, some simple solution might map the 
 paths automatically on open and back on save, to compensate for these 
 differences. And maybe there is some other solution out there. 
 I realize that having all shared data in PostGIS might be one way to solve 
 this but I suspect that it might be both slower and a little more 
 cumbersome.
 All thoughts and suggestions are highly appreciated.
 
 Árni Geirsson
 
 
 
 Qgis-user mailing list
 Qgis-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user
>>> 
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> 
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] request

2015-09-01 Thread yoon yoon
i am form myanmar forest department.
i working RS process so we should need technology and software (human
resourse) from your Org:
please, we will be hope from your supply.


Good luck

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

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Nathan Woodrow
Hey,

I think we really should just stick to what we are already doing. Run
though all the names like Andreas said, even if we lock in the release
names now.  There isn't going to be any harm in that.  If we run out of HF
place names another cool idea might be to use the place names of core
developers home towns, that would give us at least 30+ by the time that
rolls around.

Regards,

On Mon, Aug 31, 2015 at 6:24 PM, Anita Graser  wrote:

>
> On Aug 31, 2015 9:22 AM, "Andreas Neumann"  wrote:
> > Well - we are not running out to soon of dev-meeting locations
>
> Thanks Andreas! I did check the meeting list. Please note that I'm not
> only asking for names but also splash materials since sourcing those can be
> very time consuming.
>
> Best wishes
> Anita
>
>
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Basques, Bob (CI-StPaul)
We use a “Space Objects” descriptor here for our large format plotters and 
printer naming . . .

Like:

  *   Blackhole
  *   Nebula
  *   Galaxy
  *   Aurora
  *   Meteor
  *   Asteroid
  *   Fireball
  *   Supernova
  *   Star

etc.

Should provide enough fodder for naming for  while.  Also fairly generic and 
can get obscure if you want to.

Just to get you all started . . .

http://www.macmillandictionary.com/us/thesaurus-category/american/planets-stars-and-other-objects-in-space

Oooh, “Antimatter”, that’s the next plotter name !!

bobb




On Sep 1, 2015, at 4:02 PM, Jürgen E. Fischer 
> wrote:

Hi Mats,

On Tue, 01. Sep 2015 at 17:06:23 +0200, Mats Elfström wrote:
Once, Qgis versions were named after planetary moons. We probably ran
out of those, at least those known to the public.

Nope, there are probably plenty left.  But we stopped using them because there
was a trademark claim on some of the moons we used by a company that already
used it for their software product.

Place names can be biased, like: now it's time for a latin american name and
so on.

We already had a latin american name: Copiapo.


May I suggest the periodic table of elements as base for the naming instead.
By cleverly using the groups one could even indicate major/minor version
changes.

Not sure if that's safer than moons.


Jürgen

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

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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Jürgen E . Fischer
Hi James,

On Tue, 01. Sep 2015 at 08:50:27 -0400, James Keener wrote:
> At the very least, don't tell people to use ROW_NUMBER() as a primary
> key.  This is just terrible advice!

FTR I didn't suggest using row_number().

> Also, I'm running 2.10.1 and when I add a view on a table with no unique
> values, and even if I select a non-unique field as my primary key, QGIS
> will happily load the view, not complain about the cardinality of the
> "primary key" being less than the carnality of the rows, and proceed to
> draw the geometries correctly and let me select features and will show
> me the correct attributes. 

You are using "use estimated metadata"?  Otherwise QGIS should have checked if
the selected pk is actually unique.   And you will only notice that there is
something wrong when you select features that have a non unique key.

> Now, go to QGIS, select column 'a' as the "primary key".  You'll see 3
> points, and you'll be able to get the correct attribute values for each

Because the features are retrieved by geometry and not by key in identify.

Select a feature and you'll find that selecting one will select all - because
we just store that feature id 1 was selected.

And as we usually don't cache features we have nothing to tie some sort of
internally generate key to the feature.

> If tables can be used without selecting a primary key, why must views?

Because for tables we can use ctid as last resort - but not that also makes
layers readonly.


Jürgen

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



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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Jürgen E . Fischer
Hi Leknín,

On Tue, 01. Sep 2015 at 18:42:56 +0200, Leknín Řepánek wrote:
> Situation with a view without unique (and indexed) key is bad database
> model, or bad query.

Not so sure about that - you might have queries (or views) that join two or
more tables that have proper primary keys and indexed, but don't produce
a unique column of their own.

I don't think there are many assumptions you can generally make on views.

Earlier version of QGIS would deduce the primary keys of the involved tables
and offer those - but that was also nothing more than a hint of what could be
unique.



Jürgen

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



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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Jürgen E . Fischer
Hi James,

On Tue, 01. Sep 2015 at 13:15:59 -0400, James Keener wrote:
> I'd alo like to point out that the primary key need not be a single field.
> For instance (state_fips, county_fips) could be a valid key for county-based
> metrics. Going back to the previous question I posed, do we want to tell
> users to conform to a single-field primary key or will qgis accept valid
> schema designs. Again, it comes down to dev time vs the cost to the user
> experience.

And not all that difficult - we support that for postgresql and oracle tables.
spatialite doesn't need it, because it has an internal rowid (like postgresql's
old oid).  MSSQL does not yet support it.

That could be used for views too - but the user would still have to provide
which columns to use.  Automatically deducing the key columns from the view is
probably to expensive for real use (for that reason we don't even try to for
single columns).

But to me it still isn't that frequently requested that I'd like to jump on it
in my own time (which IIRC is what I did with the postgresql provider - both
for ctid and multicolumn keys).


Jürgen

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



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

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Jürgen E . Fischer
Hi Mats,

On Tue, 01. Sep 2015 at 17:06:23 +0200, Mats Elfström wrote:
> Once, Qgis versions were named after planetary moons. We probably ran
> out of those, at least those known to the public.

Nope, there are probably plenty left.  But we stopped using them because there
was a trademark claim on some of the moons we used by a company that already
used it for their software product.

> Place names can be biased, like: now it's time for a latin american name and
> so on.

We already had a latin american name: Copiapo.


> May I suggest the periodic table of elements as base for the naming instead.
> By cleverly using the groups one could even indicate major/minor version
> changes.

Not sure if that's safer than moons.


Jürgen

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



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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Jürgen E . Fischer
Hi James,

On Mon, 31. Aug 2015 at 15:05:05 -0400, James Keener wrote:
> I don't mind the behavior as much as it's entirely unclear, especially
> when the window is small and you have to scroll to see the drop down,
> what is the problem.

> There should be an error message (or even an error/warning icon with the
> tool tip saying there is on PK), along with possible remedies presented
> to the user.

Well, it's not an error (same as having to select a geometry type or SRID,
before being able to add a layer that doesn't have a 'proper' constraint).

And a tooltip is already there - although it could be more visible.

BTW the ticket for this is #11317.


Jürgen

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



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

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Alexander Bruy
Hi Andreas,

just to small correction. There was no hackfest in Moscow, only a
small user meeting.

2015-08-31 10:22 GMT+03:00 Andreas Neumann :
> Hi Anita,
>
> Well - we are not running out to soon of dev-meeting locations that haven't
> been used as release names yet: Essen, Hannover, Lyon, Nødebo, Zurich, Gran
> Canaria. Then there are the hackfests that are not in Middle Europe, such as
> Tokyo, Moscow.
>
> Also, there are 2 additional dev meetings each year.
>
> So I wouldn't be worried about names yet ;-) Enough names for years to come.
>
> Personally I would propose Essen for either the next release or the next LT
> release. We could ask the German QGIS user group to come up with a suitable
> map for Essen or a map of the Linux hotel.
>
> Andreas
>
>
> On 30.08.2015 19:29, Anita Graser wrote:
>
> Dear QGIS community,
>
> As you might know, given our new release cycle with three releases a year,
> we are sooner or later going to run out of release names based on developer
> meeting locations. This is why I would like to remind you to suggest release
> names.
>
> If you have been hosting QGIS user meetings or if you have founded a user
> group, why not suggest the meeting/foundling location?
>
> Here's a short description of what is needed to make a suggestion:
>
> -
>
> CALL for QGIS RELEASE NAME SUGGESTIONS
>
> The following rules apply:
> - The suggestion should be the name of a place.
> - The suggestion must not be the name of a software product. (Please try to
> do some Google searches before submitting the suggestion.)
> - Each suggestion must come with a suitable map image for splash design.
> (Make sure that we have the rights to use the image. Since the splash is
> also printed in our user guide, a minimum resolution of 3000x2000 px is
> necessary.)
> - Locations of developer meetings have priority.
>
> Submission format: Send an email with a short description of your suggestion
> and a link to a ZIP file containing the map image(s) to anitagra...@gmx.at
>
> -
>
> Best wishes,
> Anita
>
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user



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

[Qgis-user] rs time series viewer plugin

2015-09-01 Thread Carlo Cormio

Hello everybody,

I'm trying to display interferometry data using rs time series viewer 
plugin, but got the following error after clicking on a point from the 
vector map:


-

Traceback (most recent call last):
  File 
"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py", 
line 90, in onPointClicked

dlg = self._onPointClicked( layer, point )
  File 
"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py", 
line 121, in _onPointClicked

uri = str(ps_source)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in 
position 20: ordinal not in range(128)



Versione Python:
2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]


Versione di QGIS:
2.10.1-Pisa Pisa, d20c5b7

Percorso Python: ['C:/OSGeo4W/apps/qgis/./python/plugins\\processing', 
'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/Carlitos/.qgis2/python', 
u'C:/Users/Carlitos/.qgis2/python/plugins', 
'C:/OSGeo4W/apps/qgis/./python/plugins', 
'C:\\OSGeo4W\\bin\\python27.zip', 'C:\\OSGeo4W\\apps\\Python27\\DLLs', 
'C:\\OSGeo4W\\apps\\Python27\\lib', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin', 
'C:\\OSGeo4W\\apps\\Python27', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg', 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg', 
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode', 
u'C:/Users/Carlitos/.qgis2//python', 
'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']


-

Moreover, the shapefile in the test data folder from github seems to be 
corrupted. If I try to load that map I got an error message (invalid 
file format).


Anybody could help? Do I have to open a ticket? How?

Thank you in advance,

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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Sandro Santilli
I agree with Luca this should have been better not backported to 2.8.3.
Only proper bugs should be backported, and this was a (debatable)
GUI enhancement, as far as I can tell.

BTW: resolution of #11317 is set to "wontfix"

--strk;

On Mon, Aug 31, 2015 at 09:00:15PM +0200, Luca Lanteri wrote:
> Hi,
> 
> I noticed that this new behavior has been backported to 2.8.3.
> I think this behavior should be considered a regression because now it's
> very uncomfortable to load views, specially when I have to load many views.
> I also noticed that lot of users are confused, because they thinks that
> views doesn't work. I think the old behavior was better because it allowed
> both to choose a custom gid and to load view faster.
> Currently we decide to remain with 2.8.2.
> 
> What about reconsidering to return to the old behavior ?
> 
> Thanks
> Luca
> 
> 2015-08-06 20:58 GMT+02:00 Jürgen E. :
> 
> > Hi Randal,
> >
> > On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > > In 2.8.x I can add the view and the Primary key is automatically
> > displayed.
> >
> > No, you're supposed to select the primary key.  In 2.8.x you also have to
> > choose from all columns, but first one is preselected.  If that happens to
> > be
> > the primary key, you're fine, but that's not always the case and hence
> > newer versions force you to actually select it.
> >
> > Jürgen
> >
> > --
> > Jürgen E. Fischer   norBIT GmbH Tel.
> > +49-4931-918175-31
> > Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> > +49-4931-918175-50
> > Software Engineer   D-26506 Norden
> > http://www.norbit.de
> > QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-user
> >
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
Why are you assuming the user who created the view is the one using QGIS?

Jim

On 09/01/2015 08:50 AM, Andreas Neumann wrote:
> Hi,
> 
> I agree with Jürgen - better let the user choose the pkey column. If the
> user knows how to create a Postgis View he also knows how to select a
> primary key column.
> 
> Andreas
> 
> On 01.09.2015 14:37, Jürgen E. Fischer wrote:
>> Hi Sandro,
>>
>> On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>>> I agree with Luca this should have been better not backported to 2.8.3.
>>> Only proper bugs should be backported, and this was a (debatable)
>>> GUI enhancement, as far as I can tell.
>> We intend to only backport fixes and not bugs. ;)
>>
>> You were always supposed to select the key column - preselecting the first
>> column was the bug (also debatable).  And #11317 is a ticket that 
>> demonstrates
>> there were unaware users.
>>
>> That the first column often happens to be the primary key and and the 
>> combobox
>> is not lexically sorted is somewhat pure luck - and unless you avoid having 
>> the
>> key verified (using "use estimated metadata"), keeping a wrongly select
>> column will make the layer to insert invalid.
>>
>> But I agree that the tooltip that you get on disabled lines (not only for the
>> key selection, but also geometry type and srid) might not be visible enough
>> (but that IMHO would be just a GUI enhancement).
>>
>>
>> Jürgen
>>
>>
>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Jürgen E . Fischer
Hi Sandro,

On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
> I agree with Luca this should have been better not backported to 2.8.3.
> Only proper bugs should be backported, and this was a (debatable)
> GUI enhancement, as far as I can tell.

We intend to only backport fixes and not bugs. ;)

You were always supposed to select the key column - preselecting the first
column was the bug (also debatable).  And #11317 is a ticket that demonstrates
there were unaware users.

That the first column often happens to be the primary key and and the combobox
is not lexically sorted is somewhat pure luck - and unless you avoid having the
key verified (using "use estimated metadata"), keeping a wrongly select
column will make the layer to insert invalid.

But I agree that the tooltip that you get on disabled lines (not only for the
key selection, but also geometry type and srid) might not be visible enough
(but that IMHO would be just a GUI enhancement).


Jürgen

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


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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
I don't want to reopen the ticket, as that's not my place, but I would
like to comment on it and your comment here:

> Why does QGIS need a primary key?
>
> To create (persistent) feature ids that are used for selection (and
deletion and changing of attribute or geometries - but that doesn't
apply to normal views).

While I understand from the applications POV how a single primary key
makes sense, from the databases POV querying off of ROW_NUMBER() will
force a sequence scan, which may be _extremely_ slow. While this isn't
exactly your issue, advocating a "solution" to your problem that creates
a bad user experience isn't a good idea.

At least selecting based on geometry would be able to invoke the
(likely-to-exist) index on the underlying table(s), where there is no
possible way to index row_number() and it will _always_ sequence scan.

Additionally, ROW_NUMBER() _isn't_ a pk.  If the view has no ordering
being forced (and even if there is!), then additions to the underlying
table could reörder the order of the output rows, changing ROW_NUMBER().
If you were querying against the ROW_NUMBER() column, the updated view
the _wrong_ row returned -- this is a very very bad thing!

At the very least, don't tell people to use ROW_NUMBER() as a primary
key.  This is just terrible advice!

Also, I'm running 2.10.1 and when I add a view on a table with no unique
values, and even if I select a non-unique field as my primary key, QGIS
will happily load the view, not complain about the cardinality of the
"primary key" being less than the carnality of the rows, and proceed to
draw the geometries correctly and let me select features and will show
me the correct attributes. As a user, I felt very frustrated by this
(especially because the default window size hid the dropdown to select
the pk and there was no indication at all at what was wrong!) and like I
had to jump through a hoop for the programmer's convenience, not for any
matter that actually mattered.

As a programmer, I know what you're trying to do, but since it doesn't
appear to matter anyway, what's the point.  Try this.

> [local]:5432 jim@geodata=# create table testing_mult (a int, t text);CREATE 
> TABLE
> Time: 6.248 ms
> [local]:5432 jim@geodata=# select 
> AddGeometryColumn('public','testing_mult','g',4326,'POINT', 2);
>  addgeometrycolumn  
> 
>  public.testing_mult.g SRID:4326 TYPE:POINT DIMS:2 
> (1 row)
> 
> Time: 5.349 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'thingy', 
> st_geomfromtext('point(1 1)',4326 ));
> INSERT 0 1
> Time: 3.062 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'this', 
> st_geomfromtext('point(1 0)',4326 ));
> INSERT 0 1
> Time: 2.865 ms
> [local]:5432 jim@geodata=# insert into testing_mult values (1, 'that', 
> st_geomfromtext('point(0 0)',4326 ));
> INSERT 0 1
> Time: 2.873 ms
> [local]:5432 jim@geodata=# create view testing_mult_view as select * from 
> testing_mult ;
> CREATE VIEW
> Time: 6.055 ms

Now, go to QGIS, select column 'a' as the "primary key".  You'll see 3
points, and you'll be able to get the correct attribute values for each

Moreover, you can load the test_multi without having to give it a pk, so
again, as a user, I'm extremely confused by inconsistent behavior,
doubly so if I didn't create the DB and don't understand what a view is.

If tables can be used without selecting a primary key, why must views?
and why must the UI be so tight-lipped?  "Select a primary key" as the
tool-tip means absolutely nothing to someone not used to databases. It
means less given that you can't see the "primary key" column in the
window with the window's default size. It means even less when someone
who understands what a primary key is seeing tables that are usable and
that don't have one.

What is the point of having the user select a "primary key" if QGIS is
accepting non-unique fields with no issue?  QGIS needs to either
complain about the lack of uniqueness, or drop forcing the user to
select one.

Jim

PS: I know this isn't the place, but the db manager gives absolutely,
positively terrible feedback about this.

On 09/01/2015 04:59 AM, Jürgen E. Fischer wrote:
> Hi James,
> 
> On Mon, 31. Aug 2015 at 15:05:05 -0400, James Keener wrote:
>> I don't mind the behavior as much as it's entirely unclear, especially
>> when the window is small and you have to scroll to see the drop down,
>> what is the problem.
> 
>> There should be an error message (or even an error/warning icon with the
>> tool tip saying there is on PK), along with possible remedies presented
>> to the user.
> 
> Well, it's not an error (same as having to select a geometry type or SRID,
> before being able to add a layer that doesn't have a 'proper' constraint).
> 
> And a tooltip is already there - although it could be more visible.
> 
> BTW the ticket for this is #11317.
> 
> 
> Jürgen
> 
> 
> 
> 

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Andreas Neumann

Hi,

I agree with Jürgen - better let the user choose the pkey column. If the 
user knows how to create a Postgis View he also knows how to select a 
primary key column.


Andreas

On 01.09.2015 14:37, Jürgen E. Fischer wrote:

Hi Sandro,

On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:

I agree with Luca this should have been better not backported to 2.8.3.
Only proper bugs should be backported, and this was a (debatable)
GUI enhancement, as far as I can tell.

We intend to only backport fixes and not bugs. ;)

You were always supposed to select the key column - preselecting the first
column was the bug (also debatable).  And #11317 is a ticket that demonstrates
there were unaware users.

That the first column often happens to be the primary key and and the combobox
is not lexically sorted is somewhat pure luck - and unless you avoid having the
key verified (using "use estimated metadata"), keeping a wrongly select
column will make the layer to insert invalid.

But I agree that the tooltip that you get on disabled lines (not only for the
key selection, but also geometry type and srid) might not be visible enough
(but that IMHO would be just a GUI enhancement).


Jürgen



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


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

Re: [Qgis-user] rs time series viewer plugin

2015-09-01 Thread Enrique
Could be a problem with special characters in file names or paths?

Try to avoid spaces and non-ASCII characters (like character à) in file
names and paths.

Enrique

2015-09-01 14:13 GMT+02:00 Carlo Cormio :

> Hello everybody,
>
> I'm trying to display interferometry data using rs time series viewer
> plugin, but got the following error after clicking on a point from the
> vector map:
>
> -
>
> Traceback (most recent call last):
>   File
> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
> line 90, in onPointClicked
> dlg = self._onPointClicked( layer, point )
>   File
> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
> line 121, in _onPointClicked
> uri = str(ps_source)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in
> position 20: ordinal not in range(128)
>
>
> Versione Python:
> 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]
>
>
> Versione di QGIS:
> 2.10.1-Pisa Pisa, d20c5b7
>
> Percorso Python: ['C:/OSGeo4W/apps/qgis/./python/plugins\\processing',
> 'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/Carlitos/.qgis2/python',
> u'C:/Users/Carlitos/.qgis2/python/plugins',
> 'C:/OSGeo4W/apps/qgis/./python/plugins', 'C:\\OSGeo4W\\bin\\python27.zip',
> 'C:\\OSGeo4W\\apps\\Python27\\DLLs', 'C:\\OSGeo4W\\apps\\Python27\\lib',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin',
> 'C:\\OSGeo4W\\apps\\Python27',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode',
> u'C:/Users/Carlitos/.qgis2//python',
> 'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']
>
> -
>
> Moreover, the shapefile in the test data folder from github seems to be
> corrupted. If I try to load that map I got an error message (invalid file
> format).
>
> Anybody could help? Do I have to open a ticket? How?
>
> Thank you in advance,
>
> Carlo
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] DXF Export in QGIS 2.10

2015-09-01 Thread WhereGroup

Hello everyboy,

I have a question towards the DXF Export in QGIS 2.10 . When I try to 
export a project from QGIS into a DFX-file and open it in libreCAD, the 
labels are not presented correctly. Some of them don't appear at all, 
others are slightly dislocated and display further information towards 
character type, hight and so on in front of the actual label (e.g. 
Ubuntu|i0|b1;\H54.5776;/W0.75; Church).
Do you have any suggestions how i can avoid the additional 
label-information, export all labels into the dfx-file and get them in 
the right position?


Thanks

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


Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Ramon Andiñach
Oh! If we're randomising can we randomise them the way Clement Wragge used to? 
;)
https://en.wikipedia.org/wiki/Clement_Lindley_Wragge#Meteorology

I'm in jest here about the Wragge naming system. But the different ways that 
that cyclones are named in different areas does illustrate that there isn't one 
good way to name things - except be consistent.

I like the maps too :)

-ramon.

> On 2 Sep 2015, at 10:08, John Harrop  wrote:
> 
> I personally like the geographic names and never thought about them as 
> potentially problematic. They seem to fit the context and I always like to 
> see the interesting maps that go with each. 
> 
> Perhaps a randomizing system like they do with hurricanes would help?
> 
> John
> 
> Sent from my iPhone
> 
>> On Sep 1, 2015, at 3:45 PM, Nathan Woodrow  wrote:
>> 
>> Hey,
>> 
>> I think we really should just stick to what we are already doing. Run though 
>> all the names like Andreas said, even if we lock in the release names now.  
>> There isn't going to be any harm in that.  If we run out of HF place names 
>> another cool idea might be to use the place names of core developers home 
>> towns, that would give us at least 30+ by the time that rolls around.
>> 
>> Regards,
>> 
>>> On Mon, Aug 31, 2015 at 6:24 PM, Anita Graser  wrote:
>>> 
>>> On Aug 31, 2015 9:22 AM, "Andreas Neumann"  wrote:
>>> > Well - we are not running out to soon of dev-meeting locations
>>> 
>>> Thanks Andreas! I did check the meeting list. Please note that I'm not only 
>>> asking for names but also splash materials since sourcing those can be very 
>>> time consuming.
>>> 
>>> Best wishes 
>>> Anita
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Qgis-user mailing list
>>> Qgis-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>> 
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread Andreas Neumann

Hi John,

I don't know what you mean by "cloudify" Postgis? But if you want more 
flexibility with Postgis connections I can suggest that you make your 
connection to a service definition and not to a host/database directly.


That way you can just change your service definition file and change to 
a different server/db in case you migrate your server or you want to 
switch between dev version/productive version. Or you can switch between 
localhost on your laptop and your company's LAN Postgis server. See 
http://www.postgresql.org/docs/current/static/libpq-pgservice.html


Here is one example of a service definition:

Konsole output
[pg_uster]
host=localhost
port=5432
dbname=uster

Then you connect to service "pg_uster" and not directly to a 
host/port/db combination. I


In order for not having to type passwords I can also recommend to use a 
.pgpass file.

see http://www.postgresql.org/docs/current/static/libpq-pgpass.html

Andreas

On 02.09.2015 03:59, John Harrop wrote:
Any suggestions on how to "cloudify" PostGIS?  I would like to use it 
as well and shared across more than the local network.


Cheers,

John

Sent from my iPhone

On Sep 1, 2015, at 9:38 AM, didier peeters > wrote:



Arni,

Postgis is certainly an excellent option.
Regarding the data sources, currently QGis cannot use relative paths 
to files or photos (at least) but to svg's in styling (and maybe 
other, I don’t have an exhaustive list). One option to bypass the 
files issue would be to use a web server and store URL instead of 
internal paths.  For instance you could have a web server, and 
whenever a file (or photo) is added generate with a Postgresql 
trigger the corresponding url in another attribute, making the file 
available to all the users, either through a form or through an action.


Didier


Le 1 sept. 2015 à 17:45, Árni Geirsson > a écrit :


Thanks Jim
Your answer encourages me to try the PostGIS option - it obviously 
has some other useful advantages. But your reply also made me 
realize that the problem is really that much of the data I have is 
on another network share - hence the problem with the paths. I 
should simply move the data so that everything is on the same share 
and and then, relative paths will solve the problem.

Again, thank you for a very helpful answer.

Arni


Árni Geirsson
*Alta ehf* // +354 582 5000 // +354 897 9549
www.alta.is   // Alta á Twitter 
 // Alta á Facebook 



On Tue, Sep 1, 2015 at 3:26 PM, James Keener > wrote:


Re: postgresql in my experience it's neither cumbersome nor
slow. Feel free to email me for help if you would like to
explore that route.

Are the paths in you qgs file relative or absolute? If their
relative, is the issue that the path separator is different? If
that is the issue, I would file a bug report. (If they are
absolute, try saving them with relative paths.)

Jim

On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson"
> wrote:

Hi
I am adding a Mac to a local network of PCs. The Mac user
uses QGIS (as well as the PCs) and accesses data on a shared
drive. Now the problem comes up that data sources have
different paths to the shared drive in each operating
system, making cooperation difficult. On the other hand,
since the .qgs file is easy to edit, some simple solution
might map the paths automatically on open and back on save,
to compensate for these differences. And maybe there is some
other solution out there.
I realize that having all shared data in PostGIS might be
one way to solve this but I suspect that it might be both
slower and a little more cumbersome.
All thoughts and suggestions are highly appreciated.

Árni Geirsson




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

-- Sent from my Android device with K-9 Mail. Please excuse my
brevity.

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


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

Re: [Qgis-user] request

2015-09-01 Thread 오동하
Hi yan

What kind of supply do you want?

I forward your mail to my friend, YowngKwon Lee,  who works at Korea Forest
Service.
But I know he live in Myanamar now.



2015년 9월 2일 (수) 오후 12:13, yoon yoon 님이 작성:

> i am form myanmar forest department.
> i working RS process so we should need technology and software (human
> resourse) from your Org:
> please, we will be hope from your supply.
>
>
> Good luck
>
> yan naing min
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Anita Graser
Hi,

Thanks for your input! I'm not planning to change the system any time soon
because I also see no problem that needs fixing. I'm looking forward to any
submissions as specified in the call. In my opinion, it's a nice extra for
organizers of QGIS events to have a release named after the place of the
event. All I need to make that happen is support sourcing nice splash
screen material. I think most people enjoy them a lot.

Best wishes,
Anita




> On Sep 1, 2015, at 3:45 PM, Nathan Woodrow  wrote:
>
> Hey,
>
> I think we really should just stick to what we are already doing. Run
> though all the names like Andreas said, even if we lock in the release
> names now.  There isn't going to be any harm in that.  If we run out of HF
> place names another cool idea might be to use the place names of core
> developers home towns, that would give us at least 30+ by the time that
> rolls around.
>
> Regards,
>
> On Mon, Aug 31, 2015 at 6:24 PM, Anita Graser  wrote:
>
>>
>> On Aug 31, 2015 9:22 AM, "Andreas Neumann"  wrote:
>> > Well - we are not running out to soon of dev-meeting locations
>>
>> Thanks Andreas! I did check the meeting list. Please note that I'm not
>> only asking for names but also splash materials since sourcing those can be
>> very time consuming.
>>
>> Best wishes
>> Anita
>>
>>
>>
>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread Árni Geirsson
That's an interesting approach, John. I'll have to have a better look the
Grass style directory structure.

Árni


Árni Geirsson
*Alta ehf* // +354 582 5000 // +354 897 9549
www.alta.is  // Alta á Twitter  // Alta á
Facebook 

On Tue, Sep 1, 2015 at 4:12 PM, John Harrop  wrote:

> Árni,
>
> We have been working very successfully with the same combination.  In
> fact, most of the PC users were using ESRI software with the Macs using
> only QGIS (obviously?).  We use a directory structure based on the Grass
> style and shared (across continents) using Dropbox.  Most are using the
> business version of Dropbox for better control on read/write access.
>
> A simplesolution for us has been to use two qgs files if needed for the
> same data files (or the ESRI equivalent).  The problem has then been
> limited to sharing formatting and the data sharing has been quite seamless.
>
> I like the PostGIS idea and I’m moving to that more as well, but I’m not
> sure how much more that solves regarding sharing versus the simpler method
> explained above.
>
> John Harrop
>
> On Sep 1, 2015, at 8:12 AM, Árni Geirsson  wrote:
>
> Hi
> I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as
> well as the PCs) and accesses data on a shared drive. Now the problem comes
> up that data sources have different paths to the shared drive in each
> operating system, making cooperation difficult. On the other hand, since
> the .qgs file is easy to edit, some simple solution might map the paths
> automatically on open and back on save, to compensate for these
> differences. And maybe there is some other solution out there.
> I realize that having all shared data in PostGIS might be one way to solve
> this but I suspect that it might be both slower and a little more
> cumbersome.
> All thoughts and suggestions are highly appreciated.
>
> Árni Geirsson
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread didier peeters
Arni,

Postgis is certainly an excellent option.  
Regarding the data sources, currently QGis cannot use relative paths to files 
or photos (at least) but to svg's in styling (and maybe other, I don’t have an 
exhaustive list). One option to bypass the files issue would be to use a web 
server and store URL instead of internal paths.  For instance you could have a 
web server, and whenever a file (or photo) is added generate with a Postgresql 
trigger the corresponding url in another attribute, making the file available 
to all the users, either through a form or through an action.  

Didier


> Le 1 sept. 2015 à 17:45, Árni Geirsson  a écrit :
> 
> Thanks Jim
> Your answer encourages me to try the PostGIS option - it obviously has some 
> other useful advantages. But your reply also made me realize that the problem 
> is really that much of the data I have is on another network share - hence 
> the problem with the paths. I should simply move the data so that everything 
> is on the same share and and then, relative paths will solve the problem.
> Again, thank you for a very helpful answer.
> 
> Arni
> 
> 
> Árni Geirsson
> Alta ehf // +354 582 5000 // +354 897 9549
> www.alta.is   // Alta á Twitter 
>  // Alta á Facebook 
> 
> 
> On Tue, Sep 1, 2015 at 3:26 PM, James Keener  > wrote:
> Re: postgresql in my experience it's neither cumbersome nor slow. Feel free 
> to email me for help if you would like to explore that route.
> 
> Are the paths in you qgs file relative or absolute? If their relative, is the 
> issue that the path separator is different? If that is the issue, I would 
> file a bug report. (If they are absolute, try saving them with relative 
> paths.)
> 
> Jim
> 
> On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson"  > wrote:
> Hi
> I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as well 
> as the PCs) and accesses data on a shared drive. Now the problem comes up 
> that data sources have different paths to the shared drive in each operating 
> system, making cooperation difficult. On the other hand, since the .qgs file 
> is easy to edit, some simple solution might map the paths automatically on 
> open and back on save, to compensate for these differences. And maybe there 
> is some other solution out there. 
> I realize that having all shared data in PostGIS might be one way to solve 
> this but I suspect that it might be both slower and a little more cumbersome.
> All thoughts and suggestions are highly appreciated.
> 
> Árni Geirsson
> 
> 
> 
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-user 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user

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

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread Matthias Kuhn
Hi,

Regarding relative paths to files and photos, it would be a quite
trivial - and useful - change to fix this.
If you would like to help funding this, please do not hesitate to
contact me.

Kind regards,
Matthias

On 09/01/2015 06:38 PM, didier peeters wrote:
> Arni,
>
> Postgis is certainly an excellent option.  
> Regarding the data sources, currently QGis cannot use relative paths
> to files or photos (at least) but to svg's in styling (and maybe
> other, I don’t have an exhaustive list). One option to bypass the
> files issue would be to use a web server and store URL instead of
> internal paths.  For instance you could have a web server, and
> whenever a file (or photo) is added generate with a Postgresql trigger
> the corresponding url in another attribute, making the file available
> to all the users, either through a form or through an action.  
>
> Didier
>
>
>> Le 1 sept. 2015 à 17:45, Árni Geirsson > > a écrit :
>>
>> Thanks Jim
>> Your answer encourages me to try the PostGIS option - it obviously
>> has some other useful advantages. But your reply also made me realize
>> that the problem is really that much of the data I have is on another
>> network share - hence the problem with the paths. I should simply
>> move the data so that everything is on the same share and and then,
>> relative paths will solve the problem.
>> Again, thank you for a very helpful answer.
>>
>> Arni
>>
>>
>> Árni Geirsson
>> *Alta ehf* // +354 582 5000 // +354 897 9549
>> www.alta.is   // Alta á Twitter
>>  // Alta á Facebook
>> 
>>
>> On Tue, Sep 1, 2015 at 3:26 PM, James Keener > > wrote:
>>
>> Re: postgresql in my experience it's neither cumbersome nor slow.
>> Feel free to email me for help if you would like to explore that
>> route.
>>
>> Are the paths in you qgs file relative or absolute? If their
>> relative, is the issue that the path separator is different? If
>> that is the issue, I would file a bug report. (If they are
>> absolute, try saving them with relative paths.)
>>
>> Jim
>>
>> On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson"
>> > wrote:
>>
>> Hi
>> I am adding a Mac to a local network of PCs. The Mac user
>> uses QGIS (as well as the PCs) and accesses data on a shared
>> drive. Now the problem comes up that data sources have
>> different paths to the shared drive in each operating system,
>> making cooperation difficult. On the other hand, since the
>> .qgs file is easy to edit, some simple solution might map the
>> paths automatically on open and back on save, to compensate
>> for these differences. And maybe there is some other solution
>> out there. 
>> I realize that having all shared data in PostGIS might be one
>> way to solve this but I suspect that it might be both slower
>> and a little more cumbersome.
>> All thoughts and suggestions are highly appreciated.
>>
>> Árni Geirsson
>>
>>
>> 
>> 
>>
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my
>> brevity.
>>
>> ___ Qgis-user mailing
>> list Qgis-user@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Leknín Řepánek
Situation with a view without unique (and indexed) key is bad database
model, or bad query. Using window function is unefficient, but i can't
find another way to make unique column on query with duplicities in
records. In query without duplicities is possible to use oid (but this
needs tables with oids), or ctid (but ctid is slow).

Sorting in row_number can be defined in (ORDER BY ...). But is
unefficient (as you say). But works well for display smaller parts of
data (thousands of features).

Materialized view can be indexed. But this is about use case and it isnt
a "pretty solution".  

Je;

On Tue, Sep 01, 2015 at 11:36:53AM -0400, James Keener wrote:
> Please stop saying this. It's fine for certain situations, but it is not a
> permanently unique identifier for a row. It may change when the underlying
> table is altered. Sure, it's unique if you read the results and keep them in
> memory and never talk about it again, but qgis does that on its own already.
> 
> Moreover querying on it is extremely inefficient. Querying against it forces a
> sequence scan on the table. Depending on the table and version, it could also
> try to materialize the view fully in memory before doing the scan.
> 
> Jim
> 
> On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek"
>  wrote:
> 
> Workaround about primary key in view, i had use sever times is using
> window function "row_number() over()". It works in views and in query
> from database manager.
> 
> Je;
> 
> On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>  On Tue, Sep 01, 2015 at 02:37:22PM +0200, Jürgen E. Fischer wrote:
>  Hi Sandro,
> 
>  On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>  I agree with Luca this should have been better not 
> backported to 2.8.3.
>  Only proper bugs should be backported, and this was a 
> (debatable)
>  GUI enhancement, as far as I can
> tell.
> 
>  We intend to only backport fixes and not bugs. ;)
> 
>  You were always supposed to select the key column - preselecting 
> the first
>  column was the bug (also debatable).  And #11317 is a ticket 
> that demonstrates
>  there were unaware users.
> 
>  Reading #11317 I looks to me that the reported bug was about
>  "Add PostGIS Layer" not giving the user full detail of why a
>  layer could not be loaded: "is an invalid layer - not loaded".
>  In this I agree with Aren here: 
> http://hub.qgis.org/issues/11317#note-6
> 
>  That the first column often happens to be the primary key and 
> and the combobox
>  is not lexically sorted is somewhat pure luck - and unless you 
> avoid having the
>  key verified (using "use estimated metadata"),
> keeping a wrongly select
>  column will make the layer to insert invalid.
> 
>  I agree that the reported regression was based on the false 
> expectation
>  that QGIS would pick a primary key automatically, but in the
>  (unlikely?) case a user was aware of that and properly coded the view
>  to ensure primary key was first (or only) numeric the change was
>  indeed a degradation of the experience.
> 
>  But I agree that the tooltip that you get on disabled lines (not 
> only for the
>  key selection, but also geometry type and srid) might not be 
> visible enough
>  (but that IMHO would be just a GUI enhancement).
> 
>  There should maybe be another rule about LTS backports being:
>  debatable fixes/enhancement need to be debated more on list ?
> 
>  --strk;
> 
> ━━━
> 
>  Qgis-user mailing
> list
>  Qgis-user@lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> ━━━
> 
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread Árni Geirsson
Hi
I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as
well as the PCs) and accesses data on a shared drive. Now the problem comes
up that data sources have different paths to the shared drive in each
operating system, making cooperation difficult. On the other hand, since
the .qgs file is easy to edit, some simple solution might map the paths
automatically on open and back on save, to compensate for these
differences. And maybe there is some other solution out there.
I realize that having all shared data in PostGIS might be one way to solve
this but I suspect that it might be both slower and a little more
cumbersome.
All thoughts and suggestions are highly appreciated.

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

Re: [Qgis-user] Call for release name suggestions 2015

2015-09-01 Thread Mats Elfström
Once, Qgis versions were named after planetary moons. We probably ran
out of those, at least those known to the public. However, they had
the advantage of being unbiased, in terms of earth nations, language
or ethnicity. Place names can be biased, like: now it's time for a
latin american name and so on.
May I suggest the periodic table of elements as base for the naming
instead. By cleverly using the groups one could even indicate
major/minor version changes.

Hälsning / Regards
Mats.E

Skickat från min / Sent from my iPhone, Ursäkta att jag är kortfattad
/ Excuse my brevity.

> 1 sep 2015 kl. 14:12 skrev Alexander Bruy :
>
> Hi Andreas,
>
> just to small correction. There was no hackfest in Moscow, only a
> small user meeting.
>
> 2015-08-31 10:22 GMT+03:00 Andreas Neumann :
>> Hi Anita,
>>
>> Well - we are not running out to soon of dev-meeting locations that haven't
>> been used as release names yet: Essen, Hannover, Lyon, Nødebo, Zurich, Gran
>> Canaria. Then there are the hackfests that are not in Middle Europe, such as
>> Tokyo, Moscow.
>>
>> Also, there are 2 additional dev meetings each year.
>>
>> So I wouldn't be worried about names yet ;-) Enough names for years to come.
>>
>> Personally I would propose Essen for either the next release or the next LT
>> release. We could ask the German QGIS user group to come up with a suitable
>> map for Essen or a map of the Linux hotel.
>>
>> Andreas
>>
>>
>> On 30.08.2015 19:29, Anita Graser wrote:
>>
>> Dear QGIS community,
>>
>> As you might know, given our new release cycle with three releases a year,
>> we are sooner or later going to run out of release names based on developer
>> meeting locations. This is why I would like to remind you to suggest release
>> names.
>>
>> If you have been hosting QGIS user meetings or if you have founded a user
>> group, why not suggest the meeting/foundling location?
>>
>> Here's a short description of what is needed to make a suggestion:
>>
>> -
>>
>> CALL for QGIS RELEASE NAME SUGGESTIONS
>>
>> The following rules apply:
>> - The suggestion should be the name of a place.
>> - The suggestion must not be the name of a software product. (Please try to
>> do some Google searches before submitting the suggestion.)
>> - Each suggestion must come with a suitable map image for splash design.
>> (Make sure that we have the rights to use the image. Since the splash is
>> also printed in our user guide, a minimum resolution of 3000x2000 px is
>> necessary.)
>> - Locations of developer meetings have priority.
>>
>> Submission format: Send an email with a short description of your suggestion
>> and a link to a ZIP file containing the map image(s) to anitagra...@gmx.at
>>
>> -
>>
>> Best wishes,
>> Anita
>>
>>
>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
> --
> Alexander Bruy
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] DXF Export in QGIS 2.10

2015-09-01 Thread Andreas Neumann

Hi Thomas,

libreCAD is extremely limited with its DXF Import  and capabilities in 
general. Apparently it can't correctly deal with labels. QCAD or 
Draftsight do a slightly better job than libreCAD. The export was 
optimized for compatibility with Autocad and FME. This is our reference. 
They both read the files fine.


You should ask at the libreCAD project, if they can't correctly read the 
DXF file.


If we wouldn't export the Font/Text properties, the Autocad users would 
complain that the text does not match how it looked like in QGIS ...


Andreas

On 01.09.2015 14:59, Thomas Cürten (WhereGroup) wrote:

Hello everyboy,

I have a question towards the DXF Export in QGIS 2.10 . When I try to 
export a project from QGIS into a DFX-file and open it in libreCAD, 
the labels are not presented correctly. Some of them don't appear at 
all, others are slightly dislocated and display further information 
towards character type, hight and so on in front of the actual label 
(e.g. Ubuntu|i0|b1;\H54.5776;/W0.75; Church).
Do you have any suggestions how i can avoid the additional 
label-information, export all labels into the dfx-file and get them in 
the right position?


Thanks

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


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


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Luca Lanteri
2015-08-06 20:58 GMT+02:00 Jürgen E. :

> Hi Randal,
>
> On Thu, 06. Aug 2015 at 13:53:08 -0400, Randal Hale wrote:
> > In 2.8.x I can add the view and the Primary key is automatically
> displayed.
>
> No, you're supposed to select the primary key.  In 2.8.x you also have to
> choose from all columns, but first one is preselected.  If that happens to
> be
> the primary key, you're fine, but that's not always the case and hence
> newer versions force you to actually select it.
>
>
Indeed I think is a good habit to organize the views to always have the gid
as the first field in order to avoid the problem of choose the right PK
column.
Now qgis already warns if the column is not suitable as a PK. Probably I
miss something but I really can't understand the improvement of the new
behavior.

Thanks for your patience and for the nice work with QGIS.
Luca

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

Re: [Qgis-user] rs time series viewer plugin

2015-09-01 Thread Carlo Cormio

Thank you Enrique,

it was exactly an accent (à) from a folder along the path to shapefile :)

Now it works, and with Luigi's fix this won't be a problem in the future :)

Thank you all.

Regards,

Carlo

Il 01/09/2015 14:53, Enrique ha scritto:

Could be a problem with special characters in file names or paths?

Try to avoid spaces and non-ASCII characters (like character à) in 
file names and paths.


Enrique

2015-09-01 14:13 GMT+02:00 Carlo Cormio >:


Hello everybody,

I'm trying to display interferometry data using rs time series
viewer plugin, but got the following error after clicking on a
point from the vector map:

-

Traceback (most recent call last):
  File

"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
line 90, in onPointClicked
dlg = self._onPointClicked( layer, point )
  File

"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
line 121, in _onPointClicked
uri = str(ps_source)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0'
in position 20: ordinal not in range(128)


Versione Python:
2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]


Versione di QGIS:
2.10.1-Pisa Pisa, d20c5b7

Percorso Python:
['C:/OSGeo4W/apps/qgis/./python/plugins\\processing',
'C:/OSGeo4W/apps/qgis/./python',
u'C:/Users/Carlitos/.qgis2/python',
u'C:/Users/Carlitos/.qgis2/python/plugins',
'C:/OSGeo4W/apps/qgis/./python/plugins',
'C:\\OSGeo4W\\bin\\python27.zip',
'C:\\OSGeo4W\\apps\\Python27\\DLLs',
'C:\\OSGeo4W\\apps\\Python27\\lib',
'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win',
'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin',
'C:\\OSGeo4W\\apps\\Python27',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg',

'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',

'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode',
u'C:/Users/Carlitos/.qgis2//python',
'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']

-

Moreover, the shapefile in the test data folder from github seems
to be corrupted. If I try to load that map I got an error message
(invalid file format).

Anybody could help? Do I have to open a ticket? How?

Thank you in advance,

Carlo

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




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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Sandro Santilli
On Tue, Sep 01, 2015 at 02:37:22PM +0200, Jürgen E. Fischer wrote:
> Hi Sandro,
> 
> On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
> > I agree with Luca this should have been better not backported to 2.8.3.
> > Only proper bugs should be backported, and this was a (debatable)
> > GUI enhancement, as far as I can tell.
> 
> We intend to only backport fixes and not bugs. ;)
> 
> You were always supposed to select the key column - preselecting the first
> column was the bug (also debatable).  And #11317 is a ticket that demonstrates
> there were unaware users.

Reading #11317 I looks to me that the reported bug was about
"Add PostGIS Layer" not giving the user full detail of why a
layer could not be loaded: "is an invalid layer - not loaded".
In this I agree with Aren here: http://hub.qgis.org/issues/11317#note-6

> That the first column often happens to be the primary key and and the combobox
> is not lexically sorted is somewhat pure luck - and unless you avoid having 
> the
> key verified (using "use estimated metadata"), keeping a wrongly select
> column will make the layer to insert invalid.

I agree that the reported regression was based on the false expectation
that QGIS would pick a primary key automatically, but in the
(unlikely?) case a user was aware of that and properly coded the view
to ensure primary key was first (or only) numeric the change was
indeed a degradation of the experience.

> But I agree that the tooltip that you get on disabled lines (not only for the
> key selection, but also geometry type and srid) might not be visible enough
> (but that IMHO would be just a GUI enhancement).

There should maybe be another rule about LTS backports being:
debatable fixes/enhancement need to be debated more on list ?

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


Re: [Qgis-user] rs time series viewer plugin

2015-09-01 Thread Luigi Pirelli
fixed... I'm preparing new plugin release

regareds
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 1 September 2015 at 14:13, Carlo Cormio  wrote:
> Hello everybody,
>
> I'm trying to display interferometry data using rs time series viewer
> plugin, but got the following error after clicking on a point from the
> vector map:
>
> -
>
> Traceback (most recent call last):
>   File
> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
> line 90, in onPointClicked
> dlg = self._onPointClicked( layer, point )
>   File
> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
> line 121, in _onPointClicked
> uri = str(ps_source)
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in position
> 20: ordinal not in range(128)
>
>
> Versione Python:
> 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]
>
>
> Versione di QGIS:
> 2.10.1-Pisa Pisa, d20c5b7
>
> Percorso Python: ['C:/OSGeo4W/apps/qgis/./python/plugins\\processing',
> 'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/Carlitos/.qgis2/python',
> u'C:/Users/Carlitos/.qgis2/python/plugins',
> 'C:/OSGeo4W/apps/qgis/./python/plugins', 'C:\\OSGeo4W\\bin\\python27.zip',
> 'C:\\OSGeo4W\\apps\\Python27\\DLLs', 'C:\\OSGeo4W\\apps\\Python27\\lib',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin',
> 'C:\\OSGeo4W\\apps\\Python27',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg',
> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode',
> u'C:/Users/Carlitos/.qgis2//python',
> 'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']
>
> -
>
> Moreover, the shapefile in the test data folder from github seems to be
> corrupted. If I try to load that map I got an error message (invalid file
> format).
>
> Anybody could help? Do I have to open a ticket? How?
>
> Thank you in advance,
>
> Carlo
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


Re: [Qgis-user] rs time series viewer plugin

2015-09-01 Thread Carlo Cormio

Great! Thank you Luigi :)

Regards,

Carlo

Il 01/09/2015 15:04, Luigi Pirelli ha scritto:

fixed... I'm preparing new plugin release

regareds
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 1 September 2015 at 14:13, Carlo Cormio  wrote:

Hello everybody,

I'm trying to display interferometry data using rs time series viewer
plugin, but got the following error after clicking on a point from the
vector map:

-

Traceback (most recent call last):
   File
"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
line 90, in onPointClicked
 dlg = self._onPointClicked( layer, point )
   File
"C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
line 121, in _onPointClicked
 uri = str(ps_source)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in position
20: ordinal not in range(128)


Versione Python:
2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]


Versione di QGIS:
2.10.1-Pisa Pisa, d20c5b7

Percorso Python: ['C:/OSGeo4W/apps/qgis/./python/plugins\\processing',
'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/Carlitos/.qgis2/python',
u'C:/Users/Carlitos/.qgis2/python/plugins',
'C:/OSGeo4W/apps/qgis/./python/plugins', 'C:\\OSGeo4W\\bin\\python27.zip',
'C:\\OSGeo4W\\apps\\Python27\\DLLs', 'C:\\OSGeo4W\\apps\\Python27\\lib',
'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win',
'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin',
'C:\\OSGeo4W\\apps\\Python27',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg',
'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode',
u'C:/Users/Carlitos/.qgis2//python',
'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']

-

Moreover, the shapefile in the test data folder from github seems to be
corrupted. If I try to load that map I got an error message (invalid file
format).

Anybody could help? Do I have to open a ticket? How?

Thank you in advance,

Carlo

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


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


Re: [Qgis-user] DXF Export in QGIS 2.10

2015-09-01 Thread Andreas Neumann

Hi again,

I had a small test again with QCAD and Draftsight and apparently they 
just ignore/suppress the labels. So all of the three free CAD software 
(QCAD/Draftsight/LibreCAD) seem to have issues with labels


The more capable CADs like Autocad or Vectorworks - or the GIS/CAD 
converter FME display the labels fine.


Andreas

On 01.09.2015 15:06, Andreas Neumann wrote:

Hi Thomas,

libreCAD is extremely limited with its DXF Import  and capabilities in 
general. Apparently it can't correctly deal with labels. QCAD or 
Draftsight do a slightly better job than libreCAD. The export was 
optimized for compatibility with Autocad and FME. This is our 
reference. They both read the files fine.


You should ask at the libreCAD project, if they can't correctly read 
the DXF file.


If we wouldn't export the Font/Text properties, the Autocad users 
would complain that the text does not match how it looked like in QGIS 
...


Andreas

On 01.09.2015 14:59, Thomas Cürten (WhereGroup) wrote:

Hello everyboy,

I have a question towards the DXF Export in QGIS 2.10 . When I try to 
export a project from QGIS into a DFX-file and open it in libreCAD, 
the labels are not presented correctly. Some of them don't appear at 
all, others are slightly dislocated and display further information 
towards character type, hight and so on in front of the actual label 
(e.g. Ubuntu|i0|b1;\H54.5776;/W0.75; Church).
Do you have any suggestions how i can avoid the additional 
label-information, export all labels into the dfx-file and get them 
in the right position?


Thanks

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


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


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


Re: [Qgis-user] rs time series viewer plugin

2015-09-01 Thread Luigi Pirelli
0.2.3 version released
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 1 September 2015 at 15:04, Luigi Pirelli  wrote:
> fixed... I'm preparing new plugin release
>
> regareds
> Luigi Pirelli
>
> **
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Elance: https://www.elance.com/s/edit/luigipirelli/
> * GitHub: https://github.com/luipir
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * Mastering QGIS:
> https://www.packtpub.com/application-development/mastering-qgis
> **
>
>
> On 1 September 2015 at 14:13, Carlo Cormio  wrote:
>> Hello everybody,
>>
>> I'm trying to display interferometry data using rs time series viewer
>> plugin, but got the following error after clicking on a point from the
>> vector map:
>>
>> -
>>
>> Traceback (most recent call last):
>>   File
>> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
>> line 90, in onPointClicked
>> dlg = self._onPointClicked( layer, point )
>>   File
>> "C:/Users/Carlitos/.qgis2/python/plugins\pstimeseries\pstimeseries_plugin.py",
>> line 121, in _onPointClicked
>> uri = str(ps_source)
>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in position
>> 20: ordinal not in range(128)
>>
>>
>> Versione Python:
>> 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)]
>>
>>
>> Versione di QGIS:
>> 2.10.1-Pisa Pisa, d20c5b7
>>
>> Percorso Python: ['C:/OSGeo4W/apps/qgis/./python/plugins\\processing',
>> 'C:/OSGeo4W/apps/qgis/./python', u'C:/Users/Carlitos/.qgis2/python',
>> u'C:/Users/Carlitos/.qgis2/python/plugins',
>> 'C:/OSGeo4W/apps/qgis/./python/plugins', 'C:\\OSGeo4W\\bin\\python27.zip',
>> 'C:\\OSGeo4W\\apps\\Python27\\DLLs', 'C:\\OSGeo4W\\apps\\Python27\\lib',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\plat-win',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\lib-tk', 'C:\\OSGeo4W\\bin',
>> 'C:\\OSGeo4W\\apps\\Python27',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\PIL',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\jinja2-2.7.2-py2.7.egg',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\markupsafe-0.23-py2.7-win32.egg',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\python_dateutil-2.2-py2.7.egg',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\pytz-2014.2-py2.7.egg',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\win32\\lib',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\Pythonwin',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\six-1.6.1-py2.7.egg',
>> 'C:\\OSGeo4W\\apps\\Python27\\lib\\site-packages\\wx-2.8-msw-unicode',
>> u'C:/Users/Carlitos/.qgis2//python',
>> 'C:\\OSGeo4W\\apps\\qgis\\python\\plugins\\fTools\\tools']
>>
>> -
>>
>> Moreover, the shapefile in the test data folder from github seems to be
>> corrupted. If I try to load that map I got an error message (invalid file
>> format).
>>
>> Anybody could help? Do I have to open a ticket? How?
>>
>> Thank you in advance,
>>
>> Carlo
>>
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Leknín Řepánek
Workaround about primary key in view, i had use sever times is using
window function "row_number() over()". It works in views and in query
from database manager.

Je;

On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
> On Tue, Sep 01, 2015 at 02:37:22PM +0200, Jürgen E. Fischer wrote:
> > Hi Sandro,
> > 
> > On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
> > > I agree with Luca this should have been better not backported to 2.8.3.
> > > Only proper bugs should be backported, and this was a (debatable)
> > > GUI enhancement, as far as I can tell.
> > 
> > We intend to only backport fixes and not bugs. ;)
> > 
> > You were always supposed to select the key column - preselecting the first
> > column was the bug (also debatable).  And #11317 is a ticket that 
> > demonstrates
> > there were unaware users.
> 
> Reading #11317 I looks to me that the reported bug was about
> "Add PostGIS Layer" not giving the user full detail of why a
> layer could not be loaded: "is an invalid layer - not loaded".
> In this I agree with Aren here: http://hub.qgis.org/issues/11317#note-6
> 
> > That the first column often happens to be the primary key and and the 
> > combobox
> > is not lexically sorted is somewhat pure luck - and unless you avoid having 
> > the
> > key verified (using "use estimated metadata"), keeping a wrongly select
> > column will make the layer to insert invalid.
> 
> I agree that the reported regression was based on the false expectation
> that QGIS would pick a primary key automatically, but in the
> (unlikely?) case a user was aware of that and properly coded the view
> to ensure primary key was first (or only) numeric the change was
> indeed a degradation of the experience.
> 
> > But I agree that the tooltip that you get on disabled lines (not only for 
> > the
> > key selection, but also geometry type and srid) might not be visible enough
> > (but that IMHO would be just a GUI enhancement).
> 
> There should maybe be another rule about LTS backports being:
> debatable fixes/enhancement need to be debated more on list ?
> 
> --strk;
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Andreas Neumann

Hi,

I would regard the loading of layers from a database something 
"relatively advanced". Normally I prepare ready to use QGIS project to 
my users who edit and query our GIS data where they don't have to bother 
with loading layers.


But you are correct that it can be different persons - the one who 
creates the view and the ones who are loading them.


You are welcome to improve the situation/GUI, but please don't go back 
to the old behavior where it is an assumption that the first column in 
the list is always the primary key.


Andreas

On 01.09.2015 14:51, James Keener wrote:

Why are you assuming the user who created the view is the one using QGIS?

Jim

On 09/01/2015 08:50 AM, Andreas Neumann wrote:

Hi,

I agree with Jürgen - better let the user choose the pkey column. If the
user knows how to create a Postgis View he also knows how to select a
primary key column.

Andreas

On 01.09.2015 14:37, Jürgen E. Fischer wrote:

Hi Sandro,

On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:

I agree with Luca this should have been better not backported to 2.8.3.
Only proper bugs should be backported, and this was a (debatable)
GUI enhancement, as far as I can tell.

We intend to only backport fixes and not bugs. ;)

You were always supposed to select the key column - preselecting the first
column was the bug (also debatable).  And #11317 is a ticket that demonstrates
there were unaware users.

That the first column often happens to be the primary key and and the combobox
is not lexically sorted is somewhat pure luck - and unless you avoid having the
key verified (using "use estimated metadata"), keeping a wrongly select
column will make the layer to insert invalid.

But I agree that the tooltip that you get on disabled lines (not only for the
key selection, but also geometry type and srid) might not be visible enough
(but that IMHO would be just a GUI enhancement).


Jürgen



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



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



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


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Matthias Kuhn
Hi,

I would like to second Andreas, what we need is an improvement in the UI
to make the user aware of the problem.

My proposal (please review and improve)

1. Let the user choose whatever table/view he likes. Don't disable any
items.
2. If there are tables without a PK open a second modal dialog with an
explanation of the problem and offer to select a pk from a combobox.

-

3. Optional: Add a button "search suitable pk" which looks for a
suitable unique column.
4. Optional: Add a selection "read-only" to the combobox and do some
row_number() or other black magic and warn the user with a big red
dialog that he's about to do something very dangerous, unreliable and
that his warranty is now very void.

Best,
Matthias

On 09/01/2015 05:36 PM, Andreas Neumann wrote:
> Hi,
>
> I would regard the loading of layers from a database something
> "relatively advanced". Normally I prepare ready to use QGIS project to
> my users who edit and query our GIS data where they don't have to
> bother with loading layers.
>
> But you are correct that it can be different persons - the one who
> creates the view and the ones who are loading them.
>
> You are welcome to improve the situation/GUI, but please don't go back
> to the old behavior where it is an assumption that the first column in
> the list is always the primary key.
>
> Andreas
>
> On 01.09.2015 14:51, James Keener wrote:
>> Why are you assuming the user who created the view is the one using
>> QGIS?
>>
>> Jim
>>
>> On 09/01/2015 08:50 AM, Andreas Neumann wrote:
>>> Hi,
>>>
>>> I agree with Jürgen - better let the user choose the pkey column. If
>>> the
>>> user knows how to create a Postgis View he also knows how to select a
>>> primary key column.
>>>
>>> Andreas
>>>
>>> On 01.09.2015 14:37, Jürgen E. Fischer wrote:
 Hi Sandro,

 On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
> I agree with Luca this should have been better not backported to
> 2.8.3.
> Only proper bugs should be backported, and this was a (debatable)
> GUI enhancement, as far as I can tell.
 We intend to only backport fixes and not bugs. ;)

 You were always supposed to select the key column - preselecting
 the first
 column was the bug (also debatable).  And #11317 is a ticket that
 demonstrates
 there were unaware users.

 That the first column often happens to be the primary key and and
 the combobox
 is not lexically sorted is somewhat pure luck - and unless you
 avoid having the
 key verified (using "use estimated metadata"), keeping a wrongly
 select
 column will make the layer to insert invalid.

 But I agree that the tooltip that you get on disabled lines (not
 only for the
 key selection, but also geometry type and srid) might not be
 visible enough
 (but that IMHO would be just a GUI enhancement).


 Jürgen



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

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


Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
We also need to ask what qgis is doing with this and why we need to bug the 
user about it at all. 

Why do we not big the user about tables without a primary key? If tables can be 
loaded without a pk, why can't views.

Why can I select non-unique columns as primary keys and after loading the layer 
get no error?

Are these also bugs? Should I make (or find?) tickets for them?

Jim

On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn  wrote:
>Hi,
>
>I would like to second Andreas, what we need is an improvement in the
>UI
>to make the user aware of the problem.
>
>My proposal (please review and improve)
>
>1. Let the user choose whatever table/view he likes. Don't disable any
>items.
>2. If there are tables without a PK open a second modal dialog with an
>explanation of the problem and offer to select a pk from a combobox.
>
>-
>
>3. Optional: Add a button "search suitable pk" which looks for a
>suitable unique column.
>4. Optional: Add a selection "read-only" to the combobox and do some
>row_number() or other black magic and warn the user with a big red
>dialog that he's about to do something very dangerous, unreliable and
>that his warranty is now very void.
>
>Best,
>Matthias
>
>On 09/01/2015 05:36 PM, Andreas Neumann wrote:
>> Hi,
>>
>> I would regard the loading of layers from a database something
>> "relatively advanced". Normally I prepare ready to use QGIS project
>to
>> my users who edit and query our GIS data where they don't have to
>> bother with loading layers.
>>
>> But you are correct that it can be different persons - the one who
>> creates the view and the ones who are loading them.
>>
>> You are welcome to improve the situation/GUI, but please don't go
>back
>> to the old behavior where it is an assumption that the first column
>in
>> the list is always the primary key.
>>
>> Andreas
>>
>> On 01.09.2015 14:51, James Keener wrote:
>>> Why are you assuming the user who created the view is the one using
>>> QGIS?
>>>
>>> Jim
>>>
>>> On 09/01/2015 08:50 AM, Andreas Neumann wrote:
 Hi,

 I agree with Jürgen - better let the user choose the pkey column.
>If
 the
 user knows how to create a Postgis View he also knows how to select
>a
 primary key column.

 Andreas

 On 01.09.2015 14:37, Jürgen E. Fischer wrote:
> Hi Sandro,
>
> On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>> I agree with Luca this should have been better not backported to
>> 2.8.3.
>> Only proper bugs should be backported, and this was a (debatable)
>> GUI enhancement, as far as I can tell.
> We intend to only backport fixes and not bugs. ;)
>
> You were always supposed to select the key column - preselecting
> the first
> column was the bug (also debatable).  And #11317 is a ticket that
> demonstrates
> there were unaware users.
>
> That the first column often happens to be the primary key and and
> the combobox
> is not lexically sorted is somewhat pure luck - and unless you
> avoid having the
> key verified (using "use estimated metadata"), keeping a wrongly
> select
> column will make the layer to insert invalid.
>
> But I agree that the tooltip that you get on disabled lines (not
> only for the
> key selection, but also geometry type and srid) might not be
> visible enough
> (but that IMHO would be just a GUI enhancement).
>
>
> Jürgen
>
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


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

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
I realized I'm coming off very antagonistic and don't mean to be. I understand 
the importance of a primary key, but don't want users to be told to do anti 
patterns and non beneficial things like row_number.

I also feel that the ui should be consistent and not have surprises. Tables and 
views needed to be treated similarly, and if their not, they shouldn't be 
intermingled in the ui.

My apologizes, and I will try to write from now on with a more amiable tone.

Jim

On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn  wrote:
>Hi,
>
>I would like to second Andreas, what we need is an improvement in the
>UI
>to make the user aware of the problem.
>
>My proposal (please review and improve)
>
>1. Let the user choose whatever table/view he likes. Don't disable any
>items.
>2. If there are tables without a PK open a second modal dialog with an
>explanation of the problem and offer to select a pk from a combobox.
>
>-
>
>3. Optional: Add a button "search suitable pk" which looks for a
>suitable unique column.
>4. Optional: Add a selection "read-only" to the combobox and do some
>row_number() or other black magic and warn the user with a big red
>dialog that he's about to do something very dangerous, unreliable and
>that his warranty is now very void.
>
>Best,
>Matthias
>
>On 09/01/2015 05:36 PM, Andreas Neumann wrote:
>> Hi,
>>
>> I would regard the loading of layers from a database something
>> "relatively advanced". Normally I prepare ready to use QGIS project
>to
>> my users who edit and query our GIS data where they don't have to
>> bother with loading layers.
>>
>> But you are correct that it can be different persons - the one who
>> creates the view and the ones who are loading them.
>>
>> You are welcome to improve the situation/GUI, but please don't go
>back
>> to the old behavior where it is an assumption that the first column
>in
>> the list is always the primary key.
>>
>> Andreas
>>
>> On 01.09.2015 14:51, James Keener wrote:
>>> Why are you assuming the user who created the view is the one using
>>> QGIS?
>>>
>>> Jim
>>>
>>> On 09/01/2015 08:50 AM, Andreas Neumann wrote:
 Hi,

 I agree with Jürgen - better let the user choose the pkey column.
>If
 the
 user knows how to create a Postgis View he also knows how to select
>a
 primary key column.

 Andreas

 On 01.09.2015 14:37, Jürgen E. Fischer wrote:
> Hi Sandro,
>
> On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>> I agree with Luca this should have been better not backported to
>> 2.8.3.
>> Only proper bugs should be backported, and this was a (debatable)
>> GUI enhancement, as far as I can tell.
> We intend to only backport fixes and not bugs. ;)
>
> You were always supposed to select the key column - preselecting
> the first
> column was the bug (also debatable).  And #11317 is a ticket that
> demonstrates
> there were unaware users.
>
> That the first column often happens to be the primary key and and
> the combobox
> is not lexically sorted is somewhat pure luck - and unless you
> avoid having the
> key verified (using "use estimated metadata"), keeping a wrongly
> select
> column will make the layer to insert invalid.
>
> But I agree that the tooltip that you get on disabled lines (not
> only for the
> key selection, but also geometry type and srid) might not be
> visible enough
> (but that IMHO would be just a GUI enhancement).
>
>
> Jürgen
>
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


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

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread Matthias Kuhn
On 09/01/2015 05:54 PM, James Keener wrote:
> We also need to ask what qgis is doing with this and why we need to
> bug the user about it at all.
>
> Why do we not big the user about tables without a primary key? If
> tables can be loaded without a pk, why can't views.
QGIS relies on feature ids for a lot of different things to
unambiguously identify features.

For tables there is a (also not optimal) ctid which can be used as
feature id:
http://www.postgresql.org/docs/8.2/static/ddl-system-columns.html

For views there is none (see
http://www.postgresql.org/docs/9.1/static/rules-views.html, section 37.2.4)
>
> Why can I select non-unique columns as primary keys and after loading
> the layer get no error?
Because a lot of things in QGIS rely on feature ids and see above why
the fallback which exists for tables does not work for views.
Especially - but not only - editing. See my proposal #4.
>
> Are these also bugs? Should I make (or find?) tickets for them?
>
> Jim
>
> On September 1, 2015 11:49:23 AM EDT, Matthias Kuhn
>  wrote:
>
> Hi,
>
> I would like to second Andreas, what we need is an improvement in the UI
> to make the user aware of the problem.
>
> My proposal (please review and improve)
>
> 1. Let the user choose whatever table/view he likes. Don't disable any
> items.
> 2. If there are tables without a PK open a second modal dialog with an
> explanation of the problem and offer to select a pk from a combobox.
>
> -
>
> 3. Optional: Add a button "search suitable pk" which looks for a
> suitable unique column.
> 4. Optional: Add a selection "read-only" to the combobox and do some
> row_number() or other black magic and warn the user with a big red
> dialog that he's about to do something very dangerous, unreliable and
> that his warranty is now very void.
>
> Best,
> Matthias
>
> On 09/01/2015 05:36 PM, Andreas Neumann wrote:
>
> Hi, I would regard the loading of layers from a database
> something "relatively advanced". Normally I prepare ready to
> use QGIS project to my users who edit and query our GIS data
> where they don't have to bother with loading layers. But you
> are correct that it can be different persons - the one who
> creates the view and the ones who are loading them. You are
> welcome to improve the situation/GUI, but please don't go back
> to the old behavior where it is an assumption that the first
> column in the list is always the primary key. Andreas On
> 01.09.2015 14:51, James Keener wrote:
>
> Why are you assuming the user who created the view is the
> one using QGIS? Jim On 09/01/2015 08:50 AM, Andreas
> Neumann wrote:
>
> Hi, I agree with Jürgen - better let the user choose
> the pkey column. If the user knows how to create a
> Postgis View he also knows how to select a primary key
> column. Andreas On 01.09.2015 14:37, Jürgen E. Fischer
> wrote:
>
> Hi Sandro, On Tue, 01. Sep 2015 at 13:48:33 +0200,
> Sandro Santilli wrote:
>
> I agree with Luca this should have been better
> not backported to 2.8.3. Only proper bugs
> should be backported, and this was a
> (debatable) GUI enhancement, as far as I can
> tell. 
>
> We intend to only backport fixes and not bugs. ;)
> You were always supposed to select the key column
> - preselecting the first column was the bug (also
> debatable). And #11317 is a ticket that
> demonstrates there were unaware users. That the
> first column often happens to be the primary key
> and and the combobox is not lexically sorted is
> somewhat pure luck - and unless you avoid having
> the key verified (using "use estimated metadata"),
> keeping a wrongly select column will make the
> layer to insert invalid. But I agree that the
> tooltip that you get on disabled lines (not only
> for the key selection, but also geometry type and
> srid) might not be visible enough (but that IMHO
> would be just a GUI enhancement). Jürgen
> 
> 
> Qgis-user mailing list Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user 
>
> 
> 
> Qgis-user mailing list 

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread James Keener
Re: postgresql in my experience it's neither cumbersome nor slow. Feel free to 
email me for help if you would like to explore that route.

Are the paths in you qgs file relative or absolute? If their relative, is the 
issue that the path separator is different? If that is the issue, I would file 
a bug report. (If they are absolute, try saving them with relative paths.)

Jim

On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson"  wrote:
>Hi
>I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as
>well as the PCs) and accesses data on a shared drive. Now the problem
>comes
>up that data sources have different paths to the shared drive in each
>operating system, making cooperation difficult. On the other hand,
>since
>the .qgs file is easy to edit, some simple solution might map the paths
>automatically on open and back on save, to compensate for these
>differences. And maybe there is some other solution out there.
>I realize that having all shared data in PostGIS might be one way to
>solve
>this but I suspect that it might be both slower and a little more
>cumbersome.
>All thoughts and suggestions are highly appreciated.
>
>Árni Geirsson
>
>
>
>
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread Árni Geirsson
Thanks Jim
Your answer encourages me to try the PostGIS option - it obviously has some
other useful advantages. But your reply also made me realize that the
problem is really that much of the data I have is on another network share
- hence the problem with the paths. I should simply move the data so that
everything is on the same share and and then, relative paths will solve the
problem.
Again, thank you for a very helpful answer.

Arni


Árni Geirsson
*Alta ehf* // +354 582 5000 // +354 897 9549
www.alta.is  // Alta á Twitter  // Alta á
Facebook 

On Tue, Sep 1, 2015 at 3:26 PM, James Keener  wrote:

> Re: postgresql in my experience it's neither cumbersome nor slow. Feel
> free to email me for help if you would like to explore that route.
>
> Are the paths in you qgs file relative or absolute? If their relative, is
> the issue that the path separator is different? If that is the issue, I
> would file a bug report. (If they are absolute, try saving them with
> relative paths.)
>
> Jim
>
> On September 1, 2015 11:12:10 AM EDT, "Árni Geirsson" 
> wrote:
>
>> Hi
>> I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as
>> well as the PCs) and accesses data on a shared drive. Now the problem comes
>> up that data sources have different paths to the shared drive in each
>> operating system, making cooperation difficult. On the other hand, since
>> the .qgs file is easy to edit, some simple solution might map the paths
>> automatically on open and back on save, to compensate for these
>> differences. And maybe there is some other solution out there.
>> I realize that having all shared data in PostGIS might be one way to
>> solve this but I suspect that it might be both slower and a little more
>> cumbersome.
>> All thoughts and suggestions are highly appreciated.
>>
>> Árni Geirsson
>>
>> --
>>
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
I'm not saying the old behaviour is correct.

I'm saying the new behavior isn't friendly to non expert users. Loading from a 
database is no more difficult than loading a shapefile in most cases. I have 
clients and students do it quite often and "windowing function" means nothing 
and "primary key" is only a vague notion.

Please don't just accept a broken ui because its something _you think_ only 
"relatively advanced" users will use.

Moving towards a solution: how would people feel about a window appearing after 
selecting a view specifically asking which field to use (if one wasn't selected 
in the initial drop down). Alternatively, moving the in-row drop down to the 
beginning of the row so that small window sizes don't cut it off, and putting a 
yellow warning on it to draw attention. 

Jim

On September 1, 2015 11:36:09 AM EDT, Andreas Neumann  
wrote:
>Hi,
>
>I would regard the loading of layers from a database something 
>"relatively advanced". Normally I prepare ready to use QGIS project to 
>my users who edit and query our GIS data where they don't have to
>bother 
>with loading layers.
>
>But you are correct that it can be different persons - the one who 
>creates the view and the ones who are loading them.
>
>You are welcome to improve the situation/GUI, but please don't go back 
>to the old behavior where it is an assumption that the first column in 
>the list is always the primary key.
>
>Andreas
>
>On 01.09.2015 14:51, James Keener wrote:
>> Why are you assuming the user who created the view is the one using
>QGIS?
>>
>> Jim
>>
>> On 09/01/2015 08:50 AM, Andreas Neumann wrote:
>>> Hi,
>>>
>>> I agree with Jürgen - better let the user choose the pkey column. If
>the
>>> user knows how to create a Postgis View he also knows how to select
>a
>>> primary key column.
>>>
>>> Andreas
>>>
>>> On 01.09.2015 14:37, Jürgen E. Fischer wrote:
 Hi Sandro,

 On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
> I agree with Luca this should have been better not backported to
>2.8.3.
> Only proper bugs should be backported, and this was a (debatable)
> GUI enhancement, as far as I can tell.
 We intend to only backport fixes and not bugs. ;)

 You were always supposed to select the key column - preselecting
>the first
 column was the bug (also debatable).  And #11317 is a ticket that
>demonstrates
 there were unaware users.

 That the first column often happens to be the primary key and and
>the combobox
 is not lexically sorted is somewhat pure luck - and unless you
>avoid having the
 key verified (using "use estimated metadata"), keeping a wrongly
>select
 column will make the layer to insert invalid.

 But I agree that the tooltip that you get on disabled lines (not
>only for the
 key selection, but also geometry type and srid) might not be
>visible enough
 (but that IMHO would be just a GUI enhancement).


 Jürgen



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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Adding a Mac to a group of PCs

2015-09-01 Thread John Harrop
Árni,

We have been working very successfully with the same combination.  In fact, 
most of the PC users were using ESRI software with the Macs using only QGIS 
(obviously?).  We use a directory structure based on the Grass style and shared 
(across continents) using Dropbox.  Most are using the business version of 
Dropbox for better control on read/write access.

A simplesolution for us has been to use two qgs files if needed for the same 
data files (or the ESRI equivalent).  The problem has then been limited to 
sharing formatting and the data sharing has been quite seamless.

I like the PostGIS idea and I’m moving to that more as well, but I’m not sure 
how much more that solves regarding sharing versus the simpler method explained 
above.

John Harrop

> On Sep 1, 2015, at 8:12 AM, Árni Geirsson  wrote:
> 
> Hi
> I am adding a Mac to a local network of PCs. The Mac user uses QGIS (as well 
> as the PCs) and accesses data on a shared drive. Now the problem comes up 
> that data sources have different paths to the shared drive in each operating 
> system, making cooperation difficult. On the other hand, since the .qgs file 
> is easy to edit, some simple solution might map the paths automatically on 
> open and back on save, to compensate for these differences. And maybe there 
> is some other solution out there. 
> I realize that having all shared data in PostGIS might be one way to solve 
> this but I suspect that it might be both slower and a little more cumbersome.
> All thoughts and suggestions are highly appreciated.
> 
> Árni Geirsson
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user

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

Re: [Qgis-user] QGIS 2.10.1 adding PostGIS Views

2015-09-01 Thread James Keener
Please stop saying this. It's fine for certain situations, but it is not a 
permanently unique identifier for a row.  It may change when the underlying 
table is altered. Sure, it's unique if you read the results and keep them in 
memory and never talk about it again, but qgis does that on its own already.

Moreover querying on it is extremely inefficient. Querying against it forces a 
sequence scan on the table. Depending on the table and version, it could also 
try to materialize the view fully in memory before doing the scan.

Jim

On September 1, 2015 11:31:32 AM EDT, "Leknín Řepánek" 
 wrote:
>Workaround about primary key in view, i had use sever times is using
>window function "row_number() over()". It works in views and in query
>from database manager.
>
>Je;
>
>On Tue, Sep 01, 2015 at 04:09:49PM +0200, Sandro Santilli wrote:
>> On Tue, Sep 01, 2015 at 02:37:22PM +0200, Jürgen E. Fischer wrote:
>> > Hi Sandro,
>> > 
>> > On Tue, 01. Sep 2015 at 13:48:33 +0200, Sandro Santilli wrote:
>> > > I agree with Luca this should have been better not backported to
>2.8.3.
>> > > Only proper bugs should be backported, and this was a (debatable)
>> > > GUI enhancement, as far as I can tell.
>> > 
>> > We intend to only backport fixes and not bugs. ;)
>> > 
>> > You were always supposed to select the key column - preselecting
>the first
>> > column was the bug (also debatable).  And #11317 is a ticket that
>demonstrates
>> > there were unaware users.
>> 
>> Reading #11317 I looks to me that the reported bug was about
>> "Add PostGIS Layer" not giving the user full detail of why a
>> layer could not be loaded: "is an invalid layer - not loaded".
>> In this I agree with Aren here:
>http://hub.qgis.org/issues/11317#note-6
>> 
>> > That the first column often happens to be the primary key and and
>the combobox
>> > is not lexically sorted is somewhat pure luck - and unless you
>avoid having the
>> > key verified (using "use estimated metadata"), keeping a wrongly
>select
>> > column will make the layer to insert invalid.
>> 
>> I agree that the reported regression was based on the false
>expectation
>> that QGIS would pick a primary key automatically, but in the
>> (unlikely?) case a user was aware of that and properly coded the view
>> to ensure primary key was first (or only) numeric the change was
>> indeed a degradation of the experience.
>> 
>> > But I agree that the tooltip that you get on disabled lines (not
>only for the
>> > key selection, but also geometry type and srid) might not be
>visible enough
>> > (but that IMHO would be just a GUI enhancement).
>> 
>> There should maybe be another rule about LTS backports being:
>> debatable fixes/enhancement need to be debated more on list ?
>> 
>> --strk;
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>___
>Qgis-user mailing list
>Qgis-user@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-user

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user