Re: [Qgis-developer] Vector Layer Generalization

[Tyler Mitchell]

Good description of  a reasonable approach Brent!  At one point, for a certain 
dataset, I was able to calculate a pretty reliable (e.g. still made valid 
features)  ratio of simplification threshold based on map scale.  I don't have 
the data anymore, but it was almost like an LOD level of detail approach.  

With that in mind, I'd like to see what one could do with LOD approach in 
OpenGL with map data - probably blows away our best little hacks ;-)  Never got 
to that yet :)

On 2012-05-25, at 4:26 PM, pcr...@pcreso.com wrote:

> My 02c...
> 
> If you have a table with a geometry column, you can add a second geometry 
> column for the simplified ones. As in the script below, for a national 
> coastline with about 10,000 polygons
> 
> You can generate the simplified ones using a series of update SQL statements, 
> based on a variety of criteria, including neighbouring (or not) via a 
> ST_Distance() in the where clause.
> 
> If you hand craft the update SQL's, you can just copy rather than simplify 
> smaller polygons (ST_Area in the where clause), etc.
> 
> A slowish way, but viable for a 1-off is to have a where clause with an 
> ST_IsValid in the where clause testing the result of the simplification. If 
> the where clause includes a test for the target geometry being not-null, the 
> series can apply a large simplification initially, then progressively apply a 
> decreasing simplifcation buffer to features that failed previous iterations, 
> until the last statement copies any remaining features with zero 
> simplification.
> 
> I prefer a script with a set of SQL's rather than a function, as it is easier 
> to tweak case requirements. 
> 
> The advantage of this approach over the preserving topology simplify function 
> is the degree of control the hand crafted SQL's provide over exactly how to 
> simplify the dataset.
> 
> But, as always, your mileage may vary :-)
> 
>   Cheers,
> 
>   Brent Wood
> 
> 
> #! /bin/bash
> #
> # script to simplify NZ coastline for zoom layer
> 
> DB=nzcoast
> TAB=nz_all
> 
> 
> # add new geometry column
> psql -d $DB -c "alter table nz_all drop column simple_geom;"
> 
> psql -d $DB -c "alter table nz_all add column simple_geom 
> geometry(multipolygon,4326);"
> 
> 
> # populate
> # do small islands with no simplification
> psql -d $DB -qc "update nz_all
> set simple_geom=geom 
> where ST_Area(geom) < 0.01;"
> psql -d $DB -qc "update nz_all
> set simple_geom=ST_Simplify(geom, 0.001) 
> where simple_geom isnull
>   and ST_IsValid(ST_Simplify(geom, 0.001));"
> psql -d $DB -qc "update nz_all
> set simple_geom=ST_Simplify(geom, 0.0001) 
> where simple_geom isnull
>   and ST_IsValid(ST_Simplify(geom, 0.0001));"
> psql -d $DB -qc "update nz_all
> set simple_geom=ST_Simplify(geom, 0.1) 
> where simple_geom isnull
>   and ST_IsValid(ST_Simplify(geom, 0.1));"
> psql -d $DB -qc "update nz_all
> set simple_geom=geom 
> where simple_geom isnull;"
> 
> 
> 
> 
> --- On Sat, 5/26/12, Carson Farmer  wrote:
> 
> From: Carson Farmer 
> Subject: Re: [Qgis-developer] Vector Layer Generalization
> To: "Evgeniy Pashentsev" 
> Cc: qgis-developer@lists.osgeo.org
> Date: Saturday, May 26, 2012, 10:11 AM
> 
> Excellent! Topology preserving simplification is something I've been
> looking for!
> > But I want to ask your advice on one thing. Is it normal for user
> > to simplify all the features on a layer at once? I'm just not sure
> > which way is more suitable for a regular user:
> > - simplify all the features at once as it is now in my current prototype;
> > - simplify selected feature and all the corresponding vertexes of
> > the neighboring features;
> > - or simplify only selected features;
> > - or even something else.
> > Although it is not very important for current work, I want to make sure
> > I don't implement useless functionality.
> Personally, I normally simplify an entire layer at once... for mapping
> purposes, or simply to reduce drawing time or for computational/space
> efficiency. It might be nice to also have the option to simplify
> selected features only, but if this was an option, then I would expect
> *only* those selected features to be simplified... and *not* their
> neighbouring features...
> 
> That's my two cents anyway, looking forward to trying it out!
> 
> Carson
> 
> 
> -- 
> Dr. Carson J. Q. Farmer
> Centre for GeoInformatics (CGI)
> School of Geography and Geosciences
> Irvine Building, University of St Andrews
> St Andrews, Fife, KY16 9AL
> Scotland, UK
> ___
> 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
> htt

