Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

[Blumentrath, Stefan]

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

-  Handling of user logins for accessing other ressources e.g in the 
home directory

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?

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).

Best regards,
Stefan


From: Rashad M [mailto:mohammedrasha...@gmail.com]
Sent: 6. mars 2014 21:32
To: Vaclav Petras
Cc: epi; Blumentrath, Stefan; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Hi Vaclav,

I think that the web UI has to be based on the GRASS library and has to not 
depend on WxWidgets or any other Desktop gui toolkit like JavaFX. g.parser is 
enough to describe the modules interface and can be used to automatize the 
build of the module form for any modules. I got your idea of running the same 
on desktop, web, embedded platforms which is theoretically possible but the run 
into deadend from time to timeas they are started for desktop application.

Qt has webkit interface, like you said for JavaFX ( i dont know much about the 
java). The philosophy of a desktop gui toolkit is entirely different from a web 
application ui. For example message passing or Qt signals/slots can't be used 
directly. Infact these people have a different implementation and 
interpretation of signal and slot when used in web.
It is because people had written QtWebkit, Broadway with the same idea in mind 
as you, now it possible to run these. But they can't used in a many of 
application sucessfully. For example, rendering a map on Qt and web browser 
cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for vector 
data for this reason. We can't use the everywhere used GDAL for web easily. 
Boradway or JavaFX and other friends is very much feasible for some projects 
but not all.

For this idea i envision the web gui app based on :
- mapset-location wizard
- map canvas
- toolbar with:
  pan, query
  zoom in/out/bbox to-layer to-region
- menu bar with same layout of grass desktop

Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal with 
your data. of course you can. None will fix the data used by web application 
and you could just give a try without evening compiling etc.. (these are some 
view on webgrass we both saying).

Regarding the reuse of code. I am planning to use python bindings for wt and 
core classes will be reused. for parsing description file and the instead of 
sending boradway or JavaFX etc.. I will use directly a jquery dialog, html 
button, text and will have direct access to js code such that if i need to 
render a grass vector i could do it in openlayers or using wt itself to read 
the grass vector directly using gdal and draw polygons on a HTML5Canvas, SVG, 
etc..  I could use render module of grass ui to render a ppm or use pygrass 
numpy to read grass and render as before.

For  Sharing data is one thing i need to think about and having a "shared 
location" like share folders could be explored.

For GRASS 3D. its not possible to use opengl on web. you must use webgl. and I 
dont think the previous GTK broadway could use opengl.

Also GRASS is famous for large data processing and i was exploring that too.  
So the webUI must be behave differently when dealing with large data and should 
allow you to queue any process. Just thinking for now.

And the whole idea of having webgrass will help users and developers as stefan 
was mentioning to run them on university or a company network without caring of 
operating system and Wt support Windows, Linux, OS X among other embedded 
platforms.

The demo video of android was from 2012 and since then Wt improved Android 
support. In 2012 there was not automated apk. But when I checked in 2013 wt 
build system if configured for android will generate an apk for your 
application.

I would ask you to think webUI as a wrapper like python, java etc.. You can 
have two gui for GRASS GIS. Remember about grass6.3 and earlier version which 
uses tcl/tk and was not used now because lack of support and or func

Re: [GRASS-dev] Fwd: Android Compilation

[Hamish]

Vaclav wrote:

> But this is probably not important because there is no
> way to wxPython on Andriod. At least quick google search
> said so. So, perhaps GUI is the biggest challange for
> Android (which could be to certain extent solved by QGIS
> for Android bundled with GRASS for Android).

one question I have a hard time answering is when I'd actually
want to use GRASS from an android device? Chromebook makes
a bit more sense since it is a bit more like a workstation
experience.

The main use-case I could think of was for data entry, or to aid with data 
accounting in an archeology grid.


http://grasswiki.osgeo.org/wiki/Android#Device_used_as_a_recording_slate_in_the_field

But if the UI must be written from scratch, what do we offer (as a processing 
and analysis engine) that gvSIG-mobile, QGIS-android, and OSM walking papers 
apps (as data entry, viewing, and nav apps) don't already do?

The other use I can think of is if the ipython-notebook or whatever web UI to 
GRASS could launch jobs remotely on a server, like a light (or not so light) 
grid-engine or maui/torque cluster job submission queue.

fwiw my lightweight web-grass solution has always been to ssh/putty in to the 
server into a GNU Screen session, then have GRASS_PNGFILE=/var/www/map.png, 
then just hit refresh in the web browser. works great for command line grass 
junkies.

some ideas to think about where the end goal is and how/why that way would be 
useful for end users.



regards,

Hamish

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Website  | Version:  unspecified  
Resolution:  fixed|Keywords:  html man pages download  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by hamish):

 > can build on other existing FOSS unix man page and perl doc apps

 find them on f-droid.org

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Website  | Version:  unspecified  
Resolution:  fixed|Keywords:  html man pages download  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by hamish):

 see also idea to make a searchable man page android app (can build on
 other existing FOSS unix man page and perl doc apps), and/or using Calibre
 to convert HTML -> free cross-platform eBook.  Calibre needs a little bit
 of guidance to get the chapters right, but for searchable reference manual
 it is more important that the index works than the modules browse in
 order. I tried a quick test-case with the Valgrind docs, without structure
 guidance the chapter and section hierarchy was a big out of order mess,
 but it turned out not to be a big deal since the all the internal links
 worked and I wasn't reading it beginning to end like a story book.

 http://grasswiki.osgeo.org/wiki/Android#Device_used_as_a_reference_guide

 I'm not sure how others work, but for me this is most useful when working
 remotely or on a laptop; at my desk usually it's easier to have the docs
 open side by side in a big monitor or on a second screen/workspace.

 The programmer's manual would be good to eBook-ize or make into an android
 app too. Note HTML is Calibre's preferred input markup language, and
 luckily most of the hard work of standardizing the section h2,h3s and css
 styles is already done.


 ideas,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
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]

Rashad, please basic description of your idea to

https://trac.osgeo.org/grass/wiki/GSoC/2014#Web-basedGUIforGRASSGIS

I also created a page to have ideas mentioned here stored in systematic way:

https://trac.osgeo.org/grass/wiki/GSoC/2014/WebGRASS

I will have limited possibilities to work on it in next days, so feel edit
or put some facts directly there. I hope that others will also join this
discussion which goes far behind the GSoC.

Vaclav


On Thu, Mar 6, 2014 at 3:32 PM, Rashad M  wrote:

