Re: [GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Paulo van Breugel]

On 02-02-17 08:17, Vincent Bain wrote:

Le jeudi 02 février 2017 à 08:10 +0100, Paulo van Breugel a écrit :


I haven't tried that, but would that append objects to an existing
layer within the spatialite database?

yes it does... without warning for duplicates.
Would be good to add a few lines on that on the wiki page. Could you do 
that?



In the manual it is stated that v.out.ogr exports 3D vector data as
2.5D simple features if possible. I don't know if that is supported by
Spatialite, but if not, it is indeed good to mention.

I thought it would be nice to write a brief page related to raster
export with rasterlite format option available at r.out.gdal. I'll try
to propose it soon.
I didn't know that option, would be great if you could add something 
about that option to the wiki page


V.



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

Re: [GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Vincent Bain]

Le jeudi 02 février 2017 à 08:10 +0100, Paulo van Breugel a écrit :

> I haven't tried that, but would that append objects to an existing
> layer within the spatialite database?

yes it does... without warning for duplicates.

> In the manual it is stated that v.out.ogr exports 3D vector data as
> 2.5D simple features if possible. I don't know if that is supported by
> Spatialite, but if not, it is indeed good to mention.

I thought it would be nice to write a brief page related to raster
export with rasterlite format option available at r.out.gdal. I'll try
to propose it soon.

V.

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

Re: [GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Paulo van Breugel]

On 02-02-17 08:00, Vincent Bain wrote:

Hi Paulo,

I confirm I use the -u flag (+ --o) as you suggest, without complete
overwriting issue.
Perphaps a mention can be made to the -a flag, allowing to append
objects to an existing layer ?
I haven't tried that, but would that append objects to an existing layer 
within the spatialite database?


And f you want to export a 3d vector, you first need to turn it to 2d
(am I wrong ?)
In the manual it is stated that /v.out.ogr/ exports 3D vector data as 
2.5D simple features if possible. I don't know if that is supported by 
Spatialite, but if not, it is indeed good to mention.




Vincent.

Le mercredi 01 février 2017 à 15:33 +0100, Paulo van Breugel a écrit :

