Re: [Qgis-developer] Attribute Editor: Dual View
Am 10.01.2013 17:03, schrieb Matthias Kuhn: On 01/10/2013 04:52 PM, Bernhard Ströbl wrote: Am 10.01.2013 16:12, schrieb Matthias Kuhn: -- 8< snip -- "E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants" in extended selection enter: num_inhabitants > 10 click: "new selection" result (example): 150 datasets selected "and some others which do not meet this criterion, but some other criteria." in extended selection enter: some_other_field = some_other_ctriteria click: "add to selection" result (example): 270 datasets selected (150 from before + 120 matching "some_other_criteria") after that you can manually remove all datasets that you do not need from the selection but I doubt this is a real use case, because how would you decide which to keep and which to remove? Obviously because some attributes match certain criteria, so here we go: e.g. user wants to see only the cities with an airport in extended selection enter: airport = false click: "remove from selection" result (example): 205 datasets selected (from the previosuly selected 65 do not have an airport and are therefore removed from the selection) now have a look at the map and see where these cities are, in this case manual removal seems imaginable, so lets remove 7 from the selection; result: 198 datasets selected (205 - 7) in both table and map! now the user can do anything with this selection (update certain fields, export to new dataset, use for a spatial query...) I am of course totally aware that the 205 datasets can be achieved by using only one query like "(num_inhabitants > 10 OR some_other_field = some_other_ctriteria) AND airport = true" but the whole thing starts getting interesting when we imagine a spatial query in the start e.g. "select all cities within 20 km from the sea" then we could got to the attribute table enter "(num_inhabitants <= 10 OR some_other_field != some_other_ctriteria) AND airport = false" and click "remove from selection" to get a result containing all cities with either more than 10 inhabitants or some_other_ctriteria and an airport and within 20 km of the sea the "show only selected" checkbox should of course work as one would expect it to i.e. whenever the selection changes, no matter if this change originates from a user's click in the table or map or from using one of the selection buttons the dataset shown contains _all_ currently selected datasets and _only_ them I cannot imagine any use case that can not be tackled with what I propose but I have a feeling that the filter/selection concept would really confuse users Ok, I think I got your idea. Of course it is possible to generate a useful selection now already by using an appropriate expression. This works as long as your requirements are well defined (as in num_inhabitants > 10 AND airport = true etc.). Unfortunately that's not always the case as in this OSM data I've had a look at recently, where the number of stories was supposed to be in a field but sometimes something like "4-8", ">9" etc. was in there, requiring special attention. And there is the other use-case I mentioned in my last mail (and that's probably the main reason): The attribute editor view (the one with the list on the left and the attribute editor on the right) will greatly benefit from the filter/selection paradigm. In the example before (number of stories), you can apply a filter, to only show the buildings not containing a clean number (i.e. requiring inspection) and manually adjust the numbers to be in a consistent format you can use. In this case you will need the selection to change (because you change it, whenever you change the currently edited feature(s)) but you don't want your filter to change before you finished inspecting all the suspicious features. bare with me I do not get your point here. Why would I change the selection when I change a feature's value? We do not even have a selection, do we? All we have is a filter. ...ahh wait a bit... the filter is applied once and stays even if data are changed so they do not match the filter anymore - but that is the current behaviour with a selection, isn't it? How if we had a selection and tick "show selected only" and switch to the attribute view where we fix one dataset after another - would that be any different from using the filter? I really do like the dual view idea but do not understand why it is linked to the filter. The filter should always represent the current status of the data, even when it changes. The selection needs to be changed, because it defines which feature is currently visible in the attribute editor (right side of the editor view). And if you want to edit 5 different features one after the other, you change the selection 5 times. ok, I see, but that would be a different behaviour from wha
Re: [Qgis-developer] Attribute Editor: Dual View
On 01/10/2013 04:52 PM, Bernhard Ströbl wrote: Am 10.01.2013 16:12, schrieb Matthias Kuhn: -- 8< snip -- "E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants" in extended selection enter: num_inhabitants > 10 click: "new selection" result (example): 150 datasets selected "and some others which do not meet this criterion, but some other criteria." in extended selection enter: some_other_field = some_other_ctriteria click: "add to selection" result (example): 270 datasets selected (150 from before + 120 matching "some_other_criteria") after that you can manually remove all datasets that you do not need from the selection but I doubt this is a real use case, because how would you decide which to keep and which to remove? Obviously because some attributes match certain criteria, so here we go: e.g. user wants to see only the cities with an airport in extended selection enter: airport = false click: "remove from selection" result (example): 205 datasets selected (from the previosuly selected 65 do not have an airport and are therefore removed from the selection) now have a look at the map and see where these cities are, in this case manual removal seems imaginable, so lets remove 7 from the selection; result: 198 datasets selected (205 - 7) in both table and map! now the user can do anything with this selection (update certain fields, export to new dataset, use for a spatial query...) I am of course totally aware that the 205 datasets can be achieved by using only one query like "(num_inhabitants > 10 OR some_other_field = some_other_ctriteria) AND airport = true" but the whole thing starts getting interesting when we imagine a spatial query in the start e.g. "select all cities within 20 km from the sea" then we could got to the attribute table enter "(num_inhabitants <= 10 OR some_other_field != some_other_ctriteria) AND airport = false" and click "remove from selection" to get a result containing all cities with either more than 10 inhabitants or some_other_ctriteria and an airport and within 20 km of the sea the "show only selected" checkbox should of course work as one would expect it to i.e. whenever the selection changes, no matter if this change originates from a user's click in the table or map or from using one of the selection buttons the dataset shown contains _all_ currently selected datasets and _only_ them I cannot imagine any use case that can not be tackled with what I propose but I have a feeling that the filter/selection concept would really confuse users Ok, I think I got your idea. Of course it is possible to generate a useful selection now already by using an appropriate expression. This works as long as your requirements are well defined (as in num_inhabitants > 10 AND airport = true etc.). Unfortunately that's not always the case as in this OSM data I've had a look at recently, where the number of stories was supposed to be in a field but sometimes something like "4-8", ">9" etc. was in there, requiring special attention. And there is the other use-case I mentioned in my last mail (and that's probably the main reason): The attribute editor view (the one with the list on the left and the attribute editor on the right) will greatly benefit from the filter/selection paradigm. In the example before (number of stories), you can apply a filter, to only show the buildings not containing a clean number (i.e. requiring inspection) and manually adjust the numbers to be in a consistent format you can use. In this case you will need the selection to change (because you change it, whenever you change the currently edited feature(s)) but you don't want your filter to change before you finished inspecting all the suspicious features. bare with me I do not get your point here. Why would I change the selection when I change a feature's value? We do not even have a selection, do we? All we have is a filter. ...ahh wait a bit... the filter is applied once and stays even if data are changed so they do not match the filter anymore - but that is the current behaviour with a selection, isn't it? How if we had a selection and tick "show selected only" and switch to the attribute view where we fix one dataset after another - would that be any different from using the filter? I really do like the dual view idea but do not understand why it is linked to the filter. The filter should always represent the current status of the data, even when it changes. The selection needs to be changed, because it defines which feature is currently visible in the attribute editor (right side of the editor view). And if you want to edit 5 different features one after the other, you change the selection 5 times. Once you changed a certain feature, it may disappear from the filter. The others stay visib
Re: [Qgis-developer] Attribute Editor: Dual View
Am 10.01.2013 16:12, schrieb Matthias Kuhn: -- 8< snip -- "E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants" in extended selection enter: num_inhabitants > 10 click: "new selection" result (example): 150 datasets selected "and some others which do not meet this criterion, but some other criteria." in extended selection enter: some_other_field = some_other_ctriteria click: "add to selection" result (example): 270 datasets selected (150 from before + 120 matching "some_other_criteria") after that you can manually remove all datasets that you do not need from the selection but I doubt this is a real use case, because how would you decide which to keep and which to remove? Obviously because some attributes match certain criteria, so here we go: e.g. user wants to see only the cities with an airport in extended selection enter: airport = false click: "remove from selection" result (example): 205 datasets selected (from the previosuly selected 65 do not have an airport and are therefore removed from the selection) now have a look at the map and see where these cities are, in this case manual removal seems imaginable, so lets remove 7 from the selection; result: 198 datasets selected (205 - 7) in both table and map! now the user can do anything with this selection (update certain fields, export to new dataset, use for a spatial query...) I am of course totally aware that the 205 datasets can be achieved by using only one query like "(num_inhabitants > 10 OR some_other_field = some_other_ctriteria) AND airport = true" but the whole thing starts getting interesting when we imagine a spatial query in the start e.g. "select all cities within 20 km from the sea" then we could got to the attribute table enter "(num_inhabitants <= 10 OR some_other_field != some_other_ctriteria) AND airport = false" and click "remove from selection" to get a result containing all cities with either more than 10 inhabitants or some_other_ctriteria and an airport and within 20 km of the sea the "show only selected" checkbox should of course work as one would expect it to i.e. whenever the selection changes, no matter if this change originates from a user's click in the table or map or from using one of the selection buttons the dataset shown contains _all_ currently selected datasets and _only_ them I cannot imagine any use case that can not be tackled with what I propose but I have a feeling that the filter/selection concept would really confuse users Ok, I think I got your idea. Of course it is possible to generate a useful selection now already by using an appropriate expression. This works as long as your requirements are well defined (as in num_inhabitants > 10 AND airport = true etc.). Unfortunately that's not always the case as in this OSM data I've had a look at recently, where the number of stories was supposed to be in a field but sometimes something like "4-8", ">9" etc. was in there, requiring special attention. And there is the other use-case I mentioned in my last mail (and that's probably the main reason): The attribute editor view (the one with the list on the left and the attribute editor on the right) will greatly benefit from the filter/selection paradigm. In the example before (number of stories), you can apply a filter, to only show the buildings not containing a clean number (i.e. requiring inspection) and manually adjust the numbers to be in a consistent format you can use. In this case you will need the selection to change (because you change it, whenever you change the currently edited feature(s)) but you don't want your filter to change before you finished inspecting all the suspicious features. bare with me I do not get your point here. Why would I change the selection when I change a feature's value? We do not even have a selection, do we? All we have is a filter. ...ahh wait a bit... the filter is applied once and stays even if data are changed so they do not match the filter anymore - but that is the current behaviour with a selection, isn't it? How if we had a selection and tick "show selected only" and switch to the attribute view where we fix one dataset after another - would that be any different from using the filter? I really do like the dual view idea but do not understand why it is linked to the filter. I suppose we won't get around this (unless the dual view as a whole is dumped) but I'm sure there is a possibility that will keep it as easy as possible for every user. Maybe a solution could be to detach the selection "advanced search" tool from the attribute table (keeping it available with a button) as also requested in http://hub.qgis.org/issues/6799. This tool could then also implement your ideas such as "add to selection", "remove from selection" and "intersect with sele
Re: [Qgis-developer] Attribute Editor: Dual View
On 01/10/2013 02:07 PM, Bernhard Ströbl wrote: Matthias, I try to do it with your words... Am 10.01.2013 13:18, schrieb Matthias Kuhn: Bernhard, On 01/10/2013 07:39 AM, Bernhard Ströbl wrote: Hi Matthias, comments below. same here Am 09.01.2013 16:41, schrieb Matthias Kuhn: Hi Bernhard On 01/09/2013 03:07 PM, Bernhard Ströbl wrote: Hi Matthias (and others), I read your paper and I like the idea of the dual view because currently it is not possible to open the attribute editor from the table. On the other hand I am not convinced of the filter/selection proposal. IMHO one of the strengths when using GIS data is the unity of geometry and attribute data. Currently selecting a feature in the map also selects its attributes in the corresponding table and vice versa. examples: 1) Select in map and investigate attributes: If a filter was applied the data might not be visible in the table without clicking "selection to filter". 2) filter logical in table and investigate these features in the map: You would need an additional "filter to selection" button to handle this. 3) field calculator: will it update the selected or the filtered datasets? I think the whole concept will confuse average users. I would favour to keep the well established solution of features being selected no matter where (table or map) the selection was performed. I think the reasoning for the change in the selection/filter paradigm was rather poor in the document itself. There are other reasons which are in favor of a change of filter/selection as well. E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants and some others which do not meet this criterion, but some other criteria. At the moment, you can do this by sorting and scrolling and maybe some other tricks, but it's not that easy. With the independent filters, this would be a task of changing the filter and Ctrl-Clicking the required features out of each subset. I see the point in this, but the case you describe could be solved differently (that is at least theroretically :-). If the selection tool would not always create a new selection (as is now) but enable the user to either "add to selection" or "select within current selection" or even "remove from selection" this would IMHO be more straightforward for users. I'm sorry, I'm not able to follow this description exactly. Could you please describe in detail how you imagine the process. If possible, please also outline the scenario, where the user wants to check/update individually the attributes for all cities with more than 100'000 inhabitants in the attribute view. "E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants" in extended selection enter: num_inhabitants > 10 click: "new selection" result (example): 150 datasets selected "and some others which do not meet this criterion, but some other criteria." in extended selection enter: some_other_field = some_other_ctriteria click: "add to selection" result (example): 270 datasets selected (150 from before + 120 matching "some_other_criteria") after that you can manually remove all datasets that you do not need from the selection but I doubt this is a real use case, because how would you decide which to keep and which to remove? Obviously because some attributes match certain criteria, so here we go: e.g. user wants to see only the cities with an airport in extended selection enter: airport = false click: "remove from selection" result (example): 205 datasets selected (from the previosuly selected 65 do not have an airport and are therefore removed from the selection) now have a look at the map and see where these cities are, in this case manual removal seems imaginable, so lets remove 7 from the selection; result: 198 datasets selected (205 - 7) in both table and map! now the user can do anything with this selection (update certain fields, export to new dataset, use for a spatial query...) I am of course totally aware that the 205 datasets can be achieved by using only one query like "(num_inhabitants > 10 OR some_other_field = some_other_ctriteria) AND airport = true" but the whole thing starts getting interesting when we imagine a spatial query in the start e.g. "select all cities within 20 km from the sea" then we could got to the attribute table enter "(num_inhabitants <= 10 OR some_other_field != some_other_ctriteria) AND airport = false" and click "remove from selection" to get a result containing all cities with either more than 10 inhabitants or some_other_ctriteria and an airport and within 20 km of the sea the "show only selected" checkbox should of course wo
Re: [Qgis-developer] QGIS tool for vector data merging proposal
Hi, 2012/4/17 Viktor Nagy : > I hope this isn't the wrong place for this announcement, though I also sent > it to the soc list. It's a GSoC proposal. I'm Viktor Nagy, an MSc. student > at the University of Szeged, Hungary. > If you are interested, please have a look at my proposal about some advanced > vector data merging. > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/a0smucig/1 > Comments and suggestions are much appreciated! is anybody working on this topic? I have a student who is interested to work on it (just an idea). Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Attribute Editor: Dual View
Matthias, I try to do it with your words... Am 10.01.2013 13:18, schrieb Matthias Kuhn: Bernhard, On 01/10/2013 07:39 AM, Bernhard Ströbl wrote: Hi Matthias, comments below. same here Am 09.01.2013 16:41, schrieb Matthias Kuhn: Hi Bernhard On 01/09/2013 03:07 PM, Bernhard Ströbl wrote: Hi Matthias (and others), I read your paper and I like the idea of the dual view because currently it is not possible to open the attribute editor from the table. On the other hand I am not convinced of the filter/selection proposal. IMHO one of the strengths when using GIS data is the unity of geometry and attribute data. Currently selecting a feature in the map also selects its attributes in the corresponding table and vice versa. examples: 1) Select in map and investigate attributes: If a filter was applied the data might not be visible in the table without clicking "selection to filter". 2) filter logical in table and investigate these features in the map: You would need an additional "filter to selection" button to handle this. 3) field calculator: will it update the selected or the filtered datasets? I think the whole concept will confuse average users. I would favour to keep the well established solution of features being selected no matter where (table or map) the selection was performed. I think the reasoning for the change in the selection/filter paradigm was rather poor in the document itself. There are other reasons which are in favor of a change of filter/selection as well. E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants and some others which do not meet this criterion, but some other criteria. At the moment, you can do this by sorting and scrolling and maybe some other tricks, but it's not that easy. With the independent filters, this would be a task of changing the filter and Ctrl-Clicking the required features out of each subset. I see the point in this, but the case you describe could be solved differently (that is at least theroretically :-). If the selection tool would not always create a new selection (as is now) but enable the user to either "add to selection" or "select within current selection" or even "remove from selection" this would IMHO be more straightforward for users. I'm sorry, I'm not able to follow this description exactly. Could you please describe in detail how you imagine the process. If possible, please also outline the scenario, where the user wants to check/update individually the attributes for all cities with more than 100'000 inhabitants in the attribute view. "E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants" in extended selection enter: num_inhabitants > 10 click: "new selection" result (example): 150 datasets selected "and some others which do not meet this criterion, but some other criteria." in extended selection enter: some_other_field = some_other_ctriteria click: "add to selection" result (example): 270 datasets selected (150 from before + 120 matching "some_other_criteria") after that you can manually remove all datasets that you do not need from the selection but I doubt this is a real use case, because how would you decide which to keep and which to remove? Obviously because some attributes match certain criteria, so here we go: e.g. user wants to see only the cities with an airport in extended selection enter: airport = false click: "remove from selection" result (example): 205 datasets selected (from the previosuly selected 65 do not have an airport and are therefore removed from the selection) now have a look at the map and see where these cities are, in this case manual removal seems imaginable, so lets remove 7 from the selection; result: 198 datasets selected (205 - 7) in both table and map! now the user can do anything with this selection (update certain fields, export to new dataset, use for a spatial query...) I am of course totally aware that the 205 datasets can be achieved by using only one query like "(num_inhabitants > 10 OR some_other_field = some_other_ctriteria) AND airport = true" but the whole thing starts getting interesting when we imagine a spatial query in the start e.g. "select all cities within 20 km from the sea" then we could got to the attribute table enter "(num_inhabitants <= 10 OR some_other_field != some_other_ctriteria) AND airport = false" and click "remove from selection" to get a result containing all cities with either more than 10 inhabitants or some_other_ctriteria and an airport and within 20 km of the sea the "show only selected" checkbox should of course work as one would expect it to i.e. whenever the select
Re: [Qgis-developer] again on WPS plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 10/01/2013 13:21, Horst Düster ha scritto: > Hi Paolo, Luca > > I just checked the voronoi process and it worked fine form me. Yes, it works fine. The ongoing requests happen for other severs as well, just have a look to the logs. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDutHMACgkQ/NedwLUzIr4fkQCgt+tL6fIa6RbfM6mrAbRS5sUa hMkAnjKgH8otWQmzaT2W17SvYy4kyKv8 =3TPZ -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] again on WPS plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paolo, Luca I just checked the voronoi process and it worked fine form me. Horst Dr. Horst Düster Kappasys Alte Bernstrasse 13 CH-4500 Solothurn Tel.: +41 (0) 32 514 00 40 Mobil: +41 (0) 76 408 51 06 eMail: horst.dues...@kappasys.ch skype: horstduester Twitter: moazagotl Web: www.kappasys.ch Treasurer QGIS Project lat: N 47° 12' 06.408" lon: E 7° 32' 13.740" qgiscloud.com - The easiest way to publish online maps with your private GDI Am 10.01.2013 13:15, schrieb Luca Delucchi: > 2013/1/10 Paolo Cavallini : >> Hi all. > > Hi Paolo > >> After successfully completing the analysis, I keep on receiving network >> error messages: >> >> Network request >> http://geodati.fmach.it/zoo/?Request=DescribeProcess&identifier=v_voronoi&Service=WPS&Version=1.0.0 >> timed out >> >> apparently I have to restart QGIS to stop them. >> > > I also receive this messages and have the same messages, I already > inform Horst about this problem, I have no idea how to solve this > >> All the best. >> > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7rJhAAoJENJq1wkKM7pSuy0H/3S/vNvxPeXw0F4isGJcoPhB uopDa9DzIez/WBn58TSTrIqymfpw0rkkG0BPCEMKRVJer/h2Dwd8Kz/qvLNmSCd+ D6PGgGkSw4pSf9hOg7aYUNv7/bvm5dVhmIYy/g62eEPN8biow9qppiLZfkJVtmCQ Kf7SgupyybzOBYGU2/Sg2GadfynfpEc2EHRM42khc5g9qdr7fjb3KTjel8AGexkr emzorhW1o6IglLmJz0KSkzmPomeFKJMTr4BFG3QI5cvj+2YSVZecz90qqi6UYfUa U0OZNW7XwenAzDy5y8zEzpb+hxzwUKXx8DcIKTuwO3CGADY6n8MFQ+oMezM22Y4= =WpXe -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Attribute Editor: Dual View
Bernhard, On 01/10/2013 07:39 AM, Bernhard Ströbl wrote: Hi Matthias, comments below. same here Am 09.01.2013 16:41, schrieb Matthias Kuhn: Hi Bernhard On 01/09/2013 03:07 PM, Bernhard Ströbl wrote: Hi Matthias (and others), I read your paper and I like the idea of the dual view because currently it is not possible to open the attribute editor from the table. On the other hand I am not convinced of the filter/selection proposal. IMHO one of the strengths when using GIS data is the unity of geometry and attribute data. Currently selecting a feature in the map also selects its attributes in the corresponding table and vice versa. examples: 1) Select in map and investigate attributes: If a filter was applied the data might not be visible in the table without clicking "selection to filter". 2) filter logical in table and investigate these features in the map: You would need an additional "filter to selection" button to handle this. 3) field calculator: will it update the selected or the filtered datasets? I think the whole concept will confuse average users. I would favour to keep the well established solution of features being selected no matter where (table or map) the selection was performed. I think the reasoning for the change in the selection/filter paradigm was rather poor in the document itself. There are other reasons which are in favor of a change of filter/selection as well. E.g. If you want to manually select features out of different subsets. Let's say you have a layer with a lot of features and you're looking for a couple of cities (but not all of them) which have more than 100'000 inhabitants and some others which do not meet this criterion, but some other criteria. At the moment, you can do this by sorting and scrolling and maybe some other tricks, but it's not that easy. With the independent filters, this would be a task of changing the filter and Ctrl-Clicking the required features out of each subset. I see the point in this, but the case you describe could be solved differently (that is at least theroretically :-). If the selection tool would not always create a new selection (as is now) but enable the user to either "add to selection" or "select within current selection" or even "remove from selection" this would IMHO be more straightforward for users. I'm sorry, I'm not able to follow this description exactly. Could you please describe in detail how you imagine the process. If possible, please also outline the scenario, where the user wants to check/update individually the attributes for all cities with more than 100'000 inhabitants in the attribute view. Please excuse my ignorance Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] again on WPS plugin
2013/1/10 Paolo Cavallini : > Hi all. Hi Paolo > After successfully completing the analysis, I keep on receiving network error > messages: > > Network request > http://geodati.fmach.it/zoo/?Request=DescribeProcess&identifier=v_voronoi&Service=WPS&Version=1.0.0 > timed out > > apparently I have to restart QGIS to stop them. > I also receive this messages and have the same messages, I already inform Horst about this problem, I have no idea how to solve this > All the best. > -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] again on WPS plugin
Hi all. After successfully completing the analysis, I keep on receiving network error messages: Network request http://geodati.fmach.it/zoo/?Request=DescribeProcess&identifier=v_voronoi&Service=WPS&Version=1.0.0 timed out apparently I have to restart QGIS to stop them. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] fTools in sextante
Il 10/01/2013 12:45, Victor Olaya ha scritto: > Not really. They are all now under "QGIS algorithms", along with > SEXTANTE native ones and MMQGISX ones (basically, all the python ones > not needing external apps). I am just trying to reorder things so > there are less groups and everything is more homogeneous oh, I see, thanks for clarifying -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WPS plugin
Il 10/01/2013 12:46, Luca Delucchi ha scritto: > Now it is working for me, Paolo could you please test it? confirmed, thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WPS plugin
Now it is working for me, Paolo could you please test it? -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] fTools in sextante
Not really. They are all now under "QGIS algorithms", along with SEXTANTE native ones and MMQGISX ones (basically, all the python ones not needing external apps). I am just trying to reorder things so there are less groups and everything is more homogeneous Cheers Victor 2013/1/10 Paolo Cavallini : > Hi all. > fTools seem disappeared form Sextante, right? > All the best. > -- > Paolo Cavallini - Faunalia > www.faunalia.eu > Full contact details at www.faunalia.eu/pc > Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] fTools in sextante
Hi all. fTools seem disappeared form Sextante, right? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WPS plugin
2013/1/10 Luca Delucchi : > > yes, It is a problem with the last version, until yesterday it worked! No sorry, It's a server problem. I'm working to fix it. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WPS plugin
2013/1/10 Paolo Cavallini : > Hi all. > Testing the just upgrades WPS plugin, with geodati.fmach.it, module v_voronoi, > results in: > > It seems QGIS cannot load the result of the process. The result has a > 'text/xml' type > and can be accessed at '/tmp/qt_temp.jL9396.gml'. > > You could ask the service provider to consider changing the default data type > of the > result. > > Anyone confirms? yes, It is a problem with the last version, until yesterday it worked! Tomorrow I have a presentation about WPS and I would like to use WPS plugin and this problem is really a blocker for me. How can use the qgis master version of yesterday? > Thanks. > -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] WPS plugin
Hi all. Testing the just upgrades WPS plugin, with geodati.fmach.it, module v_voronoi, results in: It seems QGIS cannot load the result of the process. The result has a 'text/xml' type and can be accessed at '/tmp/qt_temp.jL9396.gml'. You could ask the service provider to consider changing the default data type of the result. Anyone confirms? Thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] python error after updating
the problem has already been fixed in master branch, so what you have to do is wait for the next nightly or compile the master version :-) You could also change that line in dialogSRS.py as you mentioned to get it working! Hi all, I see that the in nightly of today the problem with python has not been fixed. I really don't know how to compile the master version (my ignorance...). Does anyone have an idea of when this problem will be solved with the nightly? Thanks Cheers Matteo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] RFC for Data Frames
Hi Benedict (moving the discussion from qgis-psc to qgis-dev) On Wed, Jan 9, 2013 at 9:37 PM, Benedict Holland wrote: > Hi Tim, > > [...] > called that. I think it would make more sense to push a Legend onto the > QgsSubproject and I think I have a great use case in mind. > [...] Given the great impact your changes might have on the rest of the QGIS application (and possibly libraries, too), I would suggest starting with some mockups and use cases how the GUI would look like after, how existing features would behave etc. Diving directly into a discussion about the design decisions (like sub-projects) is not necessary if there's not a clear set idea how it should work. > Actually I do have a question regarding a lot of this. I have been diving > into the code and I see that many objects are managed using XML. Please could you be more specific? Some classses implement methods like readXml() and writeXml(), but that's really just for reading/saving of state - as Tim has already noted. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