> Hi Vaclav,
>
> I think that the web UI has to be based on the GRASS library and has to
> not depend on WxWidgets or any other Desktop gui toolkit like JavaFX.
> g.parser is enough to describe the modules interface and can be used to
> automatize the build of the module form for any modules. I got your idea of
> running the same on desktop, web, embedded platforms which is theoretically
> possible but the run into deadend from time to timeas they are started for
> desktop application.
>
> Qt has webkit interface, like you said for JavaFX ( i dont know much about
> the java). The philosophy of a desktop gui toolkit is entirely different
> from a web application ui. For example message passing or Qt signals/slots
> can't be used directly. Infact these people have a different implementation
> and interpretation of signal and slot when used in web.
> It is because people had written QtWebkit, Broadway with the same idea in
> mind as you, now it possible to run these. But they can't used in a many of
> application sucessfully. For example, rendering a map on Qt and web browser
> cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for
> vector data for this reason. We can't use the everywhere used GDAL for web
> easily. Boradway or JavaFX and other friends is very much feasible for some
> projects but not all.
>
> For this idea i envision the web gui app based on :
> - mapset-location wizard
> - map canvas
> - toolbar with:
>   pan, query
>   zoom in/out/bbox to-layer to-region
> - menu bar with same layout of grass desktop
>
> Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal
> with your data. of course you can. None will fix the data used by web
> application and you could just give a try without evening compiling etc..
> (these are some view on webgrass we both saying).
>
> Regarding the reuse of code. I am planning to use python bindings for wt
> and core classes will be reused. for parsing description file and the
> instead of sending boradway or JavaFX etc.. I will use directly a jquery
> dialog, html button, text and will have direct access to js code such that
> if i need to render a grass vector i could do it in openlayers or using wt
> itself to read the grass vector directly using gdal and draw polygons on a
> HTML5Canvas, SVG, etc..  I could use render module of grass ui to render a
> ppm or use pygrass numpy to read grass and render as before.
>
> For  Sharing data is one thing i need to think about and having a "shared
> location" like share folders could be explored.
>
> For GRASS 3D. its not possible to use opengl on web. you must use webgl.
> and I dont think the previous GTK broadway could use opengl.
>
> Also GRASS is famous for large data processing and i was exploring that
> too.  So the webUI must be behave differently when dealing with large data
> and should allow you to queue any process. Just thinking for now.
>
> And the whole idea of having webgrass will help users and developers as
> stefan was mentioning to run them on university or a company network
> without caring of operating system and Wt support Windows, Linux, OS X
> among other embedded platforms.
>
> The demo video of android was from 2012 and since then Wt improved Android
> support. In 2012 there was not automated apk. But when I checked in 2013 wt
> build system if configured for android will generate an apk for your
> application.
>
> I would ask you to think webUI as a wrapper like python, java etc.. You
> can have two gui for GRASS GIS. Remember about grass6.3 and earlier version
> which uses tcl/tk and was not used now because lack of support and or
> functionality and I am never saying Wxwidgets is not lacking a
> functionality for a desktop platform but on web perspective i think it is.
> Am I right?
>
>
> On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras wrote:
>
>>
>> On Thu, Mar 6, 2014 at 1:38 PM, epi  wrote:
>>
>>> At the moment i’m having so much fun with IPython Notebook
>>> that is my actually my grass interface ... in this idea i can see a
>>> little room for it too :)
>>>
>>
>> IPython Notebook would be the clear choice of Python command console for
>> a web GUI written from scratch. Similarly, OpenLayers or Leaflet could
>> become a web GRASS GUI map display. The downside of things such as GTK+
>> Broadway is that these solutions are simply not available. Although they
>> can be always used inside some web view. With this we are getting to the
>> other option I was mentioning: 

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Website  | Version:  unspecified  
Resolution:  fixed|Keywords:  html man pages download  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by neteler):

 I have revised it, see

 http://grass.osgeo.org/documentation/manuals/

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Website  | Version:  unspecified  
Resolution:  fixed|Keywords:  html man pages download  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-

Comment(by wenzeslaus):

 Replying to [comment:2 neteler]:
 > Replying to [comment:1 neteler]:
 > > Done for GRASS 7: http://grass.osgeo.org/documentation/manuals/
 > >
 > > Will asap add the other packages to the weekly cronjobs.
 >
 > Done (also 6.4 and 6.5). Closing.

 {{{
 GRASS 7.0 (development) HTML manual pages (alternative: download ZIP),
 updated weekly)
 }}}

 syntax error unmatched `)`

 I would say that

 {{{
 GRASS 7.0 (development) HTML manual pages (download ZIP, updated weekly)
 }}}

 is enough.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #822: enhance "Save display to graphic file" in wxGUI

[GRASS GIS]

#822: enhance "Save display to graphic file" in wxGUI
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  normal   |   Milestone:  7.0.0  
  
Component:  wxGUI| Version:  svn-trunk  
  
 Keywords:  d.out.file, save image, map display  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by cmbarton):

 'Save display' or 'save window' is better, at least in English.

 'Save image' could be confusing (what image?) and possibly misleading
 (save the GIS/image file?). What is being done is that what you see in the
 display window (technically a graphic canvas) is being written to a
 graphic format file of your choice.

 In GRASS, most of what goes on is not a display. You can display selected
 maps in a window (graphic canvas), of course. Also, this function is
 called from a button on the top of that display window. so I don't think
 that display is overly generic or confusing in this context. 'Save
 Display' is probably the most accurate and descriptive with the fewest
 words.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2210: unable to start GRASS GIS 7

[GRASS GIS]

#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 marisn):

 Please, provide output of following commands:
 {{{
 locale (outside of GRASS and inside GRASS session)
 locale -a
 grep language ~/.grass7/wx
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
--+-
  Reporter:  mlennert |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  Website  | Version:  unspecified  
Resolution:  fixed|Keywords:  html man pages download  
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by neteler):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:1 neteler]:
 > Done for GRASS 7: http://grass.osgeo.org/documentation/manuals/
 >
 > Will asap add the other packages to the weekly cronjobs.

 Done (also 6.4 and 6.5). Closing.

-- 
Ticket URL: 
GRASS GIS 

___
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]

Hi Vaclav,

I think that the web UI has to be based on the GRASS library and has to not
depend on WxWidgets or any other Desktop gui toolkit like JavaFX. g.parser
is enough to describe the modules interface and can be used to automatize
the build of the module form for any modules. I got your idea of running
the same on desktop, web, embedded platforms which is theoretically
possible but the run into deadend from time to timeas they are started for
desktop application.

Qt has webkit interface, like you said for JavaFX ( i dont know much about
the java). The philosophy of a desktop gui toolkit is entirely different
from a web application ui. For example message passing or Qt signals/slots
can't be used directly. Infact these people have a different implementation
and interpretation of signal and slot when used in web.
It is because people had written QtWebkit, Broadway with the same idea in
mind as you, now it possible to run these. But they can't used in a many of
application sucessfully. For example, rendering a map on Qt and web browser
cant be same. We have WMS, WMTS etc.. for rendering imagery and WFS for
vector data for this reason. We can't use the everywhere used GDAL for web
easily. Boradway or JavaFX and other friends is very much feasible for some
projects but not all.

For this idea i envision the web gui app based on :
- mapset-location wizard
- map canvas
- toolbar with:
  pan, query
  zoom in/out/bbox to-layer to-region
- menu bar with same layout of grass desktop

Here you can use GDAL, you are not obliged to use WPS, WMS, WFS to deal
with your data. of course you can. None will fix the data used by web
application and you could just give a try without evening compiling etc..
(these are some view on webgrass we both saying).

Regarding the reuse of code. I am planning to use python bindings for wt
and core classes will be reused. for parsing description file and the
instead of sending boradway or JavaFX etc.. I will use directly a jquery
dialog, html button, text and will have direct access to js code such that
if i need to render a grass vector i could do it in openlayers or using wt
itself to read the grass vector directly using gdal and draw polygons on a
HTML5Canvas, SVG, etc..  I could use render module of grass ui to render a
ppm or use pygrass numpy to read grass and render as before.

For  Sharing data is one thing i need to think about and having a "shared
location" like share folders could be explored.

For GRASS 3D. its not possible to use opengl on web. you must use webgl.
and I dont think the previous GTK broadway could use opengl.

Also GRASS is famous for large data processing and i was exploring that
too.  So the webUI must be behave differently when dealing with large data
and should allow you to queue any process. Just thinking for now.

And the whole idea of having webgrass will help users and developers as
stefan was mentioning to run them on university or a company network
without caring of operating system and Wt support Windows, Linux, OS X
among other embedded platforms.

The demo video of android was from 2012 and since then Wt improved Android
support. In 2012 there was not automated apk. But when I checked in 2013 wt
build system if configured for android will generate an apk for your
application.

I would ask you to think webUI as a wrapper like python, java etc.. You can
have two gui for GRASS GIS. Remember about grass6.3 and earlier version
which uses tcl/tk and was not used now because lack of support and or
functionality and I am never saying Wxwidgets is not lacking a
functionality for a desktop platform but on web perspective i think it is.
Am I right?


On Thu, Mar 6, 2014 at 8:42 PM, Vaclav Petras  wrote:

