Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

On 23 January 2015 at 15:46, Martin Landa  wrote:

> Hi,
>
> 2015-01-23 9:20 GMT+01:00 Markus Neteler :
> > my motivation to discuss the current welcome screen is that too many
> > potential new users try to launch GRASS, do not get past that screen and
> > walk away ("too difficult"). Yes, and they will likely not read the
> manual
> > but just take another GIS.
> > This is a multiple times reported fact.
>
> I have met a lot of GIS specialists who told me: I tried several times
> to use GRASS in different decades and I end up with the same result, I
> didn't managed to get my data in, so I gave up.
>
> Yes, I also had those experiences told to me.
Is it possible to open GRASS GIS wxGUI without setting the
GISDB/Location/mapset yet?
Then from "inside the opened software" you will need to go through those
steps anyway before doing anything...
Would that make any psychological difference?


> It' a sign in my eyes that we should think how to simplify this step ;-)
>
> Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
> ___
> 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] New splash screen for GRASS GIS 7?

[Yann Chemin]

On 23 January 2015 at 11:58, Vincent Bain  wrote:

> I've followed this discussion as closely as I could but might have
> missed some steps..., so to put it in a nutshell:
>
> * Right now, for the release, we propose:
>- a new splash with a "neutral/temporary/free" banner image (e.g.
> grass);
>- for the welcome screen, I make up a simple banner according to
> Vaclav's suggestion i.e. small GRASS logo+motto on transparent bg (or
> white bg to handle dark windows desktop themes).
>
> * Later on I can work on the historical map suggestion --or any other
> idea.
>
>
> I can do it between today and sunday.
>
>
>
> > With the picture for startup screen, it would be nice to have
> > an alternative for cases where GRASS is on a machine with
> > ISIS.
>
> What is ISIS ?
>
> ISIS [1] is a software from USGS that reads space mission data from the
PDS [2]
there is now a script to create menus from ISIS into the GRASS menu [3], to
use them together.
For more Planetary GRASS see [4]

[1] http://isis.astrogeology.usgs.gov/
[2] http://pds-geosciences.wustl.edu (other mirrors exist)
[3]
https://sites.google.com/site/geosnipets/Downhome/Topic2/creatinganisismenuentryingrass/mk_isis_menu.sh
[4] http://grasswiki.osgeo.org/wiki/Planetary_mapping



>
> ___
> 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] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

Hi MIchael,

Are we going to yet another branch from the original topic :-)

I believe the fundamental change you speak about is worth discussing for
GRASS 8.
I also believe that the on-the-fly reprojection on import is a feature we
all agree is (very) needed (GRASS 8).

Finally, I believe that Vaclav small changes to the welcome page are worth
agreeing upon.


On 23 January 2015 at 10:23, Michael Barton  wrote:

>  Hi Vaclav,
>
>  To be clear, I agree with you that GRASS should not start with a wizard
> and had did not intend anyone to think that.
>
>  The ‘step 1, step 2, step 3’ was simply to put this as text on the
> startup dialog, to help users know which step to do in what order.
>
>  The more radical suggestion that I made today involves fundamental
> change of how GRASS works. Change the file structure to
> GISDBASE/mapsets=working directories and get rid of locations as folders.
> Store projection information in a different way than as locations. Maybe
> store projection info in each mapset, or maybe some other way. Maybe each
> mapset still only contains maps from a single projection to keep maps of
> the same projection together. It may be necessary to do other things to
> make sure that users don’t try to combine maps of different projections.
>
>  This would make it possible to have a simpler startup. But it would take
> more thought and some programming to make it work.
>
>  Michael
> 
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  On Jan 22, 2015, at 8:22 PM, Vaclav Petras  wrote:
>
>
> On Thu, Jan 22, 2015 at 12:16 PM, Michael Barton 
> wrote:
>
>> For this release, we need to focus on just tweaking the current startup
>> screen and doing better graphics for the splash. The other topic is a much
>> bigger issue.
>>
>
>  Not everybody considers my suggestion as useful-enough change and there
> is the hard freeze (although the functionality changes are almost zero). As
> a result, I don't plan to commit it to release branch now. However, I
> consider it as a great improvement which I definitively want to use and I
> think it is very beneficial for beginners, so I will commit that to trunk
> when I get to it. Then we can continue in the other improvements.
>
>  To the other things. I also consider data in different projections as
> much bigger issue. GRASS has all the tools as described and also
> implemented by Markus Metz but it is too much for beginners. We should
> definitively make it more accessible (but it is also interesting business
> opportunity :-).
>
>  I still don't understand what the user could in the dummy/LL/XY/demo
> location besides looking to menus and being confused from wrongly imported
> data or no imported data at all because of projection issues.
>
>  Michael suggests to replace startup by some wizard and this is what QGIS
> is doing. So, is putting everything to wizard better then the window +
> optional wizard? We can go that way but note the difference between QGIS
> and GRASS, when QGIS is running the wizard, the app is already there,
> wizard is just an additional window. For GRASS, it would the window you get
> which might be strange. Even stranger if the window would be just some
> small one with "Will start in location xxx" and "Change" and "Continue"
> buttons.
>
>  It would be also useful to analyze why the thing which is done on MS
> Windows by the standalone installer is not enough. There should be a demo
> location already and set as last used. Also NC SPM can be downloaded,
> should it be checked by default?
>
>  Does somebody has a opinion on using "Location", "GRASS Location", or
> "GRASS location" consistently? You can see also "LOCATION" here and there
> in GRASS but I wouldn't go that way.
>
>
>
> ___
> 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] New splash screen for GRASS GIS 7?

[Yann Chemin]

Happy to help for ISIS banner modification,
we first need a main banner though.

What are the working options so far? Is there a consensus on something we
can submit now as a first try?

I am happy to give a +1 to Vincent's banner most people preferred (see
earlier emails), and we modify it once or twice according to reactions on
this discussion.

Comments anyone?


On 23 January 2015 at 09:11, Vaclav Petras  wrote:

>
>
> On Thu, Jan 22, 2015 at 2:25 AM, Markus Neteler  wrote:
>
>> On Thu, Jan 22, 2015 at 8:10 AM, Nikos Alexandris
>>  wrote:
>> > Dear Michael,
>> >
>> > while the maps linked below are very nice, why and how do they showcase
>> > GRASS' capabilities?  Or is it about, only, to represent in which areas
>> > GRASS can do stuff?
>> >
>> > Why not have a splash that is GRASS' very unique identity?  What it is,
>> what
>> > it can do.
>>
>> Yes, perhaps it could be an image in which an old map is warped into
>> something volumetric? So, from old to new?
>>
>>
> If we want this for the release, we should proceed with this. Or do you
> want to move it to 7.0.1?
>
> I would like to see Vincent's grass (with CC BY image and perhaps an easy
> to get font) as splash and then the simple one with logo with white or
> transparent backgroud but the smaller version I posted (where image height
> is just the height of GRASS GIS and motto texts). Vincent, or some other
> artists, are you able to work on that, or some other suggestions?
>
> With the picture for startup screen, it would be nice to have an
> alternative for cases where GRASS is on a machine with ISIS. I'm not sure
> how many users it is targeting but we have this functionality now, so I
> would keep it.
>
> Vaclav
>
>
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/images/startup_banner.png?rev=52438
>
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/images/startup_banner_isis.png?rev=57090
>
>
>
>> Markus
>> ___
>> 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] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

 "If we would find a way to automatically reproject data during import,
that would save a lot of work and explanation and it's useful not just for
beginners."

Not only beginners, I work -always- with mixed data, I spend an enourmous
amount of time juggling with creating adhoc temporary locations only to use
them once for reprojection to a main Location. This would transform my
daily work... But indeed it is another topic...

On 22 January 2015 at 20:57, Anna Petrášová  wrote:

>
>
> On Thu, Jan 22, 2015 at 9:41 AM, Martin Landa 
> wrote:
>
>> Hi,
>>
>> 2015-01-22 9:48 GMT+01:00 Markus Metz :
>> > A suggestion for a compromise:
>> >
>> > Have a minimal welcome screen that says something like
>> > "Starting GRASS GIS in location X, mapset Y"
>> > nothing else, no list of all the available locations and mapsets
>> >
>> > Only two buttons: OK, Change
>> > Make OK the default, Change will bring up the current welcome screen.
>> >
>> > The user has then just to hit enter and GRASS is running. This would
>> > reduce the (confusing) amount of information on the current welcome
>> > screen. It would also give more space for a little graphic ;-)
>> >
>> > Location and mapset can be taken from GISRC, if that does not exist,
>> > create a new GISDBASE in the user's home, put the demolocation in it
>> > and use this (I think the wingrass installer is already doing that).
>>
>> it make sense to me, I really like this idea. Martin
>>
>
> I am not particularly fond of this idea, I change location and mapset
> quite often, so this is additional step. I agree GISDBASE and the
> demolocation should be already there during the first start. Then the user
> can just hits Start GRASS on the current welcome dialog and there is no
> need for the minimal welcome screen. It works like this for Windows
> already. It creates grassdata in My Documents if I remember correctly, I am
> not sure why not in home.
>
> What I struggle with when explaining students how to use GRASS is not
> really the welcome screen but reprojecting data. If we would find a way to
> automatically reproject data during import, that would save a lot of work
> and explanation and it's useful not just for beginners. This is a topic for
> a different thread, how exactly it should be implemented. No matter what we
> decide to do with the starting of grass, this should be implemented.
> Especially when user will start with empty location, they will want to
> import their data and then the reprojection is crucial. I saw a lot of
> cases when they just override the projection check to overcome the error
> they get and don't read.
>
> Any opinion on what can we do for this release?
>
> Anna
>
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.eu/mentors/landa
>> ___
>> 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
>



-- 

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

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

+1 even better if we can test this on svn any time soon, it is often more
practical to try...

On 22 January 2015 at 20:11, Martin Landa  wrote:

> Hi,
>
> 2015-01-22 9:48 GMT+01:00 Markus Metz :
> > A suggestion for a compromise:
> >
> > Have a minimal welcome screen that says something like
> > "Starting GRASS GIS in location X, mapset Y"
> > nothing else, no list of all the available locations and mapsets
> >
> > Only two buttons: OK, Change
> > Make OK the default, Change will bring up the current welcome screen.
> >
> > The user has then just to hit enter and GRASS is running. This would
> > reduce the (confusing) amount of information on the current welcome
> > screen. It would also give more space for a little graphic ;-)
> >
> > Location and mapset can be taken from GISRC, if that does not exist,
> > create a new GISDBASE in the user's home, put the demolocation in it
> > and use this (I think the wingrass installer is already doing that).
>
> it make sense to me, I really like this idea. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
> ___
> 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] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

http://docs.qgis.org/2.2/ko/docs/training_manual/grass/grass_setup.html
http://docs.qgis.org/2.2/ko/_images/grass_folder.png

Spanish text
https://ecoslackware.wordpress.com/tag/grass-qgis-plugin/

Italian text
http://qgis4dummies.wikidot.com/grass-plugin




On 22 January 2015 at 12:35, Nikos Alexandris 
wrote:

> If I am not wrong, no-one mentioned the QGIS interface to GRASS (when
> creating a new Location & Mapset(s)).  It's not bad at all.  In fact, it's
> good.
>
> Nikos
>
> ___
> 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] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

I do understand, and feel the same way about it. There is a reason for the
set up to ask for these indeed, and it is definitely a better structure in
the long run for using it.

This raises the question of who will sit down and go through this, when any
other GIS just get to work. So yes, modifying the entry form is becoming
the most crucial part for the newcomer to stay (read?) and "open" the
software, or go and "just open" another one (Thinking about students
discovering OSGEO LiveDVD for example).

Can we propose (like it proposes a mapset with your login name) to make a
grassdata directory in the user directory, if this is not existing, and
start building on that? R does that for its Workspace creation.



On 22 January 2015 at 11:45, Michael Barton  wrote:

>  Beginners perhaps need to think about projections at the outset more so
> than advanced users. But I don’t think a ‘beginner’ and ‘advanced’ user
> version of the interface is a good idea. If we work out a way to simplify
> and/or streamline starting GRASS, it should just be the way the program
> works for all.
>
>  Michael
>
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  On Jan 21, 2015, at 11:06 PM, Yann Chemin  wrote:
>
>
>
> On 22 January 2015 at 11:30, Michael Barton 
> wrote:
>
>>
>>  This is a good start. Here are some suggestions for simplifying the
>> text even more.
>>
>>  =
>>
>>  [Select GRASS GIS database directory]
>>
>>  (make this a button rather than a text box with browse; no need to show
>> this path)
>>
>>  "A GRASS GIS database directory contains one or more Locations”
>>
>>  (no need to say that you can have more than one GISDBASE)
>>
>>  =
>>
>>  "All GIS data in a Location directory are in the same coordinate
>> reference system (projection). Locations contain Mapsets.”
>>
>>  OR
>>
>>  "All GIS data in a Location directory are in the same spatial
>> projection. Locations contain one or more Mapsets.”
>>
>>  (Locations are not necessarily related to ‘projects’. Mine are very
>> much projection based—e.g., I have a single latlon Location for ALL my
>> latlon data regardless of which research project it is used for. Do we need
>> to say “coordinate reference system (projection)”? Doesn’t just
>> “projection” cover it well enough? These are directories, so it might help
>> to say this.)
>>
>>   =
>>
>>  "A Mapset contains GIS data. Every Location automatically has one
>> Mapset named PERMANENT that also contains projection information for the
>> Location."
>>
>>  (A Mapset may or may not relate to one task; that depends on the user.
>> Some of mine do and some don’t. The ‘common data’ in PERMANENT is not
>> really important except in a multi-user setup, which is not what most
>> people use today. Mapsets are directories too, but as someone mentioned,
>> maybe we shouldn’t stress this in case someone tries to move stuff around
>> in a mapset. On the other hand, and unlike Arc, entire Locations and entire
>> Mapsets CAN be moved without any harm).
>>
>>  =
>>
>>
>>  I would not mess with trying to start GRASS without the standard
>> database/location/mapset that we have now in 7.0 until we have some time to
>> think it through and talk about it some. One easy to do thing would be to
>> add a button to this screen (instead of inside the location wizard only) to
>> create a latlon region and open GRASS in its PERMANENT mapset. But I’m not
>> even sure that this is a good way to go yet.
>>
>
>  Thus the idea of a starting flag "grass -b" to get a lat/long region and
> open a PERMANENT mapset. The whole thing can be a /tmp/random_name.
>
>>
>>  Michael
>>
>>
>>  On Jan 21, 2015, at 9:36 PM, grass-dev-requ...@lists.osgeo.org wrote:
>>
>>  *From: *Vaclav Petras 
>>  *To: *GRASS developers list 
>>  *Date: *January 21, 2015 at 9:35:40 PM MST
>>  *Subject: **Re: [GRASS-dev] Making start of GRASS GIS easi

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

On 22 January 2015 at 11:30, Michael Barton  wrote:

>
>  This is a good start. Here are some suggestions for simplifying the text
> even more.
>
>  =
>
>  [Select GRASS GIS database directory]
>
>  (make this a button rather than a text box with browse; no need to show
> this path)
>
>  "A GRASS GIS database directory contains one or more Locations”
>
>  (no need to say that you can have more than one GISDBASE)
>
>  =
>
>  "All GIS data in a Location directory are in the same coordinate
> reference system (projection). Locations contain Mapsets.”
>
>  OR
>
>  "All GIS data in a Location directory are in the same spatial
> projection. Locations contain one or more Mapsets.”
>
>  (Locations are not necessarily related to ‘projects’. Mine are very much
> projection based—e.g., I have a single latlon Location for ALL my latlon
> data regardless of which research project it is used for. Do we need to say
> “coordinate reference system (projection)”? Doesn’t just “projection” cover
> it well enough? These are directories, so it might help to say this.)
>
>   =
>
>  "A Mapset contains GIS data. Every Location automatically has one Mapset
> named PERMANENT that also contains projection information for the Location."
>
>  (A Mapset may or may not relate to one task; that depends on the user.
> Some of mine do and some don’t. The ‘common data’ in PERMANENT is not
> really important except in a multi-user setup, which is not what most
> people use today. Mapsets are directories too, but as someone mentioned,
> maybe we shouldn’t stress this in case someone tries to move stuff around
> in a mapset. On the other hand, and unlike Arc, entire Locations and entire
> Mapsets CAN be moved without any harm).
>
>  =
>
>
>  I would not mess with trying to start GRASS without the standard
> database/location/mapset that we have now in 7.0 until we have some time to
> think it through and talk about it some. One easy to do thing would be to
> add a button to this screen (instead of inside the location wizard only) to
> create a latlon region and open GRASS in its PERMANENT mapset. But I’m not
> even sure that this is a good way to go yet.
>

Thus the idea of a starting flag "grass -b" to get a lat/long region and
open a PERMANENT mapset. The whole thing can be a /tmp/random_name.

>
>  Michael
>
>
>  On Jan 21, 2015, at 9:36 PM, grass-dev-requ...@lists.osgeo.org wrote:
>
>  *From: *Vaclav Petras 
>  *To: *GRASS developers list 
>  *Date: *January 21, 2015 at 9:35:40 PM MST
>  *Subject: **Re: [GRASS-dev] Making start of GRASS GIS easier for
> newcomers*
>
>
>
>
> On Wed, Jan 21, 2015 at 5:15 PM, Vaclav Petras 
> wrote:
>
>>
>>  To satisfy everybody, I suggest to provide a buttons with something
>> like "Take me to LL", "Take me to default location" and "Take me to XY".
>> What do you think about that?
>>
>> But the real improvement should be the messages which would guide you
>> through the process.
>>
>
> So, here is screenshot and diff for new layout of the window together the
> description what the things are useful for. The descriptions can be easily
> changed, they are wrapped texts, so they will work well with translations.
> So, feel free to suggest different ones. We can also make them "gray" as
> suggested earlier.
>
>  I used GRASS Location and Location. I though that GRASS could help to
> emphasize that it is something GRASS-related and few people were using
> Location and Mapset with capital letter which could say that it is a
> something like files format or spatial database name. I aimed to address
> the things I considered confusing. I'm not sure about the GRASS GIS data
> directory as I mentioned earlier.
>
>  Now it is higher then the old one but with removal of the image it will
> be smaller. If a small-enough image is used, it could be the same. I would
> like to not include the image to have more space for the error messages
> (currently one line between GISDBASE and Location boxes), so messages can
> be longer and perhaps some what to do next tips can be shown as well. The
> position of this text can/should be changed, now middle of the window
> (usually these are at the bottom or at the top). However, without image it
> might be actually a little boring.
>
>  I reorganized the buttons to manage the (list of) Locations and (list
> of) Mapsets, so now it looks like any other lists, e.g. in Simple Layer
> Manager or in Cartographic Composer. In future we can add buttons, for
> example unpack a zipped location or download sample datasets in case of
> Locations and show existing maps button in case of Mapsets.
>
>  A "Skip" button can be added next to Start button, once implemented. I
> think that XY location in /tmp/grassdata would be appropriate.
>
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073268.html
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073266.htm

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

Just copying my last comment from the source thread...

I can concur on the feeling of being lost but most students. What about a
grass70 -b flag for "beginner" or something like this. That means we can
work through the discovery straight "out of the box". It would be even
easier to have a MSWin Icon using that option installed on the desktop
directly, if we are looking at lowering the entry/discovery level. It could
have a "beginner' infographic to direct new users to this one first.

+
What about creating a mechanism where the beginner version (as you point
out Vaclav) be made always in the /tmp/random_name on opening GRASS, with
say lat/long parameters. From Inside GRASS, one can launch the "welcome
screen" and make a new Location/mapset, hook to it, or hook into an
existing set. <- This will make the "starting use" of GRASS look like a
common GIS, with the whole Location/project management (already there but
not in one dialog) right available at any time in the software.






On 22 January 2015 at 10:05, Vaclav Petras  wrote:

>
>
> On Wed, Jan 21, 2015 at 5:15 PM, Vaclav Petras 
> wrote:
>
>>
>> To satisfy everybody, I suggest to provide a buttons with something like
>> "Take me to LL", "Take me to default location" and "Take me to XY". What do
>> you think about that?
>>
>> But the real improvement should be the messages which would guide you
>> through the process.
>>
>
> So, here is screenshot and diff for new layout of the window together the
> description what the things are useful for. The descriptions can be easily
> changed, they are wrapped texts, so they will work well with translations.
> So, feel free to suggest different ones. We can also make them "gray" as
> suggested earlier.
>
> I used GRASS Location and Location. I though that GRASS could help to
> emphasize that it is something GRASS-related and few people were using
> Location and Mapset with capital letter which could say that it is a
> something like files format or spatial database name. I aimed to address
> the things I considered confusing. I'm not sure about the GRASS GIS data
> directory as I mentioned earlier.
>
> Now it is higher then the old one but with removal of the image it will be
> smaller. If a small-enough image is used, it could be the same. I would
> like to not include the image to have more space for the error messages
> (currently one line between GISDBASE and Location boxes), so messages can
> be longer and perhaps some what to do next tips can be shown as well. The
> position of this text can/should be changed, now middle of the window
> (usually these are at the bottom or at the top). However, without image it
> might be actually a little boring.
>
> I reorganized the buttons to manage the (list of) Locations and (list of)
> Mapsets, so now it looks like any other lists, e.g. in Simple Layer Manager
> or in Cartographic Composer. In future we can add buttons, for example
> unpack a zipped location or download sample datasets in case of Locations
> and show existing maps button in case of Mapsets.
>
> A "Skip" button can be added next to Start button, once implemented. I
> think that XY location in /tmp/grassdata would be appropriate.
>
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073268.html
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073266.html
>
> ___
> 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] Making start of GRASS GIS easier for newcomers

[Yann Chemin]

Looks good Vaclav,

it makes sense on the flow, more intuitive.

On 22 January 2015 at 10:05, Vaclav Petras  wrote:

>
>
> On Wed, Jan 21, 2015 at 5:15 PM, Vaclav Petras 
> wrote:
>
>>
>> To satisfy everybody, I suggest to provide a buttons with something like
>> "Take me to LL", "Take me to default location" and "Take me to XY". What do
>> you think about that?
>>
>> But the real improvement should be the messages which would guide you
>> through the process.
>>
>
> So, here is screenshot and diff for new layout of the window together the
> description what the things are useful for. The descriptions can be easily
> changed, they are wrapped texts, so they will work well with translations.
> So, feel free to suggest different ones. We can also make them "gray" as
> suggested earlier.
>
> I used GRASS Location and Location. I though that GRASS could help to
> emphasize that it is something GRASS-related and few people were using
> Location and Mapset with capital letter which could say that it is a
> something like files format or spatial database name. I aimed to address
> the things I considered confusing. I'm not sure about the GRASS GIS data
> directory as I mentioned earlier.
>
> Now it is higher then the old one but with removal of the image it will be
> smaller. If a small-enough image is used, it could be the same. I would
> like to not include the image to have more space for the error messages
> (currently one line between GISDBASE and Location boxes), so messages can
> be longer and perhaps some what to do next tips can be shown as well. The
> position of this text can/should be changed, now middle of the window
> (usually these are at the bottom or at the top). However, without image it
> might be actually a little boring.
>
> I reorganized the buttons to manage the (list of) Locations and (list of)
> Mapsets, so now it looks like any other lists, e.g. in Simple Layer Manager
> or in Cartographic Composer. In future we can add buttons, for example
> unpack a zipped location or download sample datasets in case of Locations
> and show existing maps button in case of Mapsets.
>
> A "Skip" button can be added next to Start button, once implemented. I
> think that XY location in /tmp/grassdata would be appropriate.
>
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073268.html
> http://lists.osgeo.org/pipermail/grass-dev/2015-January/073266.html
>
> ___
> 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] New splash screen for GRASS GIS 7?

[Yann Chemin]

On 22 January 2015 at 03:25, Markus Neteler  wrote:

> On Wed, Jan 21, 2015 at 8:16 PM, Moritz Lennert
>  wrote:
> > On 21/01/15 19:35, Markus Neteler wrote:
> >> In my opinion we should not have the location selection dialog at all.
> >> Revolution!
> >>
> >> We should start GRASS right away in latlong like most GIS in the world.
> >>
> >> Then let the user open the dialog to change projection if desired from
> >> inside.
> >>
> >> This would avoid a lot of questions right away.
> >
> > Please don't do this !
>
> OK, now being back from phone to a real keyboard, I can write a few more
> lines.
>
> I am thinking about this issue for seeral years meanwhile (hint: I
> started in 1993 to use the software, getting stuck at the text start
> screen not having a manual :-).
>
> So my full suggestions are
> - beautify the actual screen (hence my recent suggestion which is
> lively discussed here),
> - optionally (!) allow to start GRASS without welcome/loc/mapset
> screen but to open it in LatLong as described above. Again, as an
> option. We could implement that in trunk and see how it goes. All the
> tools to select locations, projections and such are there.
>
> I can concur on the feeling of being lost but most students. What about a
grass70 -b flag for "beginner" or something like this. That means we can
work through the discovery straight "out of the box". It would be even
easier to have a MSWin Icon using that option installed on the desktop
directly, if we are looking at lowering the entry/discovery level. It could
have a "beginner' infographic to direct new users to this one first.


> > I find the fact that GRASS does not provide a default
> > projection system, but forces the user to think about projection from the
> > start, one of its strengths, both for work and for teaching.
>
> On of it strenghts, yes. But I have been teaching GRASS a lot to GIS
> professionals who got trained on different systems. And many asked
> "why this screen? why cannot you just start like the other GIS"? And I
> tend to agree (again: optionally). The point is that we, on the
> contrary to many other GIS, still have all the control mechanisms in
> place which avoid that the user mixes projections. So that's all fine.
>
> Also in Portland at the FOSS4G conf (where I showcased GRASS GIS 7)
> people suggested to let 'em get into the system right away. They
> explained to me that a newcomer wants to see the menu to understand
> how powerful the system is. But they would get stuck at the welcome
> screen... Yes, and they don't want to think before they open the
> program but "just try", out of curiosity.
>
> Perhaps we should move this discussion to a different thread and leave
> this to the splash/welcome screen modernization.
>
> Best
> Markus
> ___
> 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] New splash screen for GRASS GIS 7?

[Yann Chemin]

On 21 January 2015 at 22:54, Markus Neteler  wrote:

> On Wed, Jan 21, 2015 at 6:03 PM, Vaclav Petras 
> wrote:
> > Please, have a look at my suggestion in the attachment for
> welcome/startup
> > screen/window. It contains a graphics but it has small height. Title and
> > whole upper part is changed.
>
> Nice - perhaps the "Welcome to GRASS GIS." should be simply removed to
> shorten that line.
>

+1


> (the word "Welcome" can go into the splash screen)
>
> > Note that it is actually done in code, so it is
> > pretty precise, except for the graphics which was done just quickly. The
> > gray in the background of the image is the one of the window done using
> > transparency so it should always match with the window. Unfortunately,
> this
> > will fail miserably when somebody has dark window background color or
> green
> > one (text or logo will be invisible).
>
> If technically possible as a test if the window background is dark and
> if yes, replace transparency with some white?
>
> Transparency of the picture can be set to 50% white, it should failsafe
most conditions of background, while blending to some amount with the
background



> > I would also like to change some terms used in the startup window.
> Namely,
> > avoid using ambiguous word "project". If it is not clear, use "GRASS
> > location", otherwise just "location". Same for mapset. We should also let
> > the translators know that location and mapset should not be translated,
> or
> > translated very carefully.
>
> The "project" has been introduced in the past to de-confuse user
> coming from "other" GIS.
> "Location" alone is not quite clear I fear.
>
> > Perhaps also, "Start GRASS" should be replaced by
> > "Start GRASS session" which is something we avoid in documentation but
> it is
> > quite crucial to understand how it works.
>
> Good point.
>
> Markus
> ___
> 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] New splash screen for GRASS GIS 7?

[Yann Chemin]

I would like to add a +1 about how elegance helps adapting and eventually
adopting.

This is certainly to add to the group of discussions on user workflows and
user efficiency designs.

On 21 January 2015 at 12:28, Michael Barton  wrote:

>  In fact, wxPython for Mac at least, doesn’t look very Mac like. The
> windows versions I’ve seen don’t look particularly close to the current
> version of Windows either. This is unsurprising since wxPython focuses on
> cross-platform functionality. It needs to work the same across multiple
> platforms. To do that, it has a default appearance that sacrifices some
> degree of design elements that would make it look more like the platform it
> is running on. Just going with the default look in a GUI platform is not
> necessarily a virtue because it tends to be a lowest common
> denominator. However, wxPython also allows users to alter that default to
> some degree. It has ways of specifying fonts and colors that can propagate
> in equivalent ways across all platforms, for example. Giving GRASS a
> distinctive visual appearance is not a vice to be avoided, as long as both
> function and visual elements propagate in an equivalent way across multiple
> platforms. Design elegance can enhance functionality as well. Of course,
> designing an elegant as well as functional interface across multiple
> platforms is challenging. The iconography designed for GRASS, with a visual
> grammar, is a nice example of combining elegant design with functionality.
> We don’t always have the skills or time or other resources to do this
> throughout the program, of course. And interface defaults in wxPython are
> better than poorly executed customizations, which may function
> inconsistently as well as look bad. But interface customization and
> enhancement doesn’t need to be avoided on principle.
>
>  Michael
>
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>  On Jan 20, 2015, at 11:09 PM, Vaclav Petras  wrote:
>
>
>
>  On Wed, Jan 21, 2015 at 12:12 AM, Michael Barton 
>  wrote:
>
>>
>>
>>
>>  On Jan 20, 2015, at 9:49 PM, Vaclav Petras  wrote:
>>
>>
>>
>> On Tue, Jan 20, 2015 at 11:40 PM, Michael Barton 
>>  wrote:
>>
>>>
>>>
>>>  On Jan 20, 2015, at 9:22 PM, Vaclav Petras 
>>> wrote:
>>>
>>>
>>> On Sat, Jan 17, 2015 at 10:14 AM, Vaclav Petras 
>>> wrote:
>>> >
>>> > I'm not really concerned about splash screen but I think we should
>>> change the Welcome screen/window. My suggestion is to simply remove the
>>> picture and the sentence "Welcome to...open source GIS". This will save a
>>> lot of vertical space which will be great advantage for small screens, for
>>> example virtual box instances (the default screen size I got with
>>> VirtualBox and OSGeoLive was not enough to accommodate this window). The
>>> other reason why we need to save vertical space is actually a need to add
>>> more things. There is "one row" for error message but I would like to see
>>> this replaced by a block with info box for errors, warnings and general
>>> help messages (e.g., what to do next).
>>>
>>>
>>>   IMHO, this kind of stuff does not belong on the spash screen. Errors
>>> and warnings (hopefully there are none) already show up in the terminal
>>> window, and we have help available on the main start up screen.
>>>
>>>  The splash is an entry—and an advertisement—for GRASS. Looking nice is
>>> actually important, but especially for a piece of high end visual software.
>>> I don’t think we should make the first view that people have when they
>>> start GRASS be boring or ugly just to accommodate tiny screens. It would be
>>> nice if there are any with graphic design expertise who could weigh in here.
>>>
>>>  The splash screen is replaced shortly by the (much more prosaic) main
>>> start up screen anyway. So why not keep it something that has visual appeal.
>>>
>>>Sorry for the confusion. I'm speaking about welcome/start/setup/
>> window which actually appears *before* the splash screen and it has an old
>> school picture which just eats vertical space. See the following links (or
>> start GRASS :-).
>>
>> http://grass.osgeo.org/grass71/manuals/grass_start.png
>> http://grass.osgeo.org/grass71/manuals/helptext.html
>>
>>
>>  OK. I was talking about the Medieval map, which was the start of the
>> thread. I’d suggested the first real world map, with some welcome text.
>> Even better would be doing something with visual impact with a historic map
>> or some other display (we already have OpenGL loaded…). But that would take
>> someone with the needed graphic skills. A colorful map and some good text
>> is st

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Yann Chemin]

Some GIS splash screens:

http://words.mixedbredie.net/wp-content/uploads/2012/07/qgis01.jpg
http://2.bp.blogspot.com/-o-bL_x1YHAU/Uzl1Fr12ccI/HWs/RHem7hUjGFU/s1600/valmiera.png
http://live.osgeo.org/_images/kosmo_splash_screen.png
http://lh5.ggpht.com/_-qSzNjsg2KI/SkZyn9u7yNI/CAk/muhRFmiIL7c/s400/splash.png
http://www.processamentodigital.com.br/wp-content/uploads/2015/01/QGIS26_Splash.png
http://3.bp.blogspot.com/_b8ANhhOsL_Y/TObU5L2e6pI/AMs/QcMiUFtJiGc/s1600/qgis16.png
http://1.bp.blogspot.com/--hIILBxlAEg/VCAbutt6u6I/AAABy0A/LFPmp7KQNbo/s1600/beegis_splash.bmp
http://cartolab.udc.es/cartoweb/wp-content/uploads/2011/05/Clean_buffer_splash.png
http://4.bp.blogspot.com/-tB80BWUKX-I/VCAbbDliO_I/AAAByzw/W0LMaL1Q86A/s1600/splash.bmp


>From the legions of marketters...
---
http://2.bp.blogspot.com/-t-KVH1Loht8/T1T-N_e6_JI/FQM/5HHErdym1G0/s320/prerelease.png
http://3.bp.blogspot.com/_csZhg8ZmSWM/TCrT_DMRzdI/Bks/06siJHptxTo/s1600/ArcGIS+10+splash.PNG
http://www.geocap.no/sites/default/files/imagecache/storyimgsub/splash-01.png
http://sartechnology.ca/sartechnology/IncidentCommander_SplashScreen2.jpg
http://civilsuite.com/splash_backdrop.jpg


Some splashs from apps related to mapping
--
http://www.avenza.com/sites/default/files/images/pdfmaps-header-gwf2.png
http://www.mapitfast.com/images/MapItFast_Splashscreen.jpg
http://images.spatiallyadjusted.com/ArcGIS-for-iOS-Splash.PNG


"Welcome screens" returned this...
http://d32ogoqmya1dw8.cloudfront.net/images/eet/pmel/my_world_welcome_550.jpg
http://gtispk.com/images/temp/post_img_big_27_1.jpg







On 21 January 2015 at 10:42, Michael Barton  wrote:

>
>
>
>  On Jan 20, 2015, at 9:49 PM, Vaclav Petras  wrote:
>
>
>
> On Tue, Jan 20, 2015 at 11:40 PM, Michael Barton 
> wrote:
>
>>
>>
>>  On Jan 20, 2015, at 9:22 PM, Vaclav Petras  wrote:
>>
>>
>> On Sat, Jan 17, 2015 at 10:14 AM, Vaclav Petras 
>> wrote:
>> >
>> > I'm not really concerned about splash screen but I think we should
>> change the Welcome screen/window. My suggestion is to simply remove the
>> picture and the sentence "Welcome to...open source GIS". This will save a
>> lot of vertical space which will be great advantage for small screens, for
>> example virtual box instances (the default screen size I got with
>> VirtualBox and OSGeoLive was not enough to accommodate this window). The
>> other reason why we need to save vertical space is actually a need to add
>> more things. There is "one row" for error message but I would like to see
>> this replaced by a block with info box for errors, warnings and general
>> help messages (e.g., what to do next).
>>
>>
>>   IMHO, this kind of stuff does not belong on the spash screen. Errors
>> and warnings (hopefully there are none) already show up in the terminal
>> window, and we have help available on the main start up screen.
>>
>>  The splash is an entry—and an advertisement—for GRASS. Looking nice is
>> actually important, but especially for a piece of high end visual software.
>> I don’t think we should make the first view that people have when they
>> start GRASS be boring or ugly just to accommodate tiny screens. It would be
>> nice if there are any with graphic design expertise who could weigh in here.
>>
>>  The splash screen is replaced shortly by the (much more prosaic) main
>> start up screen anyway. So why not keep it something that has visual appeal.
>>
>>Sorry for the confusion. I'm speaking about welcome/start/setup/
> window which actually appears *before* the splash screen and it has an old
> school picture which just eats vertical space. See the following links (or
> start GRASS :-).
>
> http://grass.osgeo.org/grass71/manuals/grass_start.png
> http://grass.osgeo.org/grass71/manuals/helptext.html
>
>
>  OK. I was talking about the Medieval map, which was the start of the
> thread. I’d suggested the first real world map, with some welcome text.
> Even better would be doing something with visual impact with a historic map
> or some other display (we already have OpenGL loaded…). But that would take
> someone with the needed graphic skills. A colorful map and some good text
> is still tasteful.
>
>  I also agree that the start screen needs some love too. It is boring
> grey and has a dated image at the top—which is what it seems you are
> talking about, right?
>
>  Your nice green lettering on a light background would give it a nice
> clean look. FWIW, it would be classy to have the entire dialog an equally
> lighter shade too, with green or dark grey lettering in a nice font for the
> text outside of the wxPython control widgets.
>
>  I still wouldn’t put error messages on this dialog because it already
> has a lot of information and controls, and we need people to focus on what
> is needed to run GRASS. Maybe a more prominent help button because no one
> seems to notice it.
>
>  Michael
>
>
> C. Michael Barton
> Director, Ce

[GRASS-dev] anybody working on i.spec.unmix right now?

[Yann Chemin]

Hi,

I am in need of i.spec.unmix,

I see there is some work done to replace libmeschach functions with GRASS
Matrix functions. Is there somebody working actively on that?

What is the road map for this module port to G7?
Thanks
Yann

-- 

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

Re: [GRASS-dev] [GRASS-SVN] r64253 - grass-addons/grass7/imagery/i.spec.sam

[Yann Chemin]

Thanks Martin, done in r64256

On 20 January 2015 at 20:36, Martin Landa  wrote:

> 2015-01-20 16:04 GMT+01:00 Yann Chemin :
> > tentatively replaced by:
> > if (G_verbose == 3)
> > {
> > m_output(A);
> > }
> >
> > is that OK?
>
> no, should be
>
> if (G_verbose() > G_verbose_std())
>
> Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
>



-- 

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

Re: [GRASS-dev] [GRASS-SVN] r64253 - grass-addons/grass7/imagery/i.spec.sam

[Yann Chemin]

Hi Vaclav,

I have replaced all but one (in i.spec.sam/open.c):

if (!flag_quiet->answer)
{
m_output(A);
}

tentatively replaced by:
if (G_verbose == 3)
{
m_output(A);
}

is that OK?

Thanks
Yann


On 20 January 2015 at 20:15, Yann Chemin  wrote:

> Thanks Vaclav,
>
> will try.
>
> Yann
>
> On 20 January 2015 at 19:28, Vaclav Petras  wrote:
>
>>
>> On Tue, Jan 20, 2015 at 8:29 AM,  wrote:
>>
>>> Fixed the flag.quiet structure issue
>>
>>
>> This should be replaced with G_verbose_message()
>>
>> ___
>> 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-SVN] r64253 - grass-addons/grass7/imagery/i.spec.sam

[Yann Chemin]

Thanks Vaclav,

will try.

Yann

On 20 January 2015 at 19:28, Vaclav Petras  wrote:

>
> On Tue, Jan 20, 2015 at 8:29 AM,  wrote:
>
>> Fixed the flag.quiet structure issue
>
>
> This should be replaced with G_verbose_message()
>
> ___
> 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] porting i.spec.sam to grass7

[Yann Chemin]

Seems to be the last hurdle..
ogr_api.h

In file included from
/home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/digit.h:3:0,
 from
/home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vector.h:4,
 from main.c:27:
/home/yann/dev/grass_yann/dist.x86_64-unknown-linux-gnu/include/grass/vect/dig_structs.h:27:21:
fatal error: ogr_api.h: No such file or directory
 #include 
 ^
compilation terminated.
--




On 19 January 2015 at 22:31, Markus Neteler  wrote:

> On Mon, Jan 19, 2015 at 5:31 PM, Yann Chemin  wrote:
> > Hi,
> >
> > porting to grass7 i.spec.sam (grass-addons/grass7/imagery/)
> >
> > I am getting a set of complaints like this:
> >
> > OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple
> definition
> > of `Avector'
> >
> OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92:
> > first defined here
> >
> > while it is actually defined in global.h, and global.h is read in main.c
> as
> > well as in spectral_angle.c . The line 92 in main.c is the first
> appearance,
> > without declaring Avector (just using it).
>
> [neteler@pgis_north i.spec.sam]$ grep Avector *.h
> global.h:GLOBAL VEC *b, *Avector;
>
> I guess the GLOBAL declarations need to be fixed as time ago in other
> GRASS modules using "extern". See for example:
>
> http://trac.osgeo.org/grass/changeset/32675/grass/trunk/raster/r.to.vect
>
> Markus
>



-- 

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

[GRASS-dev] porting i.spec.sam to grass7

[Yann Chemin]

Hi,

porting to grass7 i.spec.sam (grass-addons/grass7/imagery/)

I am getting a set of complaints like this:

OBJ.x86_64-unknown-linux-gnu/spec_angle.o:(.bss+0x158): multiple definition
of `Avector'
OBJ.x86_64-unknown-linux-gnu/main.o:/home/yann/dev/grass-addons/grass7/imagery/i.spec.sam/main.c:92:
first defined here

while it is actually defined in global.h, and global.h is read in main.c as
well as in spectral_angle.c . The line 92 in main.c is the first
appearance, without declaring Avector (just using it).

Yann
-- 

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Yann Chemin]

I for one, will welcome our new @!SPLASH!@ ...

Yes +1

any wiki page to submit?

On 17 January 2015 at 16:21, Markus Neteler  wrote:

> Hi,
>
> I'd suggest, in order to clearly distinguish G6 from G7, to replace
> the current splash screen for the upcoming G7.0.0 release.
> We may consider to get community contributions for this.
>
> What do you think?
>
> Markus
> ___
> 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] Planning GRASS GIS 7.0.0RC1

[Yann Chemin]

In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

On 16 January 2015 at 20:31, Markus Metz 
wrote:

> On Fri, Jan 16, 2015 at 1:27 PM, Moritz Lennert
>  wrote:
> > On 16/01/15 12:15, Martin Landa wrote:
> >>
> >> Hi,
> >>
> >> 2015-01-16 12:13 GMT+01:00 Markus Metz :
> >>
> >>> Can we please get RC2 out soon? In the last days I have fixed numerous
> >>> bugs in the vector library and changed/restored the basic vector IO
> >>> interface, it is now more similar to G6 and it needed some code clean
> >>> up.
> >
> >
> > Thanks for all this work ! Could you explain a bit more on what types of
> > bugs this fixed ?
>
> The first set of bugs was related to vector topology.
>
> Bug 1 affected point-in-polygon tests, a basic geometry function. The
> affected functions were Vect_point_in_area(),
> Vect_point_in_area_outer_ring() and Vect_point_in_island() which
> returned sometimes the wrong result (point outside instead of inside
> or vice versa). This in turn affected the functions
> Vect_attach_centroids(), Vect_attach_isle() and Vect_attach_isles()
> which are needed to update topology when boundaries are added, deleted
> or modified.
>
> Bug 2 was in Vect_attach_centroids() andVect_attach_isles(). Centroids
> and isles were not properly reattached when boundaries are added,
> deleted or modified. These bugs still need to be fixed in G6.
>
> Bugs 1 + 2 meant that (re)attaching centroids and isles during vector
> modification was not working well, a fairly important feature for
> modifying vector topology.
>
> The modifications related to basic vector IO fixed some bugs
> introduced in G7. Some functions were only working with topology, even
> though equivalent functions not requiring topology are available. A
> newly introduced test prevented access to the non-topological
> variants. Further on, some function definitions were changed such that
> new arguments were introduced that were not used/not needed. I have
> syncronized the IO interface and updated the documentation. It is now
> more similar to G6 and some functions have become non-topological
> equivalents (interesting for large point clouds).
>
> >
> >>
> >> I agree, but would suggest to wait at least one/two week(s), probably
> >> more bugfixes will be collected.
> >>
> >
> > As these seem to be modifications in fundamental library functions, I
> would
> > plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for
> 1
> > week, not 2. That way these modifications will get a bit more testing
> before
> > the final release.
>
> I would plead for 1 day rather than 1 week.
>
> >
> > This is one example of why the proposed release procedure [1] contains
> this:
> >
> > "Any backports during the soft freeze should be announced on the
> developers
> > mailing list with 24 hours advance to allow possible discussion."
> >
> > Maybe this should be extended to "Any backports or extensive bug fixes
> > during..." ?
> >
> > If these changes had been announced, we could have delayed RC1 for a few
> > days...
>
> I discovered the bugs only in the last days and tried to get them
> fixed as soon as possible, but some of the bugs were rather obscure
> and I had no idea how quickly I would be able to find their reason and
> fix them. The fixes are all thoroughly tested (I guess I have never
> before tested vector topology so thoroughly...).
>
> Markus M
>
> >
> > Moritz
> >
> > [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
> ___
> 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] Managing temperature logger data in GRASS 7

[Yann Chemin]

Yes I am interested Stefan

On 16 January 2015 at 15:55, Blumentrath, Stefan  wrote:

>  Dear devs,
>
>
>
> In my institute several colleagues use (different types of) temperature
> logger in order to collect primary temperature data with more relevance for
> local vegetation than the coarse air temperature data we get from our
> meteorological institute.
>
>
>
> Different types of loggers are used in different projects with different
> purposes, for different time periods, at different places, measuring
> different parameters (some measure temperature in Farenheit, others in
> Celsius, some collect also lux, others humidity)…
>
>
>
> Nevertheless I would like to collect all data (also data of that kind we
> will collect in future) in one DB, which will have at least three
> interlinked tables:
>
> 1)  One (non-spatial) table describing the projects (which have
> several logger placed with a given purpose)
>
> 2)  One (spatial) table describing the different logger
>
> 3)  One (non-spatial) table containing the “real time series” with
> different parameters measured.
>
> Between 2 and 3 we probably need another layer with sampling periods
> (because loggers may be slightly (and spatially insignificantly) moved
> which may have an effect on measurements…), but I hope this can be avoided…
>
>
>
> For the technical solution I am considering two alternatives:
>
> GRASS 7 or QGIS/PostGIS.
>
>
>
> What I have in mind is an interface for managing the data for the three
> named tables where the interface for 3) mainly is meant for importing data
> from the different temperature logger used (here I will get various
> raw-data formats).
>
> My current preference would be to use GRASS because of the TGIS concept.
> However, I would have to acquaint myself a bit more with the concept of
> STVDS as I up to now mainly worked with STRDS! As you can imagine the data
> will be rather fragmented (from a space-time-perspective) which makes me
> unsure if they really are suitable for TGIS…
>
>
>
> Anyway, my question is: Anyone interested in such a “temperature-logger
> feature” in GRASS 7 (however that may look like in the end) who would be
> willing to give me feedback on or help developing the concept and possibly
> assist when I meet challenges which I cannot overcome myself?
>
> Or would you advise me not try to get data with such varying
> characteristics into one DB (because it would be a rather significant job)?
>
>
>
> For the interested: I could provide some example data…
>
>
>
> All the best,
>
> Stefan
>
>
>
> ___
> 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] Planning GRASS GIS 7.0.0RC1

[Yann Chemin]

+1 Markus !

On 14 January 2015 at 14:19, Moritz Lennert 
wrote:

> On 14/01/15 09:29, Markus Neteler wrote:
>
>> On Fri, Jan 2, 2015 at 10:22 PM, Markus Neteler 
>> wrote:
>>
>>> Hi devs,
>>>
>>> proposal for new RC1 release date: 14 Jan 2015.
>>> Let's please manage to keep that date if you agree.
>>>
>>> http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
>>>
>>
>> The RC1 release is due today :-)
>> The planning list is looking good to me. And it is not the final but
>> RC1 release.
>>
>> If there are no objections, I'll tag later today.
>>
>
> Go for it !
>
> Moritz
>
> ___
> 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

[GRASS-dev] irc #grass channel says tests grass 6.4

[Yann Chemin]

Hi guys,

IRC says:

* Now talking on #grass
* Topic for #grass is: GRASS GIS - http://grass.osgeo.org - Logs at
http://irclogs.geoapt.com/grass/ - Paste code at http://osgeo.pastebin.com/
- Please test http://wingrass.fsv.cvut.cz/grass64/

Maybe time to upgrade that line?


-- 

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

Re: [GRASS-dev] G70 Ubuntu: GUI menu access for i.eb.hsebal01 looks for i.eb.h_sebal01

[Yann Chemin]

maybe creating a directory in user with two significant number for the
version might help in this case

but not sure it is in the general interest.

.grass7/toolboxes/menudata.xml
->
.grass70/toolboxes/menudata.xml

On 2 January 2015 at 06:49, Vaclav Petras  wrote:

>
> On Wed, Dec 31, 2014 at 11:06 AM, Markus Neteler 
> wrote:
>
>> On Wed, Dec 31, 2014 at 3:52 PM, Yann Chemin  wrote:
>> > indeed Markus,
>> >
>> > it is using an old file from:
>> > /home/yann/.grass7/toolboxes/menudata.xml
>> >
>> > Correcting that file makes it OK.
>>
>> Good. But do you need that file at all?
>>
>> The file is generated if you have your custom menu and/or toolboxes
> defined.
>
>
>> > Deleting it makes it follow the PPA version.
>>
>> Perfect. Not sure if we could auto-detect an outdated toolbox file
>
>
> We do that for user-created files but not for the files in the
> distribution; it just didn't seem important at the time of writing.
>
> See:
>
>
> http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/toolboxes.py
>



-- 

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

Re: [GRASS-dev] G70 Ubuntu: GUI menu access for i.eb.hsebal01 looks for i.eb.h_sebal01

[Yann Chemin]

indeed Markus,

it is using an old file from:
/home/yann/.grass7/toolboxes/menudata.xml

Correcting that file makes it OK.
Deleting it makes it follow the PPA version.

Welcome page does show GRASS  version 7.

Additional things:
the rev number in the welcome page indicates (r0)
The WxGUI window header say:
GRASS GIS ? Layer Manager
GRASS GIS ? Map Display: 1 - Location: GRASSDB@PERMANENT


On 31 December 2014 at 17:59, Markus Neteler  wrote:

