Re: [Qgis-developer] GRASS QGIS module list
Il 17/10/2010 21:15, Micha Silver ha scritto: > The "GRASS QGIS Module List" wiki page [1] holds a list of the GRASS > modules now available from the QGIS GRASS Toolbox. Hamish suggested [2] > to color code the list (similar to the Live DVD packaging matrix). > I've started to add color coding to the wiki page. I did just a few > entries to see how it looks. very nice, +1 for me. thanks Micha. -- Paolo Cavallini: 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] qgs project from 1.4 crashing qgis 1.5
Hi Agus, I'm no specialist on qgs files but from what I've done in the past here is my comments: The layers in a qgs file are spread in two sections (if you have not created composer outputs). The first section will give you the name of the layer and an ID. The second section starts by the ID. e.g. First section (in the block) layerid="teststack20100829204340464" visible="1" /> Second section (in the block) teststack20100829204340464 ./teststack.shp teststack If you want to delete a layer you have to delete the block ... and the block ... If you have composer blocks I recommend you delete all of them as they could be the culprits that make the qgs crash. HTH Benoit On 18/10/2010 07:56, Agustin Lobo wrote: Hi! I've tried to open a qgs file made with qgis 1.4 on qgis 1.5 (ubuntu binaries on ubuntu 9.10) but qgis 1.5 crashes before completing the loading of all layers. Is there any way I can debug the qgs file? In particular, I would like to edit the qgs file and delete after a given layer, but guess that there is a part at the end that I should keep. Thanks Agus ___ 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] qgs project from 1.4 crashing qgis 1.5
Hi! I've tried to open a qgs file made with qgis 1.4 on qgis 1.5 (ubuntu binaries on ubuntu 9.10) but qgis 1.5 crashes before completing the loading of all layers. Is there any way I can debug the qgs file? In particular, I would like to edit the qgs file and delete after a given layer, but guess that there is a part at the end that I should keep. Thanks Agus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Release plans for QGIS 1.6
Hi Ok I went with Giovanni's suggestion of Capiopo for this release - see the new splash screen in trunk. Regards Tim On Sun, Oct 17, 2010 at 10:42 AM, Benoit de Cabissole wrote: > > > On 17/10/2010 10:37, Tim Sutton wrote: >> Hi >> >> On Sun, Oct 17, 2010 at 10:16 AM, Vincent Leong wrote: >>> How about hill names as release names? >>> Hills is better than mountains because mountains is always too well >>> known and probably been used by others. >>> Moreover, their shape can be used to differentiate releases. >>> >>> One example: Bohol >>> >> Any nice pics to go with your suggestion? I quite like the idea since >> philosophically each release is another hill we have climbed and put >> behind us :-) > > Or characteristics contour lines of the hill (we are dealing with GIS > after all)? > > My 2 cents > Benoit > >> Lets keep the discussion on-list ok? >> >> Regards >> >> Tim >> >>> On 10/17/10, Tim Sutton wrote: Hi On Sun, Oct 17, 2010 at 1:07 AM, Alex Mandel wrote: > I agree that real place names is a better idea. I could see lots of > Mythical/Fictitious names actually being claimed by people. I will also > point out that the Mozilla Foundation uses National Parks/Reserves in > the code naming of pre-release firefox branches and suggest that we > could do something with a greater cause as our release names: > Endangered Species, World Heritage Sites, Rivers, Mountain Peaks, etc.. > (suggest your idea) > Sorry in retrospect my original email was probably unclear. It was my intention that we use *real* (hence photographable) place names, but obscure ones that a) have some geographical interest and b) are unlikely to ever have been used by someone as a trademark. Having a theme to the place names would be fine (making them really obscure and interesting was kind of my idea for a theme, but another theme would be fine too). Using well known places e.g. Moscow as Maxim suggests will lead to similar conflicts as using planetary moons. Regards Tim > We could also de-emphasize the release name and use it amongst the > developer group to keep track of what's being worked on, ie the trunk > will have a name leading up to it's release and then switch names. > > I also agree, to just avoid the issue as it's not worth our effort to > fight. > > Thanks, > Alex > > On 10/16/2010 03:06 PM, Maxim Dubinin wrote: >> How about making release names geographic. QGIS 1.6 "Moscow" sounds >> good and easily memorizable. >> >> Maxim >> >> Вы писали 16 октября 2010 г., 14:07:10: >> >> TS> Hi >> >> TS> On Sat, Oct 16, 2010 at 8:09 PM, Jürgen E. wrote: Hi Tim, On Sat, 16. Oct 2010 at 01:42:54 +0200, Tim Sutton wrote: > We (the PSC) recently received a threat of legal action against our > use of the word 'Tethys' in the naming of the 1.5 release of QGIS. > It seems that the word Tethys is trademarked by a company in one > country. > Although we feel their case is weak, we do not have the time, money or > inclination to engage in a legal battle over this. Does OSGeo have a position on this? I thought the OSGeo umbrella was also covering legal support. Just curious - that would probably be a waste of time of resources anyway. >> TS> Ok Frank covered that. And yeah we should pick our battles... >> > This has a few implications: > - The PSC has agreed to stop using planetary moons as the names for > our releases, and embark on a new theme of using extremely obscure > place names (e.g. the mythical Tweebuffelsmeteenskootgeskietfontein in > South Africa). Do we need codenames at all? Any name - obscure or not - could be a trademark. >> TS> *sniff* lose the release names? That would be no funshould we let >> TS> big corporations take away our fun? :-P >> >> TS> But yeah theoretically we don't need them, though personally I'd like >> TS> to continue with them... >> >> TS> Regards >> >> TS> Tim >> Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please d
Re: [Qgis-developer] Raster histogram in Python plugin
Hi Tim, On 17/10/2010 21:36, Tim Sutton wrote: Hi On Sun, Oct 17, 2010 at 7:15 PM, Benoit de Cabissole wrote: Hi Tim, Many thanks for your reply. I see that the API doc classifies HistogramVector as a QVector but I cannot find any reference of QVector in the Qt doc (there are QVector2D, QVector3D and QVector4D). Could it be the problem? I found QVector in my (Qt 4.7) docs using Qt Assistant - not sure why its not showing up for you. Perhaps it is not ported to the python SIP lib. Well it is not in the PyQt (4.6.2) API doc I'm using! What I'm trying to do is to improve the speed of my plugin '1-band raster colour table' that allows to create colour table from a colour palette and a colouring method. Yup I use your plugin regularly - its great! Thanks! As I'm doing it in Python, the computation of the stats and histogram takes for ever on large rasters. I was hoping to piggyback on the stats and histo function built in QGIS (they themselves are (very) slow on large rasters). Right this is an issue. Part of the reason why QGIS is so slow is that it actually does two complete scans of each pixel to calculate the stats. This is needed for computing stddev - although since writing that code I have seen a way to compute stddev in a single pass - I just need to find the formula and the time to implement that. Oh no! I'm also using two passes, because I need to compute the min/max in the first pass to compute the classes for the histogram in the second pass. The STDev that I use is computed in a single pass with the following formula: STD = SQRT( ( N * Sum(X^2) - (Sum(X))^2 ) / ( N * (N-1) ) ) Note that Sum(X^2) is the 'sum of uncentered squares', not the one presently computed by QGIS/GDAL. Manuel Massing has said that QGIS/GDAL computes the 'empirical variance of the data' (i.e. sum (value-mean)2 ) and calls it the 'sum of the squared values'. So between us two we could reduce the time by having only one loop! How do you compute the histogram in one pass? Do you, a priori, know the max and min values? Are they available when the raster is loaded? I know an estimate of them is available. GDAL computes stats more quickly as it a) doesnt calculate stddev and b) will estimate things like min/max, histograms etc if you like based on a sampling of the data. GDAL can also store gathered stats (you may have noticed aux.xml files lying around in your raster dirs). Yes, I've noticed that one. Is there a function in QGIS to read its content in one go? Or do I have to parse it myself? For version 1.x of the plugin, I've eliminated the "imagette" (as Agus calls it) and replaced it by a new temporary layer in the mapcanvas because I'm now using QGIS functions to display the raster instead of my very slow matrix based raster used in the published plugin. Problem now is that QGIS compute the stats for that temp raster each time it is launched, and it can be very very slow. Is there a way to tell QGIS to use an (arbitrary) aux.xml file instead of computing the stats the first time the colour table changes? In my experience rasters files rarely change so keeping the stats file for that raster somewhere close to it would be a good idea, isn't it? In the longer term I would like to a) persist QGIS gathered stats, b) implement faster stddev calcs as mentioned above and c) only compute IO intensive stats like stddev if they are actually needed (e.g. if the user elects to use stddev in the raster symbology options). I agree that this work should be patched to the current code, but I'm not able to program in C++/C... So once the python plugin works as expected, it would be a good idea to hand it over to a C++ guru for patching! Yeah if I have time I may take a look - your plugin is really needed in the core of QGIS. Please before doing that wait for version 1.x it could be better to do the translation on it rather than on the current version. Cheers, Benoit Regards Tim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster histogram in Python plugin
Hi On Sun, Oct 17, 2010 at 7:15 PM, Benoit de Cabissole wrote: > Hi Tim, > > Many thanks for your reply. > > I see that the API doc classifies HistogramVector as a QVector but I > cannot find any reference of QVector in the Qt doc (there are QVector2D, > QVector3D and QVector4D). Could it be the problem? I found QVector in my (Qt 4.7) docs using Qt Assistant - not sure why its not showing up for you. Perhaps it is not ported to the python SIP lib. > > What I'm trying to do is to improve the speed of my plugin '1-band > raster colour table' that allows to create colour table from a colour > palette and a colouring method. Yup I use your plugin regularly - its great! > As I'm doing it in Python, the > computation of the stats and histogram takes for ever on large rasters. > I was hoping to piggyback on the stats and histo function built in QGIS > (they themselves are (very) slow on large rasters). Right this is an issue. Part of the reason why QGIS is so slow is that it actually does two complete scans of each pixel to calculate the stats. This is needed for computing stddev - although since writing that code I have seen a way to compute stddev in a single pass - I just need to find the formula and the time to implement that. GDAL computes stats more quickly as it a) doesnt calculate stddev and b) will estimate things like min/max, histograms etc if you like based on a sampling of the data. GDAL can also store gathered stats (you may have noticed aux.xml files lying around in your raster dirs). In the longer term I would like to a) persist QGIS gathered stats, b) implement faster stddev calcs as mentioned above and c) only compute IO intensive stats like stddev if they are actually needed (e.g. if the user elects to use stddev in the raster symbology options). > > I agree that this work should be patched to the current code, but I'm > not able to program in C++/C... > So once the python plugin works as expected, it would be a good idea to > hand it over to a C++ guru for patching! Yeah if I have time I may take a look - your plugin is really needed in the core of QGIS. Regards Tim > > Cheers, > Benoit > > > On 17/10/2010 19:00, Tim Sutton wrote: >> Hi >> >> I see that member is commented out in the sip file for rasterbandstats: >> >> python/core/qgsrasterbandstats.sip >> >> 40 //HistogramVector * histogramVector; >> >> If I uncomment it I get a compile time error: >> >> sip: QgsRasterBandStats::histogramVector has an unsupported type - >> provide %GetCode and %SetCode >> make[2]: *** [python/analysis/sipanalysispart0.cpp] Error 1 >> make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Error 2 >> >> So I guess the sip bindings need some tweaking to make it work. >> >> As an aside, if you are planning any tweaks improvements to the raster >> historgram, it would be great to do it as a patch to existing >> properties dialog rather than as a separate plugin. I found out how to >> enable zoom (but I wont do it in time for 1.6 release) on the charts. >> I also plan to add to the chart the user configured min/max entries >> per band, and maybe later a way to interactively set them on the >> chart. >> >> Regards >> >> Tim >> >> On Sun, Oct 17, 2010 at 4:09 PM, Benoit de Cabissole >> wrote: >>> Hi all, >>> >>> Is it possible to access the histogramVector attribute from the >>> QgsRasterBandStats Class in Python code from a plugin? >>> >>> When the following code is run it issues the error: >>> AttributeError: 'QgsRasterBandStats' object has no attribute >>> 'histogramVector' >>> >>> self.theLayer.populateHistogram(1,grd.S.nClass) >>> myStats = self.theLayer.bandStatistics(1) >>> grd.S.Histo[0, 0] = myStats.histogramVector[0].y() >>> >>> where 'self.theLayer' is a one band raster image and 'grd.S.nClass' = 40001 >>> >>> Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 >>> bit (Intel)] >>> QGIS version: 1.6.0-Trunk Trunk, 14378 >>> >From OSGeo4W on WinXP. >>> >>> Cheers, >>> Benoit >>> >>> ___ >>> 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 > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-d
[Qgis-developer] GRASS QGIS module list
The "GRASS QGIS Module List" wiki page [1] holds a list of the GRASS modules now available from the QGIS GRASS Toolbox. Hamish suggested [2] to color code the list (similar to the Live DVD packaging matrix). I've started to add color coding to the wiki page. I did just a few entries to see how it looks. Comments welcome, before I go ahead and set status coloring for all modules. -- Micha [1] http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list [2] http://osgeo-org.1803224.n2.nabble.com/forum/PostLink.jtp?post=5570523 -- Micha Silver Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster histogram in Python plugin
Hi Tim, Many thanks for your reply. I see that the API doc classifies HistogramVector as a QVector but I cannot find any reference of QVector in the Qt doc (there are QVector2D, QVector3D and QVector4D). Could it be the problem? What I'm trying to do is to improve the speed of my plugin '1-band raster colour table' that allows to create colour table from a colour palette and a colouring method. As I'm doing it in Python, the computation of the stats and histogram takes for ever on large rasters. I was hoping to piggyback on the stats and histo function built in QGIS (they themselves are (very) slow on large rasters). I agree that this work should be patched to the current code, but I'm not able to program in C++/C... So once the python plugin works as expected, it would be a good idea to hand it over to a C++ guru for patching! Cheers, Benoit On 17/10/2010 19:00, Tim Sutton wrote: > Hi > > I see that member is commented out in the sip file for rasterbandstats: > > python/core/qgsrasterbandstats.sip > > 40 //HistogramVector * histogramVector; > > If I uncomment it I get a compile time error: > > sip: QgsRasterBandStats::histogramVector has an unsupported type - > provide %GetCode and %SetCode > make[2]: *** [python/analysis/sipanalysispart0.cpp] Error 1 > make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Error 2 > > So I guess the sip bindings need some tweaking to make it work. > > As an aside, if you are planning any tweaks improvements to the raster > historgram, it would be great to do it as a patch to existing > properties dialog rather than as a separate plugin. I found out how to > enable zoom (but I wont do it in time for 1.6 release) on the charts. > I also plan to add to the chart the user configured min/max entries > per band, and maybe later a way to interactively set them on the > chart. > > Regards > > Tim > > On Sun, Oct 17, 2010 at 4:09 PM, Benoit de Cabissole > wrote: >> Hi all, >> >> Is it possible to access the histogramVector attribute from the >> QgsRasterBandStats Class in Python code from a plugin? >> >> When the following code is run it issues the error: >> AttributeError: 'QgsRasterBandStats' object has no attribute >> 'histogramVector' >> >> self.theLayer.populateHistogram(1,grd.S.nClass) >> myStats = self.theLayer.bandStatistics(1) >> grd.S.Histo[0, 0] = myStats.histogramVector[0].y() >> >> where 'self.theLayer' is a one band raster image and 'grd.S.nClass' = 40001 >> >> Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 >> bit (Intel)] >> QGIS version: 1.6.0-Trunk Trunk, 14378 >> >From OSGeo4W on WinXP. >> >> Cheers, >> Benoit >> >> ___ >> 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] Raster histogram in Python plugin
Hi I see that member is commented out in the sip file for rasterbandstats: python/core/qgsrasterbandstats.sip 40 //HistogramVector * histogramVector; If I uncomment it I get a compile time error: sip: QgsRasterBandStats::histogramVector has an unsupported type - provide %GetCode and %SetCode make[2]: *** [python/analysis/sipanalysispart0.cpp] Error 1 make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Error 2 So I guess the sip bindings need some tweaking to make it work. As an aside, if you are planning any tweaks improvements to the raster historgram, it would be great to do it as a patch to existing properties dialog rather than as a separate plugin. I found out how to enable zoom (but I wont do it in time for 1.6 release) on the charts. I also plan to add to the chart the user configured min/max entries per band, and maybe later a way to interactively set them on the chart. Regards Tim On Sun, Oct 17, 2010 at 4:09 PM, Benoit de Cabissole wrote: > Hi all, > > Is it possible to access the histogramVector attribute from the > QgsRasterBandStats Class in Python code from a plugin? > > When the following code is run it issues the error: > AttributeError: 'QgsRasterBandStats' object has no attribute > 'histogramVector' > > self.theLayer.populateHistogram(1,grd.S.nClass) > myStats = self.theLayer.bandStatistics(1) > grd.S.Histo[0, 0] = myStats.histogramVector[0].y() > > where 'self.theLayer' is a one band raster image and 'grd.S.nClass' = 40001 > > Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 > bit (Intel)] > QGIS version: 1.6.0-Trunk Trunk, 14378 > >From OSGeo4W on WinXP. > > Cheers, > Benoit > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Raster histogram in Python plugin
Hi all, Is it possible to access the histogramVector attribute from the QgsRasterBandStats Class in Python code from a plugin? When the following code is run it issues the error: AttributeError: 'QgsRasterBandStats' object has no attribute 'histogramVector' self.theLayer.populateHistogram(1,grd.S.nClass) myStats = self.theLayer.bandStatistics(1) grd.S.Histo[0, 0] = myStats.histogramVector[0].y() where 'self.theLayer' is a one band raster image and 'grd.S.nClass' = 40001 Python version: 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] QGIS version: 1.6.0-Trunk Trunk, 14378 >From OSGeo4W on WinXP. Cheers, Benoit ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 1.6 Release Timeline
Hi, > So now is a good time to identify any show stoppers. this is my "favourite" list among the last 100 filed tickets https://trac.osgeo.org/qgis/ticket/3119 https://trac.osgeo.org/qgis/ticket/3100 https://trac.osgeo.org/qgis/ticket/3090 https://trac.osgeo.org/qgis/ticket/3078 https://trac.osgeo.org/qgis/ticket/3077 https://trac.osgeo.org/qgis/ticket/3059 https://trac.osgeo.org/qgis/ticket/3013 https://trac.osgeo.org/qgis/ticket/3071 plus there are a number of interesting patches, examples: https://trac.osgeo.org/qgis/ticket/3010 https://trac.osgeo.org/qgis/ticket/2991 https://trac.osgeo.org/qgis/ticket/1899 https://trac.osgeo.org/qgis/ticket/2963 cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] ECW Support in 1.6...
Hello, I don't understand why ECW support is not included in this version. GDAL 1.7.2 now support ECW, also I downloaded ERDAS SDK kit 4.1 last night. I think a lot of users use ECW in their projects. Thank you for answers and all good work you done. Best regards, Joze. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] 1.6 Release Timeline
Hi Folks Ok so my proposed (extremely short) timeline for releasing 1.6 is: Feature freeze AND string freeze : 24 October 2010 Code freeze, branch and call for packaging: 31 October 2010 Release announcement date: November 7 2010 As per usual exact day of release will depend on package availability. So now is a good time to identify any show stoppers. Does anybody find this short timeline problematic? I started a checklist page for 1.6 at: http://www.qgis.org/wiki/Release_Checklist_1.6 If anybody has ideas and suggestions for interesting things to highlight for the visual changelog, please make a note of them here: http://www.qgis.org/wiki/VisualChangeLog1.6.0 Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Release plans for QGIS 1.6
On 17/10/2010 10:37, Tim Sutton wrote: > Hi > > On Sun, Oct 17, 2010 at 10:16 AM, Vincent Leong wrote: >> How about hill names as release names? >> Hills is better than mountains because mountains is always too well >> known and probably been used by others. >> Moreover, their shape can be used to differentiate releases. >> >> One example: Bohol >> > Any nice pics to go with your suggestion? I quite like the idea since > philosophically each release is another hill we have climbed and put > behind us :-) Or characteristics contour lines of the hill (we are dealing with GIS after all)? My 2 cents Benoit > Lets keep the discussion on-list ok? > > Regards > > Tim > >> On 10/17/10, Tim Sutton wrote: >>> Hi >>> >>> >>> >>> On Sun, Oct 17, 2010 at 1:07 AM, Alex Mandel >>> wrote: I agree that real place names is a better idea. I could see lots of Mythical/Fictitious names actually being claimed by people. I will also point out that the Mozilla Foundation uses National Parks/Reserves in the code naming of pre-release firefox branches and suggest that we could do something with a greater cause as our release names: Endangered Species, World Heritage Sites, Rivers, Mountain Peaks, etc.. (suggest your idea) >>> Sorry in retrospect my original email was probably unclear. It was my >>> intention that we use *real* (hence photographable) place names, but >>> obscure ones that a) have some geographical interest and b) are >>> unlikely to ever have been used by someone as a trademark. Having a >>> theme to the place names would be fine (making them really obscure and >>> interesting was kind of my idea for a theme, but another theme would >>> be fine too). >>> >>> Using well known places e.g. Moscow as Maxim suggests will lead to >>> similar conflicts as using planetary moons. >>> >>> Regards >>> >>> Tim >>> >>> We could also de-emphasize the release name and use it amongst the developer group to keep track of what's being worked on, ie the trunk will have a name leading up to it's release and then switch names. I also agree, to just avoid the issue as it's not worth our effort to fight. Thanks, Alex On 10/16/2010 03:06 PM, Maxim Dubinin wrote: > How about making release names geographic. QGIS 1.6 "Moscow" sounds > good and easily memorizable. > > Maxim > > Вы писали 16 октября 2010 г., 14:07:10: > > TS> Hi > > TS> On Sat, Oct 16, 2010 at 8:09 PM, Jürgen E. wrote: >>> Hi Tim, >>> >>> On Sat, 16. Oct 2010 at 01:42:54 +0200, Tim Sutton wrote: We (the PSC) recently received a threat of legal action against our use of the word 'Tethys' in the naming of the 1.5 release of QGIS. It seems that the word Tethys is trademarked by a company in one country. Although we feel their case is weak, we do not have the time, money or inclination to engage in a legal battle over this. >>> Does OSGeo have a position on this? I thought the OSGeo umbrella was >>> also >>> covering legal support. >>> >>> Just curious - that would probably be a waste of time of resources >>> anyway. >>> > TS> Ok Frank covered that. And yeah we should pick our battles... > This has a few implications: - The PSC has agreed to stop using planetary moons as the names for our releases, and embark on a new theme of using extremely obscure place names (e.g. the mythical Tweebuffelsmeteenskootgeskietfontein in South Africa). >>> Do we need codenames at all? Any name - obscure or not - could be a >>> trademark. >>> >>> > TS> *sniff* lose the release names? That would be no funshould we let > TS> big corporations take away our fun? :-P > > TS> But yeah theoretically we don't need them, though personally I'd like > TS> to continue with them... > > TS> Regards > > TS> Tim > >>> Jürgen >>> >>> -- >>> Jürgen E. Fischer norBIT GmbH Tel. >>> +49-4931-918175-20 >>> Dipl.-Inf. (FH) Rheinstraße 13Fax. >>> +49-4931-918175-50 >>> Software Engineer D-26506 Norden >>> http://www.norbit.de >>> ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> >>> -- >>> Tim Sutton - QGIS Project Steering Committee Member (Release Manager) >>> == >>> Please do not email me off-list with technical >>> support questions. Using the lists will gain >>> more exposure for your issues and the knowledge >>> surrounding your issue will be shared with all. >>> >>> Visit http://linfiniti.com to find out about: >>> * QGIS programming and support services >>> * Mapserver and PostGIS based ho
Re: [Qgis-developer] Release plans for QGIS 1.6
Hi On Sun, Oct 17, 2010 at 10:16 AM, Vincent Leong wrote: > How about hill names as release names? > Hills is better than mountains because mountains is always too well > known and probably been used by others. > Moreover, their shape can be used to differentiate releases. > > One example: Bohol > Any nice pics to go with your suggestion? I quite like the idea since philosophically each release is another hill we have climbed and put behind us :-) Lets keep the discussion on-list ok? Regards Tim > On 10/17/10, Tim Sutton wrote: >> Hi >> >> >> >> On Sun, Oct 17, 2010 at 1:07 AM, Alex Mandel >> wrote: >>> I agree that real place names is a better idea. I could see lots of >>> Mythical/Fictitious names actually being claimed by people. I will also >>> point out that the Mozilla Foundation uses National Parks/Reserves in >>> the code naming of pre-release firefox branches and suggest that we >>> could do something with a greater cause as our release names: >>> Endangered Species, World Heritage Sites, Rivers, Mountain Peaks, etc.. >>> (suggest your idea) >>> >> >> Sorry in retrospect my original email was probably unclear. It was my >> intention that we use *real* (hence photographable) place names, but >> obscure ones that a) have some geographical interest and b) are >> unlikely to ever have been used by someone as a trademark. Having a >> theme to the place names would be fine (making them really obscure and >> interesting was kind of my idea for a theme, but another theme would >> be fine too). >> >> Using well known places e.g. Moscow as Maxim suggests will lead to >> similar conflicts as using planetary moons. >> >> Regards >> >> Tim >> >> >>> We could also de-emphasize the release name and use it amongst the >>> developer group to keep track of what's being worked on, ie the trunk >>> will have a name leading up to it's release and then switch names. >>> >>> I also agree, to just avoid the issue as it's not worth our effort to >>> fight. >>> >>> Thanks, >>> Alex >>> >>> On 10/16/2010 03:06 PM, Maxim Dubinin wrote: How about making release names geographic. QGIS 1.6 "Moscow" sounds good and easily memorizable. Maxim Вы писали 16 октября 2010 г., 14:07:10: TS> Hi TS> On Sat, Oct 16, 2010 at 8:09 PM, Jürgen E. wrote: >> Hi Tim, >> >> On Sat, 16. Oct 2010 at 01:42:54 +0200, Tim Sutton wrote: >>> We (the PSC) recently received a threat of legal action against our >>> use of the word 'Tethys' in the naming of the 1.5 release of QGIS. >>> It seems that the word Tethys is trademarked by a company in one >>> country. >>> Although we feel their case is weak, we do not have the time, money or >>> inclination to engage in a legal battle over this. >> >> Does OSGeo have a position on this? I thought the OSGeo umbrella was >> also >> covering legal support. >> >> Just curious - that would probably be a waste of time of resources >> anyway. >> TS> Ok Frank covered that. And yeah we should pick our battles... >>> This has a few implications: >> >>> - The PSC has agreed to stop using planetary moons as the names for >>> our releases, and embark on a new theme of using extremely obscure >>> place names (e.g. the mythical Tweebuffelsmeteenskootgeskietfontein in >>> South Africa). >> >> Do we need codenames at all? Any name - obscure or not - could be a >> trademark. >> >> TS> *sniff* lose the release names? That would be no funshould we let TS> big corporations take away our fun? :-P TS> But yeah theoretically we don't need them, though personally I'd like TS> to continue with them... TS> Regards TS> Tim >> Jürgen >> >> -- >> Jürgen E. Fischer norBIT GmbH Tel. >> +49-4931-918175-20 >> Dipl.-Inf. (FH) Rheinstraße 13 Fax. >> +49-4931-918175-50 >> Software Engineer D-26506 Norden >> http://www.norbit.de >> >>> >>> ___ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> >> >> >> -- >> Tim Sutton - QGIS Project Steering Committee Member (Release Manager) >> == >> Please do not email me off-list with technical >> support questions. Using the lists will gain >> more exposure for your issues and the knowledge >> surrounding your issue will be shared with all. >> >> Visit http://linfiniti.com to find out about: >> * QGIS programming and support services >> * Mapserver and PostGIS based hosting plans >> * FOSS Consulting Services >> Skype: timlinux >> Irc: timlinux on #qgis at freenode.net >> == >> ___ >> Qgis-developer mailing list >> Qgis-d
Re: [Qgis-developer] Problems with Histogram tab in Raster properties
Hi On Thu, Oct 14, 2010 at 9:51 AM, Benoit de Cabissole wrote: > Hi, > > A) In release 14370 the histogram tab of the raster properties window > has a problem: > The histogram is not displayed the second time the 'histogram tab' is > clicked. > E.g.: > 1 - open the raster properties window > 2 - click on the histogram tab > 3 - histogram is computed and displayed > 4 - click on any other tab > 5 - click on the histogram tab again > 6 - blank screen!! > > On WinXP - OSGeo4W dev installation > Can someone replicate the problem? > This should be fixed now as of r14387. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] pg table inheritance
Hi all. Has anybody tested QGIS against PostgreSQL inherited tables? I have a database with parents and child, and everything works fine, but attribute tables are shown as filled up with "ERROR". Data are read, geometries can be categorized, a shp can be exported, but selection from the table does not work properly. I'm planning of setting up a public clone of it for devs testing, is anyone is interested. All the best. -- Paolo Cavallini: 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] Release plans for QGIS 1.6
Hi On Sun, Oct 17, 2010 at 1:07 AM, Alex Mandel wrote: > I agree that real place names is a better idea. I could see lots of > Mythical/Fictitious names actually being claimed by people. I will also > point out that the Mozilla Foundation uses National Parks/Reserves in > the code naming of pre-release firefox branches and suggest that we > could do something with a greater cause as our release names: > Endangered Species, World Heritage Sites, Rivers, Mountain Peaks, etc.. > (suggest your idea) > Sorry in retrospect my original email was probably unclear. It was my intention that we use *real* (hence photographable) place names, but obscure ones that a) have some geographical interest and b) are unlikely to ever have been used by someone as a trademark. Having a theme to the place names would be fine (making them really obscure and interesting was kind of my idea for a theme, but another theme would be fine too). Using well known places e.g. Moscow as Maxim suggests will lead to similar conflicts as using planetary moons. Regards Tim > We could also de-emphasize the release name and use it amongst the > developer group to keep track of what's being worked on, ie the trunk > will have a name leading up to it's release and then switch names. > > I also agree, to just avoid the issue as it's not worth our effort to fight. > > Thanks, > Alex > > On 10/16/2010 03:06 PM, Maxim Dubinin wrote: >> How about making release names geographic. QGIS 1.6 "Moscow" sounds >> good and easily memorizable. >> >> Maxim >> >> Вы писали 16 октября 2010 г., 14:07:10: >> >> TS> Hi >> >> TS> On Sat, Oct 16, 2010 at 8:09 PM, Jürgen E. wrote: Hi Tim, On Sat, 16. Oct 2010 at 01:42:54 +0200, Tim Sutton wrote: > We (the PSC) recently received a threat of legal action against our > use of the word 'Tethys' in the naming of the 1.5 release of QGIS. > It seems that the word Tethys is trademarked by a company in one country. > Although we feel their case is weak, we do not have the time, money or > inclination to engage in a legal battle over this. Does OSGeo have a position on this? I thought the OSGeo umbrella was also covering legal support. Just curious - that would probably be a waste of time of resources anyway. >> >> TS> Ok Frank covered that. And yeah we should pick our battles... >> > This has a few implications: > - The PSC has agreed to stop using planetary moons as the names for > our releases, and embark on a new theme of using extremely obscure > place names (e.g. the mythical Tweebuffelsmeteenskootgeskietfontein in > South Africa). Do we need codenames at all? Any name - obscure or not - could be a trademark. >> >> TS> *sniff* lose the release names? That would be no funshould we let >> TS> big corporations take away our fun? :-P >> >> TS> But yeah theoretically we don't need them, though personally I'd like >> TS> to continue with them... >> >> TS> Regards >> >> TS> Tim >> Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de > > ___ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
