Re: [GRASS-dev] [GRASS GIS] #3270: v.out.ogr: Append mode broken in G 7.2.1svn and 7.3

[GRASS GIS]

#3270: v.out.ogr: Append mode broken in G 7.2.1svn and 7.3
--+-
  Reporter:  sbl  |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Vector   |Version:  svn-releasebranch72
Resolution:   |   Keywords:  v.out.ogr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * owner:  grass-dev@… => martinl
 * cc: grass-dev@… (added)
 * status:  new => assigned


--
Ticket URL: 
GRASS GIS 

___
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#1908 (master - 8875135)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1908
Status: Still Failing

Duration: 1 hour, 12 minutes, and 3 seconds
Commit: 8875135 (master)
Author: Moritz Lennert
Message: i.zc: threshold was not read correctly and had no effect


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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/cf468d62e0f7...8875135d3c9f

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

--

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] update wiki page export to spatialite dbase with v.out.ogr

[Vincent Bain]

Here's a brief contribution to the Spatialite wiki page :
https://grasswiki.osgeo.org/wiki/SpatiaLite

Perhaps we should wait for a bug fix concerning the ability to append
objects to existing vector layers.

Yours,
Vincent

Le jeudi 02 février 2017 à 08:09 +, Blumentrath, Stefan a écrit :
> Hi,
> 
> If you are n latest GRASS 7.2.1svn, maybe you hit this one:
> https://trac.osgeo.org/grass/ticket/3270
> 
> Cheers
> Stefan
> 
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
> van Breugel
> Sent: torsdag 2. februar 2017 08.20
> To: Vincent Bain 
> Cc: GRASS developers email list 
> Subject: Re: [GRASS-dev] update wiki page export to spatialite dbase with 
> v.out.ogr
> 
> 
> 
> 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


___
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#1907 (master - cf468d6)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1907
Status: Still Failing

Duration: 47 minutes and 54 seconds
Commit: cf468d6 (master)
Author: Václav Petráš
Message: Python 2.6 does not support ommitting of positional argument specifiers

Fixes ValueError: zero length field name in format


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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/461d67d6fae3...cf468d62e0f7

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

--

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] update wiki page export to spatialite dbase with v.out.ogr

[Blumentrath, Stefan]

Hi,

If you are n latest GRASS 7.2.1svn, maybe you hit this one:
https://trac.osgeo.org/grass/ticket/3270

Cheers
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
van Breugel
Sent: torsdag 2. februar 2017 08.20
To: Vincent Bain 
Cc: GRASS developers email list 
Subject: Re: [GRASS-dev] update wiki page export to spatialite dbase with 
v.out.ogr



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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

[Markus Neteler]

On Thu, Feb 2, 2017 at 11:03 AM, Markus Neteler  wrote:
> On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras  wrote:
> ...
>> Daily build of the Homebrew formula repo seems more appropriate for testing
>> than the workaround in the code.
>>
>> Since Travis CI is not 100% reliable for Mac, it will also separate all the
>> false positives. It still can send messages to grass-dev (all Travis is
>> already white listed, right?) but more people should get access to the repo
>> if that's the case.
>
> Silly question: why does our Mac script fetch from SVN and not from
> git? This would solve it.

Extra question: where is the script actually doing this job?

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

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)

[Markus Neteler]

On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras  wrote:
...
> Daily build of the Homebrew formula repo seems more appropriate for testing
> than the workaround in the code.
>
> Since Travis CI is not 100% reliable for Mac, it will also separate all the
> false positives. It still can send messages to grass-dev (all Travis is
> already white listed, right?) but more people should get access to the repo
> if that's the case.

Silly question: why does our Mac script fetch from SVN and not from
git? This would solve it.

Markus
___
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#1906 (master - 461d67d)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1906
Status: Still Failing

Duration: 9 minutes and 37 seconds
Commit: 461d67d (master)
Author: Markus Neteler
Message: d.linegraph manual: fix broken HTML code

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

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

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

--

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] GSoC proposal "Higher level API for C and C++" : need for discussion

[Markus Metz]

On Wed, Feb 1, 2017 at 10:46 PM, Vaclav Petras  wrote:
>
>
> On Wed, Feb 1, 2017 at 3:24 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>> 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.

C++ is more problematic in terms of portability and robustness over time,
have a look at the revision log of e.g. r.terraflow and the iostream
library.

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

Then the project should determine what is "better". This could be a project
where a concept is going to be developed without writing a single line of
code. The main objective would then be to first identify what is bad or too
complicated and how to improve on it.

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

There are only a few modules requiring random access and external memory
(e.g. but not only tiling on disk). IMHO, random access and usage of
external memory are special cases, and I don't see how a higher-level API
would help with these special cases.

All-in-memory processing is so simple that any API would IMHO make things
more complicated.

The interface to the segment library is pretty simple: you need only
Segment_open(), Segment_put(), Segment_get(), Segment_close().

Maybe it would help if there would a better description about the
differences in the tiling-on-disk methods available in GRASS, i.e. the
segment library, the read-only cache used by r.proj, and the rowio library.

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

Note that the vast majority of portability and compatibility issues arises
from Python and C++.

Maybe this proposal addresses two different things that could be kept
separated:
1) some higher-level C and C++ API
2) random read (and write) access to raster cells.

For both cases, a more detailed description of the objective would be
helpful.

my2c

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

whoops, missed it indeed



Le jeudi 02 février 2017 à 08:09 +, Blumentrath, Stefan a écrit :
> Hi,
> 
> If you are n latest GRASS 7.2.1svn, maybe you hit this one:
> https://trac.osgeo.org/grass/ticket/3270
> 
> Cheers
> Stefan
> 
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo 
> van Breugel
> Sent: torsdag 2. februar 2017 08.20
> To: Vincent Bain 
> Cc: GRASS developers email list 
> Subject: Re: [GRASS-dev] update wiki page export to spatialite dbase with 
> v.out.ogr
> 
> 
> 
> 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


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