>
> On Thu, Mar 6, 2014 at 1:38 PM, epi  wrote:
>
>> At the moment i'm having so much fun with IPython Notebook
>> that is my actually my grass interface ... in this idea i can see a
>> little room for it too :)
>>
>
> IPython Notebook would be the clear choice of Python command console for a
> web GUI written from scratch. Similarly, OpenLayers or Leaflet could become
> a web GRASS GUI map display. The downside of things such as GTK+ Broadway
> is that these solutions are simply not available. Although they can be
> always used inside some web view. With this we are getting to the other
> option I was mentioning: web-based GUI used in a web view(s) on desktop.
> This would allow us to use all highly interactive Java Script visualization
> libraries on desktop.
>
> http://wxpython.org/Phoenix/docs/html/html2.WebView.html
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #822: enhance "Save display to graphic file" in wxGUI

[GRASS GIS]

#822: enhance "Save display to graphic file" in wxGUI
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  normal   |   Milestone:  7.0.0  
  
Component:  wxGUI| Version:  svn-trunk  
  
 Keywords:  d.out.file, save image, map display  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by wenzeslaus):

 Replying to [comment:11 martinl]:
 > Replying to [comment:10 annakrat]:
 >
 > > > The word "graphic" is very confusing, better to be changed.
 > >
 > > done in r59203
 >
 > Probably "Save display content to image file" would be more informative?

 The one point is that is should be short.

 The other is that it should be easy to understand. "image file" is the
 same as "graphic file" it does not add any information, to which kind of
 file would I want to save an image and what is that image file anyway,
 `.img`? So, to where is clear "file". Alternatively we can leave out the
 whole to part. So, we would get "Save display" (my browser also says only
 "Save page", it is clear that it will be file or files on the disk).

 What to save is more difficult. It is "display", "display content",
 "displayed image", "image", "map"? I'm not sure but one word should be
 enough. Current "display" is pretty common word in GRASS describes
 everything related to displaying maps, so it is OK here I would say. On
 the other hand "display" is strange for everybody else.

 "Save image" could be enough?

-- 
Ticket URL: 
GRASS GIS 

___
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]

On Thu, Mar 6, 2014 at 1:38 PM, epi  wrote:

> At the moment i’m having so much fun with IPython Notebook
> that is my actually my grass interface ... in this idea i can see a little
> room for it too :)
>

IPython Notebook would be the clear choice of Python command console for a
web GUI written from scratch. Similarly, OpenLayers or Leaflet could become
a web GRASS GUI map display. The downside of things such as GTK+ Broadway
is that these solutions are simply not available. Although they can be
always used inside some web view. With this we are getting to the other
option I was mentioning: web-based GUI used in a web view(s) on desktop.
This would allow us to use all highly interactive Java Script visualization
libraries on desktop.

http://wxpython.org/Phoenix/docs/html/html2.WebView.html
___
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]

Hi Stefan.

On Thu, Mar 6, 2014 at 12:45 PM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

>  Hi Rashad and Vaclav,
>
>
>
> If you allow me a user comment:
>

User comments are not only allowed but they are needed.


> The video looks very, very promoising.
>
> In our institution we are running GRASS on an Ubuntu Server which users
> access graphically either through either TightVNC or CYGWin-X.
>

ssh -X, VNC etc. are of course always here, so the question is home much
more we will get from other solutions.


> What I like about the Server solution is the “work where your data is”
> concept (even if server ressources may be smaller when shared by several
> users, compared to modern single user desktop PCs).
>

So, it seems that you want the full fully-featured GUI, not just some basic
one.


