[GRASS-dev] [GRASS GIS] #404: wxNviz does not start
#404: wxNviz does not start -+-- Reporter: jachym | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Keywords: |Platform: Linux Cpu: x86-32 | -+-- wxNVIZ does not start, only thing I get, is ERROR: Incompatible library version for module ubuntu 8.10 -- Ticket URL: http://trac.osgeo.org/grass/ticket/404 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:29 hamish]: FWIW, it was just minor whitespace on roughly 5 lines. I don't think it is necessary to run intent compulsively as long as the whitespace doesn't get too abused. The question is, keep the GRASS source code in standard format yes or no? According to the discussion on it and to SUBMITTING, the answer is something like YES, we had a long discussion on it, reformatting the whole source code was a major change, now please be so kind as to keep the code in the standard format and not Yes, but a little deviation here and there doesn't harm. No offense! My patch would introduce some new code, that's why I ran indent on it, otherwise I would have been told to do so first before proposing a patch. Justification for the patch: the TODO's in the code have been attended to; that would avoid quite a few of the problems reported in this very long ticket and IMHO the module could be regarded as working all right if these TODO's are solved. I replaced the attached patch with a new patch against the newly formatted r.out.gdal Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:30 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #404: wxNviz does not start
#404: wxNviz does not start
--+-
Reporter: jachym | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major| Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: invalid |Keywords:
Platform: Linux| Cpu: x86-32
--+-
Changes (by neteler):
* status: new = closed
* resolution: = invalid
Comment:
Replying to [ticket:404 jachym]:
wxNVIZ does not start, only thing I get, is
ERROR: Incompatible library version for module
This comes from
{{{
gisinit.c:G_fatal_error(_(Incompatible library version for
module));
}}}
and indicates that you have to compile GRASS from scratch (make
distclean).
Markus
--
Ticket URL: http://trac.osgeo.org/grass/ticket/404#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #344: TODO: move high priority incubated modules into main
#344: TODO: move high priority incubated modules into main
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: blocker | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: |Keywords:
Platform: All | Cpu: All
--+-
Comment (by martinl):
Replying to [comment:17 hamish]:
I notice that the column names are case sensitive; and could the column
check be moved before any output? and the error message should be like
column %s not found ?
{{{
GRASS64 v.out.ascii in=hospitals col=name,phone
ERROR: Column name: unsupported data type
697237.5638615|182012.65540056|1GRASS64
}}}
fixed in r34926 (6.4) r34927 (7.0).
--
Ticket URL: https://trac.osgeo.org/grass/ticket/344#comment:19
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd I remember votes for d.3d and votes again this proposal. Any consensus before rc1? Personally I have nothing against d.3d. One of the options would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz use for nviz_cmd(?) Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #82: new module: v.to.3d
#82: new module: v.to.3d --+- Reporter: hamish | Owner: martinl Type: task | Status: assigned Priority: major| Milestone: 6.4.0 Component: Vector | Version: svn-develbranch6 Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by martinl): Replying to [comment:6 martinl]: Replying to [comment:5 hamish]: Replying to [comment:3 martinl]: I am not sure which module to use for reverse transformation (3D-2D). points, centroids: v.out.ascii | v.in.ascii (without -z or z=). then you'd need to copy+merge tables adding in the new z column. polyfeatures: v.out.ascii format=standard | awk to strip away the third column | v.in.ascii format=standard. I think layer/cat setting at end of each feature is ok as it is always like 1 1, never a third column. AFAICT there's no way to keep the data in that 3rd column, as a line can only hold a single attribute/cat. the user can summarize with v.univar if they want that...? this approach will be very slow for large vector maps... That's reason why I would prefer to implement it in GRASS C module. Another option would be to rewrite v.to.3d in C. -- Ticket URL: http://trac.osgeo.org/grass/ticket/82#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
On Thu, 18 Dec 2008, Martin Landa wrote: Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd I remember votes for d.3d and votes again this proposal. Any consensus before rc1? Personally I have nothing against d.3d. One of the options would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz use for nviz_cmd(?) Glynn was against d.3d because he said he felt all d.* modules should be related to using the Raster library for 2-D drawing. He definitely has a point but d.nviz at least has already broken that convention - there *might* be others in the past but I'm not sure. Personally I tend to think it isn't such a big deal, especially as the 3d in the name clearly suggests it's different anyway. d.nviz will wait for 7.0 - is that correct? So we can put off a decision on its name. d.3d.fly, d.3d.flythrough or d.3d.flythru might all be good names. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #392: backport G_is_c_null_value() to devbr6
On Thu, 18 Dec 2008, Markus Neteler wrote: On Wed, Dec 17, 2008 at 9:11 PM, Paul Kelly paul-gr...@stjohnspoint.co.uk wrote: #392: backport G_is_c_null_value() to devbr6 Comment (by hamish): For rc2, to completely replace null_val.c or not? I am still a bit unsure- is there actually a bug in the current devbr6 version or is the idea to keep the methods in sync to ease future maintenance? Since there are no comments there does not seem to be a bug in GRASS 6.x. So: if it ain't broken, don't fix it. That's true; I agree. It's definitely not a bug; just a change for potential future compatibility with invalid raster files so we don't need it now. Just a little comment about I'm not sure about the logic of intentionally planning to change a release candidate. To me, release candidate implies this might be identical to the final release if we don't find any last minute bugs. If we're intentionally planning another change before the release it isn't really a release candidate after all. I agree. But apparently the problem isn't there and we can now create the release branch. Sounds good - is renaming nviz_cmd the only issue (actually a minor issue since we still have the old nviz in 6.4) left then? Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #402: v.in.ogr buffer overflow
#402: v.in.ogr buffer overflow --+- Reporter: epatton | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: Vector | Version: svn-develbranch6 Resolution: |Keywords: buffer overflow, vector, shapefile, import Platform: Linux| Cpu: x86-64 --+- Comment (by epatton): Jachym, I'm using gdal-1.5.3, compiled from source; so Ubuntu packages can't be the problem in my case. I'm recompiling Grass and gdal and will report the results soon. ~ Eric. -- Ticket URL: http://trac.osgeo.org/grass/ticket/402#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #402: v.in.ogr buffer overflow
#402: v.in.ogr buffer overflow --+- Reporter: epatton | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: Vector | Version: svn-develbranch6 Resolution: |Keywords: buffer overflow, vector, shapefile, import Platform: Linux| Cpu: x86-64 --+- Comment (by epatton): I noticed the OGRFeature16GetFieldAsString error that we both had, and thought there might be a problem with the dbf file that was causing this error, so I tried opening it in Open Office, but that program chokes with an error Unable to open file for reading. I then renamed the dbf to something else, and tried importing the shapefile via v.in.ogr and it worked! I can view the vector fine; v.info doesn't show anything out of the ordinary. This is still disconcerting, as the attributes have not survived the import. It's not a big problem for the polygons I'm using in this case, as their only purpose is to be rasterized into masks later on, but still...and I can't understand why ooffice won't open the dbf; gnumeric doesn't have any problem opening it. ~ Eric. -- Ticket URL: http://trac.osgeo.org/grass/ticket/402#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass-dev Digest, Vol 32, Issue 39
On Dec 18, 2008, at 4:21 AM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: Date: Thu, 18 Dec 2008 12:21:17 +0100 From: Martin Landa landa.mar...@gmail.com Subject: Re: [GRASS-dev] 6.4rc1 To: Hamish hamis...@yahoo.com Cc: grass-dev grass-dev@lists.osgeo.org Message-ID: f8fe65c40812180321x5f978efqda73bb9c9a67e...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd I remember votes for d.3d and votes again this proposal. Any consensus before rc1? Personally I have nothing against d.3d. One of the options would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz use for nviz_cmd(?) d.* commands produce a visualization in a display window. d.nviz seems the obvious one, though I don't have any objections to d.3d either. The current d.nviz is really intended to create a fly-through path for nviz--interactively or non-interactively. It won't work interactively on anything but an xterm, so d.nviz is kind of a misnomer. We don't have a prefix for 3D modules, thought maybe we should think of one. Lacking that, nviz.flythough is the most accurate description, or perhaps v.nviz.flythrough since you set (sort of) vector points to create the path. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: grass-dev Digest, Vol 32, Issue 39
On Thu, 18 Dec 2008, Michael Barton wrote: On Dec 18, 2008, at 4:21 AM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: Date: Thu, 18 Dec 2008 12:21:17 +0100 From: Martin Landa landa.mar...@gmail.com Subject: Re: [GRASS-dev] 6.4rc1 To: Hamish hamis...@yahoo.com Cc: grass-dev grass-dev@lists.osgeo.org Message-ID: f8fe65c40812180321x5f978efqda73bb9c9a67e...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd I remember votes for d.3d and votes again this proposal. Any consensus before rc1? Personally I have nothing against d.3d. One of the options would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz use for nviz_cmd(?) d.* commands produce a visualization in a display window. d.nviz seems the obvious one, though I don't have any objections to d.3d either. The current d.nviz is really intended to create a fly-through path for nviz--interactively or non-interactively. It won't work interactively on anything but an xterm, so d.nviz is kind of a misnomer. We don't have a prefix for 3D modules, thought maybe we should think of one. Lacking that, nviz.flythough is the most accurate description, or perhaps v.nviz.flythrough since you set (sort of) vector points to create the path. My only objection to that is that nviz is not at all obvious for a name for a 3-D visualisation module, historically standing for New VIZualisation (as a replacement for SG3d). The original 3-D display module from the '80s was called d.3d and now that it has been removed it seems a good time to re-use the name. Although the original d.3d did use the Raster drawing library and the new one wouldn't, so Glynn's objection still applies here. Paulk ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Martin wrote: I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd I remember votes for d.3d and votes again this proposal. Any consensus before rc1? my 0c vote is for d.3d [for the d.* purists: could the outputted png be used in the GUI display?]. maybe m.out.3d? shrug the user is interested in what the module does, not which engine is used in the background to do it. ho ho ho, Hamish (mostly offline for the next few weeks) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #392: backport G_is_c_null_value() to devbr6
MN: Since there are no comments there does not seem to be a bug in GRASS 6.x. So: if it ain't broken, don't fix it. PK: That's true; I agree. It's definitely not a bug; just a change for potential future compatibility with invalid raster files so we don't need it now. just to note that currently FCELL,DCELL checks do it the new way of if (x != x), while CELL still checks it the old way. ie F,D got backported but CELL didn't. the commit log said check if both all 0s and if nan, but the check is just for nan. Is it the case that for all modern systems (IEEE FP's) the two are identical? see ya, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
