sample dataset including plug-ins (=> was: Re: [Qgis-user] Announcing "Time Manager" Plugin v 0.1)
Pierre Chevalier Géologue
pierrechevaliergeol at free.fr
Wed Oct 6 00:30:17 PDT 2010
Guten Morgen,
Volker Fröhlich claviota:
> Hello!
> This sounds very interesting, but the devil is in the details, I suppose.
Of course it is! ;)
Let's fight it...
> For example, you can't just "deliver" a PostGIS database. This needs further
> explaination and this explaination may vary for different platforms. So the
> experience will definitly not be like what you described.
>
True. It may be a little bit more complicated. If we simply use an
sqlite database, the problem is solved.
I'm just wandering, however, if a postgresql database could be delivered
inside a .deb or an .rpm (or whatever) package. I'm pretty sure this can
be done, somehow.
For any other platform, providing the plain SQL script would be enough.
But sure, it is more complicated than just typing "volcano" within R.
> As far as I know, there is some kind of demonstrational show for R modules.
>
Yes, definitely. It is very basic, and shows in very few lines the great
power of R. Since qgis is GUI-driven, we can't do this. But we can
provide a few .qgs files, with neat ready-to-run "applications".
> Maybe you can script something like that. This would bear an advantage, as it
> could serve as an example for users interested in scripting.
>
> I also think it burdens the plugin developers, since they have to take care of
> an up-to-date demonstrational dataset as well.
Yes. Anyways, a plugin developer should always provide such a sample
dataset, even if it is very small and simple. In my humble opinion, at
least.
One thing that could be done to address such issues would be to
implement the qgis-sample-dataset on a server somewhere, with write
access to all developers (plugin, core), so that they can implement
*directly* their example dataset (through a web mapping interface, a sql
command-line, upload shapefiles, or whatever).
This means a data server, with web accesses, and a mechanism to generate
the package from the current live dataset. Shouldn't be too hard to
make. A sponsor may be needed to host the data server.
> You might have to inform the user to download new versions of the sample-datasets, as the functionality of a plugin changes or develops. I therefore think it won't work as a package on
> most Linux distributions, since most maintainers wouldn't update it as often as necessary.
>
Hm... True...
So then, another (silly?) idea: qgis plugins are now distributed through
the plugin mechanism. What about setting up a package, containing all
plugins (with the authors' authorizations, of course): it would be big
and evolving quickly. This way, it would be much easier to retrieve
plugins (it is a pain in the neck to download them one by one,
especially if you have a crappy DNS and/or a poor Internet connexion).
And also, it would allow for dependencies management through the package
management system. So, the versioning with the qgis-sample-dataset
package would be automagically managed.
> Volker
>
A+
Pierre
> Am Dienstag 05 Oktober 2010, 04:34:43 schrieb Noli Sicad:
>
>> Hi Pierre,
>>
>> This is very good idea.
>>
>> I myself don't deal with raster data at this moment, hence, all those
>> plugins dealing with raster is no use to me at this moment.
>>
>> (Cross posted to Qgis developer)
>>
>> Let see the developers feedbacks on your suggestions.
>>
>> Noli
>>
>> On 10/5/10, Pierre Chevalier Géologue <pierrechevaliergeol at free.fr> wrote:
>>
>>> Hello,
>>>
>>> I start another thread, based on the discussion about time manager
>>> dataset.
>>>
>>> Noli Sicad claviota:
>>>
>>>> Very good point. Probably you can have 2 versions with data and
>>>> without data. I suggest that probably you can put a link, a button to
>>>> get the sample data in one of the plugin widgets. These are all
>>>> suggestions to improve usabilities of the qgis plugins in general.
>>>>
>>> Yes, I plussoie beaucoup. I agree, in a more proper language.
>>>
>>>
>>>> Some of QGIS plugins are hard to figure out if you don't have a properly
>>>> data to work on. And most of the users, have no real use of the plugin
>>>> at the time the plugin is announced and just like to see how it works.
>>>>
>>> Yes. And this is particularly true in GIS software.
>>> If you look at R, for instance, they provide datasets that can be
>>> accessed so simply. It is excellent, because you are able to *really*
>>> play with data in a matter of seconds, literally.
>>>
>>> For instance, in R, all you have to do is:
>>> contour(10 * (1:nrow(2 * volcano)), 10 * (1:ncol(2 * volcano)), 1.5
>>>
>>> * volcano, pretty(range(volcano)))
>>>
>>> To get, in ONE line, a contour map from a volcano in New Zealand.
>>>
>>> Similarly, to get a perspective view of the same data:
>>> persp(10 * (1:nrow(2 * volcano)), 10 * (1:ncol(2 * volcano)), 1.5 *
>>>
>>> volcano, theta = 140, phi = 30, scale = FALSE, axes = FALSE, shade =
>>> 0.5, border = NA)
>>>
>>>
>>> In fact, the variable 'volcano' seems to directly contain a whole
>>> dataset. No need to do any file/open or anything.
>>>
>>> Another example with another dataset provided with R, 'iris':
>>> pairs(iris[1:4], main="Edgar Anderson's Iris Data", pch=21,bg =
>>>
>>> c("red", "green3", "blue")[unclass(iris$Species)])
>>>
>>>
>>> In my humble opinion, this solution is extremely effective, from the
>>> end-user-beginner point of view.
>>> Now, back to qgis: there is already the Alaska dataset, also the grass
>>> spearfish dataset.
>>>
>>>
>>> I would be in favour of compiling a "state-of-the-art" complete dataset,
>>> so that users can play immediately with it, and get a good feeling about
>>> softwares. Not only plug-ins, but the whole thing. This could be a sort
>>> of standard, a base on which any GIS newbie could rely on to make his
>>> own dataset: just erase all example data, and fill with your own, and
>>> you're up and running.
>>>
>>> Such a dataset has, of course, to be free (freedom), it may have data
>>>
>>> such as:
>>> - an srtm dem,
>>> - a topo map,
>>> - gpx data,
>>> - satellite imagery
>>> - a scanned geological map (sorry, "je prêche pour ma paroisse"
>>>
>>> => if someone
>>>
>>> knows the English
>>>
>>> translation, go on and translate ;)
>>>
>>> ),
>>>
>>> - a scanned pedological map,
>>> - a set of pictures taken from the ground, geotagged,
>>> - buildings as vectors,
>>> - roads as vectors,
>>> - "field occupation" (occupation du sol, in French: not sure about
>>>
>>> translation) as vectors,
>>>
>>> - a postgis database,
>>> - an sqlite database,
>>> - a mysql (forgot about postgis equivalent, sorry) database,
>>> - a whole grass dataset,
>>> - etc, etc. (unlimited)
>>>
>>> Then, any plug-in developer should add to this dataset some sample data.
>>>
>>> I think such a sample dataset should be:
>>> - well-structured (state of the art => so that the GIS newbies can
>>>
>>> inherit from the experience/errors from senior users),
>>>
>>> - small, in terms of size: this way, when a user tries some features,
>>>
>>> it doesn't run for hours or colonize the whole user's RAM,
>>>
>>> - available separately from the software itself (regarding issues
>>>
>>> mentioned during the initial discussion); if it was for instance a linux
>>> package, it could be something like qgis-sample-data.
>>>
>>>
>>> The "spearfish" dataset could well be a base for such an exercise. Or
>>> Alaska.
>>> Or anything else. There was a "Doncaster" totally fake dataset, provided
>>> with GDM (geological package): it was invented, by mixing different data
>>> from various places, mangling data.
>>>
>>>
>>>> I hope if it will be in python plugin repository soon. I just like to
>>>> try it.
>>>>
>>> If such a solution was adopted, then every plugin developer should add
>>> relevant data in the sample data set. Or, maybe, publish on the
>>> repository a small dataset, which would make the complement of the
>>> existing whole dataset?
>>>
>>> Your opinions? Silly ideas? Utopia?...
>>>
>>> A+
>>> Pierre
>>>
>>> --
>>> _________________________________________________________________________
>>> ___ Pierre Chevalier Géologue EI
>>>
>>> Mesté Duran
>>> 32100 Condom
>>>
>>> Tél+fax : 09 75 27 45 62
>>>
>>> 05 62 28 06 83
>>>
>>> 06 37 80 33 64
>>>
>>> Émail : pierrechevaliergeolCHEZfree.fr
>>> icq# : 10432285
>>> skype : pierre.chevalier1967
>>> http://pierremariechevalier.free.fr/pierre_chevalier_geologue
>>>
>>> _________________________________________________________________________
>>> ___
>>>
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
--
____________________________________________________________________________
Pierre Chevalier Géologue EI
Mesté Duran
32100 Condom
Tél+fax : 09 75 27 45 62
05 62 28 06 83
06 37 80 33 64
Émail : pierrechevaliergeolCHEZfree.fr
icq# : 10432285
skype : pierre.chevalier1967
http://pierremariechevalier.free.fr/pierre_chevalier_geologue
____________________________________________________________________________
More information about the Qgis-user
mailing list