[GRASS-dev] Re: [Qgis-developer] qgis-grass poll
Il 21/05/2011 19:27, Mars Sjoden ha scritto: On Sat, May 21, 2011 at 9:56 AM, Charlie Sharpsteen ch...@sharpsteen.net mailto:ch...@sharpsteen.net wrote: On Sat, May 21, 2011 at 9:15 AM, Paolo Cavallini cavall...@faunalia.it mailto:cavall...@faunalia.it wrote: Hi all. I would like to do a poll on qgis-grass usage: which would be the best web tool to use? Probably better not to use qgis or grass pages; does osgeo provides polling facilities? Hi all. OSGeo is currently unable to provide polling facilities. I would like to avoid qgis and grass websites, not to bias the results, and woldn't like too much to use an external service: any better idea? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Test suite for GRASS - proposal, discussion welcome
Hello Pawel,
2011/6/17 Pawel Netzel pawel.net...@uni.wroc.pl:
Hi,
By my opinion, sections are not clearly separated in the examples on wiki
page.
This is intention. IMHO the annotation should be part of the
documentation so the test writer need to formulate sentence using
predefined words.
It will be something like good practise to write:
# description of test
# .
#
#@preprocessing
# ... some comments
command1
command2
#
#@test
# some comments
command3
command4
or alternatively
# ... some commants ...
#@test
commandX
This will work of course too. If its generally accepted to use this
style in the test script we can document and suggest it as good
practice.
Are you going to introduce annotation @assert('...message...',condition) or
something like this?
No, it should be as simple as possible but not too simple. IMHO only
the framework has to take car of the error message generation. In case
special conditions are tested it should be noticed in the test
documentation.
Best regards
Soeren
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [Qgis-developer] qgis-grass poll
On 17/06/11 08:28, Paolo Cavallini wrote: Il 21/05/2011 19:27, Mars Sjoden ha scritto: On Sat, May 21, 2011 at 9:56 AM, Charlie Sharpsteench...@sharpsteen.net mailto:ch...@sharpsteen.net wrote: On Sat, May 21, 2011 at 9:15 AM, Paolo Cavallinicavall...@faunalia.it mailto:cavall...@faunalia.it wrote: Hi all. I would like to do a poll on qgis-grass usage: which would be the best web tool to use? Probably better not to use qgis or grass pages; does osgeo provides polling facilities? Hi all. OSGeo is currently unable to provide polling facilities. I would like to avoid qgis and grass websites, not to bias the results, and woldn't like too much to use an external service: any better idea? Install Limesurvey on any machine with a webserver... Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSOC Week 3 report : Adding WMS layer support to update WXGUI
Hi all, This is my 3rd week report. Please find it at following link. http://grass.osgeo.org/wiki/WxGUI_WMS_service_rendering_GSoC_2011#Report_.233_9-06-2011 . thanks sudeep ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Principle G3D library question
Dear developer, i have a principal question regarding the coordinate system in the g3d library. I currently review the g3d code and related modules to get a clear picture of the order of the underlying coordinate system. It looks like different approaches have been developed in the modules and the g3d library. This is very confusing. I will try to harmonize this, so here is my question: What kind of coordinate system should be used in the g3d library? From my point of view: the original authors implemented the idea of a cube coordinate system starting in the lower left (SW) corner. This is the common cube coordinate system used in a wide range of software. BUT this coordinate system uses a different row order than the raster coordinate system which start in the upper left corner. Later development of the g3d library tried to establish the upper left corner as origin, but this messed up the code base and result in confusion about the correct coordinate transformation and row ordering. I currently try to reestablish the lower left (SW) corner approach using the common x, y, z cube coordinate system. The code works fine and many tests have been implemented to assure correct behavior. BUT the result is that volume maps created with several modules before these changes have now flipped rows. AND the g3d cube coordinate system is not row compatible with the raster coordinate system. For example: g.region b=0 t=1 s=0 w=0 e=120 n=80 res=10 res3=10 tbres=1 r.mapcalc --o expr=raster_map = row() r3.mapcalc --o expr=volume_map = row() This code will result in raster and volume maps with different row counting. The raster lib counts rows from north to south but the g3d lib counts from south to north. #: r.out.ascii raster_map north: 80 south: 0 east: 120 west: 0 rows: 8 cols: 12 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 #: r3.out.ascii volume_map dp=0 version: grass7 order: nsbt north: 80.00 south: 0.00 east: 120.00 west: 0.00 top: 1.00 bottom: 0.00 rows: 8 cols: 12 levels: 1 8 8 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 Booth modules export the data in the raster coordinate system printing the rows from north to south. What i don't know: Is the row ordering irrelevant for g3d internal value storage, tile storage and tile cache coordinates? So only coordinate transformation functions should take care of correct counting? So all g3d modules can use the raster coordinate system using x, y, and z coordinates and interact with raster modules in the same coordinate system: row == y: Top (z) | | North West | _ _ _ _ _ _ East (x) / Bottom / / South (y) Or does the row ordering affect the internal g3d storage and caching too and should always count from south to north??? So any module which interacts with raster rows need to translate the y coordinate into the correct raster row: row = rows - y - 1? I prefer the last solution (which i currently implement) to avoid potential conflicts with the (by myself not fully understood) storage and tile caching in the g3d library and to have a well understood and consistent behavior: Top (z) North (y) | / | / | / West | / _ _ _ _ _ _ East (x) Bottom South Maybe i am to blind to see the obvious? Any hints or suggestions are very welcome. Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC Week 4 Report: Graphical User Interface for the hydrological tools r.stream* in GRASS GIS
Hi All, this is to inform you about progress in my soc project. I spent most of my time studying the reference book of wxpython [0] and reproducing exercises. With Jarek, we completely re-designed the GUI, details here [1]. Any comment welcome. Regards, madi [0] http://wiki.wxpython.org/wxPythonInAction [1] http://grass.osgeo.org/wiki/Wx.stream_GSoC_2011#Bulletin_Board -- Eng. Margherita Di Leo Ph.D. Candidate Methods and Technologies for Environmental Monitoring Department of Environmental Engineering and Physics (DIFA) University of Basilicata Campus Macchia Romana 85100 - Potenza Italy Office: +39-0971205360 Web page: http://www.geofemengineering.it/GeofemEngineering/MargheritaDiLeo.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Principle G3D library question
Soeren Gebbert wrote: What kind of coordinate system should be used in the g3d library? Make it match the 2d raster library. Row zero should be north; in the library, in the modules, in the file format, and in terms of externally-visible behaviour. E.g. this: r3.mapcalc --o expr=volume_map = row() #: r3.out.ascii volume_map dp=0 8 8 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 shouldn't happen. Modules should scan from north to south, i.e. increasing row numbers. Don't worry too much about compatibility; for 7.0, sanity comes first. However: if the existing file format has row zero at the southern edge, then we should to be able to distinguish the new format from the old, and the library should be able to (transparently) read either (it doesn't necessarily need to be able to write the old format). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: testing in 6.5 before backporting to 6.4
The lack of manpower makes it even more important that all developers test any changes before committing--including backporting. I agree with Glynn that moving all dev work to 7 would simplify things. But it is also important that all developers only commit code that passes a WFM (works for me) validation test. This will catch errors and typos that are easy to fix by the coder at the time of submitting but which are very difficult to track down by someone else later. Only code that the developer can be sure works on his/her local machine should be committed. This kind of test is simple enough to do. If doing a WFM validation on code changes seems to take too much time, not doing it eats up much, much more of time in the rest of the dev and user community. Even with a WFM test, there will always be the possibility that a code change can cause unforeseen problems in other parts of the code base or may not work on another platform. These are problematic enough to identify and debug without having to also deal with errors that should have been caught by the developer with a minimum of checking. We simply don't have the manpower for the hours needed to debug simple errors that should have been caught at the time of committing. This should apply to the dev branch as well as the release branch for a couple of reasons. First, many people use the dev branch on a regular basis. Making a change that breaks a vital function by not testing before committing, impacts the work of many people. Yes there is a risk to using a dev version, but we also should follow practices that attempt to limit as much as possible introducing easily avoidable bugs into a program that is used by so many people globally. Secondly, if all code has at least passed a WFM test, then bugs that are encountered in a dev branch are easier to track down. Along the same lines, I don't think that developers should be committing 'unfinished' code that knowingly does not work but is linked to an interface element. When a user encounters a button or pull-down that does nothing, does something incorrectly, or crashes a module it is very frustrating. The user does not know if it is a bug, a platform issue, or a problem with their own system. This starts a chain of emails and tests in the user and dev community to try and solve the issue. When this is done intentionally, it needlessly eats into the very limited developer resources. Sometimes there are good reasons why it is necessary to commit unfinished code; in such cases it should be well-commented as such (so that others can help complete it if necessary or at least avoid duplication) and there should be no associated interface element that could confuse and frustrate users. It is not enough to put in the manual that x function does not yet work. Just don't add the button for x function to the interface in the first place. Again, this is quite easy to do for GRASS development. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jun 15, 2011, at 9:00 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Wed, 15 Jun 2011 08:51:57 +0200 From: Markus Metz markus.metz.gisw...@googlemail.com Subject: Re: [GRASS-dev] Re: testing in 6.5 before backporting to 6.4 To: Martin Landa landa.mar...@gmail.com Cc: Helena Mitasova hmit...@ncsu.edu, grass-dev grass-dev@lists.osgeo.org Message-ID: banlktin8zpox8mim6fgdeg0guvuoedd...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 5:35 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2011/6/14 Markus Metz markus.metz.gisw...@googlemail.com: A number of changes to 6.5 and 7.0 went in untested, which is IMHO not a good idea, but being development branches, maybe sometimes excusable. Any changes to the release branch should however be tested before submitted. For most changes, the kind of test is pretty much straightforward, and, if omitted and the change introduces a bug, places a burden on users and other developers to figure out what went wrong and why, wasting other people's time and leaving a not so good impression of a releasebranch. I agree, the real problem is the manpower which we have, or better to say we don't have. Taking special care about three branches - trunk (development), devbr6 (test-bed) and relbr64 (only tested commits) is too much for us. With current manpower and our requirements, we could end up with frozen relbr64 for years. Other issue is G7, when it could be released? One year, two years? At the end the situation forces us to keep relbr64 alive, not only
Re: [GRASS-dev] Principle G3D library question
Hello Glynn, 2011/6/17 Glynn Clements gl...@gclements.plus.com: Soeren Gebbert wrote: What kind of coordinate system should be used in the g3d library? Make it match the 2d raster library. Row zero should be north; in the library, in the modules, in the file format, and in terms of externally-visible behaviour. E.g. this: Well you just destroyed my dreams to finish the g3d library and related modules next week. :) I will try to implement the addressing to match 2d raster library ... many test have to be rewritten and validated. Don't worry too much about compatibility; for 7.0, sanity comes first. Ok. However: if the existing file format has row zero at the southern edge, then we should to be able to distinguish the new format from the old, and the library should be able to (transparently) read either (it doesn't necessarily need to be able to write the old format). The problem is that i currently not completely understand the internal tile caching algorithm. I will need more time to understand it in more detail. Best regards Soeren -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Weekly reports #3 wxNviz
Hi, 1) What do I have completed this week? This week I have been studying for my bachelor final exams which are coming soon, so I had no time for wxNviz. 2) What am I going to achieve for next week? I would like to start working on thematic points. The problem is that this functionality disappeared from nviz in GRASS 6.5 and I am not sure why. I will consult this problem with my mentor but it can turn out to be bigger problem than I expected, so maybe I'll postpone it. There is lot of other work to do. 3) Is there any blocking issue? No Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: testing in 6.5 before backporting to 6.4
Hi all, 2011/6/17 Michael Barton michael.bar...@asu.edu: The lack of manpower makes it even more important that all developers test any changes before committing--including backporting. I guess there is no one who is against testing. The subjective point of view is how much the committed changes are tested. It depends on the contributor, what he/she is committing (core libs, modules, GUI), release life cycle (speaking about stable releases), etc. There is no measurement, I believe everyone is going her/his best. Even someone can have different impression. The important issue is to have working test suites (modules - thanks Soeren for good work, GUI, etc). Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: testing in 6.5 before backporting to 6.4
No disagreement from me on this. MIchael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jun 17, 2011, at 1:27 PM, Martin Landa wrote: Hi all, 2011/6/17 Michael Barton michael.bar...@asu.edu: The lack of manpower makes it even more important that all developers test any changes before committing--including backporting. I guess there is no one who is against testing. The subjective point of view is how much the committed changes are tested. It depends on the contributor, what he/she is committing (core libs, modules, GUI), release life cycle (speaking about stable releases), etc. There is no measurement, I believe everyone is going her/his best. Even someone can have different impression. The important issue is to have working test suites (modules - thanks Soeren for good work, GUI, etc). Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Test suite for GRASS - proposal, discussion welcome
... Ugh; v.random should have a seed= option (or something) to allow repeatability. Or at least an option to disable seeding with the PID. The seed option for v.random is now available in r46730 including tests. Cheers Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Week 3 report : Adding WMS layer support to update WXGUI
Sudeep Singh wrote: Hi all, This is my 3rd week report. Please find it at following link. http://grass.osgeo.org/wiki/WxGUI_WMS_service_rendering_GSoC_2011#Report_.233_9-06-2011. thanks Hi Sudeep, as you get more into the coding of the WMS parts, I guess you have seen the specification docs for it: http://www.opengeospatial.org/specs/?page=specs http://www.opengeospatial.org/standards/wms [hmrf, the spec now seems to live behind some legalese-click- through. I have an old copy which did not require that, if you don't like to agree to those things] see also links at http://live.osgeo.org/en/standards/wms_overview.html the QGIS and GDAL implementations are probably easier examples, but see also the old scripts/r.in.wms/ in the GRASS source code. (I would not suggest to use that as a model for your work, the design is a bit convoluted) Maybe the python version of r.in.wms in grass7 source code is not as complicated? best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