I made an update of the page on exporting a layer to a Spatialite
database with v.out.ogr (https://grasswiki.osgeo.org/wiki/SpatiaLite).
Can anybody please check ?

Paulo

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




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

Re: [GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Vincent Bain]

Hi Paulo,

I confirm I use the -u flag (+ --o) as you suggest, without complete
overwriting issue.
Perphaps a mention can be made to the -a flag, allowing to append
objects to an existing layer ?

And f you want to export a 3d vector, you first need to turn it to 2d
(am I wrong ?)

Vincent.

Le mercredi 01 février 2017 à 15:33 +0100, Paulo van Breugel a écrit :
> I made an update of the page on exporting a layer to a Spatialite 
> database with v.out.ogr (https://grasswiki.osgeo.org/wiki/SpatiaLite). 
> Can anybody please check ?
> 
> Paulo
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev


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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1905 (master - 6b1098b)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1905
Status: Still Failing

Duration: 13 minutes and 35 seconds
Commit: 6b1098b (master)
Author: Václav Petráš
Message: doc: unified size handling for module and default image using 
object-fit

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70472 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/1c5c17f65200...6b1098bfbbf7

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/197531742

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1904 (master - 1c5c17f)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1904
Status: Still Failing

Duration: 50 minutes and 7 seconds
Commit: 1c5c17f (master)
Author: Václav Petráš
Message: wxGUI: show the font dialog even when the font from settings is not 
recognized (fixes traceback)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70469 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/3fbf534021c0...1c5c17f65200

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/197502686

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1903 (master - 3fbf534)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1903
Status: Still Failing

Duration: 46 minutes and 56 seconds
Commit: 3fbf534 (master)
Author: Anna Petrášová
Message: r.mode: copy cover raster color table to output raster

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70468 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/92975adcd06a...3fbf534021c0

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/197500064

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

Re: [GRASS-dev] [GRASS GIS] #2450: Grass7: improve font selection dialog in GUI option for map display

[GRASS GIS]

#2450: Grass7: improve font selection dialog in GUI option for map display
-+-
  Reporter:  hellik  |  Owner:  grass-dev@…
  Type:  | Status:  closed
  enhancement|
  Priority:  normal  |  Milestone:  7.2.1
 Component:  wxGUI   |Version:  unspecified
Resolution:  fixed   |   Keywords:  fonts dialog selection d.font
   CPU:  |  d.fontlist fontcap
  Unspecified|   Platform:  Unspecified
-+-
Changes (by wenzeslaus):

 * status:  new => closed
 * keywords:  fonts => fonts dialog selection d.font d.fontlist fontcap
 * resolution:   => fixed
 * milestone:  7.4.0 => 7.2.1


Comment:

 The Map Display tab and d.vect now have selection similar to what Map
 Display tab had before but with life preview of the font as rendered by
 GRASS GIS. I'm closing this as fixed. Done in r68713 and r68757. Available
 in 7.2.0.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1378: Error when clicking 'Set Font' dialog in wxGUI settings

[GRASS GIS]

#1378: Error when clicking 'Set Font' dialog in wxGUI settings
--+--
  Reporter:  epatton  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.1
 Component:  wxGUI|Version:  svn-develbranch6
Resolution:  fixed|   Keywords:  font, set font, settings
   CPU:  x86-32   |   Platform:  Linux
--+--
Changes (by wenzeslaus):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  6.4.6 => 7.2.1


Comment:

 There was several changes recently and libraries changed as well since the
 original report. I consider this as mostly working and I'm closing this as
 fixed. Please, open new specific tickets for the new problems if you
 encounter some.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3021: Scale bar text is mostly hidden when text position left is used

[GRASS GIS]

#3021: Scale bar text is mostly hidden when text position left is used
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  trivial  |  Milestone:  7.4.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.barscale, text_position
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Workaround - add large enough x to `at`:

 {{{
 d.barscale at=10.0,10.0 text_position=left
 }}}

 This will shift the scale bar left with `d.mon cairo` and in GUI it will
 show the text (move scale bar manually afterwards).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3146: On the Programmer's Manual font color

[GRASS GIS]

#3146: On the Programmer's Manual font color
---+-
  Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.0.6
 Component:  Docs  |Version:  unspecified
Resolution:|   Keywords:  doxygen
   CPU:  Unspecified   |   Platform:  Unspecified
---+-

Comment (by wenzeslaus):

 Sounds good. It does not have to be exact color from the logo. If it has
 good contrast is more important. Please submit a patch.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert  wrote:

> >please take a look at GAL project from 2008 [1]. Ma
>
>
I didn't really work out the differences to GAL project but this GSoC
project should be less ambitious, much more limited, cover smaller part of
the functionality, and perhaps be less high level. Another difference would
be that the GSoC proposal aims to cover both C and C++ APIs and is limited
only to module development (no GUI-aware/friendly API).


>
> I don't really agree with the idea that
>
> "Unfortunately, its [GRASS'] development is stagnating because of small
> interest
> from fresh and young developers. This is partially caused by the fact that
> its design and
> concepts are overcome by modern practices in a software development."
>
> I do not see GRASS stagnating. And even though GRASS uses an "old"
> language,


I think C is fine and that might be more clear now than in 2008, but C++ is
popular too. However, the motivation for GSoC is make writing of modules in
C and C++ easier. We may discuss if "development is stagnating because of
small interest" is true or not, but for sure we can have better interface
which would attract more people. There are people writing custom C or C++
code for basic geospatial things which GRASS libraries do in a way which is
better than what they have or aim for.

More pressing problem however are the modules which use variants of
all-in-memory and tiling-on-disk raster reading modes. I'm not sure what is
the state now, because MarkusM fixed a lot of those, but some addons were
not included into core because of custom segment libraries (and even now
they have custom all-in-memory implementations).

I imagine that it's unpleasant if all you believe in is OO, but that
> doesn't necessarily make OO the naturally best way to go... :-)
>

Similarly to Python API, OOP is not the only thing we should focus on. C++
is a multiparadigm language and OOP is just part of it (e.g. templates are
kind of big), plus there are different levels of doing OOP ("C with
classes" versus more complicated OOP). So yes, the student should be
familiar with more than just OOP.


>
> b) I'm afraid it's too big of a project for GSoC and that we would put the
> student in an uncomfortable position.


It should be much smaller than GAL project and it should be mostly
additions to API, not rewriting the libraries.

That's at least my idea. I hope this clarifies it a bit.

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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Vaclav Petras]

I did not include many details in the idea so here they are.

On Wed, Feb 1, 2017 at 11:59 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> I just the GSoC proposal for a "Higher level API for C and C++".
>

It it should not remove the existing API but build on to of it.


> I _think_ I understand where this comes from,
>

Good example is the random access to raster cells which runs in
all-in-memory and tiling-on-disk modes. Several modules need it, several
modules implement it in different ways. Segement library helps but solves
just part of the issue.


> but it does raise some very fundamental issues about how GRASS is written
> and should be written,
>

The implementation should stay the the intact, especially when talking
about GSoC. The point is to create a better API. Something link PyGRASS but
in C and C++. PyGRASS also uses existing C functions but wraps them in the
way they are easy to use (this would be case for C API) or more appropriate
to the language (C++).


> notably, but not only, the inclusion of a C++ API.
>

Add C++ API can be adding just few header files. Limiting the C++ API to
what "fits" into a header file has two advantages: same functionality needs
to be accessible in C API and it avoids (some/all?) issues of C++ linking.


>
> I just want to ensure that there is sufficient discussion on the list
> about such a project which could have far-reaching consequences. And if we
> ever decide to for such a project, then I think it has to be made
> absolutely clear that the student working on this needs to be extremely
> proficient in C/C++.
>

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

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

Le 1 février 2017 21:02:25 GMT+01:00, Martin Landa  a 
écrit :
>Hi,
>
>2017-02-01 17:59 GMT+01:00 Moritz Lennert
>:
>> I just the GSoC proposal for a "Higher level API for C and C++". I
>_think_ I
>> understand where this comes from, but it does raise some very
>fundamental
>> issues about how GRASS is written and should be written, notably, but
>not
>> only, the inclusion of a C++ API.
>>
>> I just want to ensure that there is sufficient discussion on the list
>about
>> such a project which could have far-reaching consequences. And if we
>ever
>> decide to for such a project, then I think it has to be made
>absolutely
>> clear that the student working on this needs to be extremely
>proficient in
>> C/C++. Otherwise, I'm afraid that we risk creating a great mess that
>might
>> need lots of cleanup work afterwards.
>
>please take a look at GAL project from 2008 [1]. Ma


Interesting. But was this ever discussed on the lists ?

I don't really agree with the idea that

"Unfortunately, its [GRASS'] development is stagnating because of small interest
from fresh and young developers. This is partially caused by the fact that its 
design and
concepts are overcome by modern practices in a software development."

I do not see GRASS stagnating. And even though GRASS uses an "old" language, 
and it's core was developed long ago, its code base, IMHO, still represents 
very good practice in terms of programming.

I also have to smile when reading that one of the obstacles to "modernization" 
of GRASS is the "unpleasant attitude of GRASS developers to the 
object­-oriented programming." 

I imagine that it's unpleasant if all you believe in is OO, but that doesn't 
necessarily make OO the naturally best way to go... :-)

All this said : I'm not against a reflection about a fundamental rewrite of 
GRASS, but a) it should be extensively discussed on this list before even 
starting to code anything and b) I'm afraid it's too big of a project for GSoC 
and that we would put the student in an uncomfortable position.

Moritz

>
>[1]
>https://dspace.vutbr.cz/xmlui/bitstream/handle/11012/53128/5989.pdf?sequence=1&isAllowed=y
>[2] https://ojs.cvut.cz/ojs/index.php/gi/article/viewFile/gi.3.1/2561
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Martin Landa]

Hi,

2017-02-01 17:59 GMT+01:00 Moritz Lennert :
> I just the GSoC proposal for a "Higher level API for C and C++". I _think_ I
> understand where this comes from, but it does raise some very fundamental
> issues about how GRASS is written and should be written, notably, but not
> only, the inclusion of a C++ API.
>
> I just want to ensure that there is sufficient discussion on the list about
> such a project which could have far-reaching consequences. And if we ever
> decide to for such a project, then I think it has to be made absolutely
> clear that the student working on this needs to be extremely proficient in
> C/C++. Otherwise, I'm afraid that we risk creating a great mess that might
> need lots of cleanup work afterwards.

please take a look at GAL project from 2008 [1]. Ma

[1] 
https://dspace.vutbr.cz/xmlui/bitstream/handle/11012/53128/5989.pdf?sequence=1&isAllowed=y
[2] https://ojs.cvut.cz/ojs/index.php/gi/article/viewFile/gi.3.1/2561

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC proposal "Higher level API for C and C++" : need for discussion