[Qgis-developer] QGIS for mobile devices - First report

[Ramón Carrillo]

Hi all,

What did I do this week?
- Setup all the environment required to work.
- Build successfully from the android branch of QGIS.
- Build an apk and test it on a Android smartphone.
- Get better understanding of the build bash scripts that Marco made.
- Get dive into the core source code of QGIS.

What will I be working on next week?
- Get familiar with the code of QGIS related to Android.
- Try QML on Android and compare it with QWidgets.
- Create a blog for weekly reports.

Did I meet with any stumbling blocks?
- Some broken dependencies of Necessitas QtCreator.
- A missing library in the apk.

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

[Qgis-developer] Changes to python/utils.py

[Larry Shaffer]

I have two proposed changes to python/utils.py [0] (and
src/python/qgspythonutilsimpl.cpp). I think I am capable of making the
Python code changes to utils.py, but would like someone to offer to
review my work, or work with me on the changes. Since python/utils.py
is an integral part of Python support in QGIS, I don't want to screw
anything up. :)

1) Python exceptions - add lightweight debug output

Currently sys.excepthook is substituted with the qgis_excepthook
(showException() method). I propose extending showException() to
include lightweight debug info provided by additional inquiries into
the traceback object(s). A similar solution is here [1].

Output from [1]'s very simple example looks like:

# normal traceback info
Traceback (most recent call last):
  File "debug_light.py", line 72, in 
    pad4(data)
  File "debug_light.py", line 55, in pad4
    return_value.append("0" * (4 - len(thing)) + thing)
TypeError: object of type 'int' has no len()

# extended info on module and function/method (i.e. frame) variables
Locals by frame, innermost last

Frame  in debug_light.py at line 74
        __builtins__ =  
        __file__ =  debug_light.py
       traceback =  
     __package__ =  None
     sys =  
        pad4 =  
        __name__ =  __main__
        data =  ['1', '2', 3, '4']
     __doc__ =  None
      print_exc_plus =  

Frame pad4 in debug_light_2.py at line 55
       thing =  3
        return_value =  ['0001', '0002']
     seq =  ['1', '2', 3, '4']

This provides users and developers with pertinent info on
exception-state attribute and variable values, in addition to the
traceback. This additional output could be directed to a second tab,
in a new exceptions dialog, labeled 'Frames' or 'Variables'.

[0] https://github.com/qgis/Quantum-GIS/blob/master/python/utils.py
[1] http://code.activestate.com/recipes/52215/


2) Module import - add deeper module tracking/reloading

There has recently been work on a module [2][3] that recursively
tracks and reloads dependent module imports in a way that I think is a
little more robust and flexible than the current method in
python/utils.py. I have incorporated a custom version of reloader.py
in my Plugin Editor, with good success, for live editing/reloading of
Python test scripts within a running QGIS instance. Plugin Installer,
Manager, Plugin Reloader, and Plugin Editor are the only plugins (I
know of) that utilize the reloading aspect of python/utils.py. I'm
guessing that Plugin Reloader is used extensively in development.

This correct-dependency-order recursive reload not only might allow
plugins to be fully reloaded live, even with in-module sys.path
adjustments, but also *retain* selected module states (see [2]
__reload__() description). This might mean a LOT less QGIS relaunches
during plugin development.

[2] http://www.indelible.org/ink/python-reloading/
[3] https://github.com/jparise/python-reloader ,
https://github.com/jparise/python-reloader/blob/master/reloader.py


Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Vector Layer Generalization

[pcreso]

My 02c...

If you have a table with a geometry column, you can add a second geometry 
column for the simplified ones. As in the script below, for a national 
coastline with about 10,000 polygons

You can generate the simplified ones using a series of update SQL statements, 
based on a variety of criteria, including neighbouring (or not) via a 
ST_Distance() in the where clause.

If you hand craft the update SQL's, you can just copy rather than simplify 
smaller polygons (ST_Area in the where clause), etc.

A slowish way, but viable for a 1-off is to have a where clause with an 
ST_IsValid in the where clause testing the result of the simplification. If the 
where clause includes a test for the target geometry being not-null, the series 
can apply a large simplification initially, then progressively apply a 
decreasing simplifcation buffer to features that failed previous iterations, 
until the last statement copies any remaining features with zero simplification.

I prefer a script with a set of SQL's rather than a function, as it is easier 
to tweak case requirements. 