> On Wed, Dec 31, 2014 at 12:44 PM, Yann Chemin  wrote:
> > Hi,
> >
> > just got the Ubuntu PPA being worked out for G70.
> > it looks like there is a name issue in the Imagery menu looking for
> > i.eb.h_sebal01 instead of i.eb.hsebal01.
>
> Can you please search for the file? Because in SVN is all ok:
>
> cd grass70/gui/wxpython/
>
> grep i.eb.hsebal01 */*
> xml/menudata.xml:  i.eb.hsebal01
> xml/module_tree_menudata.xml:  i.eb.hsebal01
> xml/toolboxes.xml:  
>
> Either the version you installed is outdated or something else happened.
>
> Markus
>



-- 

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

[GRASS-dev] G70 Ubuntu: GUI menu access for i.eb.hsebal01 looks for i.eb.h_sebal01

[Yann Chemin]

Hi,

just got the Ubuntu PPA being worked out for G70.
it looks like there is a name issue in the Imagery menu looking for
i.eb.h_sebal01 instead of i.eb.hsebal01.

Cheers,
Yann

-- 

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

Re: [GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

[Yann Chemin]

Would it make sense to let it be separate?
On Dec 20, 2014 11:52 PM, "Nikos Alexandris" 
wrote:

> Dear all,
>
> I want to integrate the "AHPF" fusion algorithm,  [0], into
>  [1]. And I need some assistance.
>
>
> 1.  has the following, simple, interface:
>
> i.pansharpen [-sl] red=name green=name blue=name pan=name
>output=basename method=value [--overwrite] [--help] [--verbose]
>[--quiet] [--ui]
>
> plus
>
> Flags:
>   -s   Serial processing rather than parallel processing
>   -l   Rebalance blue channel for LANDSAT
>
>
> while the HPF implementation looks like:
>
> i.fusion.hpf [-l2c] pan=filename msx=filename(s)[,filename(s),...]
>outputsuffix=suffix string [ratio=rational number] [center=string]
>[center2=string] [modulation=string] [modulation2=string]
>[trim=rational number] [--overwrite] [--help] [--verbose] [--quiet]
>[--ui]
>
> plus
>
> Flags:
>   -l   Linearly match histogram of Pan-sharpened output to Multi-Spectral
> input
>   -2   2-Pass Processing (recommended) for large resolution ratio (>=5.5)
>   -c   Match color table of Pan-Sharpened output to Multi-Spectral input
>
>
> While the first module appears to be simple and straightforward, it has
> its limitations (rgb required, underlying ihs method restricted to 8-bit
> data). The second module appears complex, but it works right away by simply
> feeding a pan and a multi-spectral band (or bands) and, offers many
> fine-tuning options.
>
> 2.  has the R-G-B logic hardcoded (one pan and three
> multi-spectral bands required), while  will work simply with
> a pan and only one or any number of multiple low-resolution bands.
>
> If all of the fine-tuning options for HPF will be merged into
> i.pansharpen, it'll get "heavy" and complex.  I am asking for help to
> design the integration (not for the actual coding).  Any ideas?
>
>
> Thank you, Nikos
>
>
> --
> [0] 
> [1] 
> ___
> 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] group does not update REF file upon g.remove raster file

[Yann Chemin]

Hi,

1 create group
2 g.remove one map listed in the group
3 check the REF file list to see if the map name is still there.
On Dec 19, 2014 5:09 AM, "Huidae Cho"  wrote:

> Yann,
>
> Please be more specific. What is the group REF file and how can I
> replicate your issue? And what do you expect to happen?
>
> Regards,
> Huidae
>
> --
> Sent from my phone
> On Dec 15, 2014 3:49 AM, "Yann Chemin"  wrote:
>
>> Hi,
>>
>> did g.remove a raster, and the group REF file referencing the raster did
>> not update accordingly.
>>
>> Is this a known behaviour?
>> Yann
>>
>> --
>> 
>>
>> ___
>> 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] Invitation to submit an abstract to EGU 2015 session on FOSS for GeoInformatics and Geosciences

[Yann Chemin]

About poster, I am happy to print it and carry it to Vienna, anyone who
contributes should be named as author explicitly, and we can add to the
authors list 'grass development team and grass users'

About poster topic, raster is not there yet to my knowledge. Temporal and
pygrass are also good. Maybe a version 7 poster could be fun too.
On Dec 19, 2014 3:34 AM, "Vaclav Petras"  wrote:

>
>
>
>
> On Thu, Dec 18, 2014 at 2:12 AM, Yann Chemin  wrote:
>>
>> Hi all,
>>
>> Anybody interested to submit some new development,
>> please submit an abstract there:
>> http://www.egu2015.eu/abstract_management/how_to_submit_an_abstract.html
>>
>> The Session is:
>> --
>> ESSI2.13/SSS1.8
>> Free and Open Source Software (FOSS) for Geoinformatics and Geosciences
>> (co-organized)
>>
>>
> I'm not going there but we (grass users and devs) should definitively do
> again a GRASS-focused poster. So far we have the general GRASS poster,
> imagery and vector. I though we have also some raster poster but I don't
> see it in SVN [1], is it somewhere else? Testing framework now also have a
> poster [2]. As I see it, the possible topics are:
>
> Temporal framework
> basic concepts, API overview and use cases
> There is a lot of people who already use it. If we list our use cases, it
> could be pretty good and very different from the original TGRASS paper.
>
> GRASS and Python
> This would cover PyGRASS but also grass.script, .temporal, and .gunittest
> A lot of people didn't notice that it is possible to use Python until
> PyGRASS and Python API is considered experimental in G64, so it make sense
> to do an overview.
>
> There are other topics I would like to see but I'm not able to contribute
> to them much. Topics which would be more about the usage of GRASS, but
> would feature it, could be even better. However, this should be in
> different session and it is really up to the concrete scientists rather
> than general community.
>
> By the way, are the posters and other material from grass-promo somewhere?
> I'm wondering if it would be better to have these things on GitHub or
> something similar. It is a bit more flexible considering access rights and
> you get (possibility of) web pages automatically.
>
> Vaclav
>
> PS: I haven't mentioned authors but I think it's clear how it should work
> whoever wants to join can join and authors of the code are included or will
> be attributed in the poster.
>
> [1] http://trac.osgeo.org/grass/browser/grass-promo/grassposter
> [2]
> http://grasswiki.osgeo.org/wiki/AGU_Fall_Meeting_2014:_GRASS_related_presentations_and_posters
> (I will post announcement on G+ soon.)
>
>
>> Hope we can meet around some excellent fresh beer...
>> Cheers,
>> Yann
>>
>> --
>> 
>>
>> ___
>> 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

[GRASS-dev] Invitation to submit an abstract to EGU 2015 session on FOSS for GeoInformatics and Geosciences

[Yann Chemin]

Hi all,

Anybody interested to submit some new development,
please submit an abstract there:
http://www.egu2015.eu/abstract_management/how_to_submit_an_abstract.html

The Session is:
--
ESSI2.13/SSS1.8
Free and Open Source Software (FOSS) for Geoinformatics and Geosciences
(co-organized)

Hope we can meet around some excellent fresh beer...
Cheers,
Yann

-- 

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

[GRASS-dev] group does not update REF file upon g.remove raster file

[Yann Chemin]

Hi,

did g.remove a raster, and the group REF file referencing the raster did
not update accordingly.

Is this a known behaviour?
Yann

-- 

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

Re: [GRASS-dev] Rast_add_d_colour

[Yann Chemin]

Yes Glynns, that was my missing part, writing the file.  and sleep too.
:-)

On 8 December 2014 at 10:37, Glynn Clements 
wrote:

>
> Yann Chemin wrote:
>
> > OK, I found why I got lost in all that...
> > there is no file appearing in colr/ with the rules made in the code.
>
> Are you calling Rast_write_colors()?
>
> Also, if the map isn't in the current mapset, the file will go into
> /colr2// rather than the mapset
> containing the map.
>
> --
> Glynn Clements 
>



-- 

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

Re: [GRASS-dev] Rast_add_d_colour

[Yann Chemin]

OK, I found why I got lost in all that...
there is no file appearing in colr/ with the rules made in the code.




On 7 December 2014 at 06:51, Yann Chemin  wrote:

> Thanks,
> Will try again today.
>  On Dec 7, 2014 3:36 AM, "Vaclav Petras"  wrote:
>
>>
>>
>> On Sat, Dec 6, 2014 at 3:59 PM, Markus Metz <
>> markus.metz.gisw...@gmail.com> wrote:
>>
>>> Yann Chemin wrote:
>>> > Hi,
>>> >
>>> > I am working on beautifying the output of i.theilsen, a new addon.
>>> >
>>> > For some reason, I cannot apply a grayscale palette.
>>> > ---
>>> > Rast_init_colors(&colors);
>>> > DCELL val1 = ts_min;
>>> > DCELL val2 = ceil(ts_max);
>>> > Rast_add_d_color_rule(&val1, 0, 0, 0, &val2, 255, 255, 255, &colors);
>>> > ---
>>> >
>>> > ts_min, ts_max are known from the data processed,
>>> > val1 and val2 are declared as DCELL instead of const DCELL as required,
>>> > but if I declare const DCELL val1, then I cannot write stats to it for
>>> > palette definition...
>>> >
>>> > What I am doing wrong?
>>>
>>> If you declare const DCELL val1, you can not pass a pointer to val1 to
>>> another function, because this other function could then easily modify
>>> to contents of that pointer.
>>
>>
>> This is of course true.
>>
>>
>>> Rast_add_d_color_rule() requires const
>>> DCELL *, not const DCELL.
>>>
>>
>> Strange, (generated) documentation says const DCELL * [1] which fits with
>> the source code [2, 3].
>>
>> I haven't tried compile anything now but isn't `const DCELL` constant
>> (value) and `const DCELL *` pointer to constant value. While `const DCELL *
>> const` would be constant pointer to constant value.
>>
>> Also
>>
>> const DCELL val;
>> const DCELL * pval = &val;
>>
>> should work and carry on the constness which is exactly what should be
>> happening when calling the Rast_add_d_color_rule() function.
>>
>> So, I don't understand.
>>
>> Vaclav
>>
>> [1]
>> http://grass.osgeo.org/programming7/color__rule_8c.html#a160535a46694589674f68c60eac23a05
>> [2] lib/raster/color_rule.c:35:void Rast_add_d_color_rule(const DCELL *
>> val1, int r1, int g1, int b1, ...
>> [3] include/defs/raster.h:198:void Rast_add_d_color_rule(const DCELL *,
>> int, int, int, ...
>>
>>
>>> Markus M
>>> ___
>>> 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] Rast_add_d_colour

[Yann Chemin]

Thanks,
Will try again today.
 On Dec 7, 2014 3:36 AM, "Vaclav Petras"  wrote:

>
>
> On Sat, Dec 6, 2014 at 3:59 PM, Markus Metz  > wrote:
>
>> Yann Chemin wrote:
>> > Hi,
>> >
>> > I am working on beautifying the output of i.theilsen, a new addon.
>> >
>> > For some reason, I cannot apply a grayscale palette.
>> > ---
>> > Rast_init_colors(&colors);
>> > DCELL val1 = ts_min;
>> > DCELL val2 = ceil(ts_max);
>> > Rast_add_d_color_rule(&val1, 0, 0, 0, &val2, 255, 255, 255, &colors);
>> > ---
>> >
>> > ts_min, ts_max are known from the data processed,
>> > val1 and val2 are declared as DCELL instead of const DCELL as required,
>> > but if I declare const DCELL val1, then I cannot write stats to it for
>> > palette definition...
>> >
>> > What I am doing wrong?
>>
>> If you declare const DCELL val1, you can not pass a pointer to val1 to
>> another function, because this other function could then easily modify
>> to contents of that pointer.
>
>
> This is of course true.
>
>
>> Rast_add_d_color_rule() requires const
>> DCELL *, not const DCELL.
>>
>
> Strange, (generated) documentation says const DCELL * [1] which fits with
> the source code [2, 3].
>
> I haven't tried compile anything now but isn't `const DCELL` constant
> (value) and `const DCELL *` pointer to constant value. While `const DCELL *
> const` would be constant pointer to constant value.
>
> Also
>
> const DCELL val;
> const DCELL * pval = &val;
>
> should work and carry on the constness which is exactly what should be
> happening when calling the Rast_add_d_color_rule() function.
>
> So, I don't understand.
>
> Vaclav
>
> [1]
> http://grass.osgeo.org/programming7/color__rule_8c.html#a160535a46694589674f68c60eac23a05
> [2] lib/raster/color_rule.c:35:void Rast_add_d_color_rule(const DCELL *
> val1, int r1, int g1, int b1, ...
> [3] include/defs/raster.h:198:void Rast_add_d_color_rule(const DCELL *,
> int, int, int, ...
>
>
>> Markus M
>> ___
>> 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

[GRASS-dev] Rast_add_d_colour

[Yann Chemin]

Hi,

I am working on beautifying the output of i.theilsen, a new addon.

For some reason, I cannot apply a grayscale palette.
---
Rast_init_colors(&colors);
DCELL val1 = ts_min;
DCELL val2 = ceil(ts_max);
Rast_add_d_color_rule(&val1, 0, 0, 0, &val2, 255, 255, 255, &colors);
---

ts_min, ts_max are known from the data processed,
val1 and val2 are declared as DCELL instead of const DCELL as required,
but if I declare const DCELL val1, then I cannot write stats to it for
palette definition...

What I am doing wrong?
Yann
-- 

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

[GRASS-dev] temporal framework used as spectral framework?

[Yann Chemin]

Hi,

just wondering if there is room to use the temporal framework as a basis
for hyperspectral work?

Cheers,
Yann

-- 

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

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory (was: read cvs from GDAL data directory)

[Yann Chemin]

+1
On Oct 20, 2014 10:18 PM, "GRASS GIS"  wrote:

> #2456: read CSV from GDAL data directory
>
> -+--
>  Reporter:  martinl  |   Owner:  grass-dev@…
>  Type:  task |  Status:  new
>  Priority:  normal   |   Milestone:  7.1.0
> Component:  Default  | Version:  unspecified
>  Keywords:  gdal |Platform:  Unspecified
>   Cpu:  Unspecified  |
>
> -+--
> Description changed by martinl:
>
> Old description:
>
> > Currently GRASS contains copy of several CVS files from GDAL
> > source:grass/trunk/lib/proj. It would make sense to modify GRASS
> > libraries to read these files dynamically.
> >
> > Any comments?
>
> New description:
>
>  Currently GRASS contains copy of several CSV files from GDAL
>  source:grass/trunk/lib/proj. It would make sense to modify GRASS libraries
>  to read these files dynamically.
>
>  Any comments?
>
> --
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> 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] Significant r.in.gdal speed-up: predefined 300 MiB as default cache size

[Yann Chemin]

WoW ! Thanks Markus !

On 30 July 2014 21:42, Markus Neteler  wrote:
> Hi,
>
> I have made a modification to r.in.gdal for a (significant) speedup
> (both in trunk and relbranch70).
>
> A nice test case is the European 25m elevation model which is a 23GB
> GeoTIFF file of 4.8 billion raster cells:
>
> gdalinfo /geodata/eudem_dem_3035_europe.tif
> Driver: GTiff/GeoTIFF
> Files: /geodata/eudem_dem_3035_europe.tif
> Size is 24, 20
> Coordinate System is:
> PROJCS["ETRS89 / LAEA Europe",
> ...
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","3035"]]
> ...
> Pixel Size = (25.000,-25.000)
> ...
>
> Previously:
> # using default GDAL cache (~40MB, which is tiny also for gdalwarp etc!)
> GRASS 7.0.0svn (eu_laea):~ > time -p r.in.gdal
> /geodata/eudem_dem_3035_europe.tif \
>   output=eudem_dem_3035_europe
>  100%
> Raster map  created.
> r.in.gdal complete.
> real 279901.23
> user 267876.52
> sys 1456.18
> --> 77h
>
> New:
> # I have now defined 300MB as default cache size (i.e. memory=300)
> GRASS 7.0.0svn (eu_laea):~ > time -p r.in.gdal
> /geodata/eudem_dem_3035_europe.tif \
>   output=eu_dem_25m
>  100%
> Raster map  created.
> r.in.gdal complete.
> real 5381.95
> user 5091.27
> sys 31.03
> --> 1:30h
>
> The user can set different cache sizes via the memory option as
> before. Most probably didn't know about this huge difference, that's
> why I added 300MB as default cache size (rather than keeping the
> original tiny GDAL setting [1]).
>
> If I am not wrong, it took only 2% of the previous time for importing
> this big file.
> Perhaps the GDAL project should reconsider their default cache size as well 
> :-)
>
> enjoy,
> Markus
>
> [1] http://trac.osgeo.org/gdal/wiki/ConfigOptions#GDAL_CACHEMAX
> ___
> 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 7 release planning

[Yann Chemin]

+1

On 21/06/2014, Markus Neteler  wrote:
> Hi devs,
>
> ... so, getting out 7.0 seems to be endless...
>
> A radical solution might be to change trunk into GRASS GIS 8. Then we
> do not need to wait in 7 for API stabilization and can release it "as
> is" and go ahead with the planned massive improvements.
>
> Best
> Markus
> ___
> 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-SVN] r60879 - grass/trunk/lib/gis/colors

[Yann Chemin]

Thank you Markus,

updated in r60889

Yann

On 20/06/2014, Markus Neteler  wrote:
> On Fri, Jun 20, 2014 at 8:33 AM,   wrote:
>> Author: ychemin
>> Date: 2014-06-19 23:33:17 -0700 (Thu, 19 Jun 2014)
>> New Revision: 60879
>>
>> Added:
>>grass/trunk/lib/gis/colors/kelvin
>> Log:
>> Added Kelvin palette
>
> ... this is incomplete, it lacks the description in
> lib/gis/colors.desc
>
> Markus
>


-- 

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

[GRASS-dev] pyGRASS not finding addons?

[Yann Chemin]

Hi,

Running GRASS through pyGRASS with an addon (i.eb.z0m) made this:

Traceback (most recent call last):
  File "L8.py", line 312, in 
i.eb_z0m( input = b_ndvi, output = b_z0m, quiet = QIET, overwrite = OVR )
  File "/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/shortcuts.py",
line 50, in __getattr__
return self.cls('%s.%s' % (self.prefix, name.replace('_', '.')))
  File 
"/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/interface/module.py",
line 272, in __init__
self.params_list = [Parameter(p) for p in tree.findall("parameter")]
  File 
"/usr/local/grass-7.1.svn/etc/python/grass/pygrass/modules/interface/parameter.py",
line 86, in __init__
self.typedesc = diz['gisprompt']['prompt']
KeyError: u'prompt'



-- 

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

[GRASS-dev] i.topo.corr does not appear in the wxGUI menu

[Yann Chemin]

Hi,

For some reason i.topo.corr is not mapped to the menu or tree.


It should appear in:
Imagery=>Satellite images tools=> below i.atcorr entry

Yann
-- 

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

Re: [GRASS-dev] i.atcorr Landsat 8: Unsupported iwave value 116, 117, etc

[Yann Chemin]

Yes SVN,

let me rebuild GRASS manually to be sure it all goes above the rev number.

will comment as needed.
Yann

On 08/06/2014, Markus Neteler  wrote:
> On Sun, Jun 8, 2014 at 2:07 PM, Yann Chemin  wrote:
>> hi, I am trying to run atcorr on a Landsat 8 image, and it says
>
> Is it the current trunk from SVN version?
>
>> LC81270512014115LGN00.toar.1 LC81270512014115LGN00.surf.1
>> iwave no:   115
>> Atmospheric correction...
>>  100% <== NOTE: this one is OK ==><
>> Atmospheric correction complete.
>> LC81270512014115LGN00.toar.2 LC81270512014115LGN00.surf.2
>> iwave no:   116
>> WARNING: Unsupported iwave value: 116
>>  wavelength  less  than  0.25  micron:
>>  let's take s(l)=s(0.25)
>> Atmospheric correction...
>> LC81270512014115LGN00.toar.3 LC81270512014115LGN00.surf.3
>> iwave no:   117
>> WARNING: Unsupported iwave value: 117
>>  wavelength  less  than  0.25  micron:
>>  let's take s(l)=s(0.25)
>> Atmospheric correction...
>> LC81270512014115LGN00.toar.4 LC81270512014115LGN00.surf.4
>> iwave no:   118
>> WARNING: Unsupported iwave value: 118
>> Atmospheric correction...
>>  100%
>> Atmospheric correction complete.
>> LC81270512014115LGN00.toar.5 LC81270512014115LGN00.surf.5
>> iwave no:   120
>> WARNING: Unsupported iwave value: 120
>> Atmospheric correction...
>
> See
> http://trac.osgeo.org/grass/ticket/2305
>
> Comments therein are desired,
>
> Markus
>


-- 

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

[GRASS-dev] i.atcorr Landsat 8: Unsupported iwave value 116, 117, etc

[Yann Chemin]

hi, I am trying to run atcorr on a Landsat 8 image, and it says

LC81270512014115LGN00.toar.1 LC81270512014115LGN00.surf.1
iwave no:   115
Atmospheric correction...
 100% <== NOTE: this one is OK ==><
Atmospheric correction complete.
LC81270512014115LGN00.toar.2 LC81270512014115LGN00.surf.2
iwave no:   116
WARNING: Unsupported iwave value: 116
 wavelength  less  than  0.25  micron:
 let's take s(l)=s(0.25)
Atmospheric correction...
LC81270512014115LGN00.toar.3 LC81270512014115LGN00.surf.3
iwave no:   117
WARNING: Unsupported iwave value: 117
 wavelength  less  than  0.25  micron:
 let's take s(l)=s(0.25)
Atmospheric correction...
LC81270512014115LGN00.toar.4 LC81270512014115LGN00.surf.4
iwave no:   118
WARNING: Unsupported iwave value: 118
Atmospheric correction...
 100%
Atmospheric correction complete.
LC81270512014115LGN00.toar.5 LC81270512014115LGN00.surf.5
iwave no:   120
WARNING: Unsupported iwave value: 120
Atmospheric correction...

...etc.


-- 

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

[GRASS-dev] adding Isis menu to GRASS

[Yann Chemin]

Hi,

I made a bash script to create an Isis menu in GRASS [1].

It scans Isis/bin for applications, makes a list of them according to
keywords and builds the toolbox menu in
"$HOME/.grass7/toolboxes/toolboxes.xml" and a main_menu with Isis
entry in "$HOME/.grass7/toolboxes/main_menu.xml" both also attached.

https://www.youtube.com/watch?v=4O-MY4dBZx4

There are two issues now:
1 - if a toolboxes.xml already exists, it will overwrite it (not wanted?)
2 - if it is in gis_set.py it will regenerate the files each time the
GUI is starting (not wanted)

Yann


[1] 
https://sites.google.com/site/geosnipets/Downhome/Topic2/creatinganisismenuentryingrass

-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

Looking into the Wiki page I got FFMPEG configured by this:

sudo apt-get install libffms2-dev

and from wiki page:

--with-ffmpeg=yes \
--with-ffmpeg-includes="/usr/include/libavcodec
/usr/include/libavformat /usr/include/libswscale
/usr/include/libavutil"



On 31/05/2014, Vaclav Petras  wrote:
> On Sat, May 31, 2014 at 9:32 AM, Yann Chemin  wrote:
>
>> OK it was that thanks Vaclav
>>
>> Summary:
>> sudo apt-get install libboost-thread-dev,libboost-program-options-dev
>> liblas-c-dev
>>
>> in configure options:
>> --with-liblas-config=/usr/bin/liblas-config
>> --with-liblas=yes
>>
>> I updated the wiki for 14.04 and added libLAS packages and added libLAS
>> to
> configure for GRASS 7. I think the page needs some refactoring. I have hard
> time to navigate it when I understand most of the terms but the problem is
> the high number of possibilities.
>
> http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu
>
>
>
>>  On 31/05/2014, Vaclav Petras  wrote:
>> > On Sat, May 31, 2014 at 9:23 AM, Yann Chemin  wrote:
>> >
>> >> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> >> directory
>> >>  #include 
>> >>
>> >
>> > Hm, are you sure you have the liblas-c-dev package? And are you sure
>> > the
>> > file liblas/capi/liblas.h is there (on include path, in case of the
>> > liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>> >
>>
>>
>> --
>> 
>>
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

OK it was that thanks Vaclav

Summary:
sudo apt-get install libboost-thread-dev,libboost-program-options-dev
liblas-c-dev

in configure options:
--with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

On 31/05/2014, Vaclav Petras  wrote:
> On Sat, May 31, 2014 at 9:23 AM, Yann Chemin  wrote:
>
>> configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or
>> directory
>>  #include 
>>
>
> Hm, are you sure you have the liblas-c-dev package? And are you sure the
> file liblas/capi/liblas.h is there (on include path, in case of the
> liblas-c-dev package it should be /usr/include/liblas/capi/liblas.h)?
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

More from config.log (thx MarkusM)

configure:6198: checking whether to use libLAS
configure:6215: checking for liblas-config
configure:6272: gcc -o conftest -g -O2  -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c  -L/usr/lib -llas -llas_c
-L/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libboost_program_options.so
/usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6266:32: fatal error: liblas/capi/liblas.h: No such file or directory
 #include 
^
compilation terminated.
configure: failed program was:
#line 6265 "configure"
#include "confdefs.h"
#include 
int main() {
LASReader_Create("foo");
; return 0; }
configure:6287: gcc -o conftest -g -O2  -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -I/usr/include -I/usr/include/gdal
-I/usr/include/geotiff -I/usr/include/x86_64-linux-gnu
-Wl,--export-dynamic conftest.c  -L/usr/lib -llas -llas_c
-L/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libboost_program_options.so
/usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/libgdal.so
/usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so 1>&5
configure:6281:32: fatal error: liblas/capi/liblas.h: No such file or directory
 #include 
^
compilation terminated.
configure: failed program was:
#line 6280 "configure"
#include "confdefs.h"
#include 
int main() {
LASReader_Create("foo");
; return 0; }


On 31/05/2014, Yann Chemin  wrote:
> Hi,
>
> I have libboost-thread-dev, libboost-program-options-dev, and
> libboost-all-dev installed
> in configure options:  --with-liblas-config=/usr/bin/liblas-config
> --with-liblas=yes
>
> still:
> checking whether to use libLAS... yes
> checking for liblas-config... /usr/bin/liblas-config
> configure: error: *** Unable to locate libLAS library.
>
> Full config script:
> CFLAGS="-g -Wall"
> ./configure --with-cxx --with-wxwidgets --with-freetype=yes
> --with-postgres=no --with-sqlite=yes --without-tcltk
> --enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
> --with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
> --with-lapack --with-gdal=/usr/bin/gdal-config
> --with-proj-share=/usr/share/proj --with-pthread
> --with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
> --with-blas
>
>
> On 30/05/2014, Vaclav Petras  wrote:
>> On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
>> javi.martinez.lo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I had the same problem with the latest grass 71 svn version (from
>>> today) under ubuntu 14.04 and I certainly solved it installing
>>> libboost-all-dev and the config option: --with-liblas=yes
>>> --with-liblas-config=/usr/bin/liblas-config
>>>
>>>
>> Thank you. This was very helpful. The problem was that I included only
>>
>> --with-liblas-config=/usr/bin/liblas-config
>>
>> in my ./configure call. I thought that this is enough. When I added
>>
>> --with-liblas=yes
>>
>> it started to work. After ./configure ... && make, I have r.in.lidar and
>> v.in.lidar.
>>
>> I still have just libboost-thread-dev and libboost-program-options-dev,
>> the
>> libboost-all-dev package is not necessary, although it is the simplest
>> option.
>>
>> I don't understand the think with --with-liblas=yes, I really though I
>> read
>> here that it is not necessary (once you have --with-liblas-config) and
>> Yann
>> was saying that different combinations of --with-liblas* does not work
>> for
>> him.
>>
>> There is still the problem with different content of CFLAGS and CPPFLAGS
>> variables (r57541 and the patch from #2065) in ./configure and also I'm
>> not
>> able to run the test program from ./configure myself. I don't know how
>> this
>> is important.
>>
>> Thanks all for help. I'll try this also on other computers with Ubuntu
>> 14.04 and I'll let you know if it will not work.
>>
>> Vaclav
>>
>>
>> On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras 
>> wrote:
>>> I was trying to compile GRASS with libLAS but ./configure says no.
>>>
>>> I used:
>>>
>>> --with-liblas-config=/usr/bin/liblas-config
>>>
>>> and I have all liblas packages from standard Ubuntu 14.0

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

Hi,

I have libboost-thread-dev, libboost-program-options-dev, and
libboost-all-dev installed
in configure options:  --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes

still:
checking whether to use libLAS... yes
checking for liblas-config... /usr/bin/liblas-config
configure: error: *** Unable to locate libLAS library.

Full config script:
CFLAGS="-g -Wall"
./configure --with-cxx --with-wxwidgets --with-freetype=yes
--with-postgres=no --with-sqlite=yes --without-tcltk
--enable-largefile=yes --with-freetype-includes=/usr/include/freetype2
--with-opengl-libs=/usr/include/GL --with-readline --with-python=yes
--with-lapack --with-gdal=/usr/bin/gdal-config
--with-proj-share=/usr/share/proj --with-pthread
--with-liblas-config=/usr/bin/liblas-config --with-liblas=yes
--with-blas


On 30/05/2014, Vaclav Petras  wrote:
> On Thu, May 29, 2014 at 1:09 PM, Javier Martínez-López <
> javi.martinez.lo...@gmail.com> wrote:
>
>> Hi,
>>
>> I had the same problem with the latest grass 71 svn version (from
>> today) under ubuntu 14.04 and I certainly solved it installing
>> libboost-all-dev and the config option: --with-liblas=yes
>> --with-liblas-config=/usr/bin/liblas-config
>>
>>
> Thank you. This was very helpful. The problem was that I included only
>
> --with-liblas-config=/usr/bin/liblas-config
>
> in my ./configure call. I thought that this is enough. When I added
>
> --with-liblas=yes
>
> it started to work. After ./configure ... && make, I have r.in.lidar and
> v.in.lidar.
>
> I still have just libboost-thread-dev and libboost-program-options-dev, the
> libboost-all-dev package is not necessary, although it is the simplest
> option.
>
> I don't understand the think with --with-liblas=yes, I really though I read
> here that it is not necessary (once you have --with-liblas-config) and Yann
> was saying that different combinations of --with-liblas* does not work for
> him.
>
> There is still the problem with different content of CFLAGS and CPPFLAGS
> variables (r57541 and the patch from #2065) in ./configure and also I'm not
> able to run the test program from ./configure myself. I don't know how this
> is important.
>
> Thanks all for help. I'll try this also on other computers with Ubuntu
> 14.04 and I'll let you know if it will not work.
>
> Vaclav
>
>
> On Thu, May 22, 2014 at 3:25 PM, Vaclav Petras 
> wrote:
>> I was trying to compile GRASS with libLAS but ./configure says no.
>>
>> I used:
>>
>> --with-liblas-config=/usr/bin/liblas-config
>>
>> and I have all liblas packages from standard Ubuntu 14.04 repository
> (libLAS version is 1.7.0 which is the current stable release).
>
> On Thu, May 22, 2014 at 8:47 PM, Yann Chemin  wrote:
>>
>> I can confirm the issue,
>>
>> also by trying these configure options it is not helping:
>> --with-liblas --with-liblas-config
>> --with-liblas --with-liblas-config=/usr/bin/liblas-config
>> --with-liblas=yes --with-liblas-config
>> --with-liblas=yes --with-liblas-config=/usr/bin/liblas-config
>>
>> Also two targets are found, both valid (v1.7.0) and identical:
>> whereis liblas-config
>> liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
>> /usr/share/man/man1/liblas-config.1.gz
>>
>> $ ls -aslh /usr/bin/X11/liblas-config
>> 4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
>> $ ls -aslh /usr/bin/liblas-config
>> 4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config
>>
>


-- 

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

Re: [GRASS-dev] libLAS on Ubuntu 14.04

[Yann Chemin]

I can confirm the issue,

also by trying these configure options it is not helping:
--with-liblas --with-liblas-config
--with-liblas --with-liblas-config=/usr/bin/liblas-config
--with-liblas=yes --with-liblas-config
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config

Also two targets are found, both valid (v1.7.0) and identical:
whereis liblas-config
liblas-config: /usr/bin/liblas-config /usr/bin/X11/liblas-config
/usr/share/man/man1/liblas-config.1.gz

$ ls -aslh /usr/bin/X11/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/X11/liblas-config
$ ls -aslh /usr/bin/liblas-config
4.0K -rwxr-xr-x 1 root root 2.5K Feb 26 14:43 /usr/bin/liblas-config




On 23/05/2014, Vaclav Petras  wrote:
> Hi,
>
> I was trying to compile GRASS with libLAS but ./configure says no.
>
> I used:
>
> --with-liblas-config=/usr/bin/liblas-config
>
> and I have all liblas packages from standard Ubuntu 14.04 repository
> (libLAS version is 1.7.0 which is the current stable release).
>
> Since configure went OK but the result for libLAS was "no", I tried to
> compile and run the ./configure's testing code myself.
>
>
> Code:
>
> #include 
> int main() {
> LASReader_Create("foo");
> ; return 0; }
>
> Compilation:
>
> gcc liblastest.c -o liblastest -ggdb -L/usr/lib -llas -llas_c
> -L/usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
> /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 /usr/lib/libgdal.so
> /usr/lib/libgeotiff.so /usr/lib/x86_64-linux-gnu/libtiff.so $(liblas-config
> --includes)
>
> Debugging test:
>
> gdb liblastest
>
> Starting program: /home/vasek/dev/grass/test/liblastest
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77285471 in std::istream::seekg(std::fpos<__mbstate_t>) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> #0 0x77285471 in std::istream::seekg(std::fpos<__mbstate_t>) ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #1 0x7759597b in liblas::detail::reader::Header::ReadHeader() ()
> from /usr/lib/liblas.so.2
> #2 0x7754713b in
> liblas::ReaderFactory::CreateWithStream(std::istream&) () from
> /usr/lib/liblas.so.2
> #3 0x77bb1a80 in LASReader_Create () from /usr/lib/liblas_c.so.2
> #4 0x004006ab in main () at liblastest.c:4
>
> So the test failed with segmentation fault but it would actually fail
> during compilation if I would use `liblas-config --libs` because the boost
> libraries are `libboost_program_options.so.1.54.0` on my computer while
> `liblas-config --libs` says just `libboost_program_options.so` (same for
> thread library).
>
> It seems that the thing with boost libraries is a packaging issue but I'm
> not sure about the other ones. I can repeat it outside GRASS I don't know
> if this is actually what GRASS is doing and if it makes sense.
>
> Was somebody successful with libLAS on Ubuntu 14.04 and what is the general
> procedure for Linux anyway?
>
> Thanks,
> Vaclav
>


-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi Anna,

Thank you, updating trunk now !

About RunMenuCmd, it is just a note to remember that it is the call to
use for external program. All good there.

Yann

On 18/05/2014, Anna Petrášová  wrote:
> Hi Yann,
>
>
> On Sat, May 17, 2014 at 11:46 PM, Yann Chemin  wrote:
>
>> Hi Anna,
>>
>> Patch works great ! Needs RunMenuCmd and all goes to perfection. Any
>> chance to have it included in the SVN tree?
>>
>>
> I committed the patch in trunk, if you agree, I won't backport it now. I
> don't understand what do you mean with RunMenuCmd, is there still some
> problem and what is it exactly?
>
> Anna
>
>
> Thank you
>> Yann
>>
>> On 18/05/2014, Anna Petrášová  wrote:
>> > Hi Yann,
>> >
>> > it's grayed out because it tests if it's a working grass command (for
>> > example r.in.lidar is grayed when you don't compile grass with liblas).
>> You
>> > can try to apply this patch which tests if the command looks like grass
>> > command (regular expression) and if it is not, it doesn't disable it in
>> > menu.
>> >
>> > Index: gui_core/menu.py
>> > ===
>> > --- gui_core/menu.py (revision 60284)
>> > +++ gui_core/menu.py (working copy)
>> > @@ -18,7 +18,7 @@
>> >  @author Robert Szczepanek (menu customization)
>> >  @author Vaclav Petras  (menu customization)
>> >  """
>> > -
>> > +import re
>> >  import wx
>> >
>> >  from core  import globalvar
>> > @@ -91,7 +91,8 @@
>> >  cmd = utils.split(str(command))
>> >  except UnicodeError:
>> >  cmd = utils.split(EncodeString((command)))
>> > -if cmd and cmd[0] not in globalvar.grassCmd:
>> > +if cmd and cmd[0] not in globalvar.grassCmd and \
>> > +   re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
>> >  menuItem.Enable(False)
>> >
>> >  rhandler = eval('self.parent.' + handler)
>> >
>> >
>> >
>> > On Fri, May 16, 2014 at 12:30 AM, Yann Chemin 
>> > wrote:
>> >
>> >> in svn/gui/wxpython/lmgr/frame.py
>> >> line 758
>> >> by adding:
>> >>
>> >> def RunCmd(self, event = None, cmd = []):
>> >> """!Run command to system from menu"""
>> >> if event:
>> >> cmd = self.GetMenuCmd(event)
>> >> os.system(cmd)
>> >>
>> >>
>> > I am not sure if this is needed. I would say it might work without this
>> > change but you have to try it out.
>> >
>> >
>> > Best,
>> >
>> > Anna
>> >
>> >
>> >> it should handle it, however, it seems that a flag is needed to enable
>> >> the possibility to click the command from the created menu. It is
>> >> still grey/shadowed.
>> >>
>> >>
>> >>
>> >> On 16/05/2014, Yann Chemin  wrote:
>> >> > To be precise, the non-GRASS programs have their own GUI already,
>> >> > and
>> >> > the calls need only one word.
>> >> >
>> >> > On 16/05/2014, Yann Chemin  wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I would like to make a customized toolbox to call some non-GRASS
>> >> >> CLI
>> >> >> programs.
>> >> >>
>> >> >> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items
>> are
>> >> >> grey/shadowed so that no mouse click is allowed on them.
>> >> >>
>> >> >> thanks
>> >> >> Yann
>> >> >> --
>> >> >> 
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 
>> >> >
>> >>
>> >>
>> >> --
>> >> 
>> >> ___
>> >> 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] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi Anna,

Patch works great ! Needs RunMenuCmd and all goes to perfection. Any
chance to have it included in the SVN tree?

Thank you
Yann

On 18/05/2014, Anna Petrášová  wrote:
> Hi Yann,
>
> it's grayed out because it tests if it's a working grass command (for
> example r.in.lidar is grayed when you don't compile grass with liblas). You
> can try to apply this patch which tests if the command looks like grass
> command (regular expression) and if it is not, it doesn't disable it in
> menu.
>
> Index: gui_core/menu.py
> ===
> --- gui_core/menu.py (revision 60284)
> +++ gui_core/menu.py (working copy)
> @@ -18,7 +18,7 @@
>  @author Robert Szczepanek (menu customization)
>  @author Vaclav Petras  (menu customization)
>  """
> -
> +import re
>  import wx
>
>  from core  import globalvar
> @@ -91,7 +91,8 @@
>  cmd = utils.split(str(command))
>  except UnicodeError:
>  cmd = utils.split(EncodeString((command)))
> -if cmd and cmd[0] not in globalvar.grassCmd:
> +if cmd and cmd[0] not in globalvar.grassCmd and \
> +   re.match('[rvdipmgt][3bs]?\.([a-z0-9\.])+', cmd[0]):
>      menuItem.Enable(False)
>
>  rhandler = eval('self.parent.' + handler)
>
>
>
> On Fri, May 16, 2014 at 12:30 AM, Yann Chemin  wrote:
>
>> in svn/gui/wxpython/lmgr/frame.py
>> line 758
>> by adding:
>>
>> def RunCmd(self, event = None, cmd = []):
>> """!Run command to system from menu"""
>> if event:
>> cmd = self.GetMenuCmd(event)
>> os.system(cmd)
>>
>>
> I am not sure if this is needed. I would say it might work without this
> change but you have to try it out.
>
>
> Best,
>
> Anna
>
>
>> it should handle it, however, it seems that a flag is needed to enable
>> the possibility to click the command from the created menu. It is
>> still grey/shadowed.
>>
>>
>>
>> On 16/05/2014, Yann Chemin  wrote:
>> > To be precise, the non-GRASS programs have their own GUI already, and
>> > the calls need only one word.
>> >
>> > On 16/05/2014, Yann Chemin  wrote:
>> >> Hi,
>> >>
>> >> I would like to make a customized toolbox to call some non-GRASS CLI
>> >> programs.
>> >>
>> >> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
>> >> grey/shadowed so that no mouse click is allowed on them.
>> >>
>> >> thanks
>> >> Yann
>> >> --
>> >> 
>> >>
>> >
>> >
>> > --
>> > 
>> >
>>
>>
>> --
>> 
>> ___
>> 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] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

in svn/gui/wxpython/lmgr/frame.py
line 758
by adding:

def RunCmd(self, event = None, cmd = []):
"""!Run command to system from menu"""
if event:
cmd = self.GetMenuCmd(event)
os.system(cmd)

it should handle it, however, it seems that a flag is needed to enable
the possibility to click the command from the created menu. It is
still grey/shadowed.



On 16/05/2014, Yann Chemin  wrote:
> To be precise, the non-GRASS programs have their own GUI already, and
> the calls need only one word.
>
> On 16/05/2014, Yann Chemin  wrote:
>> Hi,
>>
>> I would like to make a customized toolbox to call some non-GRASS CLI
>> programs.
>>
>> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
>> grey/shadowed so that no mouse click is allowed on them.
>>
>> thanks
>> Yann
>> --
>> 
>>
>
>
> --
> 
>


-- 

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

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

To be precise, the non-GRASS programs have their own GUI already, and
the calls need only one word.

On 16/05/2014, Yann Chemin  wrote:
> Hi,
>
> I would like to make a customized toolbox to call some non-GRASS CLI
> programs.
>
> Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
> grey/shadowed so that no mouse click is allowed on them.
>
> thanks
> Yann
> --
> 
>


-- 

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

[GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

[Yann Chemin]

Hi,

I would like to make a customized toolbox to call some non-GRASS CLI programs.

Handlers OnMenuCmd and RunMenuCmd seem not to work. The menu items are
grey/shadowed so that no mouse click is allowed on them.

thanks
Yann
-- 

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

[GRASS-dev] vector line coordinates

[Yann Chemin]

Hi,

I have a set of faults (lines made from 2 points only)
and my target is to calculate the distance from a city to all of the
faults in the region.

Ideally I would need the location (X,Y) of the mid-point of the line,
but if I can extract the two tipline nodes coordinates, then it is
half-way to it.

v.to.db has option=coor but it does not take type=line

Also, v.type does not convert line to point
v.type input=analysis output=analysis_pts from_type=line to_type=point

Yann

-- 

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

Re: [GRASS-dev] vector line coordinates

[Yann Chemin]

I somehow missed the v.to.db option:
start: line/boundary starting point coordinates, X,Y or X,Y,Z
end: line/boundary end point coordinates, X,Y or X,Y,Z




On 14/05/2014, Yann Chemin  wrote:
> Hi,
>
> I have a set of faults (lines made from 2 points only)
> and my target is to calculate the distance from a city to all of the
> faults in the region.
>
> Ideally I would need the location (X,Y) of the mid-point of the line,
> but if I can extract the two tipline nodes coordinates, then it is
> half-way to it.
>
> v.to.db has option=coor but it does not take type=line
>
> Also, v.type does not convert line to point
> v.type input=analysis output=analysis_pts from_type=line to_type=point
>
> Yann
>
> --
> 
>


-- 

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

[GRASS-dev] discussion: spectral libraries and GRASS

[Yann Chemin]

Hi, I would like to start a discussion about supporting spectral
libraries in GRASS.

known formats:

ASTER speclibv2.0 has each signature in a plain text file with 27
lines of headers and the rest in 2 columns Tab-separated
(1=wavelength, 2=reflectance)

Speclab.lib06 (http://speclab.cr.usgs.gov/spectral.lib06/) is in text
format, seems a bit more complex than speclibv2.0 and I have not been
able to compile their reading code yet, I might just skip it and make
directly a reader.

ENVI .sli seems to be a hyperspectral image cube with an augmented
header file to fit the attributes handling.

Questions:

1 - anybody worked with spectral libraries in GRASS before? If yes,
which approach you used?
2 - any (un/less)known modules waiting to be resurrected about that?
3 - If nothing is there, anybody has a strong feeling about the way to
go for GRASS to: a) import b) store such libraries?
4 - A last note: each signature has significant amount of metadata,
this might be a challenge.

(I am willing to code the necessary to import and store)

Yann
-- 

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

Re: [GRASS-dev] i.spectral limited to 400 files

[Yann Chemin]

In Ubuntu, I could expand the number of opened files by:

#PCA will require the extension of ulimit for open files in Ubuntu
sudo vi /etc/security/limits.conf

#There you should enter:
#usernamehardnofile  65000
#usernamesoftnofile  1
#before # End of file

and reboot

On 18/04/2014, Nikos Alexandris  wrote:
> Yann Chemin wrote:
>
>> >> is there a way to modify i.spectral to remove the limit of 400 files:
>
> Glynn:
>
>> > The limit is from r.what. It probably wouldn't be that hard to fix.
>
> Markus N:
>
>> ... "nice to have" for sure.
>>
>> BTW:
>> The next limit would be the operating system. Default Linux allows
>> 1024 files to be opened, which can be increased in
>> /etc/security/limits.conf
>
> Aren't there, however, any important side-effects in altering this limit?
> There must be a (security?) reason for the number 2^10.
>
> Nikos
>


-- 

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

Re: [GRASS-dev] Who wants GUI and who does not and why

[Yann Chemin]

1. Allow for the release stable versions of core GRASS without
having to wait for GUI fixes on different OS.

+1 for that !
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] i.spectral limited to 400 files

[Yann Chemin]

Hi,

is there a way to modify i.spectral to remove the limit of 400 files:

i.spectral -c 
group=ta_group@PERMANENTcoordinates=104.118832166,14.7585647484,103.525338069,13.0911289527,103.304897404,12.9328638602
output=/home/yann/dev/grass-promo/grassposter/2014_EGU_WD_Landscape/images/ta_spectral
ERROR: Can only do up to 400 raster maps (400 given)
ERROR: No data returned from query

I have about 1500 files in the group.

-- 

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

Re: [GRASS-dev] Who wants GUI and who does not and why

[Yann Chemin]

Maybe some of the earlier involved developers can share their thoughts on
the Tcl/Tk GUI and its integration, its rise and fall, why and where this
experience can lead the wxPython GUI now...


On 16 April 2014 08:00, Vaclav Petras  wrote:

> Hi all,
>
> I believe, I was calling for this discussion recently, and I'm calling for
> it again. It seems that there are quite different opinions on GRASS GIS GUI
> ranging from "GUI is the only thing which brings us new users" to "no GUI
> needed".
>
> There is no better time to discuss this: we are discussing issues with MS
> Windows support, planing to release 7, working towards compatibility of 7
> with QGIS and gvSIG, and we also discussed WebGRASS topic recently.
>
> Here are recent quotations from "Handling of Python scripts on MS Windows"
> discussion (
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068269.html) with
> few notes and questions but feel free to start wherever you want.
>
>
> On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke wrote:
> > On Sun, Apr 13, 2014 at 11:03 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> > [Side note: The same discussion should also constantly be held about
>> > functionality which is specific to the GUI, because specifically
>> > developed for it), i.e. not just a GUI layer above command line
>> > functionality, something I'm afraid to see creep in more and more...]
>> >
>>
>> Does this mean that you want remove everything from `gui/*` besides
> `gui/wxpython/forms/*`?
>
>
>>  Agreed. Once more, I plead for a clean separation between GUI
>> and CLI developments, and a disconnection of their release cycles.
>>
>
> I see some advantages, for example just using same bug tracker makes
> difficult to say what is critical issue; but there are some GUI errors are
> tightly coupled to core module issues.
>
> On the other hand, I don't see how these disconnected release cycles would
> work. Also it seems that it is impossible or very hard to create good GUI
> without the support of the processing and management tools.
>
>
>> The wxPython GUI can be considered a monolithic application,
>> and FWIW it can pull every trick in the book to integrate a
>> Python interpreter, and to make it all easier for Windows users.
>>
>> ...
>>
>> I would say: Consider the wxGUI, the QGIS and gvSIG plug-ins etc.
>> monolithic applications and let their maintainers figure out how
>> to deal with this. In the gvSIG CE project, we do a lot of hair-
>> raising stuff to hide the complexity of GRASS and its dependencies
>> from the end user, and I suspect so does QGIS. But I would not
>> advocate the same approach to the core GRASS architecture.
>
>
> Than perhaps, no wxGUI is needed because we have QGIS and gvSIG plugins.
> Managing one GUI less in OSGeo could save some work. For example, QGIS
> GRASS plugin is developed separately, so there is no need to have another
> graphical user interface for GRASS with disconnect development.
>
> > I also think that some of the debate comes from the question of whether
> > the wxGUI should have a special status or whether it should just
> > be treated as one of the hundreds of modules that GRASS offers.
>
> This is more or less the current state, there is g.gui, you can start
> without it, there are g.gui.* modules. On the other hand, there is always
> something spatial with GUI, e.g. if you want GUI to start when module is
> started without parameters/with --ui.
>
>
>
> Or, are you satisfied with the situation as it is now?
>
> Thanks for sharing your thoughts,
> Vaclav
>
> ___
> 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] TOC in the manual

[Yann Chemin]

+1


On 12 April 2014 03:57, Anna Petrášová  wrote:

> Note, that on Windows and on Ubuntu with wxPython 3, the manual page in
> the tab is loaded immediately. I believe we should keep the manual in the
> tab, I think people are more likely to look at the manual there than
> pressing Help button. Personally I try to avoid pressing Help button in any
> application, it usually takes a lot of time to start browser and load it.
> WxPython 3 has some new widget for websites so eventually, it could replace
> the widget we use now.
>
> Anna
>
>
>
>
>
> On Fri, Apr 11, 2014 at 6:49 AM, Yann Chemin  wrote:
>
>> Did not have an opinion fixed, so went back to work, opened a module,
>> pressed on the manual tab and did have to wait a bit because of
>> rendering... If it was to open in a default web browser, I could have
>> continued looking around the module.
>>
>> +1 for button to external browser
>>
>>
>> On 11 April 2014 14:33, Martin Landa  wrote:
>>
>>> Hi,
>>>
>>> 2014-04-11 10:38 GMT+02:00 Martin Landa :
>>>
>>> > body part is 80%, see eg. [1]. Since wxPython widget doesn't support
>>> > most of css, it's shown before DESCRIPTION and not as fixed.
>>>
>>> the question is whether to hide manual tab and just to provide button
>>> which opens manual in the web browser. 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
>>>
>>
>>
>>
>> --
>> 
>>
>> ___
>> 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] TOC in the manual

[Yann Chemin]

Did not have an opinion fixed, so went back to work, opened a module,
pressed on the manual tab and did have to wait a bit because of
rendering... If it was to open in a default web browser, I could have
continued looking around the module.

+1 for button to external browser


On 11 April 2014 14:33, Martin Landa  wrote:

> Hi,
>
> 2014-04-11 10:38 GMT+02:00 Martin Landa :
>
> > body part is 80%, see eg. [1]. Since wxPython widget doesn't support
> > most of css, it's shown before DESCRIPTION and not as fixed.
>
> the question is whether to hide manual tab and just to provide button
> which opens manual in the web browser. 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
>



-- 

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

Re: [GRASS-dev] Structure of links for addons, manual pages etc.

[Yann Chemin]

About the manual urls, I have an opinion:

Main manual for G7 to be linked to the SVN version (always updated).
Old manuals fixed to released versions (not maintained).

I understand how extreme it may be, but it may be very easy to maintain
(only one version)

0.02c


On 10 April 2014 07:21, Vaclav Petras  wrote:

> Hi,
>
> I think we need to rethink the structure of addresses/links to various
> things which we are putting online.
>
> The motivation are discussions "Linking Addons manual pages to core
> modules", "addons for windows", and "Addon manual pages not linked".
>
> For example, so far we were linking the trunk documentation using
> grass70/manuals but since we forked the 70 branch these links now points to
> it and not to trunk. Also all general links to GRASS documentation leads to
> grass64/manuals but this will be soon very obsolete.
>
> A lot of projects uses links such as latest, release or current (e.g.
> latest/manuals or release/manuals) which leads to the current (latest)
> release. And also links such as master, latest, trunk, nightly which leads
> to the one builds from the source code of the main branch. Alternatively,
> there is no special link for the current release which shortens URLs. I
> think something like this might be beneficial for us.
>
> So far I identified this set of things:
>
> * GRASS binaries
> * addons for MS Windows
> * addons SVN
> * manual pages
> * programming manual (or manuals)
>
> I don't have any concrete suggestion now. What are your experiences with
> this?
>
> Thanks,
> Vaclav
>
>
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068192.html
> http://lists.osgeo.org/pipermail/grass-dev/2014-April/068193.html
> http://lists.osgeo.org/pipermail/grass-web/2013-December/004587.html
>
> ___
> 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-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Yann Chemin]

 Agreeing with Moritz,

"In other words, there are some types of users (those that don't read
anything provided by the developers) for whom I am sometimes tempted to
just say "RTFM" instead of trying to find ways to make it possible for them
to still use GRASS"

I used to start my GRASS GIS courses by saying to students that this is not
going to work if you do not read the instructions. Invariably, those who
did not listen to that would come back frustrated 30 minutes later...

Cheers
Yann


On 9 April 2014 12:51, Moritz Lennert  wrote:

> On 09/04/14 03:17, Vaclav Petras wrote:
>
>>
>> On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements > > wrote:
>>
>> If there's no Python installed, the installer can install it. If
>> Python is installed and the version is compatible, the installer can
>> install any required packages. Otherwise, it can at least inform the
>> user of the situation and enumerate the options.
>>
>>
>> This is a good point, the documentation must be in the installer, not a
>> separate file. For example Git installer for MS Windows list three
>> options how to install git and other command line tools with an
>> explanation. The problem is that only part of the users will read it and
>> only part of them will understand all the consequences (I mean, I was
>> not sure when I saw installing Git installation for the first time).
>>
>
> I think part of this discussion boils down to the very old debate about
> how far we should go in taking the user's hand. Do we really want to
> compete with programs that "just do the work for you", thus having to think
> of every possible problem they might face, or do we decide that even though
> we can lower the entrance hurdle a bit, GRASS does demand some more
> involvement from the user than other software.
>
> Personally, I am a bit afraid that by going down the first route we
> concentrate much developer time that could be spent on other (IMHO more
> useful) things and we also risk to make GRASS less efficient for those that
> have taken the time to pass the hurdle.
>
> In other words, there are some types of users (those that don't read
> anything provided by the developers) for whom I am sometimes tempted to
> just say "RTFM" instead of trying to find ways to make it possible for them
> to still use GRASS.
>
> Moritz
>
> ___
> 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] wxGUI having a hard time overlaying data with 0-360 and -180+180 proj

[Yann Chemin]

Found this worked (with limitations and only for point data):

from http://lists.osgeo.org/pipermail/gdal-dev/2006-June/009293.html

ogr2ogr Moon_N.shp MOON_nomenclature.shp --config CENTER_LONG 0 -t_srs
'+proj=longlat +a=1737400 +b=1737400 +no_defs'
Warning 1: Field name of width 255 truncated to 254.
Warning 1: Field clean_name of width 255 truncated to 254.
Warning 1: Field origin of width 255 truncated to 254.
Warning 1: Field type of width 255 truncated to 254.
Warning 1: Field code of width 255 truncated to 254.
Warning 1: Field approval of width 255 truncated to 254.
Warning 1: Field ethnicity of width 255 truncated to 254.
Warning 1: Field continent of width 255 truncated to 254.
Warning 1: Field quad_name of width 255 truncated to 254.
Warning 1: One or several characters couldn't be converted correctly from
UTF-8 to ISO-8859-1.
This warning will not be emitted anymore.

but also this is documented with a python code (not tried though):
https://isis.astrogeology.usgs.gov/IsisSupport/index.php?topic=3722.0



On 3 April 2014 12:12, Yann Chemin  wrote:

> Hi,
>
> Using the Moon nomenclature data set with the geological maps of the Moon
> gives strange results:
>
> http://www.tiikoni.com/tis/view/?id=b7713fd
>
> The Moon Nomenclature (text) is going 0-360 and the Moon geology is
> -180+180.
>
> The Moon Nomenclature does not wrap around, but does map full in 0-360
>
> http://www.tiikoni.com/tis/view/?id=b936970
>
> Any help please
>
> --
> 
>



-- 

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

Re: [GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Yann Chemin]

+1
I also think we should stop GRASS 6 development


On 6 April 2014 19:01, Martin Landa  wrote:

> 2014-04-06 15:16 GMT+02:00 Moritz Lennert :
>
> > Hamish, maybe you could be the official grass6 maintainer, managing the
> > whole grass6 development in the way you propose, i.e. any new development
> > and bugfixes first go into grass6dev for a period of testing, before
> _you_
> > make the decision that something can be backported to grass6release. I do
> > think however, that for this to work, we would need to regularly publish
> > snapshots of grass6dev for easy testing.
>
> I think we should really stop thinking about GRASS 6 "development",
> ideally we should fully focus our energy on GRASS 7. We do not have
> enough man-power for keeping development in GRASS 6, simply saying. So
> please bug fix only should go there (relbr64). No new functionality.
>
> 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
>



-- 

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

[GRASS-dev] wxGUI having a hard time overlaying data with 0-360 and -180+180 proj

[Yann Chemin]

Hi,

Using the Moon nomenclature data set with the geological maps of the Moon
gives strange results:

http://www.tiikoni.com/tis/view/?id=b7713fd

The Moon Nomenclature (text) is going 0-360 and the Moon geology is
-180+180.

The Moon Nomenclature does not wrap around, but does map full in 0-360

http://www.tiikoni.com/tis/view/?id=b936970

Any help please

-- 

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

Re: [GRASS-dev] Planetary Datums help to add in GRASS

[Yann Chemin]

Hi Alessandro,

I updated the planetary Ellipsoid table (r59566) with the definitions from
the website.

Cheers,
Yann


On 2 April 2014 23:27, Alessandro Frigeri
wrote:

> Hi Yann,
>
> maybe the name of the ellipse/datum fund in LOLA metadata does not match
> the name found in the ellipse.table
> http://svn.osgeo.org/grass/grass/trunk/lib/gis/ellipse.table.solar.system?
>
>
> I'm out of office now, I will check tomorrow
>
> Best,
>
> Alessandro
>
>
>
>
>
> 2014-04-02 17:23 GMT+02:00 Yann Chemin :
>
> Hi,
>>
>> I would like to add planetary Datums in GRASS as from this:
>>
>> http://help.arcgis.com/en/arcims/10.0/mainhelp/mergedprojects/ArcXMLGuide/elements/gcs.htm#104900and
>>  after
>>
>> Right now GRASS issues a benign warning on importing LOLA DEM:
>>
>> WARNING: Datum  not recognised by GRASS and no parameters found
>>
>> This kind of information is in the URL:
>> 104900 GCS_Mercury_2000
>>
>> GEOGCS["GCS_Mercury_2000",DATUM["D_Mercury_2000",SPHEROID["Mercury_2000_IAU_IAG",2439700.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104901 GCS_Venus_1985
>>
>> GEOGCS["GCS_Venus_1985",DATUM["D_Venus_1985",SPHEROID["Venus_1985_IAU_IAG_COSPAR",6051000.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104902 GCS_Venus_2000
>>
>> GEOGCS["GCS_Venus_2000",DATUM["D_Venus_2000",SPHEROID["Venus_2000_IAU_IAG",6051800.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104903 GCS_Moon_2000
>>
>> GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104904 GCS_Mars_1979
>>
>> GEOGCS["GCS_Mars_1979",DATUM["D_Mars_1979",SPHEROID["Mars_1979_IAU_IAG",3393400.0,192.0430107526882]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>> 104905 GCS_Mars_2000
>> GEOGCS["GCS_Mars_2000",DATUM["D_Mars_2000",SPHEROID["Mars_2000_IAU_IAG",3396190.0,169.8944472236118]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]
>>
>>
>> Any hint would be great thanks,
>> Yann
>> --
>> 
>>
>
>
>
> --
> Alessandro Frigeri
> Istituto di Astrofisica e Planetologia Spaziali - Istituto Nazionale di
> Astrofisica, Roma, Italy
>



-- 

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

[GRASS-dev] Planetary Datums help to add in GRASS

[Yann Chemin]

Hi,

I would like to add planetary Datums in GRASS as from this:
http://help.arcgis.com/en/arcims/10.0/mainhelp/mergedprojects/ArcXMLGuide/elements/gcs.htm#104900and
after

Right now GRASS issues a benign warning on importing LOLA DEM:

WARNING: Datum  not recognised by GRASS and no parameters found

This kind of information is in the URL:
104900 GCS_Mercury_2000
GEOGCS["GCS_Mercury_2000",DATUM["D_Mercury_2000",SPHEROID["Mercury_2000_IAU_IAG",2439700.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104901 GCS_Venus_1985
GEOGCS["GCS_Venus_1985",DATUM["D_Venus_1985",SPHEROID["Venus_1985_IAU_IAG_COSPAR",6051000.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104902 GCS_Venus_2000
GEOGCS["GCS_Venus_2000",DATUM["D_Venus_2000",SPHEROID["Venus_2000_IAU_IAG",6051800.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104903 GCS_Moon_2000
GEOGCS["GCS_Moon_2000",DATUM["D_Moon_2000",SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104904 GCS_Mars_1979
GEOGCS["GCS_Mars_1979",DATUM["D_Mars_1979",SPHEROID["Mars_1979_IAU_IAG",3393400.0,192.0430107526882]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]

104905 GCS_Mars_2000
GEOGCS["GCS_Mars_2000",DATUM["D_Mars_2000",SPHEROID["Mars_2000_IAU_IAG",3396190.0,169.8944472236118]],PRIMEM["Reference_Meridian",0.0],UNIT["Degree",0.0174532925199433]]


Any hint would be great thanks,
Yann
-- 

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

Re: [GRASS-dev] Fwd: Android Compilation

[Yann Chemin]

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




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

[GRASS-dev] Fwd: Android Compilation

[Yann Chemin]

I had a go at Android cross-compilation again, this time with new libraries
(most svn versions) and SVN trunk of GRASS, on an Ubuntu 64bit machine.

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

I am attaching the changed setup scripts (~/dev/grass/android/scripts/) as
it was in an initial tarball that MarkusN  gave me last year. if you
replace them, then run "Yann_try.sh" for Ubuntu (64-bit) install and
building the android version.

It did create in ~/dev/grass/:
grass-7.0.svn-arm-unknown-linux-androideabi-05_03_2014-install.sh
grass-7.0.svn-arm-unknown-linux-androideabi-05_03_2014.tar.gz

I am now looking for information on creating a .apk file most probably
involving something with files like Android.mk and Application.mk


build-grass.sh
Description: Bourne shell script


build-libs.sh
Description: Bourne shell script


config.conf
Description: Binary data


setup-env.sh
Description: Bourne shell script


Yann_try.sh
Description: Bourne shell script
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxgui: enabling "page down" key in map selection boxes

[Yann Chemin]

Hi,

in wxgui when looking to display a raster layer, "down arrow" works, but it
is too slow to go through 1000s of maps.

Maybe "Page down" could be set up to scroll faster.

Yann

-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

I will contact Aruna to check about the videos...

I just repeated inefficient from:



On 5 March 2014 14:30, Sören Gebbert  wrote:

> Hi Yann,
>
> 2014-03-05 9:48 GMT+01:00 Yann Chemin :
> > Yes Soeren, such a pity, I missed all your temporal fun!
> > As usual, have to do it the hard way...
>
> I am sorry for that. Are the videos of the workshop ready yet?
>
> >
> > Thanks,
> > I will set up the input file, inefficient, but my data is not regular in
> > time...
>
> Well, TGRASS was designed to support irregular time, hence using an
> input file with thousands of maps with irregular time stamps is the
> most efficient way to register IMHO.
>
> Why is it in your case inefficient?
>
> Cheers
> Soeren
>
> >
> >
> >
> > On 5 March 2014 14:15, Sören Gebbert 
> wrote:
> >>
> >> Hi,
> >> such a pity you were not in the TGIS workshop.
> >> However, there can be gaps between time intervals.
> >> Hence the end time of a time interval can be start time of a potential
> >> successor or the start time of a gap.
> >> But gaps are not stored explicitly, they are computed by topological
> >> analysis
> >>
> >> I would suggest that you create an input text file that lists all maps
> >> with time stamps that should be registered
> >> If you call t.register for each single map the registration will be
> >> very inefficient and slow
> >> Example of an input file with gaps between map intervals:
> >> mapA|2001-05-10|2001-05-11
> >> mapB|2001-05-15|2001-05-16
> >>
> >> Best regards
> >> Soeren
> >>
> >> 2014-03-05 9:29 GMT+01:00 Yann Chemin :
> >> > Thank you Soeren,
> >> >
> >> > If I want to register an irregular set of daily maps (missing days),
> >> > will
> >> > the end date need to be the next day (say 5 days after this image, 2
> >> > days
> >> > after in the next image)?
> >> >
> >> > Cheers,
> >> > Yann
> >> >
> >> >
> >> > On 5 March 2014 12:14, Sören Gebbert 
> >> > wrote:
> >> >>
> >> >> Hi Yann,
> >> >> if you need support for time zones you have to use postgresql as
> >> >> backend. Unfortunately sqlite does not support time zones. A work
> >> >> around would be to ignore the time zone and use t.shift to temporally
> >> >> shift the created STRDS by 5h and 30 min to UTC time after
> registering
> >> >> the maps. I should notice this in the help page, i don't know why i
> >> >> missed that ..???!!!
> >> >>
> >> >> The next thing is that TGRASS uses time intervals in which the end
> >> >> time is not part of the time interval, but the start time of a
> >> >> successor. That means that you do not need to know how many days in a
> >> >> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
> >> >>
> >> >> Best regards
> >> >> Soeren
> >> >>
> >> >> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> >> >> > Hi,
> >> >> >
> >> >> > input line is:
> >> >> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00
> +0530"
> >> >> > end="2004
> >> >> > -05-10 23:59:59 +0530"
> >> >> >
> >> >> > temporal says:
> >> >> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> >> >> > convert_timestamp
> >> >> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> >> >> > ValueError: invalid literal for int() with base 10: '00+05'
> >> >> >
> >> >> > Manual says following format accepted:
> >> >> > start=string
> >> >> > Valid start date and time of the first map. Format absolute time:
> >> >> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> >> >> > end=string
> >> >> > Valid end date and time of all map. Format absolute time:
> "-mm-dd
> >> >> > HH:MM:SS +HHMM", relative time is of type integer).
> >> >> >
> >> >> > yann
> >> >> > --
> >> >> > 
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > 
> >
> >
> >
> >
> > --
> > 
>



-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Yes Soeren, such a pity, I missed all your temporal fun!
As usual, have to do it the hard way...

Thanks,
I will set up the input file, inefficient, but my data is not regular in
time...



On 5 March 2014 14:15, Sören Gebbert  wrote:

> Hi,
> such a pity you were not in the TGIS workshop.
> However, there can be gaps between time intervals.
> Hence the end time of a time interval can be start time of a potential
> successor or the start time of a gap.
> But gaps are not stored explicitly, they are computed by topological
> analysis
>
> I would suggest that you create an input text file that lists all maps
> with time stamps that should be registered
> If you call t.register for each single map the registration will be
> very inefficient and slow
> Example of an input file with gaps between map intervals:
> mapA|2001-05-10|2001-05-11
> mapB|2001-05-15|2001-05-16
>
> Best regards
> Soeren
>
> 2014-03-05 9:29 GMT+01:00 Yann Chemin :
> > Thank you Soeren,
> >
> > If I want to register an irregular set of daily maps (missing days), will
> > the end date need to be the next day (say 5 days after this image, 2 days
> > after in the next image)?
> >
> > Cheers,
> > Yann
> >
> >
> > On 5 March 2014 12:14, Sören Gebbert 
> wrote:
> >>
> >> Hi Yann,
> >> if you need support for time zones you have to use postgresql as
> >> backend. Unfortunately sqlite does not support time zones. A work
> >> around would be to ignore the time zone and use t.shift to temporally
> >> shift the created STRDS by 5h and 30 min to UTC time after registering
> >> the maps. I should notice this in the help page, i don't know why i
> >> missed that ..???!!!
> >>
> >> The next thing is that TGRASS uses time intervals in which the end
> >> time is not part of the time interval, but the start time of a
> >> successor. That means that you do not need to know how many days in a
> >> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
> >>
> >> Best regards
> >> Soeren
> >>
> >> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> >> > Hi,
> >> >
> >> > input line is:
> >> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
> >> > end="2004
> >> > -05-10 23:59:59 +0530"
> >> >
> >> > temporal says:
> >> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> >> > convert_timestamp
> >> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> >> > ValueError: invalid literal for int() with base 10: '00+05'
> >> >
> >> > Manual says following format accepted:
> >> > start=string
> >> > Valid start date and time of the first map. Format absolute time:
> >> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> >> > end=string
> >> > Valid end date and time of all map. Format absolute time: "-mm-dd
> >> > HH:MM:SS +HHMM", relative time is of type integer).
> >> >
> >> > yann
> >> > --
> >> > 
> >
> >
> >
> >
> > --
> > 
>



-- 

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

Re: [GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Thank you Soeren,

If I want to register an irregular set of daily maps (missing days), will
the end date need to be the next day (say 5 days after this image, 2 days
after in the next image)?

Cheers,
Yann


On 5 March 2014 12:14, Sören Gebbert  wrote:

> Hi Yann,
> if you need support for time zones you have to use postgresql as
> backend. Unfortunately sqlite does not support time zones. A work
> around would be to ignore the time zone and use t.shift to temporally
> shift the created STRDS by 5h and 30 min to UTC time after registering
> the maps. I should notice this in the help page, i don't know why i
> missed that ..???!!!
>
> The next thing is that TGRASS uses time intervals in which the end
> time is not part of the time interval, but the start time of a
> successor. That means that you do not need to know how many days in a
> month are;  Interval of one day: start="2004-05-10" end="2004-05-11"
>
> Best regards
> Soeren
>
> 2014-03-05 6:36 GMT+01:00 Yann Chemin :
> > Hi,
> >
> > input line is:
> > t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
> > end="2004
> > -05-10 23:59:59 +0530"
> >
> > temporal says:
> >   File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in
> convert_timestamp
> > hours, minutes, seconds = map(int, timepart_full[0].split(":"))
> > ValueError: invalid literal for int() with base 10: '00+05'
> >
> > Manual says following format accepted:
> > start=string
> > Valid start date and time of the first map. Format absolute time:
> > "-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
> > end=string
> > Valid end date and time of all map. Format absolute time: "-mm-dd
> > HH:MM:SS +HHMM", relative time is of type integer).
> >
> > yann
> > --
> > 
>



-- 

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

[GRASS-dev] Temporal: t.register: problem parsing when time zone present

[Yann Chemin]

Hi,

input line is:
t.register input=ta maps=ta_2004131 start="2004-05-10 00:00:00 +0530"
end="2004
-05-10 23:59:59 +0530"

temporal says:
  File "/usr/lib/python2.7/sqlite3/dbapi2.py", line 69, in convert_timestamp
hours, minutes, seconds = map(int, timepart_full[0].split(":"))
ValueError: invalid literal for int() with base 10: '00+05'

Manual says following format accepted:
start=string
Valid start date and time of the first map. Format absolute time:
"-mm-dd HH:MM:SS +HHMM", relative time is of type integer).
end=string
Valid end date and time of all map. Format absolute time: "-mm-dd
HH:MM:SS +HHMM", relative time is of type integer).

yann
-- 

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

Re: [GRASS-dev] GSoC idea: Testing framework

[Yann Chemin]

Hi Vaclav,

I would be interested to help for the imagery modules,

Good luck !
Yann


On 31 January 2014 09:23, Vaclav Petras  wrote:

> Hi all,
>
> I would like to apply to GSoC this year with the idea of testing framework
> for GRASS. I probably don't have to explain the need for it.
>
> Sören suggested that he would be my mentor in case my application is
> successful. I hope also that I will get the feedback from all developers,
> now or in the future, because it is crucial that GRASS developers will
> actually use this framework.
>
> I described the idea shortly on Trac GSoC 2014 wiki page. I plan to
> include more notes on separate page in next weeks but the basic idea should
> be clear. Some discussion is also in #2105. Perhaps, the most innovative
> idea is that different types of tests should be supported (e.g. Python
> doctest and shell scripts), although it would be always driven form Python.
> For example, it seems that doctest is very convenient for modules which has
> standard input and output (see recent doctest for r.category module).
>
> Best regards,
> Vaclav
>
>
> http://trac.osgeo.org/grass/wiki/GSoC/2014#TestingframeworkforGRASSGIS
> http://trac.osgeo.org/grass/ticket/2105
>
> http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.category/test_rcategory_doctest.txt
>
> ___
> 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] Proposal for GSoC idea on INSPIRE

[Yann Chemin]

Yes Vaclav,

There are several entry points in GRASS GIS to create/(up)load some kind of
information that can be part of a metadata system. We know that GRASS is
lacking a unified system to report into a metadata format that is "modern",
interchangable and exportable into online systems.

Once GSoC starts, there will be some more discussions coming up indeed !

Cheers,
Yann


On 28 January 2014 22:00, Vaclav Petras  wrote:

>
>
>
> On Tue, Jan 28, 2014 at 11:12 AM, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>> On 28/01/14 16:00, Margherita Di Leo wrote:
>>
>>> Hi All,
>>>
>>> I'd like to bring a proposal for the forthcoming GSoC, that is the
>>> support for INSPIRE. This proposal is twofold, one regarding the
>>> metadata support, the other regarding the support for the data
>>> transformation to meet the inspire schema. I would like to know your
>>> opinion before drafting the idea into the trac. I'm willing to mentor
>>> for the INSPIRE POV, and since I'm working at JRC I have the opportunity
>>> to take advantage of a direct contact with the very people who are
>>> developing the Directive. Martin Landa kindly made himself available to
>>> co-mentor from the GRASS POV.
>>>
>>
>> +1, but I think we should aim for generic metadata handling and then
>> allow the use of specific schemas such as INSPIRE.
>>
>> INSPIRE is using some more general ISO standards, isn't it?
>
> QGIS metatools is a nice example of such a generic tool allowing for
>> specification of different schemas and for different outputs through the
>> use of XSLT conversion.
>>
>> QGIS compatibility would be appreciated by a lot of users and it might
> even show the way to go.
>
> Some other thing to consider is how this metadata support would interact
> with existing r.support, r.timestamp etc. I remember that Yann and NikosA
> was talking about this in Genova in 2013.
>
> Vaclav
>
> Moritz
>>
>> ___
>> 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
>



-- 

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

Re: [GRASS-dev] Proposal for GSoC idea on INSPIRE

[Yann Chemin]

+1


On 28 January 2014 20:30, Margherita Di Leo wrote:

> Hi All,
>
> I'd like to bring a proposal for the forthcoming GSoC, that is the support
> for INSPIRE. This proposal is twofold, one regarding the metadata support,
> the other regarding the support for the data transformation to meet the
> inspire schema. I would like to know your opinion before drafting the idea
> into the trac. I'm willing to mentor for the INSPIRE POV, and since I'm
> working at JRC I have the opportunity to take advantage of a direct contact
> with the very people who are developing the Directive. Martin Landa kindly
> made himself available to co-mentor from the GRASS POV.
>
> cheers,
> 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
>



-- 

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

Re: [GRASS-dev] v.clean problem with rmarea (ERROR: Area merging failed)

[Yann Chemin]

Projection is in meters...

projection: 1 (UTM)
zone:   26
datum:  wgs84
ellipsoid:  wgs84
north:  1666020
south:  1639095
west:   767715
east:   794535
nsres:  15
ewres:  15
rows:   1795
cols:   1788
cells:  3209460



On 31 December 2013 09:53, Yann Chemin  wrote:

> Hi,
> (SVN G7)
> it does work with thres inferior to 600, but not above...
>
> ---
>
> v.clean input=vnir4567_seg_0 output=vnir4567_seg_0_no_small_areas
> type=area tool=rmarea thres=1.00 --overwrite
> --
> Tool: Threshold
> Remove small areas: 1
> --
> WARNING: Vector map  already exists and
> will be overwritten
> Copying features...
> Rebuilding parts of topology...
> Building topology for vector map  >...
> Registering primitives...
> 19070 primitives registered
> 187624 vertices registered
> Building areas...
> 5344 areas built
> 251 isles built
> Attaching islands...
> Attaching centroids...
> Number of nodes: 8636
> Number of primitives: 19070
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 13729
> Number of centroids: 5341
> Number of areas: 5344
> Number of isles: 251
> --
> Tool: Remove small areas
> ERROR: Area merging failed
>
>
>
> --
> 
>



-- 

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

[GRASS-dev] v.clean problem with rmarea (ERROR: Area merging failed)

[Yann Chemin]

Hi,
(SVN G7)
it does work with thres inferior to 600, but not above...

---

v.clean input=vnir4567_seg_0 output=vnir4567_seg_0_no_small_areas type=area
tool=rmarea thres=1.00 --overwrite
--
Tool: Threshold
Remove small areas: 1
--
WARNING: Vector map  already exists and will
be overwritten
Copying features...
Rebuilding parts of topology...
Building topology for vector map ...
Registering primitives...
19070 primitives registered
187624 vertices registered
Building areas...
5344 areas built
251 isles built
Attaching islands...
Attaching centroids...
Number of nodes: 8636
Number of primitives: 19070
Number of points: 0
Number of lines: 0
Number of boundaries: 13729
Number of centroids: 5341
Number of areas: 5344
Number of isles: 251
--
Tool: Remove small areas
ERROR: Area merging failed



-- 

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

Re: [GRASS-dev] GRASS7.0 on Mavericks

[Yann Chemin]

Thank you Anna,

it works as main owner of the machine, not as an additional user...

Will try,
Yann


On 15 December 2013 20:25, Anna Petrášová  wrote:

> Hi Yann,
>
> I don't think this problem relates to toolboxes. The error message is
> completely different. I would first suggest to install new Python version
> 2.7.6 [1] because there have been some problems and Python had to release
> new version. If this does not help, unfortunately I have no other idea.
>
> Anna
>
> [1] http://www.python.org/getit/
>
>
> On Sun, Dec 15, 2013 at 2:43 AM, Yann Chemin  wrote:
>
>> Oh yes I remember some times back reading about it, apologies.
>>
>>
>>
>> On 15 December 2013 02:19, Michael Barton wrote:
>>
>>> This is the bug I've been reporting for months now. It was introduced
>>> with the new tool box feature. There is a work around I can send you when
>>> I'm back at a computer. But it really needs to be found and fixed. Anna and
>>> I have tried to track it down without success yet.
>>>
>>> Michael Barton
>>>
>>> Sent from my iPhone...
>>> (so please excuse any typos)
>>>
>>> On Dec 14, 2013, at 5:51 AM, Yann Chemin  wrote:
>>>
>>> Hi,
>>>
>>> I created a new user (also administrator) on a MacBook and started to
>>> follow Michael's steps to install version 7 Maverick
>>>
>>> I get a strange error on install, the directory GRASS (inside is the
>>> application grass-7.0) is there but I do not have permission to open the
>>> directory in Finder (though I did install it). Going to the "main" user of
>>> the machine I could change the permissions, and also checked that GRASS7.0
>>> runs well, all good there, no worries.
>>>
>>> Going back to my user, I can go in the directory, and launch the
>>> application, ok. Then things go weird. It was working well in the "main"
>>> user but bugs in that new user... Both have admin level.
>>>
>>> Python 2.7.5 found.
>>>
>>>
>>> WELCOME TO GRASS 7.0.svn
>>>
>>>
>>>1) Have at your side all available GRASS GIS tutorials
>>>
>>>
>>>2) When working on your location, the following materials
>>>
>>>   are extremely useful:
>>>
>>>   - A topographic map of your area
>>>
>>>   - Current catalog of available computer maps
>>>
>>>
>>>3) heck the GRASS GIS web pages for supporting mailing lists and more:
>>>
>>>   http://grass.osgeo.org
>>>
>>>
>>> Hit RETURN to continue
>>>
>>> Starting GRASS GIS...
>>>
>>> Traceback (most recent call last):
>>>
>>>   File
>>> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gis_set.py",
>>> line 37, in 
>>>
>>> from core.utils import _
>>>
>>>   File
>>> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/utils.py",
>>> line 36, in 
>>>
>>> from core.gcmd  import RunCommand
>>>
>>>   File
>>> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
>>> line 744, in 
>>>
>>> _enc = GetDefaultEncoding() # define as global variable
>>>
>>>   File
>>> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
>>> line 737, in GetDefaultEncoding
>>>
>>> enc = locale.getdefaultlocale()[1]
>>>
>>>   File
>>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
>>> line 511, in getdefaultlocale
>>>
>>> return _parse_localename(localename)
>>>
>>>   File
>>> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
>>> line 443, in _parse_localename
>>>
>>> raise ValueError, 'unknown locale: %s' % localename
>>>
>>> ValueError: unknown locale: UTF-8
>>>
>>> Error in GUI startup. If necessary, please report this error to the
>>> GRASS developers.
>>>
>>> Switching to text mode now.
>>>
>>>
>>> --
>>> 
>>>
>>>
>>
>>
>> --
>> 
>>
>> ___
>> 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] GRASS7.0 on Mavericks

[Yann Chemin]

Oh yes I remember some times back reading about it, apologies.



On 15 December 2013 02:19, Michael Barton wrote:

> This is the bug I've been reporting for months now. It was introduced with
> the new tool box feature. There is a work around I can send you when I'm
> back at a computer. But it really needs to be found and fixed. Anna and I
> have tried to track it down without success yet.
>
> Michael Barton
>
> Sent from my iPhone...
> (so please excuse any typos)
>
> On Dec 14, 2013, at 5:51 AM, Yann Chemin  wrote:
>
> Hi,
>
> I created a new user (also administrator) on a MacBook and started to
> follow Michael's steps to install version 7 Maverick
>
> I get a strange error on install, the directory GRASS (inside is the
> application grass-7.0) is there but I do not have permission to open the
> directory in Finder (though I did install it). Going to the "main" user of
> the machine I could change the permissions, and also checked that GRASS7.0
> runs well, all good there, no worries.
>
> Going back to my user, I can go in the directory, and launch the
> application, ok. Then things go weird. It was working well in the "main"
> user but bugs in that new user... Both have admin level.
>
> Python 2.7.5 found.
>
>
> WELCOME TO GRASS 7.0.svn
>
>
>1) Have at your side all available GRASS GIS tutorials
>
>
>2) When working on your location, the following materials
>
>   are extremely useful:
>
>   - A topographic map of your area
>
>   - Current catalog of available computer maps
>
>
>3) heck the GRASS GIS web pages for supporting mailing lists and more:
>
>   http://grass.osgeo.org
>
>
> Hit RETURN to continue
>
> Starting GRASS GIS...
>
> Traceback (most recent call last):
>
>   File
> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gis_set.py",
> line 37, in 
>
> from core.utils import _
>
>   File
> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/utils.py",
> line 36, in 
>
> from core.gcmd  import RunCommand
>
>   File
> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
> line 744, in 
>
> _enc = GetDefaultEncoding() # define as global variable
>
>   File
> "/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
> line 737, in GetDefaultEncoding
>
> enc = locale.getdefaultlocale()[1]
>
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
> line 511, in getdefaultlocale
>
> return _parse_localename(localename)
>
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
> line 443, in _parse_localename
>
> raise ValueError, 'unknown locale: %s' % localename
>
> ValueError: unknown locale: UTF-8
>
> Error in GUI startup. If necessary, please report this error to the GRASS
> developers.
>
> Switching to text mode now.
>
>
> --
> 
>
>


-- 

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

[GRASS-dev] GRASS7.0 on Mavericks

[Yann Chemin]

Hi,

I created a new user (also administrator) on a MacBook and started to
follow Michael's steps to install version 7 Maverick

I get a strange error on install, the directory GRASS (inside is the
application grass-7.0) is there but I do not have permission to open the
directory in Finder (though I did install it). Going to the "main" user of
the machine I could change the permissions, and also checked that GRASS7.0
runs well, all good there, no worries.

Going back to my user, I can go in the directory, and launch the
application, ok. Then things go weird. It was working well in the "main"
user but bugs in that new user... Both have admin level.

Python 2.7.5 found.


WELCOME TO GRASS 7.0.svn


   1) Have at your side all available GRASS GIS tutorials


   2) When working on your location, the following materials

  are extremely useful:

  - A topographic map of your area

  - Current catalog of available computer maps


   3) heck the GRASS GIS web pages for supporting mailing lists and more:

  http://grass.osgeo.org


Hit RETURN to continue

Starting GRASS GIS...

Traceback (most recent call last):

  File
"/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/gis_set.py",
line 37, in 

from core.utils import _

  File
"/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/utils.py",
line 36, in 

from core.gcmd  import RunCommand

  File
"/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
line 744, in 

_enc = GetDefaultEncoding() # define as global variable

  File
"/Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/gcmd.py",
line 737, in GetDefaultEncoding

enc = locale.getdefaultlocale()[1]

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
line 511, in getdefaultlocale

return _parse_localename(localename)

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py",
line 443, in _parse_localename

raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: UTF-8

Error in GUI startup. If necessary, please report this error to the GRASS
developers.

Switching to text mode now.


-- 

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

Re: [GRASS-dev] importing M3 data (Chandrayaan Moon Multispectral Mapper) in GRASS

[Yann Chemin]

Following up, I made this script to create an ascii file per band of M3.
Inputs are L1B LOC.IMG (ENVI format actually) for X,Y,Z, and L2 REF.IMG
(also ENVI, but many bands). output are ascii*.xyz, will update with final
scripts once it will have finished the process once...

-
Temporary script to create r.in.xyz compatible input files, one file per
band of M3...
-

#!/usr/bin/env python
#if older python use:
#from __future__ import *

print("Usage: m3xyz.py LOCfile.IMG ReflectFile.IMG")
# For image processing

from math import *
import numpy

from osgeo import gdalnumeric
from osgeo import gdal

from osgeo.gdal_array import *
from osgeo.gdalconst import *


import os, sys
#Load Loc file

#loc = LoadFile( sys.argv[1] )
#ref = LoadFile( sys.argv[2] )
loc = "M3G20090111T013904_V03_LOC.IMG"
ref = "M3G20090111T013904_V01_RFL.IMG"
out = "outascii"

#Location dataset
ds_loc = gdal.Open(loc, GA_ReadOnly)
ds_loc_cols = ds_loc.RasterXSize
ds_loc_rows = ds_loc.RasterYSize
ds_loc_bands = ds_loc.RasterCount
ds_loc_driver = ds_loc.GetDriver().LongName

b1 = ds_loc.GetRasterBand(1)
longitude = b1.ReadAsArray(0, 0, ds_loc_cols,
ds_loc_rows).astype(numpy.float)
b2 = ds_loc.GetRasterBand(2)
latitude = b2.ReadAsArray(0, 0, ds_loc_cols,
ds_loc_rows).astype(numpy.float)
b3 = ds_loc.GetRasterBand(3)
radius = b3.ReadAsArray(0, 0, ds_loc_cols, ds_loc_rows).astype(numpy.float)

#Reflectance dataset
ds_ref = gdal.Open(ref, GA_ReadOnly)
ds_ref_cols = ds_ref.RasterXSize
ds_ref_rows = ds_ref.RasterYSize
ds_ref_bands = ds_ref.RasterCount
ds_ref_driver = ds_ref.GetDriver().LongName

for n in range (ds_ref.RasterCount):
f=open(out+"_"+str(n)+".xyz","w")
b = ds_ref.GetRasterBand(n+1)
d = b.ReadAsArray(0, 0, ds_ref_cols, ds_ref_rows).astype(numpy.float)
for row in range(ds_ref_rows):
for col in range(ds_ref_cols):

f.write(str(longitude[row,col])+str(latitude[row,col])+str(d[row,col]))

f.close()
del d,b,f



On 28 November 2013 10:47, Yann Chemin  wrote:

> Hi,
>
> Chandrayaan M3 data is rather strange, it has products without
> Georeference (i.e. Reflectance bands etc) and it has a .LOC image set (3
> bands), with one latitude band, one longitude band and one "altitude" band
> (actually a distance to center of the moon).
>
> So each pixel of a product has indeed a coordinate, stored into a map.
> Problem is that the products are not projected datasets (rectangular kind
> of swath storage).
>
> What would be the best option to import with reprojection using all pixels
> coordinates available...
> What about importing in 3D?
>
> Thank you,
> Yann
>
>
>
> --
> 
>



-- 

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

[GRASS-dev] importing M3 data (Chandrayaan Moon Multispectral Mapper) in GRASS

[Yann Chemin]

Hi,

Chandrayaan M3 data is rather strange, it has products without Georeference
(i.e. Reflectance bands etc) and it has a .LOC image set (3 bands), with
one latitude band, one longitude band and one "altitude" band (actually a
distance to center of the moon).

So each pixel of a product has indeed a coordinate, stored into a map.
Problem is that the products are not projected datasets (rectangular kind
of swath storage).

What would be the best option to import with reprojection using all pixels
coordinates available...
What about importing in 3D?

Thank you,
Yann



-- 

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

Re: [GRASS-dev] using libpath + ":" + in grass70 unsupported operand type

[Yann Chemin]

Hi Vaclav,

on my 64 bit machine, none of this happens.
Will check back home tonight...

Cheers,
Yann


On 25 November 2013 21:39, Vaclav Petras  wrote:

>
>
>
> On Mon, Nov 25, 2013 at 10:55 AM, Yann Chemin  wrote:
>
>> Hi,
>>
>> ~/grass_dev$ grass70
>> Traceback (most recent call last):
>>   File "/usr/local/bin/grass70", line 1267, in 
>> load_env()
>>   File "/usr/local/bin/grass70", line 753, in load_env
>> os.environ['LD_LIBRARY_PATH'] = libpath + ":" + isislibpath + ":" +
>> isis3rdparty
>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
>>
>> : is certainly not considered a string, but I cannot force it to be
>> string either... Any idea?
>>
>>
> Hi Yann,
>
> I'm not sure if I understand your situation, anyway:
>
> My line 753 in lib/init/grass.py says:
>
>   ... libpath + os.pathsep + isislibpath + os.pathsep + isis3rdparty
>
> os.pathsep is for sure type str as well as ":" literal is type str.
>
> I would say that one of libpath, isislibpath and isis3rdparty is None
> although lines above seems that they sets everything.
>
> Can you debug your code? Simple print before line 753 should be enough:
>
>   print libpath, isislibpath, isis3rdparty
>
> As far as I know, the print will not break the start up, so it should work.
>
> Vaclav
>
> Thanks
>>
>> --
>> 
>>
>> ___
>> 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

[GRASS-dev] using libpath + ":" + in grass70 unsupported operand type

[Yann Chemin]

Hi,

~/grass_dev$ grass70
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 1267, in 
load_env()
  File "/usr/local/bin/grass70", line 753, in load_env
os.environ['LD_LIBRARY_PATH'] = libpath + ":" + isislibpath + ":" +
isis3rdparty
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

: is certainly not considered a string, but I cannot force it to be string
either... Any idea?

Thanks

-- 

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

Re: [GRASS-dev] i.pansharpen and Landsat 8

[Yann Chemin]

I did not run i.landsat.toar, so data is still 16-bit, not float. Might be
the difference indeed.


On 23 October 2013 18:43, Moritz Lennert wrote:

> On 23/10/13 12:48, Markus Neteler wrote:
>
>> On Wed, Oct 23, 2013 at 10:09 AM, Yann Chemin  wrote:
>>
>>> Using L8 with i.pansharpen gives nodata output, is it assuming 8-bit
>>> datasets?
>>>
>>
>> I didn't have such problems, see
>>
>> http://courses.neteler.org/**processing-landsat-8-data-in-**
>> grass-gis-7-rgb-composites-**and-pan-sharpening/<http://courses.neteler.org/processing-landsat-8-data-in-grass-gis-7-rgb-composites-and-pan-sharpening/>
>>
>
> In the first part of that tutorial, you run i.landsat.toar on the data.
> Could that make a difference ?
>
> Moritz
> __**_
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/grass-dev<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

[GRASS-dev] i.pansharpen and Landsat 8

[Yann Chemin]

Using L8 with i.pansharpen gives nodata output, is it assuming 8-bit
datasets?

-- 

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

Re: [GRASS-dev] ccmath compilation error

[Yann Chemin]

Yes an upgrade to 13.10 does (again) solve the problem


On 22 October 2013 02:38, Rashad M  wrote:

> This is only for ubuntu 13.04 34bit. Failing for a long time in launchpad
> builds[1]. I had filed a bug report[2] but no response yet.
>
> [1]
> https://launchpadlibrarian.net/149593351/buildlog_ubuntu-raring-i386.grass70_7.0.0%2B0ubuntu2%2B29074~ubuntu13.04.1_FAILEDTOBUILD.txt.gz
>
> [2] https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1201048
>
> Unfortunately no response. Too bad for a gcc project.
>
>
> On Sun, Oct 20, 2013 at 4:47 PM, Yann Chemin  wrote:
>
>> Yes Markus, seems to be an Ubuntu 13.04 issue with both my nettop (Atom)
>> pcs.
>> I am upgrading this one too in the hope to fix the same way.
>>
>>
>>
>> On 20 October 2013 17:26, Markus Neteler  wrote:
>>
>>> On Sun, Oct 20, 2013 at 9:48 AM, Yann Chemin  wrote:
>>> > lib/external/ccmath$ make
>>> > make lib
>>> > make[1]: Entering directory
>>> > `/home/yann/grass_dev/grass_yann/lib/external/ccmath'
>>> > gcc  -g -O2  -fPIC
>>> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
>>> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
>>> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPACKAGE=\""grasslibs"\"
>>> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
>>> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include -o
>>> > OBJ.i686-pc-linux-gnu/house.o -c house.c
>>> > house.c: In function ‘house’:
>>> > house.c:10:6: internal compiler error: in rewrite_use_nonlinear_expr,
>>> at
>>> > tree-ssa-loop-ivopts.c:6215
>>> > Please submit a full bug report,
>>> > with preprocessed source if appropriate.
>>> > See  for instructions.
>>> > Preprocessed source stored into /tmp/cc8wc4KR.out file, please attach
>>> this
>>> > to your bugreport.
>>> > make[1]: *** [OBJ.i686-pc-linux-gnu/house.o] Error 1
>>> > make[1]: Leaving directory
>>> > `/home/yann/grass_dev/grass_yann/lib/external/ccmath'
>>> > make: *** [default] Error 2
>>> >
>>> > GCC version
>>> > gcc -v
>>> > Using built-in specs.
>>> > COLLECT_GCC=gcc
>>> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
>>> > Target: i686-linux-gnu
>>> > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
>>> > 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
>>> > --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
>>> > --program-suffix=-4.7 --enable-shared --enable-linker-build-id
>>> > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
>>> > --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib
>>> --enable-nls
>>> > --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
>>> > --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
>>> > --with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog
>>> > --enable-cloog-backend=ppl --disable-cloog-version-check
>>> > --disable-ppl-version-check --enable-multiarch --disable-werror
>>> > --with-arch-32=i686 --with-multilib-list=m32,m64,mx32
>>> --with-tune=generic
>>> > --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
>>> > --target=i686-linux-gnu
>>> > Thread model: posix
>>> > gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
>>>
>>> You posted that also earlier this year with this solution:
>>>
>>> http://lists.osgeo.org/pipermail/grass-dev/2013-June/064468.html
>>> "I have not had that problem after upgrading the machine..."
>>>
>>> Perhaps try that again on your actual system?
>>>
>>> Markus
>>>
>>
>>
>>
>> --
>> 
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
>
> --
> Regards,
>Rashad
>



-- 

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

[GRASS-dev] Planetary option gone in GRASS 7 SVN WxGUI Location Wizard?

[Yann Chemin]

Hi,

wanted to make a Moon location and the option for Planetary Locations
definitions is gone...

Yann

-- 

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

Re: [GRASS-dev] ccmath compilation error

[Yann Chemin]

Yes Markus, seems to be an Ubuntu 13.04 issue with both my nettop (Atom)
pcs.
I am upgrading this one too in the hope to fix the same way.



On 20 October 2013 17:26, Markus Neteler  wrote:

> On Sun, Oct 20, 2013 at 9:48 AM, Yann Chemin  wrote:
> > lib/external/ccmath$ make
> > make lib
> > make[1]: Entering directory
> > `/home/yann/grass_dev/grass_yann/lib/external/ccmath'
> > gcc  -g -O2  -fPIC
> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPACKAGE=\""grasslibs"\"
> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
> > -I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include -o
> > OBJ.i686-pc-linux-gnu/house.o -c house.c
> > house.c: In function ‘house’:
> > house.c:10:6: internal compiler error: in rewrite_use_nonlinear_expr, at
> > tree-ssa-loop-ivopts.c:6215
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > Preprocessed source stored into /tmp/cc8wc4KR.out file, please attach
> this
> > to your bugreport.
> > make[1]: *** [OBJ.i686-pc-linux-gnu/house.o] Error 1
> > make[1]: Leaving directory
> > `/home/yann/grass_dev/grass_yann/lib/external/ccmath'
> > make: *** [default] Error 2
> >
> > GCC version
> > gcc -v
> > Using built-in specs.
> > COLLECT_GCC=gcc
> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
> > Target: i686-linux-gnu
> > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
> > 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
> > --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
> > --program-suffix=-4.7 --enable-shared --enable-linker-build-id
> > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> > --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib
> --enable-nls
> > --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
> > --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
> > --with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog
> > --enable-cloog-backend=ppl --disable-cloog-version-check
> > --disable-ppl-version-check --enable-multiarch --disable-werror
> > --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic
> > --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
> > --target=i686-linux-gnu
> > Thread model: posix
> > gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
>
> You posted that also earlier this year with this solution:
>
> http://lists.osgeo.org/pipermail/grass-dev/2013-June/064468.html
> "I have not had that problem after upgrading the machine..."
>
> Perhaps try that again on your actual system?
>
> Markus
>



-- 

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

[GRASS-dev] ccmath compilation error

[Yann Chemin]

lib/external/ccmath$ make
make lib
make[1]: Entering directory
`/home/yann/grass_dev/grass_yann/lib/external/ccmath'
gcc  -g -O2  -fPIC
-I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
-I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -DPACKAGE=\""grasslibs"\"
-I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include
-I/home/yann/grass_dev/grass_yann/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/house.o -c house.c
house.c: In function ‘house’:
house.c:10:6: internal compiler error: in rewrite_use_nonlinear_expr, at
tree-ssa-loop-ivopts.c:6215
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc8wc4KR.out file, please attach this
to your bugreport.
make[1]: *** [OBJ.i686-pc-linux-gnu/house.o] Error 1
make[1]: Leaving directory
`/home/yann/grass_dev/grass_yann/lib/external/ccmath'
make: *** [default] Error 2

GCC version
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog
--enable-cloog-backend=ppl --disable-cloog-version-check
--disable-ppl-version-check --enable-multiarch --disable-werror
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)



-- 

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

Re: [GRASS-dev] pygrass - r.report

[Yann Chemin]

+1

Yann


On 17 October 2013 16:41, Martin Landa  wrote:

> 2013/10/17 Pietro :
> > Maybe this is better:
> >
> > ValueError: The Parameter , must be a python list containing
> > one or more of the following values: ['mi', 'me', 'k',  'a', 'h', 'c',
> 'p']
>
> +1, Martin
>
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> 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