[Moritz Lennert]

Hi,

I just the GSoC proposal for a "Higher level API for C and C++". I 
_think_ I understand where this comes from, but it does raise some very 
fundamental issues about how GRASS is written and should be written, 
notably, but not only, the inclusion of a C++ API.


I just want to ensure that there is sufficient discussion on the list 
about such a project which could have far-reaching consequences. And if 
we ever decide to for such a project, then I think it has to be made 
absolutely clear that the student working on this needs to be extremely 
proficient in C/C++. Otherwise, I'm afraid that we risk creating a great 
mess that might need lots of cleanup work afterwards.


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

[GRASS-dev] update wiki page export to spatialite dbase with v.out.ogr

[Paulo van Breugel]

I made an update of the page on exporting a layer to a Spatialite 
database with v.out.ogr (https://grasswiki.osgeo.org/wiki/SpatiaLite). 
Can anybody please check ?


Paulo

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

Re: [GRASS-dev] cannot make it to Genova GFOSS.it 2017

[Martin Landa]

Hi Yann,

2017-02-01 10:18 GMT+01:00 Yann Chemin :
> sorry cannot make it to Genova gfoss.it,
> I'll try to do something over the week-end online though.

it's pity, I will be there at the end. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] small correction r.gradient help file

[Paulo van Breugel]

On 01-02-17 10:32, Luca Delucchi wrote:

On 31 January 2017 at 23:28, Markus Neteler  wrote:

On Mon, Jan 30, 2017 at 11:20 AM, Paulo van Breugel
 wrote:

I have a small correction for the manual page of the r.gradient addon. In
the examples, the parameter 'values'  is used. This should be 'range' I
assume. Luca, if you want me to correct his, I can, otherwise, see attached
a patch file.

Please apply, Paulo.

+1

done



Markus





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

Re: [GRASS-dev] small correction r.gradient help file

[Luca Delucchi]

On 31 January 2017 at 23:28, Markus Neteler  wrote:
> On Mon, Jan 30, 2017 at 11:20 AM, Paulo van Breugel
>  wrote:
>> I have a small correction for the manual page of the r.gradient addon. In
>> the examples, the parameter 'values'  is used. This should be 'range' I
>> assume. Luca, if you want me to correct his, I can, otherwise, see attached
>> a patch file.
>
> Please apply, Paulo.

+1

>
> Markus



-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] cannot make it to Genova GFOSS.it 2017

[Yann Chemin]

Hi guys,

sorry cannot make it to Genova gfoss.it,
I'll try to do something over the week-end online though.

Ciao,
Yann
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev