date:20140624

Il 24/06/2014 10:31, Paolo Cavallini ha scritto:

> I'm consistently getting an error running v.clean through Processing.
> The error layer is not produced (in fact,
> /tmp/processing/45d64e93dfee4b52a7229d3fdf2f84e9/ is empty).
> The cleaned layer is loaded correctly on the canvas.

Clarified: http://hub.qgis.org/issues/10702
Thanks Giovanni for helping.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Access count and center point from QgsPointDisplacementRenderer

2014-06-24 Thread Martin Dobias

Hi Matthias

On Tue, Jun 24, 2014 at 10:07 PM, Matthias Ludwig  wrote:
> Hi,
>
> for a project (python standalone) I try to display points in "clusters"
> (like the Leaflet-marker-Cluster
> http://leaflet.github.io/Leaflet.markercluster/example/marker-clustering-realworld.388.html,
> or Openlayers, etc. just a simple distance based solution).  As far as I
> understand the PointDisplacementRenderer more or less it does the same:
> group all points in a radius into a cluster and show the center point. If
> the tolerance is set depending on the scale the center points are displayed
> properly.
> I looked into the docs and the source code and didn't found a way to access
> the list of displacementGroups (to get the count and the center point) or
> just the count of points in each group. After that I tried to modify the
> source code of the renderer. I made the mDisplacementGroups publicly
> accessable (or i tried to do so) and moved the:
> typedef QMap DisplacementGroup;
> /**Groups of features that have the same position*/
> QList mDisplacementGroups;
> /**Mapping from feature ID to its group index*/
> above the private section but it didn't worked. Is this completly wrong or
> do I have to change something else to get access with the python bindings?
> Is there any way to get the center point of each group and the count from
> the current implementation?

Those members variables are just temporary and not meant to be used
publicly. I don't think there is a way to retrieve these groupings.

> I didn't found something in the mailing list or somewhere else: is someone
> working on a "visual clustering" solution?

If the time will allow, I would like to do few improvements to the
point displacement renderer. It would probably make sense to actually
take the clustering out of the renderer and have a class just for the
clustering algorithm that will return the groups.

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

Re: [Qgis-developer] Concurrent editing and locking in PostGIS

Il 24/06/2014 18:40, Tim Keitt ha scritto:
> Depends on a lot of factors. Generally updates and inserts will be serialized 
> and
> there will be little contention.

thanks. in the meantime I also found (thanks Giovanni) this interesting 
discussion:
http://hub.qgis.org/issues/972
all the best
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Concurrent editing and locking in PostGIS

2014-06-24 Thread Tim Keitt

Depends on a lot of factors. Generally updates and inserts will be
serialized and there will be little contention.

THK

http://www.postgresql.org/docs/9.1/static/mvcc-intro.html


On Tue, Jun 24, 2014 at 11:34 AM, Paolo Cavallini 
wrote:

> Hi all.
> What should be expected if many different users INSERT geometries on the
> same PostGIS
> table? Would editing from one be expected to lock out all others, or?
> Thanks for clarifying.
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



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

[Qgis-developer] Concurrent editing and locking in PostGIS

Hi all.
What should be expected if many different users INSERT geometries on the same 
PostGIS
table? Would editing from one be expected to lock out all others, or?
Thanks for clarifying.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Datum Transformation - parameters for mainland Portugal

2014-06-24 Thread Pedro Venâncio

Hi André,


- Mensagem original -
> DE: André Joost 
>>>
>>> The transformation table inside QGIS only has those tfm from the
>>> EPSG database where the target CRS is 4326 (we want towgs84,
>>> right?)
>>>
>>> So I suggest to set target CRS for all new portuguese CRS to 4326
>>> as well.
>>
>>
>> Yes, I know Andre, in my proposal I put the transformations to 4326,
>> except the transformations using NTv2 grids, since these have been
>> prepared specifically for 4258, and do not use the "+towgs84"
>> parameter, but "+nadgrids". What do you think?
>
> We need them to convert to WGS84. If Marco filters the EPSG list for
> target=4326, he won't get them.
>
> In earlier years, WGS84 parameters were adopted from ETRS89 with a note
> "assuming that WGS84 and ETSR89 are the same". They seem to have
> dropped
> that.
>


I've been doing some tests and, in the case of NTv2 grids, using 
target_crs_code 4258 vs 4326, the difference is ~0.104mm, which is compatible 
with the coord_op_scope (decimetre accuracy), don't you think? In this case, we 
can simply put 4326 as target_crs_code, right?

Anyway, as Marco already inserted portuguese grids in srs.db, and the parameter 
used is +nadgrids, we don't need to put 4326 as grids target, because it is 
already in QGIS and the filter to the EPSG DB will prevent duplication.


Different situation happens with Molodensky and Bursa-Wolf transformations. 

Apparently, the latest transformation parameters are being made available for 
4258. Nevertheless, if we use 4258 as target_crs_code, the error we get is 
huge, maybe because it generate some conflict with +towgs84 parameter.
So, simply changing the target_crs_code for 4326 (no further changes), it works 
ok.

I did some tests with tfm 5037, and with this same tfm but with target_crs_code 
changed to 4326. The results were these:
- Tmf 5037 (4274 -> 4258): more than 120m error! (this must be the problem with 
+towgs84)
- Tmf changed, using exactly the same transformation parameters, but with 
target_crs_code 4326 (4274 -> 4326): error ~0.292m. 

The question is, inevitably we have to put these latest transformations 
"manually" in srs.db, right? Otherwise they will be filtered out, because the 
target_crs is not 4326. There is nothing we can do with EPSG, right? 



>
>>
>>
>> The difference between them seems to me only the Prime Meridian, one
>> is referenced to Greenwich and the other to Lisbon:
>
> The transformation for those is a 2-step-transformation: First move the
> prime meridian from Lisbon to Greenwich, then do one of the
> Lisbon-to-WGS84 transformations. So no new parameters here.
>
>
>>
>> I also do not know if this has any implications on the accuracy of
>> the transformations, but which I find more strange is that all the
>> transformations are set from 4207. Would, in the past, EPSG
>> 20790/20791 were using Greenwich Prime Meridian, and this was updated
>> recently?
>


But then, why are the transformations referring to 4207 when the reference 
systems use pm=lisbon (4803) (except the new 5018)? This leads to this problem 
http://hub.qgis.org/issues/9614.



>
> No, they still use pm=lisbon, but 20791 was replaced by 5018 using
> Greenwich. The lon_0 moved from +1 to +lon_0=-8.1319062
>
> The pm=lisbon is at -9.0754862. I wonder why that fits.
>


I've been watching this and I get it! The information in the EPSG DB v8.4 is in 
Degrees, Minutes and Seconds, and when I extracted it for the table, the data 
in DMS changed the format. The longitude of datum Lisbon 1937 is 9°07'54.862" W 
of Greenwich, which, transformed to Decimal Degrees, is -9.1319062.
When I extracted that field to the table, it did not convert anything, simply 
changed from 9°07'54.862 to 9.0754862! :)



Regarding the Datum Transformation window, whenever I want to convert something 
to 4258, through a transformation +towgs84, what is done is, again, a 
2-step-transformation:
1) source_crs -> 4326
2) 4326 -> 4258.
The problem is that there are now two transformations in srs.db 4326 -> 4258: 
tfm 1149 (+towgs84=0,0,0); and tmf 1571, that as you explained already, is a 
bug in the EPSG DB, and is generating a lot of confusion in the 2nd step of the 
transformation.

I think all deprecated transformations should be dropped.


Thank you very much!

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

2014-06-24 Thread AntonioLocandro

 IMHO a scale bar is to enable
>>>>> readers to use their ruler to measure a distance on the map in _any_
>>>>> direction.
>>>>>
>>>>>> I agree that it's not very common and most people
>>>>>> are probably unused, but if you explicitly state the fact that the
>>> map
>>>>>> is in degrees you might even avoid confusion and prevent people from
>>>>>> trying to compare distances.
>>>>>
>>>>> But adding a scale bar encourages users to compare distances! The fact
>>>>> that a map is suitable to measure and compare distances is not decided
>>>>> by the map units but by the used projection and the covered area. If
>>>>> your map is in degrees just enable the graticules and (if useful) add
>>>>> a scalebar in m/km/miles (does that work with degrees? I have not
>>>>> tried. If not this would be a feature request.)
>>>>>
>>>> Doesn't really make sense to me. Graticules are just another reference
>>>> for distances (in degrees in this case) and an alternative or addition
>>>> to scale bars. What problem exactly would the combination of a grid in
>>>> degrees and a scalebar in meters solve?
>>>
>>> a scale bar makes distances measurable while a graticule helps
>>> localizing a point. In certain cases (projections) the graticule could
>>> be used for measuring, though.
>> You are right here. It's not a replacement but a bit of a different
>> thing (because graticules are not necessarily required to be straight).
>> So for the ship navigation example before, graticules in degrees for
>> localization (non-straight) combined with a meaningful scalebar (given a
>> suitable projection) make absolutely sense. My main point was, that a
>> graticule doesn't compensate for a scalebar on an unsuitable projection.
> 
> OK, total agreement, all is related to the projection, so the maker of 
> the map has to use care to choose a suitable one.
> 
>>>
>>>>
>>>>> BTW: for which point of a map is the scale bar currently created
>>>>> (thinking of non-distance-true projections and large areas e.g.
>>>>> continents)?
>>>> No idea.
>>>> But if there should be proper support for scalebars in meters on
>>>> degree-based maps, then it has to be configurable. And also the two
>>>> different scalebars (horizontal vs. vertical) that you mentioned. Then
>>>> it could be that there is a small enough area that this can be
>>>> considered accurate enough to be useful. And there should be
>>> warnings to
>>>> inform the mapper that he might be misleading readers and should
>>>> consider to reproject.
>>>
>>> I cannot imagine any use case for measuring distances in degrees. If
>>> you look at either of my maps you see that the south of Greenland is
>>> apporximately 40 degrees north of Cuba and that Canada covers almost
>>> 90 degrees in east-west direction. But why should someone measure this
>>> in degrees and not in km or miles? Would you measure the distance
>>> between your place and your favourite bar in degrees?
>>
>> That's not the right question to ask. Instead it should be: "Why would
>> someone want to measure distances on an unsuitable projection, with a
>> ruler that he has no idea if it has any meaning for the location he
>> tries to measure?".
> 
> Again, its up to the maker of the map to provide a scalebar if it is 
> meaningful and none otherwise, same with the graticule.
> 
>> The result is the same as when a friend measures the distance to his
>> favorite bar, find out that it's 2.8 miles and then telling me that it's
>> 2.8 km. I'd rather know that it's 2.8 "units" and therefore be aware of
>> the requirement to be careful with the interpretation of the result.
>> Or even better: have somebody warn my friend that he might be using the
>> wrong tool for the job he tries to accomplish :)
> 
> or even better: go with him to the bar to show you the way :-)
> 
> Bernhard
> 
> 
> __ Information from ESET Mail Security, version of virus signature
> database 9993 (20140624) __
> 
> The message was checked by ESET Mail Security.
> http://www.eset.com
> 
> 
> ___
> Qgis-developer mailing list

> Qgis-developer@.osgeo

> http://lists.osgeo.org/mailman/listinfo/qgis-developer





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QGIS-Crash-Serious-problem-in-2x-tp5147434p5147622.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

doesn't compensate for a scalebar on an unsuitable projection.


OK, total agreement, all is related to the projection, so the maker of 
the map has to use care to choose a suitable one.







BTW: for which point of a map is the scale bar currently created
(thinking of non-distance-true projections and large areas e.g.
continents)?

No idea.
But if there should be proper support for scalebars in meters on
degree-based maps, then it has to be configurable. And also the two
different scalebars (horizontal vs. vertical) that you mentioned. Then
it could be that there is a small enough area that this can be
considered accurate enough to be useful. And there should be

warnings to

inform the mapper that he might be misleading readers and should
consider to reproject.


I cannot imagine any use case for measuring distances in degrees. If
you look at either of my maps you see that the south of Greenland is
apporximately 40 degrees north of Cuba and that Canada covers almost
90 degrees in east-west direction. But why should someone measure this
in degrees and not in km or miles? Would you measure the distance
between your place and your favourite bar in degrees?


That's not the right question to ask. Instead it should be: "Why would
someone want to measure distances on an unsuitable projection, with a
ruler that he has no idea if it has any meaning for the location he
tries to measure?".


Again, its up to the maker of the map to provide a scalebar if it is 
meaningful and none otherwise, same with the graticule.



The result is the same as when a friend measures the distance to his
favorite bar, find out that it's 2.8 miles and then telling me that it's
2.8 km. I'd rather know that it's 2.8 "units" and therefore be aware of
the requirement to be careful with the interpretation of the result.
Or even better: have somebody warn my friend that he might be using the
wrong tool for the job he tries to accomplish :)


or even better: go with him to the bar to show you the way :-)

Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 9993 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] Access count and center point from QgsPointDisplacementRenderer

2014-06-24 Thread Matthias Ludwig

Hi,

 

for a project (python standalone) I try to display points in "clusters" (like the Leaflet-marker-Cluster http://leaflet.github.io/Leaflet.markercluster/example/marker-clustering-realworld.388.html, or Openlayers, etc. just a simple distance based solution).  As far as I understand the PointDisplacementRenderer more or less it does the same: group all points in a radius into a cluster and show the center point. If the tolerance is set depending on the scale the center points are displayed properly.

I looked into the docs and the source code and didn't found a way to access the list of displacementGroups (to get the count and the center point) or just the count of points in each group. After that I tried to modify the source code of the renderer. I made the mDisplacementGroups publicly accessable (or i tried to do so) and moved the:

    typedef QMap DisplacementGroup;
    /**Groups of features that have the same position*/
    QList mDisplacementGroups;
    /**Mapping from feature ID to its group index*/

above the private section but it didn't worked. Is this completly wrong or do I have to change something else to get access with the python bindings?

Is there any way to get the center point of each group and the count from the current implementation?

I didn't found something in the mailing list or somewhere else: is someone working on a "visual clustering" solution?

 

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

On 24.06.2014 16:10, Bernhard Ströbl wrote:
>
> Hi Matthias,
>
> In your mail I attached two files (not for the list). One is North
> America in a Lambert Conformal Conic projection, the other one in
> WGS84. Both show a grid with 10 degrees distance between parallels and
> meridians.
>
> Am 24.06.2014 14:02, schrieb Matthias Kuhn:
> > Hi Bernhard,
> >
> > On 24.06.2014 11:06, Bernhard Ströbl wrote:
> >> Hi Matthias,
> >>
> >> probably this is academical...
> >>
> >> Am 24.06.2014 10:42, schrieb Matthias Kuhn:
> >>> Hi Bernhard,
> >>>
> >>> I wouldn't say no sense at all. It strongly depends on the
> context, but
> >>> if you have for example a lesson for geography students and are
> >>> introducing CRS/projections and their properties one could want to
> add a
> >>> scale bar in degrees.
> >>
> >> But would that scalebar show the degrees for lon or lat?
> >
> > Maybe I am wrong, but I assume that there is no difference. One unit
> > (degree) will represent the same amount of pixels/points horizontal and
> > vertical.
>
> Well, you are wrong because one degree in lat is always ~110km whereas
> one degree in lon is ~110 km at the equator and e.g. in Zurich ~75km
> (for calculation see [1]). So how many pixels are 1 degree? Depends on
> the projection; in WGS84 it is the same amount no matter if for lon or
> lat, in Lambert it is not.

For Lambert neither one nor the other makes sense. The only appropriate
solution here would be some kind of "Lambert unit" whatever that may be.
But for the WGS84 map you sent the original statement above holds true:
the same amount of pixels matches the same amount of degrees everywhere
on the map (In terms of lat/lon, not in terms of degrees on the sphere
though). While a scalebar in km as provided is subject to distortion for
the exact reason you noted.

>
> >
> >> If the first (lon) for which latitude?
> > It doesn't matter in degrees. But it really matters when trying to
> put a
> > scalebar in meters.
>
> It does also matter in degrees, depending on the projection. same in
> meters: 1 cm on the map represents always a certain distance in
> reality (though this distance varies troughout the map depending on
> the projection and the area covered). If you look at the Lambert map,
> you realize that the distance between two parallels (10 degrees!)
> increases towards the pole, although in reality it is always (10*110km
> =) 1100 km. In the WGS84 map the distance between the parallels is
> constant but so is the distance between the meridians, but this is
> false as the distance gets less towards the pole in reality. So a
> scalebar (in m) being accurate in the middle of the map becomes less
> accurate towards the edges. Hence my question on which base the
> scalebar is calculated.

The question absolutely makes sense but I don't know the answer :)

>
> >> Either of the two: how do you want to tell people that this scalebar
> >> is only true for North-South (lat) or East-West (lon) measurements and
> >> must not be used in any other direction? IMHO a scale bar is to enable
> >> readers to use their ruler to measure a distance on the map in _any_
> >> direction.
> >>
> >>> I agree that it's not very common and most people
> >>> are probably unused, but if you explicitly state the fact that the
> map
> >>> is in degrees you might even avoid confusion and prevent people from
> >>> trying to compare distances.
> >>
> >> But adding a scale bar encourages users to compare distances! The fact
> >> that a map is suitable to measure and compare distances is not decided
> >> by the map units but by the used projection and the covered area. If
> >> your map is in degrees just enable the graticules and (if useful) add
> >> a scalebar in m/km/miles (does that work with degrees? I have not
> >> tried. If not this would be a feature request.)
> >>
> > Doesn't really make sense to me. Graticules are just another reference
> > for distances (in degrees in this case) and an alternative or addition
> > to scale bars. What problem exactly would the combination of a grid in
> > degrees and a scalebar in meters solve?
>
> a scale bar makes distances measurable while a graticule helps
> localizing a point. In certain cases (projections) the graticule could
> be used for measuring, though.
You are right here. It's not a replacement but a bit of a different
thing (because graticules are not necessarily required to be straight).
So for the ship navigation example before, graticules in degrees for
localization (non-straight) combined with a meaningful scalebar (given a
suitable projection) make absolutely sense. My main point was, that a
graticule doesn't compensate for a scalebar on an unsuitable projection.
>
> >
> >> BTW: for which point of a map is the scale bar currently created
> >> (thinking of non-distance-true projections and large areas e.g.
> >> continents)?
> > No idea.
> > But if there should be proper support for scalebars in meters on
> > degree-based maps, then it has to be configurable

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

Hi Matthias,

In your mail I attached two files (not for the list). One is North 
America in a Lambert Conformal Conic projection, the other one in WGS84. 
Both show a grid with 10 degrees distance between parallels and meridians.

Am 24.06.2014 14:02, schrieb Matthias Kuhn:
> Hi Bernhard,
>
> On 24.06.2014 11:06, Bernhard Ströbl wrote:
>> Hi Matthias,
>>
>> probably this is academical...
>>
>> Am 24.06.2014 10:42, schrieb Matthias Kuhn:
>>> Hi Bernhard,
>>>
>>> I wouldn't say no sense at all. It strongly depends on the context, but
>>> if you have for example a lesson for geography students and are
>>> introducing CRS/projections and their properties one could want to 
add a

>>> scale bar in degrees.
>>
>> But would that scalebar show the degrees for lon or lat?
>
> Maybe I am wrong, but I assume that there is no difference. One unit
> (degree) will represent the same amount of pixels/points horizontal and
> vertical.

Well, you are wrong because one degree in lat is always ~110km whereas 
one degree in lon is ~110 km at the equator and e.g. in Zurich ~75km 
(for calculation see [1]). So how many pixels are 1 degree? Depends on 
the projection; in WGS84 it is the same amount no matter if for lon or 
lat, in Lambert it is not.

>
>> If the first (lon) for which latitude?
> It doesn't matter in degrees. But it really matters when trying to put a
> scalebar in meters.

It does also matter in degrees, depending on the projection. same in 
meters: 1 cm on the map represents always a certain distance in reality 
(though this distance varies troughout the map depending on the 
projection and the area covered). If you look at the Lambert map, you 
realize that the distance between two parallels (10 degrees!) increases 
towards the pole, although in reality it is always (10*110km =) 1100 km. 
In the WGS84 map the distance between the parallels is constant but so 
is the distance between the meridians, but this is false as the distance 
gets less towards the pole in reality. So a scalebar (in m) being 
accurate in the middle of the map becomes less accurate towards the 
edges. Hence my question on which base the scalebar is calculated.

>> Either of the two: how do you want to tell people that this scalebar
>> is only true for North-South (lat) or East-West (lon) measurements and
>> must not be used in any other direction? IMHO a scale bar is to enable
>> readers to use their ruler to measure a distance on the map in _any_
>> direction.
>>
>>> I agree that it's not very common and most people
>>> are probably unused, but if you explicitly state the fact that the map
>>> is in degrees you might even avoid confusion and prevent people from
>>> trying to compare distances.
>>
>> But adding a scale bar encourages users to compare distances! The fact
>> that a map is suitable to measure and compare distances is not decided
>> by the map units but by the used projection and the covered area. If
>> your map is in degrees just enable the graticules and (if useful) add
>> a scalebar in m/km/miles (does that work with degrees? I have not
>> tried. If not this would be a feature request.)
>>
> Doesn't really make sense to me. Graticules are just another reference
> for distances (in degrees in this case) and an alternative or addition
> to scale bars. What problem exactly would the combination of a grid in
> degrees and a scalebar in meters solve?

a scale bar makes distances measurable while a graticule helps 
localizing a point. In certain cases (projections) the graticule could 
be used for measuring, though.

>
>> BTW: for which point of a map is the scale bar currently created
>> (thinking of non-distance-true projections and large areas e.g.
>> continents)?
> No idea.
> But if there should be proper support for scalebars in meters on
> degree-based maps, then it has to be configurable. And also the two
> different scalebars (horizontal vs. vertical) that you mentioned. Then
> it could be that there is a small enough area that this can be
> considered accurate enough to be useful. And there should be warnings to
> inform the mapper that he might be misleading readers and should
> consider to reproject.

I cannot imagine any use case for measuring distances in degrees. If you 
look at either of my maps you see that the south of Greenland is 
apporximately 40 degrees north of Cuba and that Canada covers almost 90 
degrees in east-west direction. But why should someone measure this in 
degrees and not in km or miles? Would you measure the distance between 
your place and your favourite bar in degrees?

all the best

Bernhard

[1] http://en.wikipedia.org/wiki/Longitude

__ Information from ESET Mail Security, version of virus signature 
database 9992 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

Hi Jorge

On 24.06.2014 14:34, Jorge Tornero - Listas wrote:
> Hello All,
>
> El 24/06/14 14:02, Matthias Kuhn escribió:
>> Doesn't really make sense to me. Graticules are just another
>> reference for distances (in degrees in this case) and an alternative
>> or addition to scale bars. What problem exactly would the combination
>> of a grid in degrees and a scalebar in meters solve?
>
> Well, you should try to think about people which may receive
> positioning info in degrees but need to judge distances in "real
> world" units: on ships, for instance (sorry but that's my
> bussiness...). And remember, always taking into account that the area
> should be relatively small.
... and close enough to the equator to have no horizontal/vertical
length mismatch problems.
In this case (comparing distances in real-world units) another
projection should actually be preferred. Putting the degrees-grid on top
of that in turn sounds very sensible.
>
> Grid in degrees --> Fast  positioning in the map.
> Scale in whichever units but degrees --> Fast estimation of distances,
> travel times, speeds.
>
> Of course you shouldn't trust this kinds of map to navigate... but for
> practical uses (survey planning (up to some extent), quick info,
> simple illustration) they are OK and appreciated.
>
>> No idea.But if there should be proper support for scalebars in meters
>> on degree-based maps, then it has to be configurable. And also the
>> two different scalebars (horizontal vs. vertical) that you mentioned.
>> Then it could be that there is a small enough area that this can be
>> considered accurate enough to be useful. And there should be warnings
>> to inform the mapper that he might be misleading readers and should
>> consider to reproject.
>
> To tell you the truth, in the actual state of the scalebar, all this
> is sort of tricky. It would be great to have it properly implemented,
> as you suggest. But maybe this maps are seldom used by the majority of
> QGIS users and it is not worth the effort and it may perfectly stay as
> a trick.

Thinking about it. A warning for unsuitable scale bars would be a nice
feature. That could be the shown if the scale varies by more than a
certain threshold over the map. I expect that this would help a lot of
people to even be aware of the risk involved when choosing projections
and to make a conscious decision.

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

Re: [Qgis-developer] qgis-server and troubles using jpeg as output format

2014-06-24 Thread Andrea Peri

Hi,
I do some tests.
Using a shell environment to see any error returned.

I see using the
"FORMAT=image/png"
 the image is correctly returned.
Instead using the
"FORMAT=image/jpeg"
the image is not returned.
But no crash at all.
Simply the qgis-server request will end returning nothing.

Also using a debug session no error reported.
Only apparently return nothing.


A.


2014-06-24 14:31 GMT+02:00 Andrea Peri :
> Hi,
> I'm having some trouble with qgis-server and the output in jpeg format.
>
> The request getmap using the jpeg format as not response at all.
>
> I try on two distinct debian machine but the result is the same.
>
> So I guess the most probable theory is the lack of a library or a
> library too early on Debian stable distro'.
>
> So I like to know what is the used jpeg library and if there is a
> minimal version for the jpeg library used.
>
> Thx
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -



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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

2014-06-24 Thread Jorge Tornero - Listas


Hello All,

El 24/06/14 14:02, Matthias Kuhn escribió:
Doesn't really make sense to me. Graticules are just another reference 
for distances (in degrees in this case) and an alternative or addition 
to scale bars. What problem exactly would the combination of a grid in 
degrees and a scalebar in meters solve?


Well, you should try to think about people which may receive positioning 
info in degrees but need to judge distances in "real world" units: on 
ships, for instance (sorry but that's my bussiness...). And remember, 
always taking into account that the area should be relatively small.


Grid in degrees --> Fast  positioning in the map.
Scale in whichever units but degrees --> Fast estimation of distances, 
travel times, speeds.


Of course you shouldn't trust this kinds of map to navigate... but for 
practical uses (survey planning (up to some extent), quick info, simple 
illustration) they are OK and appreciated.


No idea.But if there should be proper support for scalebars in meters 
on degree-based maps, then it has to be configurable. And also the two 
different scalebars (horizontal vs. vertical) that you mentioned. Then 
it could be that there is a small enough area that this can be 
considered accurate enough to be useful. And there should be warnings 
to inform the mapper that he might be misleading readers and should 
consider to reproject.


To tell you the truth, in the actual state of the scalebar, all this is 
sort of tricky. It would be great to have it properly implemented, as 
you suggest. But maybe this maps are seldom used by the majority of QGIS 
users and it is not worth the effort and it may perfectly stay as a trick.


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

[Qgis-developer] qgis-server and troubles using jpeg as output format

2014-06-24 Thread Andrea Peri

Hi,
I'm having some trouble with qgis-server and the output in jpeg format.

The request getmap using the jpeg format as not response at all.

I try on two distinct debian machine but the result is the same.

So I guess the most probable theory is the lack of a library or a
library too early on Debian stable distro'.

So I like to know what is the used jpeg library and if there is a
minimal version for the jpeg library used.

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

Re: [Qgis-developer] Error in MetaSearch

Il 24/06/2014 14:01, Richard Duivenvoorde ha scritto:

> @paolo: is it still reproducable by you?

yes, got it with current nightly (not recompiled afterwards).
Thanks.

-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Error in MetaSearch

2014-06-24 Thread Richard Duivenvoorde


Hi Tom,

I can reproduce it sometimes. Reading the mail I tested, and had Paolo's
error.

In the Log Console (tab 'Python warning')  I had a warning (sorry cannot
copy from the Log Console??):
... csw.py:356:UserWarning: CSW Server did not supply a nextRecord value
(it is optional), so the client should page througt the results in
another way.""

But NOW I cannot reproduce it anymore
I tried both the latest dev and the latest stable version :-(

@paolo: is it still reproducable by you?

Regards,

Richard Duivenvoorde





On 24-06-14 13:19, Tom Kralidis wrote:
> 
> Paolo: I can't reproduce this error.  Can you provide a use case (i.e.
> keyword used)?
> 
> Thanks
> 
> ..Tom
> 
> 
> On Tue, 24 Jun 2014, Paolo Cavallini wrote:
> 
>> Date: Tue, 24 Jun 2014 11:04:11 +0200
>> From: Paolo Cavallini 
>> To: qgis-developer 
>> Subject: [Qgis-developer] Error in MetaSearch
>>
>> Errore durante l'esecuzione di codice Python:
>>
>>
>> Hi all.
>> Adding the Italian CSW (http://www.rndt.gov.it/RNDT/CSW) to
>> MetaSearch, and searching
>> for a common keyword, I get > 10 records. Only 5 are displayed, even
>> if the dialog
>> reports "1-10 of 21 shown". If I click on the Next arrow, I get an
>> error (see below).
>> Should I open a ticket?
>> All the best.
>> ===
>> Traceback (most recent call last):
>>  File
>> "/usr/share/qgis/python/plugins/MetaSearch/dialogs/maindialog.py",
>> line 644,
>> in navigate
>>startposition=self.startfrom, esn='full')
>>  File "/usr/share/qgis/python/owslib/csw.py", line 348, in getrecords2
>>self.results['matches'] = int(util.testXMLValue(val, True))
>> TypeError: int() argument must be a string or a number, not 'NoneType'
>>
>>
>> Versione Python:
>> 2.7.7 (default, Jun  3 2014, 16:19:10)
>> [GCC 4.8.3]
>>
>>
>> Versione di QGIS:
>> 2.3.0-Master Master, exported
>>
>> Percorso Python:
>> ['/home/paolo/.qgis2/python/plugins/processinglwgeomprovider',
>> '/home/paolo/.qgis2/python/plugins/sextante_animove',
>> '/home/paolo/.qgis2/python/plugins/processing',
>> '/home/paolo/.qgis2/python/plugins/LecoS',
>> '/home/paolo/.qgis2/python/plugins/GeoCoding', '/usr/share/qgis/python',
>> u'/home/paolo/.qgis2/python', u'/home/paolo/.qgis2/python/plugins',
>> '/usr/share/qgis/python/plugins', '/usr/lib/python2.7',
>> '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk',
>> '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
>> '/usr/local/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages',
>> '/usr/lib/python2.7/dist-packages/PILcompat',
>> '/usr/lib/python2.7/dist-packages/gst-0.10',
>> '/usr/lib/python2.7/dist-packages/gtk-2.0',
>> '/usr/lib/pymodules/python2.7',
>> '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
>> '/home/paolo/.qgis2/python/plugins/mmqgis/forms',
>> '/home/paolo/.qgis2/python/plugins/QuickMultiAttributeEdit/forms',
>> '/usr/share/qgis/python/plugins/fTools/tools',
>> '/home/paolo/.qgis2/python/plugins/DigitizingTools/tools']
>> -- 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

Hi Bernhard,

On 24.06.2014 11:06, Bernhard Ströbl wrote:
> Hi Matthias,
>
> probably this is academical...
>
> Am 24.06.2014 10:42, schrieb Matthias Kuhn:
>> Hi Bernhard,
>>
>> I wouldn't say no sense at all. It strongly depends on the context, but
>> if you have for example a lesson for geography students and are
>> introducing CRS/projections and their properties one could want to add a
>> scale bar in degrees.
>
> But would that scalebar show the degrees for lon or lat?

Maybe I am wrong, but I assume that there is no difference. One unit
(degree) will represent the same amount of pixels/points horizontal and
vertical.

> If the first (lon) for which latitude?
It doesn't matter in degrees. But it really matters when trying to put a
scalebar in meters.
> Either of the two: how do you want to tell people that this scalebar
> is only true for North-South (lat) or East-West (lon) measurements and
> must not be used in any other direction? IMHO a scale bar is to enable
> readers to use their ruler to measure a distance on the map in _any_
> direction.
>
>> I agree that it's not very common and most people
>> are probably unused, but if you explicitly state the fact that the map
>> is in degrees you might even avoid confusion and prevent people from
>> trying to compare distances.
>
> But adding a scale bar encourages users to compare distances! The fact
> that a map is suitable to measure and compare distances is not decided
> by the map units but by the used projection and the covered area. If
> your map is in degrees just enable the graticules and (if useful) add
> a scalebar in m/km/miles (does that work with degrees? I have not
> tried. If not this would be a feature request.)
>
Doesn't really make sense to me. Graticules are just another reference
for distances (in degrees in this case) and an alternative or addition
to scale bars. What problem exactly would the combination of a grid in
degrees and a scalebar in meters solve?

> BTW: for which point of a map is the scale bar currently created
> (thinking of non-distance-true projections and large areas e.g.
> continents)?
No idea.
But if there should be proper support for scalebars in meters on
degree-based maps, then it has to be configurable. And also the two
different scalebars (horizontal vs. vertical) that you mentioned. Then
it could be that there is a small enough area that this can be
considered accurate enough to be useful. And there should be warnings to
inform the mapper that he might be misleading readers and should
consider to reproject.

Regards,
Matthias

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

Re: [Qgis-developer] Processing: module duplications

2014-06-24 Thread Alexander Bruy

2014-06-24 13:21 GMT+03:00 G. Allegri :
> The tagging system would be great, and in the future we can imagine a system
> to let a user groups algorithms under its own groups (like favorites links
> in the browser).

IMO "smart groups" like in Style Manager is flexible approach


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

Re: [Qgis-developer] Error in MetaSearch

Il 24/06/2014 13:19, Tom Kralidis ha scritto:
> 
> Paolo: I can't reproduce this error.  Can you provide a use case (i.e. 
> keyword used)?

I tried with province (21 results) the second click resulted in an error.
thanks.

-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Error in MetaSearch

2014-06-24 Thread Tom Kralidis



Paolo: I can't reproduce this error.  Can you provide a use case (i.e. keyword 
used)?

Thanks

..Tom


On Tue, 24 Jun 2014, Paolo Cavallini wrote:


Date: Tue, 24 Jun 2014 11:04:11 +0200
From: Paolo Cavallini 
To: qgis-developer 
Subject: [Qgis-developer] Error in MetaSearch

Errore durante l'esecuzione di codice Python:


Hi all.
Adding the Italian CSW (http://www.rndt.gov.it/RNDT/CSW) to MetaSearch, and 
searching
for a common keyword, I get > 10 records. Only 5 are displayed, even if the 
dialog
reports "1-10 of 21 shown". If I click on the Next arrow, I get an error (see 
below).
Should I open a ticket?
All the best.
===
Traceback (most recent call last):
 File "/usr/share/qgis/python/plugins/MetaSearch/dialogs/maindialog.py", line 
644,
in navigate
   startposition=self.startfrom, esn='full')
 File "/usr/share/qgis/python/owslib/csw.py", line 348, in getrecords2
   self.results['matches'] = int(util.testXMLValue(val, True))
TypeError: int() argument must be a string or a number, not 'NoneType'


Versione Python:
2.7.7 (default, Jun  3 2014, 16:19:10)
[GCC 4.8.3]


Versione di QGIS:
2.3.0-Master Master, exported

Percorso Python: ['/home/paolo/.qgis2/python/plugins/processinglwgeomprovider',
'/home/paolo/.qgis2/python/plugins/sextante_animove',
'/home/paolo/.qgis2/python/plugins/processing',
'/home/paolo/.qgis2/python/plugins/LecoS',
'/home/paolo/.qgis2/python/plugins/GeoCoding', '/usr/share/qgis/python',
u'/home/paolo/.qgis2/python', u'/home/paolo/.qgis2/python/plugins',
'/usr/share/qgis/python/plugins', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat',
'/usr/lib/python2.7/dist-packages/gst-0.10',
'/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
'/home/paolo/.qgis2/python/plugins/mmqgis/forms',
'/home/paolo/.qgis2/python/plugins/QuickMultiAttributeEdit/forms',
'/usr/share/qgis/python/plugins/fTools/tools',
'/home/paolo/.qgis2/python/plugins/DigitizingTools/tools']
--

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

2014-06-24 Thread Jorge Tornero - Listas

he scale-bar issue. I think, that one should always be
allowed to show a scale-bar, but that the units need to match with
the

one in the projection, so in the case of WGS84, the units should be
degrees.

Regards,
Matthias

On 24.06.2014 08:29, Richard Duivenvoorde wrote:

Hi Ted,

I'm not on Win, but if possible can you test this with latest
release

candidates, see

http://qgis.org/en/site/getinvolved/development/index.html#location-of-prereleases-nightly-builds

and if that one is crashing, please file an issue:

http://qgis.org/en/site/getinvolved/development/index.html#bugs-features-and-issues

Current dev version has a lot of changes under the hood, but also an
awfull lot of fixes!
So please test the latest version and let us know if that crashes
also

Regards,

Richard Duivenvoorde

On 24-06-14 01:30, Ted wrote:

forgot,

using Windows OS

Win 7 Professional x64

Thanks

Ted

On Tue, Jun 24, 2014 at 7:27 AM, Ted mailto:tiruchirapa...@gmail.com>> wrote:

Hi Developers

Encountered a very serious problem, looks like this issue is
there
in 2.x

Ways to reproduce;

1. Add a world boundary shp file in wgs84 (you can use other
files too)
http://thematicmapping.org/downloads/world_borders.php

2. Open the print composer, add a new map

3. add scale bar

4. close the composer, return back

5 remove the layer from layer list

6. boom, qgis crash

hope you can fix this soon, thanks

The scale bar issue

1. When a file is degree (wgs84), the scale-bar in print
composer is
useless since its trying to use the map unit.

2. Its logical that, in map composer its always linear map
unit as
in meter, feet, km, etc

3. using qgis in schools and this pose a serious issue, since
the
users dont understand projection etc.

4. the expected behavior is, immaterial of underlying
projection the
scale-bar should have the option to use linear map unit,
specially
meters, km, mile

5. read in stackexchange, this is a known issue. hope the dev
community can help to fix this one.

thanks a lot.

hurt my fingers, not able to type proper :(

cheers
ted

__ Information from ESET Mail Security, version of virus
signature database 9990 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com

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

__ Information from ESET Mail Security, version of virus
signature database 9990 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com

__ Information from ESET Mail Security, version of virus
signature database 9991 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com

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

Re: [Qgis-developer] Processing: module duplications

2014-06-24 Thread G. Allegri

The tagging system would be great, and in the future we can imagine a
system to let a user groups algorithms under its own groups (like favorites
links in the browser).

Vector and raster menus should at least point to the Processing tool
window, in case the algorithm is there too...

I still miss the semantics of the "normal" group. This word doesn't mean
anything to me as a grouping, but I see I'm the only one with this doubt :)

giovanni
Il 24/giu/2014 10:10 "Alex Mandel"  ha scritto:

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

Re: [Qgis-developer] Display a Photo stored in varbinary from MSSQL Server 2008R2

2014-06-24 Thread DewaldvS

DewaldvS wrote
> Good day.
> 
> I am new to QGis.
> Environment used: 
> 1. QGis 2.2.0
> 2. MS SQL Server 2008 R2
> 
> Scenario:
> I have a thumbnail stored in a varbinary(max) column, that the user needs
> to see.
> For example: When the user clicks on a water source, they would like to
> see the different images that are linked to that water source and the
> relative information that goes with that selected water source.
> 
> I can get the information to display, but for some reason even when
> changing the Edit widget (@Properties/Fields dialog) to Photo and
> assigning the height and width to the image box still no image is shown.
> 
> I know that the encoding of the varbinary(max) column is correct, because
> if I connect a different viewer to the table, the column is interpreted
> correctly.
> 
> Could you please assist me with this matter?
> 
> Thank you for your time

Any possible thoughts/solutions to my question?




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Display-a-Photo-stored-in-varbinary-from-MSSQL-Server-2008R2-tp5146477p5147510.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QMAP in core?

2014-06-24 Thread Vincent Picavet

Hi Paolo,
Nathan will provide more information, but QMap has been superseded by Intramap 
ROAM, and is no longer developped. I think that Nathan still does some 
bugfixing for some people still using QMAP, but all new work is being done on 
ROAM  :
http://nathanw.net/2014/03/10/intramaps-roam---a-qgis-data-collection-app/
https://github.com/DMS-Aus/Roam
Not sure it would be a good thing to integrate it into core, as it is a 
separated application, and aims at specific platforms (tablets mainly).
Vincent

Le mardi 24 juin 2014 10:43:59, Paolo Cavallini a écrit :
> Hi all.
> Any palns to add http://nathanw2.github.io/qmap/ to master? I think it
> would be good for our users to have it straight away, without downloading
> a different application. I'm available to give a hand, in case it would be
> useful.
> All the best.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QMAP in core?

2014-06-24 Thread Nathan Woodrow

Hey Paolo,

QMap is dead. I rebuilt it as http://dms-aus.github.io/Roam/

- Nathan


On Tue, Jun 24, 2014 at 6:43 PM, Paolo Cavallini 
wrote:

> Hi all.
> Any palns to add http://nathanw2.github.io/qmap/ to master? I think it
> would be good
> for our users to have it straight away, without downloading a different
> application.
> I'm available to give a hand, in case it would be useful.
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

r, return back

  5 remove the layer from layer list

  6. boom, qgis crash


  hope you can fix this soon, thanks


  The scale bar issue

  1. When a file is degree (wgs84), the scale-bar in print
composer is
  useless since its trying to use the map unit.

  2. Its logical that, in map composer its always linear map
unit as
  in meter, feet, km, etc

  3. using qgis in schools and this pose a serious issue, since
the
  users dont understand projection etc.

  4. the expected behavior is, immaterial of underlying
projection the
  scale-bar should have the option to use linear map unit,
specially
  meters, km, mile

  5. read in stackexchange, this is a known issue. hope the dev
  community can help to fix this one.


  thanks a lot.

  hurt my fingers, not able to type proper :(


  cheers
  ted




__ Information from ESET Mail Security, version of virus
signature database 9990 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com


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




__ Information from ESET Mail Security, version of virus signature 
database 9990 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature 
database 9991 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] Roam (was: QMAP in core?)

Il 24/06/2014 10:43, Paolo Cavallini ha scritto:
> Hi all.
> Any plans to add http://nathanw2.github.io/qmap/ to master? I think it would 
> be good
> for our users to have it straight away, without downloading a different 
> application.
> I'm available to give a hand, in case it would be useful.
> All the best.
> 
Sorry, I meant:
https://github.com/DMS-Aus/Roam
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Error in MetaSearch

Errore durante l'esecuzione di codice Python:


Hi all.
Adding the Italian CSW (http://www.rndt.gov.it/RNDT/CSW) to MetaSearch, and 
searching
for a common keyword, I get > 10 records. Only 5 are displayed, even if the 
dialog
reports "1-10 of 21 shown". If I click on the Next arrow, I get an error (see 
below).
Should I open a ticket?
All the best.
===
Traceback (most recent call last):
  File "/usr/share/qgis/python/plugins/MetaSearch/dialogs/maindialog.py", line 
644,
in navigate
startposition=self.startfrom, esn='full')
  File "/usr/share/qgis/python/owslib/csw.py", line 348, in getrecords2
self.results['matches'] = int(util.testXMLValue(val, True))
TypeError: int() argument must be a string or a number, not 'NoneType'


Versione Python:
2.7.7 (default, Jun  3 2014, 16:19:10)
[GCC 4.8.3]


Versione di QGIS:
2.3.0-Master Master, exported

Percorso Python: ['/home/paolo/.qgis2/python/plugins/processinglwgeomprovider',
'/home/paolo/.qgis2/python/plugins/sextante_animove',
'/home/paolo/.qgis2/python/plugins/processing',
'/home/paolo/.qgis2/python/plugins/LecoS',
'/home/paolo/.qgis2/python/plugins/GeoCoding', '/usr/share/qgis/python',
u'/home/paolo/.qgis2/python', u'/home/paolo/.qgis2/python/plugins',
'/usr/share/qgis/python/plugins', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat',
'/usr/lib/python2.7/dist-packages/gst-0.10',
'/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
'/home/paolo/.qgis2/python/plugins/mmqgis/forms',
'/home/paolo/.qgis2/python/plugins/QuickMultiAttributeEdit/forms',
'/usr/share/qgis/python/plugins/fTools/tools',
'/home/paolo/.qgis2/python/plugins/DigitizingTools/tools']
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QMAP in core?

Hi all.
Any palns to add http://nathanw2.github.io/qmap/ to master? I think it would be 
good
for our users to have it straight away, without downloading a different 
application.
I'm available to give a hand, in case it would be useful.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

m, looks like this issue is
>>>>> there
>>>>>  in 2.x
>>>>>
>>>>>  Ways to reproduce;
>>>>>
>>>>>  1. Add a world boundary shp file in wgs84 (you can use other
>>>>> files too)
>>>>>  http://thematicmapping.org/downloads/world_borders.php
>>>>>
>>>>>  2. Open the print composer, add a new map
>>>>>
>>>>>  3. add scale bar
>>>>>
>>>>>  4. close the composer, return back
>>>>>
>>>>>  5 remove the layer from layer list
>>>>>
>>>>>  6. boom, qgis crash
>>>>>
>>>>>
>>>>>  hope you can fix this soon, thanks
>>>>>
>>>>>
>>>>>  The scale bar issue
>>>>>
>>>>>  1. When a file is degree (wgs84), the scale-bar in print
>>>>> composer is
>>>>>  useless since its trying to use the map unit.
>>>>>
>>>>>  2. Its logical that, in map composer its always linear map
>>>>> unit as
>>>>>  in meter, feet, km, etc
>>>>>
>>>>>  3. using qgis in schools and this pose a serious issue, since
>>>>> the
>>>>>  users dont understand projection etc.
>>>>>
>>>>>  4. the expected behavior is, immaterial of underlying
>>>>> projection the
>>>>>  scale-bar should have the option to use linear map unit,
>>>>> specially
>>>>>  meters, km, mile
>>>>>
>>>>>  5. read in stackexchange, this is a known issue. hope the dev
>>>>>  community can help to fix this one.
>>>>>
>>>>>
>>>>>  thanks a lot.
>>>>>
>>>>>  hurt my fingers, not able to type proper :(
>>>>>
>>>>>
>>>>>  cheers
>>>>>  ted
>>>>>
>
>
> __ Information from ESET Mail Security, version of virus
> signature database 9990 (20140624) __
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
> ___
> 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] Processing: error in v.clean

Hi all.
I'm consistently getting an error running v.clean through Processing.
The error layer is not produced (in fact,
/tmp/processing/45d64e93dfee4b52a7229d3fdf2f84e9/ is empty).
The cleaned layer is loaded correctly on the canvas.
Any hint?
Thanks.
==
GRASS execution commands
g.proj -c proj4="+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0
+ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m 
+no_defs"
v.in.ogr min_area=0.0001 snap=-1
dsn="/home/paolo/Documents/Didattica/Corsi_Formazione_Faunalia/QGIS/QGIS_data"
layer=invalid output=tmp140359813035 --overwrite -o
g.region n=4911865.94038 s=4700983.4614 e=1723143.06065 w=1563640.73718 res=1
v.clean input=tmp140359813035 tool=break thresh="0.1"
output=output10f5fa9095d94a178fae347ad9f5825e
error=error10f5fa9095d94a178fae347ad9f5825e --overwrite
v.out.ogr -s -c -e -z input=output10f5fa9095d94a178fae347ad9f5825e
dsn="/tmp/processing/d6adef8f0e254de38ba9533dc158fdd4" format=ESRI_Shapefile
olayer=output type=auto
v.out.ogr -s -c -e -z input=error10f5fa9095d94a178fae347ad9f5825e
dsn="/tmp/processing/45d64e93dfee4b52a7229d3fdf2f84e9" format=ESRI_Shapefile
olayer=error type=auto
==
GRASS execution commands
g.proj -c proj4="+proj=utm +zone=30 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0
+units=m +no_defs"
v.in.ogr min_area=0.0001 snap=-1
dsn="/home/paolo/.qgis2/python/plugins/processing/tests/data" layer=points
output=tmp1403598159246 --overwrite -o
g.region n=4458983.8488 s=4458921.97814 e=270855.745301 w=270778.60198 res=1
v.voronoi input=tmp1403598159246 output=output158c9061c39d49e0ac1e146f19de1907
--overwrite
v.out.ogr -s -c -e -z input=output158c9061c39d49e0ac1e146f19de1907
dsn="/tmp/processing/a3fa565b9ca74325b2f049f382e78368" format=ESRI_Shapefile
olayer=output type=auto
==
Oooops! The following output layers could not be open
Errors layer: /tmp/processing/45d64e93dfee4b52a7229d3fdf2f84e9/error.shp
The above files could not be opened, which probably indicates that they were not
correctly produced by the executed algorithm
Checking the log information might help you see why those layers were not 
created as
expected
This algorithm requires GRASS to be run. A test to check if GRASS is correctly
installed and configured in your system has been performed, with the following 
result:
GRASS seems to be correctly installed and configured
==
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

Hi,

IMHO a scale bar in degrees doesn't make sense at all apart from being
unused to readers of the map. Because one degree in latitude is always
(uhmm if I recall correctly) 110 km, in longitude this is only true for
the equator, the closer you get to the poles the less km per degree in
longitude (until 0 at the pole itself). If you display only a small part
of the earth you migth manage with two scale bars (lon/lat) but how
would you imagine a scale bar for e.g. north America?

Bernhard

Am 24.06.2014 10:07, schrieb Jorge Tornero - Listas:

Hi, Ted, Matthias and all,

If you enable CRS transform on-the-fly, meter/feet/NM scales can be
shown in WGS84 projects.

About what Matthias said in

Concerning the scale-bar issue. I think, that one should always be
allowed to show a scale-bar, but that the units need to match with the
one in the projection, so in the case of WGS84, the units should be
degrees.

In my opinion, despite this is completely true from a formal point of
view, sometimes you need scales in 'real world' units just to make
possible for people to understand your maps. For the most of the people
I know that see my little work it makes no sense a scale in degrees (in
fact, they could have it in the grid labels) but a scale in nautical
miles (or whatever) makes sense inmediatly for them, even if it is not
accurate. So, providing that the person who is making the map should
know what he/she is doing, it is nice for the user to have the
possibility to show the scale in whatever units he wants. Maybe it could
be corrected just using a projection (I guess that's the proper way),
but sometimes it leads to "weird" (in the sense of people is used to see
*their geography* in a determinate way) maps which somehow annoy people.

All the best,

Jorge Tornero

El 24/06/14 08:59, Matthias Kuhn escribió:

Hi Ted,

I don't get a crash here (Linux/latest prerelease). It would be much
appreciated if you could follow Richards advice for testing/reporting.

Regards,
Matthias

On 24.06.2014 08:29, Richard Duivenvoorde wrote:

Hi Ted,

I'm not on Win, but if possible can you test this with latest release
candidates, see

http://qgis.org/en/site/getinvolved/development/index.html#location-of-prereleases-nightly-builds

and if that one is crashing, please file an issue:

http://qgis.org/en/site/getinvolved/development/index.html#bugs-features-and-issues

Current dev version has a lot of changes under the hood, but also an
awfull lot of fixes!
So please test the latest version and let us know if that crashes also

Regards,

Richard Duivenvoorde

On 24-06-14 01:30, Ted wrote:

forgot,

using Windows OS

Win 7 Professional x64

Thanks

Ted

On Tue, Jun 24, 2014 at 7:27 AM, Ted mailto:tiruchirapa...@gmail.com>> wrote:

Hi Developers

Encountered a very serious problem, looks like this issue is there
in 2.x

Ways to reproduce;

1. Add a world boundary shp file in wgs84 (you can use other
files too)
http://thematicmapping.org/downloads/world_borders.php

2. Open the print composer, add a new map

3. add scale bar

4. close the composer, return back

5 remove the layer from layer list

6. boom, qgis crash

hope you can fix this soon, thanks

The scale bar issue

1. When a file is degree (wgs84), the scale-bar in print
composer is
useless since its trying to use the map unit.

2. Its logical that, in map composer its always linear map unit as
in meter, feet, km, etc

3. using qgis in schools and this pose a serious issue, since the
users dont understand projection etc.

4. the expected behavior is, immaterial of underlying
projection the
scale-bar should have the option to use linear map unit, specially
meters, km, mile

5. read in stackexchange, this is a known issue. hope the dev
community can help to fix this one.

thanks a lot.

hurt my fingers, not able to type proper :(

cheers
ted

__ Information from ESET Mail Security, version of virus signature
database 9990 (20140624) __

The message was checked by ESET Mail Security.
http://www.eset.com

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

Re: [Qgis-developer] Processing: module duplications

2014-06-24 Thread Alex Mandel

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

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

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

Thanks,
Alex

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

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

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x

2014-06-24 Thread Jorge Tornero - Listas

Hi, Ted, Matthias and all,

If you enable CRS transform on-the-fly, meter/feet/NM scales can be
shown in WGS84 projects.

About what Matthias said in

All the best,

Jorge Tornero

El 24/06/14 08:59, Matthias Kuhn escribió:

Hi Ted,

I don't get a crash here (Linux/latest prerelease). It would be much
appreciated if you could follow Richards advice for testing/reporting.

Regards,
Matthias

On 24.06.2014 08:29, Richard Duivenvoorde wrote:

Hi Ted,

I'm not on Win, but if possible can you test this with latest release
candidates, see

http://qgis.org/en/site/getinvolved/development/index.html#location-of-prereleases-nightly-builds

and if that one is crashing, please file an issue:

http://qgis.org/en/site/getinvolved/development/index.html#bugs-features-and-issues

Current dev version has a lot of changes under the hood, but also an
awfull lot of fixes!
So please test the latest version and let us know if that crashes also

Regards,

Richard Duivenvoorde

On 24-06-14 01:30, Ted wrote:

forgot,

using Windows OS

Win 7 Professional x64

Thanks

Ted

On Tue, Jun 24, 2014 at 7:27 AM, Ted mailto:tiruchirapa...@gmail.com>> wrote:

Hi Developers

Encountered a very serious problem, looks like this issue is there
in 2.x

Ways to reproduce;

1. Add a world boundary shp file in wgs84 (you can use other files too)
http://thematicmapping.org/downloads/world_borders.php

2. Open the print composer, add a new map

3. add scale bar

4. close the composer, return back

5 remove the layer from layer list

6. boom, qgis crash

hope you can fix this soon, thanks

The scale bar issue

1. When a file is degree (wgs84), the scale-bar in print composer is
useless since its trying to use the map unit.

2. Its logical that, in map composer its always linear map unit as
in meter, feet, km, etc

3. using qgis in schools and this pose a serious issue, since the
users dont understand projection etc.

4. the expected behavior is, immaterial of underlying projection the
scale-bar should have the option to use linear map unit, specially
meters, km, mile

5. read in stackexchange, this is a known issue. hope the dev
community can help to fix this one.

thanks a lot.

hurt my fingers, not able to type proper :(

cheers
ted

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

Re: [Qgis-developer] Processing: module duplications

Il 23/06/2014 19:28, Alexander Bruy ha scritto:
> some time ago not all FTools modules were available via Processing, but we add
> at least part of missed modules to it (e.g. Random Points algs were added 
> about
> month ago with Faunalia support). Unfortunately if I'm not wrong
> several algorithms
> still missed (for example Vector Grid).

Hi all.
Could someone draw a list of missing modules? This would help deciding further 
steps.
Thanks.

-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: module duplications

2014-06-24 Thread Alexander Bruy

2014-06-24 10:18 GMT+03:00 Paolo Cavallini :
>> This raise the question of unit tests, and maybe of a vote/rating system. Do
>> we have that for processing modules?
>
> Not (yet); IMHO Processing modules and models should mimic much of the 
> structure of
> plugins, perhaps sharing some of the same interface.
> All the best.

Processing has simple test subsystem and every user can contribute tests to it.
Just run desired algorithm using test data (can be found in
processing/tests/data
or loaded via "Load test data" algorithm. If some data not exists —
add them, but
try to keep it as small and generic as possible), then open History
and Log dialog,
select command and from context menu choose "Create test".

Unfortunatelly, this test subsystem does not intergrated into QGIS
tests, so tests did
not run at QGIS build time


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

Re: [Qgis-developer] Processing: module duplications

Il 23/06/2014 19:40, Larry Shaffer ha scritto:

> +1  However, I think the menu items should stay for at least one release. The
> FTools/GDALTools plugins can be dropped and the associated menu items in each 
> menu
> can instead interface with Processing, triggering a call to the appropriate
> algorithm's GUI.
> 
> In addition, there could be a non-blocking QgsMessageBar that quickly 
> notifies the
> user that some items in the menus will be going away, and to start using 
> Processing more.
> 
> Forcing everyone to immediately switch (by removing those menu items) may be 
> a bit
> harsh. (I can just see all the issue tickets about missing menus.) Also, 
> gives time
> for the docs to catch up with the change, before the menu items are removed.

+1; very sensible approach IMHO. I especially like the idea of leaving the 
current
menu that will trigger the corresponding Processing module.

Please note however that GDALTools have a high end feature not currently 
available in
Processing: it produces the actual GDAL command, that can be edited by hand, 
copied
to a shell, and reused in a bas script. We do have in Processing a similar 
function
through Python scripting, but it is more complex to understand and use.

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: module duplications

2014-06-24 Thread G. Allegri

Paolo, I'm not sure I fully understand the proposal. Do you mean to show
the "basic", "normal" and "advanced" groups in the GUI?
I'm not sure it's something a user will understand easily. What is a
"normal" algorithm? I understand your meaning, but I fear it's not
stragthforward, and it doesn't seeme to be the first criteria a user would
look for. Probably I misudnerstood you...

giovanni


2014-06-24 9:15 GMT+02:00 Paolo Cavallini :

> Il 23/06/2014 19:18, Victor Olaya ha scritto:
> > Paolo, that sounds good to me
> >
> > The basic and experimental modules that you propose are the current
> simplified and
> > advanced modes. We should work on a normal mode.
> >
> > Let's discuss it here and maybe create a spreadsheet that we can edit to
> select the
> > list of modules to include
>
> maybe we could add tags to modules, much easier to maintain than a
> separate spreadsheet?
> first of all, however, I think we should agree on criteria for the
> inclusion in each
> category; IMHO normal should be:
> * well tested (ideally, modules without a test should not be included
> here, so we can
> always guarantee normal modules are working properly)
> * non duplicated (never have two modules doing exactly the same thing;
> choose the
> faster and more reliable
> * with a reasonable set of options, avoiding esoteric stuff (this may be
> the most
> difficult choice).
> Anything more?
> All the best, and thanks for picking this up.
> --
> Paolo Cavallini - www.faunalia.eu
> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Giovanni Allegri
http://about.me/giovanniallegri
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: module duplications

Il 23/06/2014 20:31, Régis Haubourg ha scritto:

> experimentals. I loose lots of time each time testing every module before
> finding the good one. Today, I struggled with spline surface interpolation,
> some grass 6 modules do run out of memory after 3 hours computing, some saga
> modules run with error, but data is quickly generated, some others run fast
> and right. 

Exactly, that's what I encounter, and what should be avoided as hell.

> This raise the question of unit tests, and maybe of a vote/rating system. Do
> we have that for processing modules?

Not (yet); IMHO Processing modules and models should mimic much of the 
structure of
plugins, perhaps sharing some of the same interface.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: module duplications

Il 23/06/2014 19:18, Victor Olaya ha scritto:
> Paolo, that sounds good to me
> 
> The basic and experimental modules that you propose are the current 
> simplified and
> advanced modes. We should work on a normal mode.
> 
> Let's discuss it here and maybe create a spreadsheet that we can edit to 
> select the
> list of modules to include

maybe we could add tags to modules, much easier to maintain than a separate 
spreadsheet?
first of all, however, I think we should agree on criteria for the inclusion in 
each
category; IMHO normal should be:
* well tested (ideally, modules without a test should not be included here, so 
we can
always guarantee normal modules are working properly)
* non duplicated (never have two modules doing exactly the same thing; choose 
the
faster and more reliable
* with a reasonable set of options, avoiding esoteric stuff (this may be the 
most
difficult choice).
Anything more?
All the best, and thanks for picking this up.
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Processing: module duplications

Il 23/06/2014 19:36, Alexander Bruy ha scritto:
> Maybe tagging support will help with this, as same algorithm
> may be useful in different  domains

exactly; I have opened a ticket for this:
http://hub.qgis.org/issues/5377
in fact, we could use tags more extensively, so one user could select all 
modules
that are, for instance, both stable and forestry-related.

all the best.
-- 
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Crash - Serious problem in 2x