lost trying to get the right file.
I think we can do much better.
Then it is a matter of advertising the preview at large : official call for
testing from qgis project on osgeo mailing lists, twitter, linkedin, and if
possible on a qgis-news mailing list where we have gathered a lot of user
beforehand (with their approval of course).
Vincent
--
Message: 6
Date: Fri, 06 Jun 2014 14:16:22 +0200
From: Paolo Cavallini cavall...@faunalia.it
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Opinion on plugin named prepair (and
possible likes)
Message-ID: 5391b116.3080...@faunalia.it
Content-Type: text/plain; charset=ISO-8859-1
Il 06/06/2014 13:17, Hugo Ledoux ha scritto:
A windows Installer would be nice, but, Paulo, do you mean that QGIS would
add
prepair? That would be tricky, since we use CGAL too. But that would be
great.
The plugin should remember the path of the EXE, it does on all computers
we've
tested. Report bug on the issue page with details please.
Hi.
Hugo, would you object in tagging the plugin as experimental for now?
Yes, I meant to include prepair (the plugin+the exe+des) in the standalone
installer,
as well as making it easy to install it in other OSs.
Are you willing to help with that?
All the best.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
--
Message: 7
Date: Fri, 6 Jun 2014 22:24:23 +1000
From: Nathan Woodrow madman...@gmail.com
To: Paolo Cavallini cavall...@faunalia.it
Cc: qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Opinion on plugin named prepair (and
possiblelikes)
Message-ID:
caai8yg_r0i8fkp4a_aww0wjdwbbyve0l7zbjfv3fo3ooupn...@mail.gmail.com
Content-Type: text/plain; charset=utf-8
I'm not sure just adding it to QGIS like that is the best idea really, it's
a bit bolt on. It would be better to port the prepair C++ logic into QGIS
itself to use QGIS geometry rather then GDAL. We could then just expose the
API and wrap it in Python to expose in Processing.
- Nathan
On Fri, Jun 6, 2014 at 10:16 PM, Paolo Cavallini cavall...@faunalia.it
wrote:
Il 06/06/2014 13:17, Hugo Ledoux ha scritto:
A windows Installer would be nice, but, Paulo, do you mean that QGIS
would add
prepair? That would be tricky, since we use CGAL too. But that would be
great.
The plugin should remember the path of the EXE, it does on all computers
we've
tested. Report bug on the issue page with details please.
Hi.
Hugo, would you object in tagging the plugin as experimental for now?
Yes, I meant to include prepair (the plugin+the exe+des) in the standalone
installer,
as well as making it easy to install it in other OSs.
Are you willing to help with that?
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140606/5937703a/attachment-0001.html
--
Message: 8
Date: Fri, 6 Jun 2014 14:26:47 +0200
From: Even Rouault even.roua...@mines-paris.org
To: qgis-developer@lists.osgeo.org, rich...@duif.net
Subject: Re: [Qgis-developer] ogr osm provider seems broken
Message-ID: 201406061426.47643.even.roua...@mines-paris.org
Content-Type: Text/Plain; charset=iso-8859-1
Le vendredi 06 juin 2014 08:55:39, Richard Duivenvoorde a ?crit :
Hi Devs,
to me the way qgis handles .osm files seems broken, see:
http://hub.qgis.org/issues/1
http://hub.qgis.org/issues/10427
apparently ogr returns -1 on the number of features, but more important
the feature interator seems broken
Problems: loading an osm file and viewing the attribute table only shows
2 records (while all points are shown on the map).
Iterating over the features with python also raises errors.
Not sure if we should make this a blocker, because I'm not convinced of
the importance of .osm files.
Richard,
Jukka pretty much answered rightly the questions in the tickets. The OGR OSM
driver is rather tuned to handle multi-gigabyte .osm/.pbf files, and due to
the
structure of those files, it is impossible to count efficiently the number of
features without reading it entirely. Hence -1 returned as the feature count.
If you issue an explicit SELECT COUNT(*) FROM, it means that you know what you
want, and you're ready to wait for it...
And, also related to the structure of the data, the driver is a bit particular
in the sense that the iteratation over features with GetNextFeature() might
not work if the osm file is of a sufficient size. See the Interleaved