The advantage of this approach over the preserving topology simplify function 
is the degree of control the hand crafted SQL's provide over exactly how to 
simplify the dataset.

But, as always, your mileage may vary :-)

  Cheers,

  Brent Wood


#! /bin/bash
#
# script to simplify NZ coastline for zoom layer

DB=nzcoast
TAB=nz_all


# add new geometry column
psql -d $DB -c "alter table nz_all drop column simple_geom;"

psql -d $DB -c "alter table nz_all add column simple_geom 
geometry(multipolygon,4326);"


# populate
# do small islands with no simplification
psql -d $DB -qc "update nz_all
    set simple_geom=geom 
    where ST_Area(geom) < 0.01;"
psql -d $DB -qc "update nz_all
    set simple_geom=ST_Simplify(geom, 0.001) 
    where simple_geom isnull
  and ST_IsValid(ST_Simplify(geom, 0.001));"
psql -d $DB -qc "update nz_all
    set simple_geom=ST_Simplify(geom, 0.0001) 
    where simple_geom isnull
  and ST_IsValid(ST_Simplify(geom, 0.0001));"
psql -d $DB -qc "update nz_all
    set simple_geom=ST_Simplify(geom, 0.1) 
    where simple_geom isnull
  and ST_IsValid(ST_Simplify(geom, 0.1));"
psql -d $DB -qc "update nz_all
    set simple_geom=geom 
    where simple_geom isnull;"




--- On Sat, 5/26/12, Carson Farmer  wrote:

From: Carson Farmer 
Subject: Re: [Qgis-developer] Vector Layer Generalization
To: "Evgeniy Pashentsev" 
Cc: qgis-developer@lists.osgeo.org
Date: Saturday, May 26, 2012, 10:11 AM

Excellent! Topology preserving simplification is something I've been
looking for!
> But I want to ask your advice on one thing. Is it normal for user
> to simplify all the features on a layer at once? I'm just not sure
> which way is more suitable for a regular user:
> - simplify all the features at once as it is now in my current prototype;
> - simplify selected feature and all the corresponding vertexes of
> the neighboring features;
> - or simplify only selected features;
> - or even something else.
> Although it is not very important for current work, I want to make sure
> I don't implement useless functionality.
Personally, I normally simplify an entire layer at once... for mapping
purposes, or simply to reduce drawing time or for computational/space
efficiency. It might be nice to also have the option to simplify
selected features only, but if this was an option, then I would expect
*only* those selected features to be simplified... and *not* their
neighbouring features...

That's my two cents anyway, looking forward to trying it out!

Carson


-- 
Dr. Carson J. Q. Farmer
Centre for GeoInformatics (CGI)
School of Geography and Geosciences
Irvine Building, University of St Andrews
St Andrews, Fife, KY16 9AL
Scotland, UK
___
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] Vector Layer Generalization

[Carson Farmer]

Excellent! Topology preserving simplification is something I've been
looking for!
> But I want to ask your advice on one thing. Is it normal for user
> to simplify all the features on a layer at once? I'm just not sure
> which way is more suitable for a regular user:
> - simplify all the features at once as it is now in my current prototype;
> - simplify selected feature and all the corresponding vertexes of
> the neighboring features;
> - or simplify only selected features;
> - or even something else.
> Although it is not very important for current work, I want to make sure
> I don't implement useless functionality.
Personally, I normally simplify an entire layer at once... for mapping
purposes, or simply to reduce drawing time or for computational/space
efficiency. It might be nice to also have the option to simplify
selected features only, but if this was an option, then I would expect
*only* those selected features to be simplified... and *not* their
neighbouring features...

That's my two cents anyway, looking forward to trying it out!

Carson


-- 
Dr. Carson J. Q. Farmer
Centre for GeoInformatics (CGI)
School of Geography and Geosciences
Irvine Building, University of St Andrews
St Andrews, Fife, KY16 9AL
Scotland, UK
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Vector Layer Generalization

[Evgeniy Pashentsev]

Hello!

I've done some work to understand QGIS tools development.
Also some topology preserving simplification code has been
written. When i get it to work, I'll make a branch and post a link
to it. Hopefully, I will manage to do this by the end of this weekend.
If you want to see my reports you can visit [0] for some general
info and [1] for more detailed weekly reports.

But I want to ask your advice on one thing. Is it normal for user
to simplify all the features on a layer at once? I'm just not sure
which way is more suitable for a regular user:
- simplify all the features at once as it is now in my current prototype;
- simplify selected feature and all the corresponding vertexes of
the neighboring features;
- or simplify only selected features;
- or even something else.
Although it is not very important for current work, I want to make sure
I don't implement useless functionality.

Thank you.

[0]:
http://hub.qgis.org/wiki/quantum-gis/GSOC_2012_Vector_Layer_Generalization
[1]:
http://blogs.gis-lab.info/ugnpaul/2012/05/25/gsoc-2012-weekly-report-number-one/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: Re: Starting GSoC

[cpolymeris]

El , Victor Olaya  escribió:

Sounds great to me.





I have given you write access to the SEXTANTE SVN (as I told you, this



might change to another location if it finally gets integrated into



QGIS, but for now it will remain there, at least until the end of



GSoC). Feel free to add your changes there so we can all start testing



them. It affects just a single element of SEXTANTE (though a key



one!), so there is no risk of breaking anything else. Also, SEXTANTE



is still an experimental and unstable plugin, so I see no reason why



you should keep your code in a different place.



Uhm. I am still a bit afraid of breaking stuff, I must admit. I'll post  
patches attached to blog posts till this is more mature, ie doesn't  
randomly crash taking QGIS down. I hope we can switch to git soon, and keep  
a separate branch for mt-related code. Or maybe I should figure out how  
distributed svn works (never used it that way).




Regarding the progress elements, they are very simple now and in fact



only the main parameters dialog acts as a progress display. We can



maybe leave them like that (passing the progress object to the



algorithm) in a first step, and then implement some sort of signaling



mechanism



Yes, I that is the approach I have taken for now. Eventually there could be  
a mechanism for the algorithms to fire the signals themselves. It might  
also be a good thing if they react to cancel signals. Currently, canceled  
algorithms just keep running and their output is ignored.


BTW, QtConcurrent was mentioned in the other thread as nice, functional,  
high level api for threading. It has the advantage of keeping a thread pool  
around and reusing them, and, I believe, the QGIS core uses it. Only  
problem is, there seem to be no bindings for python, because of some sort  
of incompatibility with the interpreter I don't understand.


Regards,

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

[Qgis-developer] Re: Starting GSoC

[Alexander Bruy]

2012/5/25 Paolo Cavallini :
> Il 25/05/2012 17:23, Victor Olaya ha scritto:
>> Sounds great to me.
>>
>> I have given you write access to the SEXTANTE SVN (as I told you, this
>> might change to another location if it finally gets integrated into
>> QGIS, but for now it will remain there, at least until the end of
>> GSoC).
> I think we can add sextante to qgis-master as soon as 1.8 is released,
> and the feature freeze is over.
Another way is to create branch in QGIS repo and keep work in it. After
releasing 1.8 this branch can be merged into master

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

Re: [Qgis-developer] Discussion on browser and file extensions

[Etienne Tourigny]

On Fri, May 25, 2012 at 12:41 PM, Giuseppe Sucameli
 wrote:
> Hi Etienne,
>
> On Fri, May 25, 2012 at 5:08 PM, Etienne Tourigny
>  wrote:
>>> BTW we need another method, right? Something like
>>> QgsLayerItem::layerName()
>>
>> This is the approach in my patches, only it is also supported in
>> QgsDataItem (see below why).
>
> IMHO it isn't.
>
> In your patch the fileName method is used to get the name
> displayed in the browser (see QgsBrowserModel::data() line 153),
>
> instead in my proposal the QgsLayerItem::layerName() would be used to get
> the name of the layer to load (not the filename).
>
> You should keep the QgsDataItem::name() for filename (data shown
> in the browser) and add a new method for QgsLayerItem::layerName().

ah ok, so name() would return the filename, whereas layerName() would
return the filename without extension, to be used in the drag&drop
operations. Sounds reasonable.
Would need to modify mime data stuff also, in QgsMimeDataUtils::Uri

what about file-based datacollection items? I guess only the layers
can get dropped to other targets, therefore no need to change
anything?

>
> BTW, I'm wondering if Radim meant the same.
>
>> Also, this could use uri() like you suggested instead of path(), not
>> sure I understand the distinction
>
> URI is the string used to load a layer, path is a way to identify a
> qgsdataitem in the browser tree.

ah ok, thanks

>
> Cheers.
>
>> QString QgsDataItem::fileName() const
>> {
>>  QFileInfo fileInfo( path() );
>>  return fileInfo.isFile() ? fileInfo.fileName() : name();
>> }
>>
>> Again, this works in the default case, but the function should be
>> overloaded for efficiency in the case of gdal ang ogr /vsizip files
>> (like I did in my patches)
>>
>> Regards,
>> Etienne
>>
>>>
 QgsDataItem is base for various data sources, most of them are not
 file based.
>>>
>>> I agree, having a fileName() method in the QgsDataItem class
>>> is non-sense.
>>
>> Well unless mistaken, you could have a QgsDataCollectionItem which is
>> file-based, such as multi-layer shape or qml?
>>
>>>
>>> Cheers.
>>>
>>> --
>>> Giuseppe Sucameli - Faunalia
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Giuseppe Sucameli
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Discussion on browser and file extensions

[Giuseppe Sucameli]

Hi Etienne,

On Fri, May 25, 2012 at 5:08 PM, Etienne Tourigny
 wrote:
>> BTW we need another method, right? Something like
>> QgsLayerItem::layerName()
>
> This is the approach in my patches, only it is also supported in
> QgsDataItem (see below why).

IMHO it isn't.

In your patch the fileName method is used to get the name
displayed in the browser (see QgsBrowserModel::data() line 153),

instead in my proposal the QgsLayerItem::layerName() would be used to get
the name of the layer to load (not the filename).

You should keep the QgsDataItem::name() for filename (data shown
in the browser) and add a new method for QgsLayerItem::layerName().

BTW, I'm wondering if Radim meant the same.

> Also, this could use uri() like you suggested instead of path(), not
> sure I understand the distinction

URI is the string used to load a layer, path is a way to identify a
qgsdataitem in the browser tree.

Cheers.

> QString QgsDataItem::fileName() const
> {
>  QFileInfo fileInfo( path() );
>  return fileInfo.isFile() ? fileInfo.fileName() : name();
> }
>
> Again, this works in the default case, but the function should be
> overloaded for efficiency in the case of gdal ang ogr /vsizip files
> (like I did in my patches)
>
> Regards,
> Etienne
>
>>
>>> QgsDataItem is base for various data sources, most of them are not
>>> file based.
>>
>> I agree, having a fileName() method in the QgsDataItem class
>> is non-sense.
>
> Well unless mistaken, you could have a QgsDataCollectionItem which is
> file-based, such as multi-layer shape or qml?
>
>>
>> Cheers.
>>
>> --
>> Giuseppe Sucameli - Faunalia
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



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

[Qgis-developer] Re: Starting GSoC

[Paolo Cavallini]

Il 25/05/2012 17:23, Victor Olaya ha scritto:
> Sounds great to me.
>
> I have given you write access to the SEXTANTE SVN (as I told you, this
> might change to another location if it finally gets integrated into
> QGIS, but for now it will remain there, at least until the end of
> GSoC). 
I think we can add sextante to qgis-master as soon as 1.8 is released,
and the feature freeze is over.
> Feel free to add your changes there so we can all start testing
> them. It affects just a single element of SEXTANTE (though a key
> one!), so there is no risk of breaking anything else. Also, SEXTANTE
> is still an experimental and unstable plugin, so I see no reason why
> you should keep your code in a different place.
+1, much easier for us to test.
All the best, and thanks.

-- 
Paolo Cavallini
See: http://www.faunalia.it/pc

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

[Qgis-developer] Re: Starting GSoC

[Victor Olaya]

Sounds great to me.

I have given you write access to the SEXTANTE SVN (as I told you, this
might change to another location if it finally gets integrated into
QGIS, but for now it will remain there, at least until the end of
GSoC). Feel free to add your changes there so we can all start testing
them. It affects just a single element of SEXTANTE (though a key
one!), so there is no risk of breaking anything else. Also, SEXTANTE
is still an experimental and unstable plugin, so I see no reason why
you should keep your code in a different place.

Regarding the progress elements, they are very simple now and in fact
only the main parameters dialog acts as a progress display. We can
maybe leave them like that (passing the progress object to the
algorithm) in a first step, and then implement some sort of signaling
mechanism

Great work so far :-)

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

Re: [Qgis-developer] Discussion on browser and file extensions

[Etienne Tourigny]

On Fri, May 25, 2012 at 11:55 AM, Giuseppe Sucameli
 wrote:
> Hi Radim,
>
> On Wed, May 23, 2012 at 6:45 PM, Radim Blazek  wrote:
>>> and adding a QgsDataItem::fileName() member which the browser would
>>> use for layer items. It very simple to fix now.
>>
>> It should be possible to get the file name from QgsDataItem::uri().
>
> if the layer is file-based get the name from the uri, otherwise get
> it from name(). Is that what you meant?
>
> BTW we need another method, right? Something like
> QgsLayerItem::layerName()

This is the approach in my patches, only it is also supported in
QgsDataItem (see below why).

Also, this could use uri() like you suggested instead of path(), not
sure I understand the distinction

QString QgsDataItem::fileName() const
{
  QFileInfo fileInfo( path() );
  return fileInfo.isFile() ? fileInfo.fileName() : name();
}

Again, this works in the default case, but the function should be
overloaded for efficiency in the case of gdal ang ogr /vsizip files
(like I did in my patches)

Regards,
Etienne

>
>> QgsDataItem is base for various data sources, most of them are not
>> file based.
>
> I agree, having a fileName() method in the QgsDataItem class
> is non-sense.

Well unless mistaken, you could have a QgsDataCollectionItem which is
file-based, such as multi-layer shape or qml?

>
> Cheers.
>
> --
> Giuseppe Sucameli - Faunalia
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Discussion on browser and file extensions

[Etienne Tourigny]

On Wed, May 23, 2012 at 1:45 PM, Radim Blazek  wrote:
> On Wed, May 23, 2012 at 1:35 PM, Etienne Tourigny
>  wrote:
>> This can be solved in code by removing the extension in the
>> QgsDataItem name() member, this way it does not have to be stripped in
>> drop operations,
>> and adding a QgsDataItem::fileName() member which the browser would
>> use for layer items. It very simple to fix now.
>
> It should be possible to get the file name from QgsDataItem::uri().
> QgsDataItem is base for various data sources, most of them are not
> file based.

I understand your point.

Getting the filename from QgsDataItem::uri() has some issues with .zip
files (because of the special /vsizip/file.zip/file_in_zip.ext
syntax).  It is possible to strip the first part and get just the
filename.

Unfortunately, it seems that QgsBrowserModel::data() gets called
*very* often, even though the contents of the browser have not changed
-  when hiding or showing the window, or scrolling the browser for
example.

This can be taxing if there are many files and the filename stripping
logic has to be done on all visible files many many times.

So the 2 solutions I see are
1) have a new member fileName() that returns this effectively (say
with an internal member when creating the item) and deals with
provider-related issues such as /vsizip/ issues
2) cache the values of the data() function

Etienne

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

Re: [Qgis-developer] Discussion on browser and file extensions

[Giuseppe Sucameli]

Hi Radim,

On Wed, May 23, 2012 at 6:45 PM, Radim Blazek  wrote:
>> and adding a QgsDataItem::fileName() member which the browser would
>> use for layer items. It very simple to fix now.
>
> It should be possible to get the file name from QgsDataItem::uri().

if the layer is file-based get the name from the uri, otherwise get
it from name(). Is that what you meant?

BTW we need another method, right? Something like
QgsLayerItem::layerName()

> QgsDataItem is base for various data sources, most of them are not
> file based.

I agree, having a fileName() method in the QgsDataItem class
is non-sense.

Cheers.

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

Re: [Qgis-developer] Fix for bug #4521 and possible improvements

[Victor Axbom]

Hi List!

I have submitted a patch to fix the bug which related to the map tip
function. It would be great if someone could review it and get it into
master before 1.8. This is my first attemp to contribute to the qgis
project so I might have missed something regarding the coding
conventions or some other part, but hopefully not. I also have a patch
with some, IMO, improvements on the map tips. I think it would be
useful to not only be able to see just one field (the display field),
but to see all of the attributes and values of a feature in the map
tip. This should be a choice and the prefered method should be set in
the settings. See attached screenshots. Is there any interest in
submitting this into master after 1.8 is out?

Regards

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

Re: [Qgis-developer] Raster transparency plugin with PostGIS rasters

[Paolo Cavallini]

Il 24/05/2012 14:24, Alexander Bruy ha scritto:
> Hi Paolo,
>
> please try version 0.1.14
>
seems to work well, thanks

-- 
Paolo Cavallini
See: http://www.faunalia.it/pc

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

Re: [Qgis-developer] Help me compile a 'what's new' list for QGIS 1.8

[kimaidou]

Thanks Nathan, you are right, I misread it ! Sorry for the noise, I should
have checked the sources before asking.

Michael

2012/5/25 Nathan Woodrow 

> > Is it related with the patch I proposed [1] ? I understood it was a new
> > feature, and because we were on "feature freeze", it could not be
> applied on
> > 1.8 ?
>
> No I suspect not.  The predefined scales it is refering to the ones that
> were
> there before you patch.
>
> - Nathan
>
> On Fri, May 25, 2012 at 5:21 PM, kimaidou  wrote:
> > Hi devs,
> >
> > Back to the 1st topic : 1.8 new features :)
> >
> > I have read this line in the wiki page [0] : "New scale selector with
> > predefined scales"
> >
> > Is it related with the patch I proposed [1] ? I understood it was a new
> > feature, and because we were on "feature freeze", it could not be
> applied on
> > 1.8 ?
> >
> > Michael
> >
> > [0] http://hub.qgis.org/wiki/quantum-gis/WhatsNew_18
> > [1] http://hub.qgis.org/issues/5561
> >
> > ___
> > 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] Help me compile a 'what's new' list for QGIS 1.8

[Nathan Woodrow]

> Is it related with the patch I proposed [1] ? I understood it was a new
> feature, and because we were on "feature freeze", it could not be applied on
> 1.8 ?

No I suspect not.  The predefined scales it is refering to the ones that were
there before you patch.

- Nathan

On Fri, May 25, 2012 at 5:21 PM, kimaidou  wrote:
> Hi devs,
>
> Back to the 1st topic : 1.8 new features :)
>
> I have read this line in the wiki page [0] : "New scale selector with
> predefined scales"
>
> Is it related with the patch I proposed [1] ? I understood it was a new
> feature, and because we were on "feature freeze", it could not be applied on
> 1.8 ?
>
> Michael
>
> [0] http://hub.qgis.org/wiki/quantum-gis/WhatsNew_18
> [1] http://hub.qgis.org/issues/5561
>
> ___
> 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: AW: [Qgis-developer] Library linking problems when release changes - eg. 1.9 --> 1.8

[Andreas Neumann]

Thanks Stefan and Kimaidou

Setting LD_LIBRARY_PATH seems to work. It is strange. I was assuming 
that /usr/local/lib was searched by default anyway. After all this is 
the directory for libraries (next to /usr/lib )


Well - always some mysteries we can't understand ...

Thanks for helping me to solve the problem,
Andreas

On Fri, 25 May 2012 07:30:13 +, Ziegler Stefan wrote:

Hi Andi

I solved it by exporting LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

It's a bit strange since I think it used to work without this

Regards
Stefan


-Ursprüngliche Nachricht-
Von: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-
boun...@lists.osgeo.org] Im Auftrag von Andreas Neumann
Gesendet: Freitag, 25. Mai 2012 09:25
An: qgis-developer
Betreff: [Qgis-developer] Library linking problems when release 
changes - eg. 1.9 -->

1.8

 Hi,

 Whenever there is a change in the major version of QGIS, e.g. 1.7 
to
 1.9 and most recently the switch back from 1.9 to 1.8 I am running 
into  problems.


 The compile runs fine but when I try to start it I get this 
message:
 error while loading shared libraries: libqgis_core.so.1.8.0: cannot 
open shared object

file: No such file or directory


 But the libqgis_core.so.1.8.0 is present in /usr/local/lib

 I removed the build directory and ran ccmake .. and cmake .. again, 
but

 it doesn't solve this problem that it can't find the library that
 obviously is present and recent on my machine.

 I would very much appreciate if someone could help me out here.

 Thanks a lot,
 Andreas

--
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Library linking problems when release changes - eg. 1.9 --> 1.8

[kimaidou]

Hi Andreas

I ran into the same problem, and wrote a "Tip" here, thanks to the help of
someone in the chan irc
http://hub.qgis.org/projects/quantum-gis/wiki/Building_QGIS_from_Source

2012/5/25 Andreas Neumann 

> Hi,
>
> Whenever there is a change in the major version of QGIS, e.g. 1.7 to 1.9
> and most recently the switch back from 1.9 to 1.8 I am running into
> problems.
>
> The compile runs fine but when I try to start it I get this message:
> error while loading shared libraries: libqgis_core.so.1.8.0: cannot open
> shared object file: No such file or directory
>
>
> But the libqgis_core.so.1.8.0 is present in /usr/local/lib
>
> I removed the build directory and ran ccmake .. and cmake .. again, but it
> doesn't solve this problem that it can't find the library that obviously is
> present and recent on my machine.
>
> I would very much appreciate if someone could help me out here.
>
> Thanks a lot,
> Andreas
>
> --
> --
> Andreas Neumann
> Böschacherstrasse 10A
> 8624 Grüt (Gossau ZH)
> Switzerland
> __**_
> 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

AW: [Qgis-developer] Library linking problems when release changes - eg. 1.9 --> 1.8

[Ziegler Stefan]

Hi Andi

I solved it by exporting LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

It's a bit strange since I think it used to work without this

Regards
Stefan

> -Ursprüngliche Nachricht-
> Von: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-
> boun...@lists.osgeo.org] Im Auftrag von Andreas Neumann
> Gesendet: Freitag, 25. Mai 2012 09:25
> An: qgis-developer
> Betreff: [Qgis-developer] Library linking problems when release changes - eg. 
> 1.9 -->
> 1.8
> 
>  Hi,
> 
>  Whenever there is a change in the major version of QGIS, e.g. 1.7 to
>  1.9 and most recently the switch back from 1.9 to 1.8 I am running into  
> problems.
> 
>  The compile runs fine but when I try to start it I get this message:
>  error while loading shared libraries: libqgis_core.so.1.8.0: cannot  open 
> shared object
> file: No such file or directory
> 
> 
>  But the libqgis_core.so.1.8.0 is present in /usr/local/lib
> 
>  I removed the build directory and ran ccmake .. and cmake .. again, but
>  it doesn't solve this problem that it can't find the library that
>  obviously is present and recent on my machine.
> 
>  I would very much appreciate if someone could help me out here.
> 
>  Thanks a lot,
>  Andreas
> 
> --
>  --
>  Andreas Neumann
>  Böschacherstrasse 10A
>  8624 Grüt (Gossau ZH)
>  Switzerland
> ___
> 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] Library linking problems when release changes - eg. 1.9 --> 1.8

[Andreas Neumann]

Hi,

Whenever there is a change in the major version of QGIS, e.g. 1.7 to 
1.9 and most recently the switch back from 1.9 to 1.8 I am running into 
problems.


The compile runs fine but when I try to start it I get this message:
error while loading shared libraries: libqgis_core.so.1.8.0: cannot 
open shared object file: No such file or directory



But the libqgis_core.so.1.8.0 is present in /usr/local/lib

I removed the build directory and ran ccmake .. and cmake .. again, but 
it doesn't solve this problem that it can't find the library that 
obviously is present and recent on my machine.


I would very much appreciate if someone could help me out here.

Thanks a lot,
Andreas

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Help me compile a 'what's new' list for QGIS 1.8

[kimaidou]

Hi devs,

Back to the 1st topic : 1.8 new features :)

I have read this line in the wiki page [0] : "New scale selector with
predefined scales"

Is it related with the patch I proposed [1] ? I understood it was a new
feature, and because we were on "feature freeze", it could not be applied
on 1.8 ?

Michael

[0] http://hub.qgis.org/wiki/quantum-gis/WhatsNew_18
[1] http://hub.qgis.org/issues/5561
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Rendering order in rule-based style not working

[kimaidou]

Hi all

Is there a wiki page describing the changes between 1.7 and next release
concerning rule based rendering ? Or this kind of wiki page won't ever
exists because it will "compete" with documentation ? Anyway, pointing
users to specific chapters in documentations will help people to knwo what
to change between 1.7 and 1.8 to adapt their projects.

We use the "new features" pages [1] and add links to the documentation here
?

[1] http://hub.qgis.org/wiki/quantum-gis/WhatsNew_18

Michael

2012/5/25 Nathan Woodrow 

> Just to clarify things the old 1.9 now equals 1.8.  If you are running
> the dev build of QGIS you are running the upcoming 1.8 release.
>
> So yes the new rule engine will be in 1.8.
>
> - Nathan
>
> On Fri, May 25, 2012 at 11:06 AM, Ramon Andiñach 
> wrote:
> > I've not yet been game to try 1.8 (I will soon) but with the OSGeo
> installer in 1.9 all of my rule based styles behave differently than in 1.7
> because rendering order/symbology levels are assumed.
> >
> > Since that has been in 1.9 for a while I'd expect it to be 1.8 and I'd
> start there.
> >
> > -ramon.
> >
> >
> > On 24/05/2012, at 23:04, Bernhard Ströbl 
> wrote:
> >
> >> addon:
> >> behaviour can only be observed if rule-based style is combined with
> scale ranges
> >>
> >> Bernhard
> >>
> >> Am 24.05.2012 16:16, schrieb Bernhard Ströbl:
> >>> Dear devs,
> >>>
> >>> the rendering order in rule based style does not work any more, instead
> >>> features rendering is ordered by chance.
> >>> QGIS 1.8 RC 1 (code version c367a35) on OpenSUSE 11.4
> >>>
> >>> anybody confirms?
> >>>
> >>> Bernhard
> >>>
> >>>
> >>
> >>
> >>  Information from NOD32 
> >> This message was checked by NOD32 Antivirus System for Linux Mail
> Server.
> >> http://www.nod32.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 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