> I also perceive GRASS`s  mapset concept as very useful for multi-user
> environment and data sharing (maybe except for the ownership check which
> hampers usage of mapsets by groups of people (I know there are workarounds
> (e.g. goup users as owners or overriding the ownership check in GRASS 7)).
>

This is what I was mentioning in other email. There could be different
requirements on data management, especially sharing, in the online
environment.

>
>
> On the same Server we also have an RStudio-Server running which would be
> comparable to your webGRASS-solution.
>
> Our experience with RStudio Server is very positive, so I would appreciate
> such a solution for GRASS (though TightVNC and CYGWin-X are fine too)…
>

>From quick check RSStudio is written in Java. E.g. the new Java GUI
framework JavaFX allows to create desktop and web (probably client-server)
application at once. Unfortunately, nor wxPython/wxWidgets or Qt (or its
Python friends) does not allow this by themselves. JavaFX is not really an
option for use, however the concept is what I would like to have. The GUI
with the same look and (I believe) the same implementation on all desktops
and also on web.

https://www.rstudio.com/ide/screenshots/ (first four screenshots)

 The main advantage is (from my point of view) that users do not have to
> install additional software…
>

So, web-based solution is necessary for that. Which e.g. kills my
suggestion of wxGUI executing commands on server.

Thanks for your input, if you have more, please do.

Vaclav


>
> Cheers
>
> Stefan
>
>
>
>
>
> *From:* grass-dev-boun...@lists.osgeo.org [mailto:
> grass-dev-boun...@lists.osgeo.org] *On Behalf Of *Rashad M
> *Sent:* 6. mars 2014 18:12
> *To:* Vaclav Petras
> *Cc:* grass-dev@lists.osgeo.org
> *Subject:* Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
>
>
>
> Hi Vaclav,
>
>
>
> On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras 
> wrote:
>
> Hi Rashad,
>
>
>
> web GRASS is certainly something we need and I'm very excited about that.
> But there are several things which should be considered to make this
> project successful.
>
>
>
> First, there is already one (desktop) GUI. Do we want to have (an
> maintain) another GUI? Is there a possibility to share the code between the
> desktop and web GUI?  What about limiting the functionality of the web GUI
> to minimum, so that there will not much code to maintain and (as defined)
> nothing to add?
>
>
>
> This is the rather important part and we do want to reuse the code from
> core classes.
>
>
>
> 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, or to reuse web GUI on desktop
> (some web view or browser with local web pages and processes)? Although
> GTK+ and some wxWidgets applications can run with Broadway backend,
> wxPython, and especially GRASS is still far from running that way. However,
> there are some (perhaps even more interesting) alternatives such as Ulteo
> and noVNC. And I'm wondering what rollapp.com is using.
>
>
>
> I am interested to use Wt, not because of C++ and its recent Python love,
> because the idea of Widget centric, security of Wt apps (very much safe
> than any other web framework), embedded platform support.  and so on. The
> main idea behind the birth of Wt is they want a web application to run on
> Web browser and embedded platforms (Android and others). The code is
> written in python or C++, webserver (Wthttp) renders a bunch of AJAX code
> and compatible with any recent browsers and it takes care of the some
> browser related stuff like special css prop for webkit and mozilla. And of
> course there is no code conversion or generation from a c++ to html/js
> script. Indeed I am allowed to use as much as javascript code. In the demo
> you can see openlayers widget!
>
>
>
> When you write:
>
>
>
> WButton *button = new WButton();
>
>
>
> Wt makes the css for Wbutton which it has and provide a very decent and
> easy access to render it on browsers. I would rather stop here talking
> about Wt before it turn into a name drop of the toolkit which I d

Re: [GRASS-dev] [GRASS GIS] #2211: g.gui.iclass raise a PyAssertionError

[GRASS GIS]

#2211: g.gui.iclass raise a PyAssertionError
--+-
 Reporter:  zarch |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Display   | Version:  svn-trunk
 Keywords:  g.gui.iclass, wxPython 3  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
Changes (by annakrat):

  * keywords:  g.gui.iclass => g.gui.iclass, wxPython 3


Comment:

 I fixed it hopefully in r59207. Please mention next time that you use
 wxPython 3, as a keyword for example.

-- 
Ticket URL: 
GRASS GIS 

___
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]

On Thu, Mar 6, 2014 at 12:12 PM, Rashad M 
 wrote:

> Hi Vaclav,
>
> On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras 
>  wrote:
>
>> Hi Rashad,
>>
> ...

> First, there is already one (desktop) GUI. Do we want to have (an
>> maintain) another GUI? Is there a possibility to share the code between the
>> desktop and web GUI?  What about limiting the functionality of the web GUI
>> to minimum, so that there will not much code to maintain and (as defined)
>> nothing to add?
>>
>
> This is the rather important part and we do want to reuse the code from
> core classes.
>

You need to use Python to really reuse the classes. And do also a large
refactoring of wxGUI code to make them reusable (although some improvements
were already made). How much you can reuse? How much you want to reuse?
This is probably hard to answer, easier might be which functionality do we
want in web GUI? Only modules and map visualization? Or also digitizers,
animations, map swipe, ...?

The code is written in python or C++, webserver (Wthttp) renders a bunch of
> AJAX code and compatible with any recent browsers and it takes care of the
> some browser related stuff like special css prop for webkit and mozilla.
> And of course there is no code conversion or generation from a c++ to
> html/js script.


This is what previously mentioned GTK+ Broadway is doing. I'm not sure how
does this compare to Ulteo and to whatever rollapp.com is using. noVNC is
VNC where client runs in web browser. The advantage of these is that you
don't write any new GUI code.

https://developer.gnome.org/gtk3/stable/gtk-broadway.html
http://blogs.gnome.org/alexl/2012/12/27/broadway-multi-process-suppor/
http://kolyakosenko.wordpress.com/2013/07/18/wxwidgets-2-9-5/
https://www.youtube.com/watch?v=P6lzZpS5M4g

http://en.wikipedia.org/wiki/Ulteo_Open_Virtual_Desktop
http://www.ulteo.com/
http://kanaka.github.io/noVNC/
https://www.youtube.com/watch?v=ZiIxtoHa9bU (rollapp.com)


>> Third, the GUI is not the only part. The GUI is supposed to be a part of
>> some server/cloud infrastructure. You need to upload data, sign in users...
>> And also we are not sure what are the security issues of using GRASS on
>> server with unlimited access (i.e. you can run anything you want as opposed
>> to predefined processes in WPS).
>>
>>
> IIUC, you mean security of the data right?. WebGRASS project is not about
> providing server infrastructure to preserve the data. Of course it wont
> allow to get other users data and in my plan users will have access to
> their own location rather than anyone can use everyone's data. And
> sensitivity of data uploaded is a question and you never publish such kind
> of data under NDA or so in public server right? And you cant access a data
> on server even when you render it on browser screen. That is what
> mapserver, Openlayers and other web map viewer are doing.
>

I though that the goal is to have something like Google Docs but for GIS.
Which could be provided by GRASS community but more importantly, everyone
would be able to setup his or her own server. I'm not concern about license
of data, in terms of security, I'm concern about users accidentally
deleting each other data or somebody running some evil processes on my
server. And in terms of usability, some data upload/download functions are
needed, management, ideally also sharing and perhaps publishing through web
services by forwarding then to some map server.

On Thu, Mar 6, 2014 at 12:12 PM, Rashad M 
 wrote:

> Fifth, the choice of the GUI framework is important. We don't want to
>> tight this to some project which will not be here in few years. Wt has nice
>> examples and your (Rashad's) experience is big plus. But there is many
>> others such as Dabo and some of them might be better for us since they are
>> using Python, so we could share some code with wxGUI. Results on mobile
>> platforms must be evaluated, too.
>>
>>
> There has been a python binding for Wt and myself and massmio had tried
> these successfully. The support for bindings are not much, I would say but
> I had a pretty much idea about how its generated which BTW is not using
> swig and SIP. Regarding mobile platforms I do had a working apk of another
> Wt application for which I got a recording on youtube[1] (offline android).
>  [2] is the web version. The patch required for me was very minimal as Wt
> compiles clean on Android. [1] also used libgdal (Android). This one just
> renders a shapefile and style it without OpenLayers or its friends
>

How much code are these applications? I somewhere accessible? How much
development was in Wt since than? Some improvements, e.g. for Android?


>> And finally, a sustainability of the new web GUI must be considered. What
>> will happen after the GSoC? There already were several GRASS web interfaces
>> starting with GRASSLinks in 1995 and also we have some web sites using
>> GRASS in background but they are not general GRASS GUI (e.g.
>> http://www.gapserve.ncsu.edu/segap/segap/). 

Re: [GRASS-dev] [GRASS GIS] #822: enhance "Save display to graphic file" in wxGUI

[GRASS GIS]

#822: enhance "Save display to graphic file" in wxGUI
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…
  
 Type:  enhancement  |  Status:  new
  
 Priority:  normal   |   Milestone:  7.0.0  
  
Component:  wxGUI| Version:  svn-trunk  
  
 Keywords:  d.out.file, save image, map display  |Platform:  All
  
  Cpu:  All  |  
-+--

Comment(by martinl):

 Replying to [comment:10 annakrat]:

 > > The word "graphic" is very confusing, better to be changed.
 >
 > done in r59203

 Probably "Save display content to image file" would be more informative?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] importing big vector data

[Martin Landa]

Hi all,

2014-03-04 17:13 GMT+01:00 Martin Landa :

[...]

> it fails when trying to allocate about 2GB,
>
> D0/0: 2047 -> 204700
> D0/0: 2048 -> 204800
> Current region rows: 3, cols: 7
> ERROR: G_realloc: unable to allocate 204800 bytes of memory at main.c:101
>
> There is memory available and no limits per process:
>
> $ free -m
>  total   used   free sharedbuffers cached
> Mem: 48395   4587  43808  0   3272361
> -/+ buffers/cache:953  47441
> Swap:47682  0  47682
>
> Trying to investigate more. In any case thanks for testing... Martin

ok, I checked the server again and the mystery is solved. Originally I
checked only

$ uname -m
x86_64

but I missed `dpkg` platform which is strangely 32bit

$ dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_BITS=32

So all binaries are 32bit including self-compiled GRASS. Sorry for
noise! I was using 32bit binaries...

Thanks for all the comments, 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] GSoC 2014: GRAS GIS Web UI

[epi]

Hi Rashad, Vaclav, all


that’s a great idea for a GSOC! and I’m willing to apply as student for it :)

I’m familiar with the Web GRASS prototype as i was a beta-testing during its 
early development.
and i have experience with grass and python development and and with WT and its 
python bindings.

At the moment i’m having so much fun with IPython Notebook
that is my actually my grass interface ... in this idea i can see a little room 
for it too :)

Cheers,

Massimo.


On Mar 6, 2014, at 12:45 PM, Blumentrath, Stefan  
wrote:

> Hi Rashad and Vaclav,
>  
> If you allow me a user comment: The video looks very, very promoising.
> In our institution we are running GRASS on an Ubuntu Server which users 
> access graphically either through either TightVNC or CYGWin-X. What I like 
> about the Server solution is the “work where your data is” concept (even if 
> server ressources may be smaller when shared by several users, compared to 
> modern single user desktop PCs). I also perceive GRASS`s  mapset concept as 
> very useful for multi-user environment and data sharing (maybe except for the 
> ownership check which hampers usage of mapsets by groups of people (I know 
> there are workarounds (e.g. goup users as owners or overriding the ownership 
> check in GRASS 7)).
>  
> On the same Server we also have an RStudio-Server running which would be 
> comparable to your webGRASS-solution.
> Our experience with RStudio Server is very positive, so I would appreciate 
> such a solution for GRASS (though TightVNC and CYGWin-X are fine too)…
> The main advantage is (from my point of view) that users do not have to 
> install additional software…
>  
> Cheers
> Stefan  
>  
>  
> From: grass-dev-boun...@lists.osgeo.org 
> [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad M
> Sent: 6. mars 2014 18:12
> To: Vaclav Petras
> Cc: grass-dev@lists.osgeo.org
> Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
>  
> Hi Vaclav,
>  
> 
> On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras  wrote:
> Hi Rashad,
>  
> web GRASS is certainly something we need and I'm very excited about that. But 
> there are several things which should be considered to make this project 
> successful.
>  
> First, there is already one (desktop) GUI. Do we want to have (an maintain) 
> another GUI? Is there a possibility to share the code between the desktop and 
> web GUI?  What about limiting the functionality of the web GUI to minimum, so 
> that there will not much code to maintain and (as defined) nothing to add?
>  
> This is the rather important part and we do want to reuse the code from core 
> classes. 
>  
> 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, or to reuse web GUI on desktop 
> (some web view or browser with local web pages and processes)? Although GTK+ 
> and some wxWidgets applications can run with Broadway backend, wxPython, and 
> especially GRASS is still far from running that way. However, there are some 
> (perhaps even more interesting) alternatives such as Ulteo and noVNC. And I'm 
> wondering what rollapp.com is using.
>  
> I am interested to use Wt, not because of C++ and its recent Python love, 
> because the idea of Widget centric, security of Wt apps (very much safe than 
> any other web framework), embedded platform support.  and so on. The main 
> idea behind the birth of Wt is they want a web application to run on Web 
> browser and embedded platforms (Android and others). The code is written in 
> python or C++, webserver (Wthttp) renders a bunch of AJAX code and compatible 
> with any recent browsers and it takes care of the some browser related stuff 
> like special css prop for webkit and mozilla. And of course there is no code 
> conversion or generation from a c++ to html/js script. Indeed I am allowed to 
> use as much as javascript code. In the demo you can see openlayers widget!
>  
> When you write:
>  
> WButton *button = new WButton();
>  
> Wt makes the css for Wbutton which it has and provide a very decent and easy 
> access to render it on browsers. I would rather stop here talking about Wt 
> before it turn into a name drop of the toolkit which I dont want to do.
>  
>  
>  
> Third, the GUI is not the only part. The GUI is supposed to be a part of some 
> server/cloud infrastructure. You need to upload data, sign in users... And 
> also we are not sure what are the security issues of using GRASS on server 
> with unlimited access (i.e. you can run anything you want as opposed to 
> predefined processes in WPS).
>  
>  
> IIUC, you mean security of the data right?. WebGRASS project is not about 
> providing server infrastructure to preserve the data. Of course it wont allow 
> to get other users data and in my plan users will have access to their own 
> location rather than anyone can use everyone's data. And sensitivity of data 
> uploaded i

Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

[Blumentrath, Stefan]

Hi Rashad and Vaclav,

If you allow me a user comment: The video looks very, very promoising.
In our institution we are running GRASS on an Ubuntu Server which users access 
graphically either through either TightVNC or CYGWin-X. What I like about the 
Server solution is the "work where your data is" concept (even if server 
ressources may be smaller when shared by several users, compared to modern 
single user desktop PCs). I also perceive GRASS`s  mapset concept as very 
useful for multi-user environment and data sharing (maybe except for the 
ownership check which hampers usage of mapsets by groups of people (I know 
there are workarounds (e.g. goup users as owners or overriding the ownership 
check in GRASS 7)).

On the same Server we also have an RStudio-Server running which would be 
comparable to your webGRASS-solution.
Our experience with RStudio Server is very positive, so I would appreciate such 
a solution for GRASS (though TightVNC and CYGWin-X are fine too)...
The main advantage is (from my point of view) that users do not have to install 
additional software...

Cheers
Stefan


From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad M
Sent: 6. mars 2014 18:12
To: Vaclav Petras
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

Hi Vaclav,

On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras 
mailto:wenzesl...@gmail.com>> wrote:
Hi Rashad,

web GRASS is certainly something we need and I'm very excited about that. But 
there are several things which should be considered to make this project 
successful.

First, there is already one (desktop) GUI. Do we want to have (an maintain) 
another GUI? Is there a possibility to share the code between the desktop and 
web GUI?  What about limiting the functionality of the web GUI to minimum, so 
that there will not much code to maintain and (as defined) nothing to add?

This is the rather important part and we do want to reuse the code from core 
classes.

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, or to reuse web GUI on desktop (some web 
view or browser with local web pages and processes)? Although GTK+ and some 
wxWidgets applications can run with Broadway backend, wxPython, and especially 
GRASS is still far from running that way. However, there are some (perhaps even 
more interesting) alternatives such as Ulteo and noVNC. And I'm wondering what 
rollapp.com is using.

I am interested to use Wt, not because of C++ and its recent Python love, 
because the idea of Widget centric, security of Wt apps (very much safe than 
any other web framework), embedded platform support.  and so on. The main idea 
behind the birth of Wt is they want a web application to run on Web browser and 
embedded platforms (Android and others). The code is written in python or C++, 
webserver (Wthttp) renders a bunch of AJAX code and compatible with any recent 
browsers and it takes care of the some browser related stuff like special css 
prop for webkit and mozilla. And of course there is no code conversion or 
generation from a c++ to html/js script. Indeed I am allowed to use as much as 
javascript code. In the demo you can see openlayers widget!

When you write:

WButton *button = new WButton();

Wt makes the css for Wbutton which it has and provide a very decent and easy 
access to render it on browsers. I would rather stop here talking about Wt 
before it turn into a name drop of the toolkit which I dont want to do.



Third, the GUI is not the only part. The GUI is supposed to be a part of some 
server/cloud infrastructure. You need to upload data, sign in users... And also 
we are not sure what are the security issues of using GRASS on server with 
unlimited access (i.e. you can run anything you want as opposed to predefined 
processes in WPS).


IIUC, you mean security of the data right?. WebGRASS project is not about 
providing server infrastructure to preserve the data. Of course it wont allow 
to get other users data and in my plan users will have access to their own 
location rather than anyone can use everyone's data. And sensitivity of data 
uploaded is a question and you never publish such kind of data under NDA or so 
in public server right? And you cant access a data on server even when you 
render it on browser screen. That is what mapserver, Openlayers and other web 
map viewer are doing.


Fourth, the processing on server could be also invoked from a desktop GUI. This 
would require user to install the desktop GUI but the processing part would be 
placed on server. This is just another option.

I am not clear with this. Why do you need to invoke a desktop interface for 
running a webapp. I did had a the demo version running on server with no X 
server.

Fifth, the choice of the GUI framework is important. We don't want

Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI

[Rashad M]

Hi Vaclav,


On Thu, Mar 6, 2014 at 5:08 PM, Vaclav Petras  wrote:

> Hi Rashad,
>
> web GRASS is certainly something we need and I'm very excited about that.
> But there are several things which should be considered to make this
> project successful.
>
> First, there is already one (desktop) GUI. Do we want to have (an
> maintain) another GUI? Is there a possibility to share the code between the
> desktop and web GUI?  What about limiting the functionality of the web GUI
> to minimum, so that there will not much code to maintain and (as defined)
> nothing to add?
>

This is the rather important part and we do want to reuse the code from
core classes.

>
> 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, or to reuse web GUI on desktop
> (some web view or browser with local web pages and processes)? Although
> GTK+ and some wxWidgets applications can run with Broadway backend,
> wxPython, and especially GRASS is still far from running that way. However,
> there are some (perhaps even more interesting) alternatives such as Ulteo
> and noVNC. And I'm wondering what rollapp.com is using.
>

I am interested to use Wt, not because of C++ and its recent Python love,
because the idea of Widget centric, security of Wt apps (very much safe
than any other web framework), embedded platform support.  and so on. The
main idea behind the birth of Wt is they want a web application to run on
Web browser and embedded platforms (Android and others). The code is
written in python or C++, webserver (Wthttp) renders a bunch of AJAX code
and compatible with any recent browsers and it takes care of the some
browser related stuff like special css prop for webkit and mozilla. And of
course there is no code conversion or generation from a c++ to html/js
script. Indeed I am allowed to use as much as javascript code. In the demo
you can see openlayers widget!

When you write:

WButton *button = new WButton();

Wt makes the css for Wbutton which it has and provide a very decent and
easy access to render it on browsers. I would rather stop here talking
about Wt before it turn into a name drop of the toolkit which I dont want
to do.



> Third, the GUI is not the only part. The GUI is supposed to be a part of
> some server/cloud infrastructure. You need to upload data, sign in users...
> And also we are not sure what are the security issues of using GRASS on
> server with unlimited access (i.e. you can run anything you want as opposed
> to predefined processes in WPS).
>
>
IIUC, you mean security of the data right?. WebGRASS project is not about
providing server infrastructure to preserve the data. Of course it wont
allow to get other users data and in my plan users will have access to
their own location rather than anyone can use everyone's data. And
sensitivity of data uploaded is a question and you never publish such kind
of data under NDA or so in public server right? And you cant access a data
on server even when you render it on browser screen. That is what
mapserver, Openlayers and other web map viewer are doing.



> Fourth, the processing on server could be also invoked from a desktop GUI.
> This would require user to install the desktop GUI but the processing part
> would be placed on server. This is just another option.
>

I am not clear with this. Why do you need to invoke a desktop interface for
running a webapp. I did had a the demo version running on server with no X
server.

>
> Fifth, the choice of the GUI framework is important. We don't want to
> tight this to some project which will not be here in few years. Wt has nice
> examples and your (Rashad's) experience is big plus. But there is many
> others such as Dabo and some of them might be better for us since they are
> using Python, so we could share some code with wxGUI. Results on mobile
> platforms must be evaluated, too.
>
>
There has been a python binding for Wt and myself and massmio had tried
these successfully. The support for bindings are not much, I would say but
I had a pretty much idea about how its generated which BTW is not using
swig and SIP. Regarding mobile platforms I do had a working apk of another
Wt application for which I got a recording on youtube[1] (offline android).
 [2] is the web version. The patch required for me was very minimal as Wt
compiles clean on Android. [1] also used libgdal (Android). This one just
renders a shapefile and style it without OpenLayers or its friends


> And finally, a sustainability of the new web GUI must be considered. What
> will happen after the GSoC? There already were several GRASS web interfaces
> starting with GRASSLinks in 1995 and also we have some web sites using
> GRASS in background but they are not general GRASS GUI (e.g.
> http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with
> the desktop GUI seems crucial and merging this to GRASS and de

[GRASS-dev] [GRASS GIS] #2211: g.gui.iclass raise a PyAssertionError

[GRASS GIS]

#2211: g.gui.iclass raise a PyAssertionError
--+-
 Reporter:  zarch |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Display   | Version:  svn-trunk
 Keywords:  g.gui.iclass  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 I'm trying to use g.gui.iclass but it seems broken I got this error when I
 try to add a class with the class manager.


 {{{
 Traceback (most recent call last):
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iclass/dialogs.py", line
 318, in OnAddCategory

 self.catList.AddCategory(cat = cat, name = defaultName,
 color = defaultColor)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iclass/dialogs.py", line
 414, in AddCategory

 self.stats_data.AddStatistics(cat, name, color)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iclass/statistics.py",
 line 58, in AddStatistics

 self.statisticsAdded.emit(cat = cat, name = name, color =
 color)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/python/grass/pydispatch/signal.py",
 line 229, in emit

 dispatcher.send(signal=self, *args, **kwargs)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-
 gnu/etc/python/grass/pydispatch/dispatcher.py", line 343, in
 send

 **named
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-
 gnu/etc/python/grass/pydispatch/robustapply.py", line 57, in
 robustApply

 return receiver(*arguments, **named)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iscatt/controllers.py",
 line 1055, in AddCategory

 self.cats_mgr.AddCategory(cat_id = cat, name = name, color =
 color, nstd = stats.nstd)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iscatt/controllers.py",
 line 679, in AddCategory

 color = self.cats[cat_id]["color"] )
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/python/grass/pydispatch/signal.py",
 line 229, in emit

 dispatcher.send(signal=self, *args, **kwargs)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-
 gnu/etc/python/grass/pydispatch/dispatcher.py", line 343, in
 send

 **named
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-
 gnu/etc/python/grass/pydispatch/robustapply.py", line 57, in
 robustApply

 return receiver(*arguments, **named)
   File
 "/home/pietro/docdat/src/gis/grass/grass_trunk/dist.x86_64
 -unknown-linux-gnu/etc/gui/wxpython/iscatt/frame.py", line
 403, in Update

 self.RefreshItems(0, len(self.cats_mgr.GetCategories()))
   File "/usr/lib64/python2.7/site-
 packages/wx-3.0-gtk2/wx/_controls.py", line 4635, in
 RefreshItems

 return _controls_.ListCtrl_RefreshItems(*args, **kwargs)
 wx._core
 .
 PyAssertionError
 :
 C++ assertion "lineTo < GetItemCount()" failed at
 ./src/generic/listctrl.cpp(1923) in RefreshLines(): invalid
 line range
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
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]

Hi Rashad,

web GRASS is certainly something we need and I'm very excited about that.
But there are several things which should be considered to make this
project successful.

First, there is already one (desktop) GUI. Do we want to have (an maintain)
another GUI? Is there a possibility to share the code between the desktop
and web GUI?  What about limiting the functionality of the web GUI to
minimum, so that there will not much code to maintain and (as defined)
nothing to add?

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, or to reuse web GUI on desktop
(some web view or browser with local web pages and processes)? Although
GTK+ and some wxWidgets applications can run with Broadway backend,
wxPython, and especially GRASS is still far from running that way. However,
there are some (perhaps even more interesting) alternatives such as Ulteo
and noVNC. And I'm wondering what rollapp.com is using.

Third, the GUI is not the only part. The GUI is supposed to be a part of
some server/cloud infrastructure. You need to upload data, sign in users...
And also we are not sure what are the security issues of using GRASS on
server with unlimited access (i.e. you can run anything you want as opposed
to predefined processes in WPS).

Fourth, the processing on server could be also invoked from a desktop GUI.
This would require user to install the desktop GUI but the processing part
would be placed on server. This is just another option.

Fifth, the choice of the GUI framework is important. We don't want to tight
this to some project which will not be here in few years. Wt has nice
examples and your (Rashad's) experience is big plus. But there is many
others such as Dabo and some of them might be better for us since they are
using Python, so we could share some code with wxGUI. Results on mobile
platforms must be evaluated, too.

And finally, a sustainability of the new web GUI must be considered. What
will happen after the GSoC? There already were several GRASS web interfaces
starting with GRASSLinks in 1995 and also we have some web sites using
GRASS in background but they are not general GRASS GUI (e.g.
http://www.gapserve.ncsu.edu/segap/segap/). Minimizing duplication with the
desktop GUI seems crucial and merging this to GRASS and developing other
infrastructure, too.

I don't want you to feel overwhelmed by all of these considerations but I
was thinking about this topic for some time, so I collected some ideas and
now is the time to share them.

Vaclav

PS: I just saw your video, congratulations, it looks good and responsive.
Is the code somewhere online?



On Thu, Mar 6, 2014 at 4:28 AM, Rashad M  wrote:

> Hello All,
>
> 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.
>
> [1] http://www.webtoolkit.eu/wt
>
> --
> Regards,
>Rashad
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
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]

Hi Margherita,

I do have a proof of concept quite old now. No recent updates. But I hope
GSoC will be able to change the current situation and move it upfront

https://www.youtube.com/watch?v=B71DQiCw86o


On Thu, Mar 6, 2014 at 3:17 PM, Margherita Di Leo  wrote:

> Rashad,
>
> On Thu, Mar 6, 2014 at 10:28 AM, Rashad M wrote:
>
>> Hello All,
>>
>> 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.
>>
>> [1] http://www.webtoolkit.eu/wt
>>
>
>  FWIW, I like this idea and would like to see it developed. Do you have a
> prototype already?
>
> Thanks,
> madi
>
>
>
>
> --
> Best regards,
>
> Dr. Margherita DI LEO
> Scientific / technical project officer
>
> European Commission - DG JRC
> Institute for Environment and Sustainability (IES)
> Via Fermi, 2749
> I-21027 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
> Disclaimer: The views expressed are purely those of the writer and may not
> in any circumstance be regarded as stating an official position of the
> European Commission.
>



-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2210: unable to start GRASS GIS 7

[GRASS GIS]

#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  |  
+---
 Hi,

 since r59163 I am getting following error when GRASS 7 is started. I am
 getting same error also in recent revisions (r59205):


 {{{
 ostepok@ostepok-pc:~/Dev/GRASS/grass_wms/grass_trunk$ ./bin.x86_64
 -unknown-linux-gnu/grass70
 Cleaning up temporary files...
 Starting GRASS GIS...
 Traceback (most recent call last):
   File "/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
 linux-gnu/etc/gui/wxpython/gis_set.py", line 37, in 
 from core.utils import _
   File "/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
 linux-gnu/etc/gui/wxpython/core/utils.py", line 36, in 
 from core.gcmd  import RunCommand
   File "/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
 linux-gnu/etc/gui/wxpython/core/gcmd.py", line 744, in 
 _enc = GetDefaultEncoding() # define as global variable
   File "/home/ostepok/Dev/GRASS/grass_wms/grass_trunk/dist.x86_64-unknown-
 linux-gnu/etc/gui/wxpython/core/gcmd.py", line 737, in GetDefaultEncoding
 enc = locale.getdefaultlocale()[1]
   File "/usr/lib/python2.7/locale.py", line 511, in getdefaultlocale
 return _parse_localename(localename)
   File "/usr/lib/python2.7/locale.py", line 443, in _parse_localename
 raise ValueError, 'unknown locale: %s' % localename
 ValueError: unknown locale: None
 Error in GUI startup. If necessary, please report this error to the GRASS
 developers.
 Switching to text mode now.

 Hit RETURN to continue...
 }}}

-- 
Ticket URL: 
GRASS GIS 

___
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

[Margherita Di Leo]

Rashad,

On Thu, Mar 6, 2014 at 10:28 AM, Rashad M wrote:

> Hello All,
>
> 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.
>
> [1] http://www.webtoolkit.eu/wt
>

FWIW, I like this idea and would like to see it developed. Do you have a
prototype already?

Thanks,
madi




-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: Android Compilation

[Vaclav Petras]

On Wed, Mar 5, 2014 at 11:46 PM, Yann Chemin  wrote:

> I can find the 2 toolbox files in the
>
> /home/yann/dev/grass/dist.arm-unknown-linux-androideabi/etc/gui/wxpython/xml
> but they have 0 bytes...
>
> I guess that this is similar problem to the g.gui.* modules: wrong build
environment since on Mac OS X this is fixed by running the compilation of
gui/wxpython again within the GRASS session.

But this is probably not important because there is no way to wxPython on
Andriod. At least quick google search said so. So, perhaps GUI is the
biggest challange for Android (which could be to certain extent solved by
QGIS for Android bundled with GRASS for Android).

>
>
>
> On 6 March 2014 10:08, Vaclav Petras  wrote:
>
>>
>> On Wed, Mar 5, 2014 at 11:23 PM, Yann Chemin  wrote:
>>
>>> Errors compiling only in
>>> /home/yann/dev/grass/gui/wxpython/animation
>>> /home/yann/dev/grass/gui/wxpython/mapswipe
>>> /home/yann/dev/grass/gui/wxpython/gmodeler
>>> /home/yann/dev/grass/gui/wxpython/rlisetup
>>> /home/yann/dev/grass/gui/wxpython/psmap
>>> /home/yann/dev/grass/gui/wxpython/dbmgr
>>> /home/yann/dev/grass/gui/wxpython/vdigit
>>> /home/yann/dev/grass/gui/wxpython/iclass
>>> /home/yann/dev/grass/gui/wxpython/gcp
>>> /home/yann/dev/grass/gui/wxpython/timeline
>>>
>>
>> These (g.gui.* modules) are also problematic on Mac OS X. For me there is
>> no difference between these and standard scripts but there probably is
>> some. It seems that the build system is a bit fragile when it compiles
>> wxGUI things.
>>
>> I'm wondering if toolboxes were generated
>> (etc/gui/wxpython/xml/menudata.xml and module_tree_menudata.xml).
>>
>
>
>
> --
> 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2207: provide downloadable tar balls of html man pages

[GRASS GIS]

#2207: provide downloadable tar balls of html man pages
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Website  | Version:  unspecified  
 Keywords:  html man pages download  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Done for GRASS 7: http://grass.osgeo.org/documentation/manuals/

 Will asap add the other packages to the weekly cronjobs.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2014: GRAS GIS Web UI

[Rashad M]

Hello All,

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.

[1] http://www.webtoolkit.eu/wt

-- 
Regards,
   Rashad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] importing big vector data

[Blumentrath, Stefan]

Hi,

Just to add a side-note: I had no problems with importing the entire Norwegian 
N50 dataset in GRASS 7 (r58048 on Ubuntu Server 12.04 LTS with 48GM RAM). The 
N50 dataset contains 2909696 areas. And also v.overlay worked very well...

Cheers
Stefan

-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Glynn Clements
Sent: 6. mars 2014 10:01
To: Martin Landa
Cc: GRASS developers list; Markus Metz
Subject: Re: [GRASS-dev] [GRASS-user] importing big vector data


Martin Landa wrote:

> right, this strange, I used code bellow
> 
> int i;
> int base = 1e6;
> char *buf = NULL;
> for(i = 1 ; i <= 8000; i++) {
>   G_debug(0, "%d -> %ld", i, i * base);
>   buf = G_realloc(buf, i * base);
>   if (i % 100 == 0)
> sleep(1);
> }
> 
> it fails when trying to allocate about 2GB,

If any part of the code leaks memory, this will fail due to heap fragmentation.

Each allocation is slightly larger than the previous one. If something 
allocates memory between the reallocations of the main block, you'll end up 
with the heap looking like:

[1Mb free][used][2Mb free][used][3Mb free][used]...

The end result will be 1+2+3+...+7999 Mb = ~32 terabytes of "free"
memory, all of it in blocks too small to be used for the next allocation.

If it fails at i==2048, the figure would be 2 terabytes.

Does removing the G_debug call have an effect?

--
Glynn Clements  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2208: r.in.gdal/v.in.ogr: reprojection at import

[GRASS GIS]

#2208: r.in.gdal/v.in.ogr: reprojection at import
+---
 Reporter:  mlennert|   Owner:  grass-dev@… 
 
 Type:  enhancement |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  unspecified 
 
 Keywords:  projection import gdal ogr  |Platform:  Unspecified 
 
  Cpu:  Unspecified |  
+---

Comment(by mlennert):

 Replying to [comment:2 mmetz]:
 > Replying to [comment:1 martinl]:
 > > reprojection option available for r.in.gdal/v.in.ogr would a step
 forward from user perspective.
 >
 > You would need to supply all options of [r|v].proj. Moreover, vector
 data might need preprocessing (adding vertices to lines/boundaries) in
 order to provide realistic and topologically correct results. The
 reprojection option could IMHO be best implemented in a script which calls
 r.in.gdal/v.in.ogr and then r.proj/(v.split + v.proj).
 >

 I had actually thought that it might be possible to integrate GDAL/OGR
 library tools such as GDALWarpOperation and OGRCoordinateTransformation
 directly into r.in.gdal/v.in.ogr.

 But maybe you're right and we should not touch the general GRASS structure
 of import into one location + reproject into another, and rather use a
 wrapper.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Metz wrote:

> > .py is supposed to be associated with a Python interpreter, and
> > the stock Python installer will do that.
> 
> .py is not supposed to be associated with a Python interpreter that is
> installed system-wide

It certainly is, because that's what the stock Python installer will
do by default.

> because this assumes some kind of package
> manager as available on Linux/BSD/Unix. MS Windows does not have a
> package manager. Any software installed on Windows must include any
> script interpreters and enforce the use of these for the respective
> scripts.
> 
> The fundamental assumption of MS Windows software installers is that
> no other software installer will interfere with its installation. This
> assumption is violated as soon as a software installer invokes another
> software installer. This means that the WinGRASS software installer
> should not invoke or require a Python installation on MS Windows.

All of this goes out the window if you want to provide a command-line
environment, whether an interactive shell or the ability to execute
commands via system() or CreateProcess().

The only way that you can "configure" Windows' command execution
mechanism is by registering extensions.

> Instead of battling the MS Windows software management system,

But that's exactly what trying to "bundle" Python is doing. You don't
trust the OS to be configured correctly so you're trying to construct
an isolated sandbox.

> I would
> rather follow the approach of other projects that have been running
> successfully on MS Windows with their embedded python interpreter for
> a couple of years.

You're referring to monolithic applications which require that any
"scripting" is done from within the application itself. They typically
also require the use of a specific language for scripting, and have
entirely separate mechanisms for extension via scripts and extension
via compiled code (the latter typically being in the form of DLL
"plug-ins").

IOW, the exact opposite of GRASS.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] importing big vector data

[Glynn Clements]

Martin Landa wrote:

> right, this strange, I used code bellow
> 
> int i;
> int base = 1e6;
> char *buf = NULL;
> for(i = 1 ; i <= 8000; i++) {
>   G_debug(0, "%d -> %ld", i, i * base);
>   buf = G_realloc(buf, i * base);
>   if (i % 100 == 0)
> sleep(1);
> }
> 
> it fails when trying to allocate about 2GB,

If any part of the code leaks memory, this will fail due to heap
fragmentation.

Each allocation is slightly larger than the previous one. If something
allocates memory between the reallocations of the main block, you'll
end up with the heap looking like:

[1Mb free][used][2Mb free][used][3Mb free][used]...

The end result will be 1+2+3+...+7999 Mb = ~32 terabytes of "free"
memory, all of it in blocks too small to be used for the next
allocation.

If it fails at i==2048, the figure would be 2 terabytes.

Does removing the G_debug call have an effect?

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Enc: Re: Enc: Re: i.atcorr returns nan for Landsat 5 TM bands 1 and 2

[Alessandro Samuel Rosa]

I talked with Mauro Antunes and he allowed me to share the source code of his 
actual version of 6S.

The Fortran source code can be download from my Dropbox account using this 
link: https://www.dropbox.com/s/cjkghyhmk2p8og3/6s_8_and_16_bits.rar.

Alessandro

--- Em qua, 5/3/14, Mauro A. Homem Antunes  escreveu:

> De: Mauro A. Homem Antunes 
> Assunto: Re: Enc: Re: [GRASS-dev] i.atcorr returns nan for Landsat 5 TM bands 
> 1 and 2
> Para: alessandrosam...@yahoo.com.br
> Data: Quarta-feira, 5 de Março de 2014, 21:08
> 
>   
> 
>     
>   
>   
>     Caro
> Alessandro,
> 
>       
> 
>       Não deu para descansar o necessário,
> pois acabei ficando "online
>       para resolver algumas coisas.
> 
>       
> 
>       Com certeza posso disponibilizar sim mas por favor
> peça que eles
>       esperem até o final de março ou no
> máximo início de abril para que
>       eu dê uma limpada no código nessa parte
> de entrada de coeficientes
>       de calibração. Dessa maneira o risco de
> problemas é menor.
> 
>       
> 
>       Estou entrando de férias (apesar de ainda ter
> umas coisas
>       pendentes para resolver) e retorno dia 26 de
> março, aí sim com
>       baterias recarregadas...
> 
>       
> 
>       Se o pessoal do GRASS tiver com alguma deadline para
> colocar isso
>       online aí tudo bem, passe o código para
> eles, mas não vai estar
>       redondinho que seria o ideal. Pode falar isso para
> eles, que vai
>       ser disponibilizado mas era só para ajustar
> algumas coisas nas
>       entradas e saídas do modelo.
> 
>       
> 
>       Um abraço,
> 
>       Mauro 
> 
>       
> 
>       
> 
>       Em 5/3/2014 08:33, Alessandro Samuel Rosa escreveu:
> 
>     
>     
>       Olá Mauro,
> 
> Espero que tenha descansado durante o carnaval.
> 
> Os desenvolvedores do GRASS perguntaram-me se é
> possível obter uma cópia da versão
> atual do 6S em Fortran para que eles possam encontrar uma
> maneira de solucionar alguns dos bugs do módulo
> i.atcorr do GRASS. Como disseste que não deveria
> compartilhar o código fonte que me passou, preciso da
> sua autorizacão para atender ao pedido dos
> desenvolvedores do GRASS.
> 
> Abraco,
> 
> Alessandro Samuel-Rosa
> ---
> Graduate School in Agronomy - Soil Science
> Federal Rural University of Rio de Janeiro
> Seropédica, Rio de Janeiro, Brazil
> ---
> Guest Researcher at ISRIC - World Soil Information
> Wageningen, the Netherlands
> ---
> Homepage: soil-scientist.net   Skype: alessandrosamuel
> 
> 
> --- Em qua, 5/3/14, Markus Neteler 
> escreveu:
> 
> 
>       
>         De: Markus Neteler 
> Assunto: Re: [GRASS-dev] i.atcorr returns nan for Landsat 5
> TM bands 1 and 2
> Para: "Alessandro Samuel Rosa" 
> Cc: "GRASS developers list" 
> Data: Quarta-feira, 5 de Março de 2014, 7:32
> On Thu, Feb 27, 2014 at 8:40 PM,
> Alessandro Samuel Rosa
> 
> wrote:
> 
> 
>         
>           I also tried contacting Mauro Antunes, the
> author of
> 
>         
>         the original code in Fortran. 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
> 
> 
>       
>     
>     
> 
>     
> 
>     -- 
> 
>       Signature
>       
>       
>       Prof. Mauro Antonio Homem
> Antunes
>       Ph.D., Remote Sensing
> 
>       Federal Rural University
>       of Rio de Janeiro-UFRRJ
> 
>       Engineering Department
> 
>       BR 465, km 7
> 
>       CEP: 23.890-000 - Seropédica - RJ - Brazil
> 
>       +55 21 2682-1864 FAX: 21 3787-3750 
> 
>       Currículo
>             Lattes 
> 
>          Página do
>             Doutorado Binacional
> 
>         Book Chapter of Solar
>           Radiation
>     
> 
> 
> 
> 
> 
> 
>     
>         
>             
>                 
>             
>         
>         
>             
>                 Este email está limpo de vírus e malwares porque a
> proteção do avast! Antivírus está
> ativa.
>             
>         
>     
> 
> 
> 
> 
> 
>

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Working with GRASS without starting it explicitly on windows

[Glynn Clements]

Pietro wrote:

> yes, I' attached the results

I see nothing fundamentally wrong there.

In theory, this could be a problem:

 'PYTHONSTARTUP':
 'C:\\Python27\\lib\\site-packages\\spyderlib\\scientific_startup.py',

Also, some of the directories which are ahead of GRASS in the PATH
setting could create issues. Try setting PATH so that it only includes
the base Windows directories plus the GRASS directories.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Character encoding of module i.atcorr files

[Glynn Clements]

Vaclav Petras wrote:

> What are coding cookies?

A coding cookie is a piece of text indicating the encoding of a text
file, such as:

-*- coding: utf-8 -*-

The above syntax originates from Emacs, and has been adopted by
Python. I don't know what else (if anything) supports it.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.gui.rlisetup updates

[Luca Delucchi]

On 6 March 2014 02:43, Anna Petrášová  wrote:
> Hi Luca,
>

Hi Anna,

>
> I committed some improvements in r59202. I hope it's what you need, I am
> always confused from all the offered possibilities in the wizard...
>

Yes thanks, I'm also confused from all the offered possibilities in
the wizard ;-)

> Anna
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev