Re: [GRASS-dev] polygon boundaries not showing
Hi, 2014-03-05 15:28 GMT+01:00 Paulo van Breugel p.vanbreu...@gmail.com: In GRASS 7, rev 59197 (running on Ubuntu 13.10 64bits) the polygon boundaries are not showing. Or more correctly, they do show as very thin whitish lines, but line width and colour cannot be changed. This is if cairo is used for rendering. With png rendering, the polygons are not shown at al. Line vectors do show normally. you need to enter `d.vect type=area,boundary`. I added 'boundary' to default answer in r59208. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] polygon boundaries not showing
I really thought I checked that, but apparently not :-/ ... (just for clarity, in the gui, the boundary feature type should be enabled). But it is good if this is enabled by default (as it always has been as far as I am aware when opening a vector layer in the GUI), thanks for adding that back. Cheers, Paulo On Fri 07 Mar 2014 10:12:00 AM CET, Martin Landa wrote: Hi, 2014-03-05 15:28 GMT+01:00 Paulo van Breugel p.vanbreu...@gmail.com: In GRASS 7, rev 59197 (running on Ubuntu 13.10 64bits) the polygon boundaries are not showing. Or more correctly, they do show as very thin whitish lines, but line width and colour cannot be changed. This is if cairo is used for rendering. With png rendering, the polygons are not shown at al. Line vectors do show normally. you need to enter `d.vect type=area,boundary`. I added 'boundary' to default answer in r59208. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Rashad M wrote: I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. None of this is an issue for normal use, as exploiting GRASS modules doesn't gain a user any access which they don't already have. But for a web application, allowing a user to run GRASS modules with arbitrary inputs amounts to giving them shell access. You might even want to create an actual Unix account for each user, so that any failures regarding input sanitisation are contained. However, this would require something like suExec or servlets. -- 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] i.atcorr returns nan for Landsat 5 TM bands 1 and 2, and also for RapidEye bands 4 and 5
Dear Grass developers, In a previous message I mentioned that the i.atcorr module returns nan values for Landsat 5 TM bands 1 and 2. Today I was processing some RapidEye images and found out that i.atcorr fails to process bands 4 and 5. Notice that when I processed this bands as if they were band 1, i.atcorr returned the expected result. This means that there is nothing wrong with the image files. I hope that the Fortran source code that I shared with you has the answers to solve this issue. Regards, Alessandro On wo, 2014-03-05 at 11:32 +0100, Markus Neteler wrote: On Thu, Feb 27, 2014 at 8:40 PM, Alessandro Samuel Rosa alessandrosam...@yahoo.com.br wrote: ... I also tried contacting Mauro Antunes, the author of the original code in Fortran. He was my teacher, so I have a close relation with him. I asked him if he was interested in taking a look at the C++ code implemented in GRASS, but he is not willing to do it. He has been working on the Fortran code during the last years and provided me with a copy. Using his Fortran code and the same input file that I used for i.atcorr gave the expected results. Would the Fortran code author make his latest version available? Then we might be able to compare the implementations. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Vaclav Petras wrote: Second, if we would decide to go the way of the full GUI (which resembles current wxGUI), wouldn't be better to use something like GTK+ GDK Broadway (1) to just reuse the desktop GUI on web, Broadway is probably far too heavyweight. It's basically a remote desktop approach (the X server runs on the client, but you still have a persistent GUI application for each user running on the server). Also, it behaves like a desktop application which is exported to a web browser, not like a web application. The end result is almost identical to using a desktop application via ssh with X forwarding; if there's any advantage to Broadway, it's that it simplifies the connection setup. Basically, it's a question of thin client (Broadway, ssh -X, VNC, etc) versus thick client (web browser). Both have their pros and cons, but a thin-client solution isn't really worthy of a GSoC project IMHO (thin client approaches typically target an entire desktop environment rather than specific applications). -- 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] GSoC 2014: GRAS GIS Web UI
Hi Glynn. On Fri, Mar 7, 2014 at 5:14 PM, Glynn Clements gl...@gclements.plus.comwrote: Rashad M wrote: I would like to check with grass-devs about the possibility of having a web version of GRASS GIS as a part of SoC 2014. I had done some behind the scenes work for web version using C++ web toolkit Wt[1]. This involves running a grass modules online just like you do on Desktop with a UI that resembles that of wxGUI. I had been in touch with one of my juniors in my lab and he is interested to work on it. I could mentor this project as I had experience with Wt, GRASS and GSoC. I hope this web version will be very useful in both users and developers. Comments and suggestions are most welcomed. My main concern would be security. You will need to thoroughly sanitise all inputs. You cannot rely upon GRASS modules to do this, as e.g. most string handling uses fixed-size buffers, so you need to explicitly limit the length of any arguments to avoid the possibility of buffer overruns. I am not clear with this. maybe security and web apps are creating me a confusion. None of this is an issue for normal use, as exploiting GRASS modules doesn't gain a user any access which they don't already have. But for a web application, allowing a user to run GRASS modules with arbitrary inputs amounts to giving them shell access. Regarding shell accees we are thinking IPython. and massimo had experience in using with GRASS. We are exploring its integration with Wt You might even want to create an actual Unix account for each user, so that any failures regarding input sanitisation are contained. However, this would require something like suExec or servlets. I thought of having a user account setup and the shell on web ui won't allow to navigate around any folder -- Glynn Clements gl...@gclements.plus.com -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Stefan, I can try to answer here, On Mar 7, 2014, at 2:25 AM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Rashad and Vaclav, As mentioned, I really like the idea of a web-gui. Yet, at the end it will compete with VNC / Cygwin-X (at least in our setting). And I am afraid if it does not offer the same (or at least comparable functionality) most of my colleagues will stick to the former solutions. Things which would be high on my personal priority list would be: - A commandline interface (and possibly also a python console) in order to be able to paste code This part is satisfied by the IPython Notebook interface. the ipython notebook App (is highly customizable) and offer what you are asking, see here for very basic example [1] usage with grass. the user can have access to both ‘python grass interface’ as well as ‘standard grass command line’ and any other tool is available on the user $PATH (just add the “!” prefix at each command, or %%bash” on top of each cell ) Note that the IPython notebook is in active development and tons of new feature are coming out soon with the 2.0 release that implement api for complex widget (python—Js) to interact with the IPython kernel using JS widgets. .. read below about security. - Handling of user logins for accessing other ressources e.g in the home directory WT has it’s auth framework for a basic login, so sure this is possible to implement and the web framework is here to support us, but keep in mind that this is a GSOC project with limited resources so i don’t think we are going to implement an full “user workspace” with filesystem navigation and feature like save/load workspace etc (it is possible of course but it will require some work, means you’ll have to wait) Another interesting question would be probably how users can get results to their local machines, both regarding map data (e.g. r.out.gdal) and text output (e.g. from r.stats)… Is there a chance for fetching output through the web-gui or would users have to connect to the server e.g. using FTP or fileshares e.g. in a company network? the adoption of an IPython notebook as shell will provide a server app with “limited” file system navigation and ability to download file. # note: This could also be done irrespective of IPython I personally use the apache web directory to download my products. r.out.gdal … … output=/var/www/username/output where “/var/www/username/output” is reader from a configurable option for each user But of course, a research company network is only one use-case for a web-gui for GRASS… Maybe you ask on the user-list how other users would like to use a web-gui? That could help identifying priorities in the development process (e.g. regarding the possible data-license or security problems). The main security risk as highlighted by Glynn is in enabling the shell access trough the web, and that’s my concern too. A resonable option can be to enabled/disabled shell avaibility based on a configurable option and IMHO such feature should be enabled only to a sub-set of trusted users. In Rstudio the multiuser interface is based on PAM auth method and each user has his own ‘home’ server side Means that each user is a unix user on that machine. (also here the user as full access on its home, so this kind of approach is dedicated to trusted users only .. is not intended to be a web app available for anyone on the web .. will not be a forum or wikipedia but of course is intended to be an app for working group of trusted people) (there are exceptions**) In IPython the dev team will work on this direction in the next release 3.0. (work will strut in july after release the 2.0) An other extra layer of security can be to have the “shell feature” (that means IPython notebook) from inside a chroot jail on the a host machine. My thought is that enabling the shell will be a cool addition but it is an hard/hot topic and deserve some discussion here. For a GSOC idea already have most of all the gui feature available in a web app (without shell access) will end in a great and useful app. Of course the design of the app will take into the account the possibility to add shell access, but we can think about its implementation in a late stage of the project. The answer to that will come along the line following the future development of the IPython notebook multiuser interface. **There is people (see here [2] [3] [4] ) that has already working example on how to “jail” in a sandbox the ipython environment perhaps they can be useful source for ideas on how to implement this in a safe way. [1] http://nbviewer.ipython.org/gist/epifanio/9409749 [2] http://www.python.org/ (there is an interactive shell based on ipython) [3] https://cloud.sagemath.com/ [4] https://github.com/liyanage/ipython-notebook/wiki as Vaclav suggestion (thanks to start the wiki page about
Re: [GRASS-dev] [GRASS GIS] #2210: unable to start GRASS GIS 7
#2210: unable to start GRASS GIS 7
+---
Reporter: turek | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Keywords: |Platform: Linux
Cpu: x86-64 |
+---
Comment(by turek):
Hi,
locale outside GRASS session:
{{{
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
}}}
locale inside GRASS session:
{{{
LANG=None
LANGUAGE=None
LC_CTYPE=C
LC_NUMERIC=C
LC_TIME=C
LC_COLLATE=C
LC_MONETARY=C
LC_MESSAGES=C
LC_PAPER=C
LC_NAME=C
LC_ADDRESS=C
LC_TELEPHONE=C
LC_MEASUREMENT=C
LC_IDENTIFICATION=C
LC_ALL=
}}}
locale -a:
{{{
C
C.UTF-8
POSIX
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
}}}
grep language ~/.grass7/wx:
{{{
language;locale;lc_all;None
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2210#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
On Fri, Mar 7, 2014 at 12:23 PM, epi massimodisa...@gmail.com wrote: as Vaclav suggestion (thanks to start the wiki page about that!), should we put all the info on the wiki and extend the discussion to the user list as well ? My idea is that mailing list is for discussion while wiki is better for preserving results of the discussion and as a overview for the people not involved in the dicussion from the beginning. Speaking about https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS For the GSoC idea itself, it should be in the same form as other ideas here: https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS grass-user would be best for getting requirements, such as I want what ArcGIS Online is doing and finding out what does this actually means. And about the other things, I really cannot elaborate on this (no knowledge, no time) but when we are speaking about jails, virtual session or whatever for Wt-based and IPython-Notebook-based web GUI, wouldn't that be the same for Broadway-based GUI? I would guess that rollapp.com is doing something similar. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
