Re: [GRASS-dev] GSOC Horizon based voxel interpolation wk 7 checkin
Hi Tim, Can you please check your commits into your Google code repo? It seems to me that there are some parts of your files missing? Besides of that, can you please provide manpages for your modules so that we can see what they are designed for? It is important for us to be able to run your modules. Best regards Soeren Am 01.08.2013 07:28 schrieb Tim Bailey timi...@gmail.com: Hi Folks I worked through the weekend, I am going to have limited internet access at the end of the week, and I am working under a rather clear mentor ultimatum, So here is my week 7 report. This week I implemented the voronoi operator, that had confounded me for much of July, through a two stage iterative process. Process A propagates identities vertically up profiles from horizon boundaries. Process B propagates identities horizontally away from the profiles. I applied this to one of my experimental sandboxes that was built for a study of late holocene co-seismic subsidence in a coastal saltmarsh. In this circumstance coastal marshes exhibit extreme sensitivity to their elevation above sea level. A series of earthquakes during the past 4500 years are recorded by the sedimentary record at the coastal margins. These earthquakes resulted in subsidence events of almost a meter and a half in one episode, and notable movement in several other events. In addition the introduction of tsunami, and mudflat deposits overlaying peat deposits create a very appealing paleo environment to reconstruct using voxel operators.The GRASS region was bound between the deepest core at 6 meters below sea level and 3 meters above, which was clearly out of the range of the modern salt marsh. On my computer with an amd5700 processor, 12gb ram, with ssd, Ubuntu 13.04 and GRASS7,process A takes 12 seconds per iteration, and process B takes 22 seconds per iteration for a 32,000,000 voxel map. From the data that I am working with process A required 9 iterations and process B required 50 cycles. Region anisotropy was set to 10:1, where it could really comfortably be 100:1. Nonetheless, this is not that different from the computing demands of moderately large lidar job. Also in this case iteration limits can be used to limit the area of influence of a data point. Next week will work on refining this weeks work and implement a surface limit. Tim Bailey ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Horizon based voxel interpolation wk 7 checkin
I concur.
Please make sure that your code has been completely
uploaded to the trunk folder in your SVN repo.
Also, some sample input data and at least screenshots
of the output that you get would be very helpful.
Preferably, export your result (or a lower resolution
version of it) using r3.out.vtk, zip the VTK file and
upload it to the SVN.
Best,
Ben
On 08/01/2013 08:52 AM, Sören Gebbert wrote:
Hi Tim,
Can you please check your commits into your Google code repo? It seems
to me that there are some parts of your files missing? Besides of that,
can you please provide manpages for your modules so that we can see what
they are designed for?
It is important for us to be able to run your modules.
Best regards
Soeren
Am 01.08.2013 07:28 schrieb Tim Bailey timi...@gmail.com
mailto:timi...@gmail.com:
Hi Folks
I worked through the weekend, I am going to have limited internet
access at the end of the week, and I am working under a rather clear
mentor ultimatum, So here is my week 7 report.
This week I implemented the voronoi operator, that had confounded me
for much of July, through a two stage iterative process. Process A
propagates identities vertically up profiles from horizon
boundaries. Process B propagates identities horizontally away from
the profiles.
I applied this to one of my experimental sandboxes that was built
for a study of late holocene co-seismic subsidence in a coastal
saltmarsh. In this circumstance coastal marshes exhibit extreme
sensitivity to their elevation above sea level. A series of
earthquakes during the past 4500 years are recorded by the
sedimentary record at the coastal margins. These earthquakes
resulted in subsidence events of almost a meter and a half in one
episode, and notable movement in several other events. In addition
the introduction of tsunami, and mudflat deposits overlaying peat
deposits create a very appealing paleo environment to reconstruct
using voxel operators.The GRASS region was bound between the deepest
core at 6 meters below sea level and 3 meters above, which was
clearly out of the range of the modern salt marsh. On my computer
with an amd5700 processor, 12gb ram, with ssd, Ubuntu 13.04 and
GRASS7,process A takes 12 seconds per iteration, and process B
takes 22 seconds per iteration for a 32,000,000 voxel map. From the
data that I am working with process A required 9 iterations and
process B required 50 cycles. Region anisotropy was set to 10:1,
where it could really comfortably be 100:1. Nonetheless, this is
not that different from the computing demands of moderately large
lidar job. Also in this case iteration limits can be used to limit
the area of influence of a data point.
Next week will work on refining this weeks work and implement a
surface limit.
Tim Bailey
___
grass-dev mailing list
grass-dev@lists.osgeo.org mailto: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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Michael Barton wrote: Nikos, What about just using r.rescale to rescale this? Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. Thank you Michael, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue
---+
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement| Status: new
Priority: normal | Milestone: 7.0.0
Component: Default| Version: unspecified
Keywords: r.in.gdal rgb |Platform: Unspecified
Cpu: Unspecified|
---+
Working with multispectral satellite data in tiff where bands are not just
red, green, blue, but, for example (for Worldview 2):
{{{
1:Coastal
2:Blue
3:Green
4:Yellow
5:Red
6:Red Edge
7:NIR1
8:NIR2
}}}
it is a bit annoying that r.in.gdal automatically calls the first three
bands .red, .green and .blue. Even in satellite imagery which has only
three bands, this does not necessarily mean that they are rgb. Calling
them .red, .green and .blue can leave to confusion for the inexperienced
user.
I would suggest to remove that functionality and leave it up to the user
to decide what the bands represent.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2052
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] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On 01/08/13 11:04, Nikos Alexandris wrote: Michael Barton wrote: Nikos, What about just using r.rescale to rescale this? Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Michael: What about just using r.rescale to rescale this? Nikos: Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. Moritz: r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Didn't work also (tried the previous days) -- I can try again. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass7 nightly builds
On 26/07/13 13:45, Moritz Lennert wrote: Any idea when wingrass7 nightly builds will be available again ? As many of the current critical issues for grass7 are windows specific, it would be great to have the nightly builds to help in testing. ping ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue ---+ Reporter: mlennert | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: Default| Version: unspecified Keywords: r.in.gdal rgb |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by nikosa): I can only agree that it might confuse people (working these days also with IKONOS, QB and WV2 data). Also, somewhat related, it seems that in the past, QuickBird delivered data in a different order? See some reference/instructions in the wiki [http://grasswiki.osgeo.org/wiki/QuickBird#Cleanup]. I will alter the wiki as this is no (longer?) valid -- QuickBird MS bands are in the expected order for me (that is B, G, R and NIR) -- and keep it as an extra note in case if... -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#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
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On 01/08/13 11:40, Nikos Alexandris wrote: Michael: What about just using r.rescale to rescale this? Nikos: Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. Moritz: r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Didn't work also (tried the previous days) -- I can try again. Please be more precise than didn't work... Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue ---+ Reporter: mlennert | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal rgb |Platform: Unspecified Cpu: Unspecified| ---+ Changes (by hamish): * version: unspecified = svn-trunk * component: Default = Raster Comment: I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. -- gdal band name detection bug? It would be bad if the (e.g.) .blue band was being named .red! Hamish ps- trac's parser logic wants keywords separated by commas -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:2 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] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Changes (by hamish): * keywords: r.in.gdal rgb = r.in.gdal, rgb -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:3 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] wingrass7 nightly builds
On 26/07/13 13:45, Moritz Lennert wrote: Any idea when wingrass7 nightly builds will be available again ? As many of the current critical issues for grass7 are windows specific, it would be great to have the nightly builds to help in testing. ping at least osgeo4w-wingrass is again there http://wingrass.fsv.cvut.cz/grass70/osgeo4w/ - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/wingrass7-nightly-builds-tp5068927p5070163.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Comment(by mlennert): Replying to [comment:2 hamish]: I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. -- gdal band name detection bug? Replying to [comment:2 hamish]: I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. -- gdal band name detection bug? Yes and no: GDAL does return a ColorInterp info which is wrong, but this is apparently due to the original data: [https://trac.osgeo.org/gdal/ticket/5177] The problem in r.in.gdal is here: [https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525]. ps- trac's parser logic wants keywords separated by commas Noted. Thanks for the hint ! -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:4 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] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Comment(by mmetz): Replying to [comment:4 mlennert]: Replying to [comment:2 hamish]: I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. -- gdal band name detection bug? Yes and no: GDAL does return a !ColorInterp info which is wrong, but this is apparently due to the original data: [https://trac.osgeo.org/gdal/ticket/5177] The problem in r.in.gdal is here: [https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525]. That means the -k flag should be removed and the band number always used as suffix, or optionally the meaning of the -k flag should be reverted such that color names are appended only on request? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:5 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] wingrass7 nightly builds
Hi, 2013/7/26 Moritz Lennert mlenn...@club.worldonline.be: Any idea when wingrass7 nightly builds will be available again ? As many of the current critical issues for grass7 are windows specific, it would be great to have the nightly builds to help in testing. it's related to the new redesigned and updated osgeo4w msys/mingw packages [1,2]. Currently I am solving last issues related to GRASS7 compilation errors. OSGeo4w package is not available, standalone package will be online later. If you are using osgeo4w I suggest to install the environment from the scratch. Sorry for inconvenience, Martin [1] http://trac.osgeo.org/osgeo4w/wiki/pkg-msys [2] http://trac.osgeo.org/osgeo4w/wiki/pkg-grass -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [osgeo4w] #58: grass-pkg: make icon GRASS GIS
#58: grass-pkg: make icon GRASS GIS +--- Reporter: hamish | Owner: osgeo4w-dev@… Type: enhancement | Status: new Priority: trivial | Component: Package Version: |Keywords: grass +--- Comment(by martinl): Replying to [ticket:58 hamish]: rename the GRASS desktop icon to be GRASS GIS not just GRASS. It's a bit more informative to new users and is more consistent with the Quantum GIS icon. already done. -- Ticket URL: http://trac.osgeo.org/osgeo4w/ticket/58#comment:3 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer and package environment for the OSGeo stack. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [osgeo4w] #58: grass-pkg: make icon GRASS GIS
#58: grass-pkg: make icon GRASS GIS +--- Reporter: hamish | Owner: osgeo4w-dev@… Type: enhancement | Status: new Priority: trivial | Component: Package Version: |Keywords: grass +--- Comment(by martinl): Replying to [comment:1 hamish]: Also, perhaps rename the OSGeo4W icon to be OSGeo4W shell or so. i.e. say what it does. To a new user it is just a jumble of numbers and letters which leads them to a DOS prompt (which they probably have no idea about as well). feel free to open ticket for that, see wiki:pkg-shell -- Ticket URL: http://trac.osgeo.org/osgeo4w/ticket/58#comment:4 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer and package environment for the OSGeo stack. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Comment(by mlennert): Replying to [comment:5 mmetz]: Replying to [comment:4 mlennert]: Replying to [comment:2 hamish]: I'm not 100% sure, but ISTR that it was libgdal doing that, r.in.gdal was just passing the band name along untouched. -- gdal band name detection bug? Yes and no: GDAL does return a !ColorInterp info which is wrong, but this is apparently due to the original data: [https://trac.osgeo.org/gdal/ticket/5177] The problem in r.in.gdal is here: [https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.in.gdal/main.c#L525]. That means the -k flag should be removed and the band number always used as suffix, or optionally the meaning of the -k flag should be reverted such that color names are appended only on request? Duh. I have to admit that I completely overlooked this flag. So the question is: what is less confusion for newcomers: have rgb extensions sometimes not be correct, or always only have numbers ? Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#comment:6 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] wingrass7 nightly builds
On 01/08/13 12:30, Martin Landa wrote: Hi, 2013/7/26 Moritz Lennertmlenn...@club.worldonline.be: Any idea when wingrass7 nightly builds will be available again ? As many of the current critical issues for grass7 are windows specific, it would be great to have the nightly builds to help in testing. it's related to the new redesigned and updated osgeo4w msys/mingw packages [1,2]. Currently I am solving last issues related to GRASS7 compilation errors. Thanks for the feedback. OSGeo4w package is not available, But then what is http://wingrass.fsv.cvut.cz/grass70/osgeo4w/ ? standalone package will be online later. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [osgeo4w] #58: grass-pkg: make icon GRASS GIS
#58: grass-pkg: make icon GRASS GIS +--- Reporter: hamish | Owner: martinl Type: enhancement | Status: assigned Priority: trivial | Component: Package Version: |Keywords: grass +--- Changes (by martinl): * owner: osgeo4w-dev@… = martinl * status: new = assigned Comment: Replying to [comment:2 hamish]: ... and msys to msys UNIX prompt or so ... (bash prompt is probably rather unhelpful to windows users) renamed to 'MSYS Shell' (consistency with 'OSGeo4W Shell') [wiki:pkg- msys#Etcscripts here] -- Ticket URL: http://trac.osgeo.org/osgeo4w/ticket/58#comment:5 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer and package environment for the OSGeo stack. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2051: r.to.vect: add option to not create attribute table if -v flag is used
#2051: r.to.vect: add option to not create attribute table if -v flag is used ---+ Reporter: mlennert | Owner: grass-dev@… Type: enhancement| Status: new Priority: minor | Milestone: 7.0.0 Component: Default| Version: svn-trunk Keywords: r.to.vect attribute table |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by mlennert): Replying to [comment:1 mmetz]: Replying to [ticket:2051 mlennert]: The -v flag of r.to.vect allows to use the pixel values of a CELL raster as category values of the created vector features. In that case and in certain circumstances it might not be necessary to create a database table for the output vector. It would thus be nice if r.to.vect had an option that would allow not to create an attribute table if the -v flag is used. Try r57333. The change is slightly different than requested: the creation of an attribute table can also be suppressed if the -v flag is not used, in which case a warning is printed out that raster values will be lost. Sometimes it might be useful to just have e.g. areas or lines with a unique category and the raster values are no longer needed. Thanks ! I agree with your version of the change. Won't have the time to test, though, as I'm leaving on vacation in a few hours... Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2051#comment:2 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] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Michael: What about just using r.rescale to rescale this? Nikos: Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. Moritz: r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Nikos: Didn't work also (tried the previous days) -- I can try again. Moritz: Please be more precise than didn't work... Right, be more precise is the key to freedom :D. Indeed, I used to say (either in a rules file, or directly using ... EOF 0.0:1.0:0:255 This did not work. Both stats and histogram of the recoded raster map, e.g. a Red-Reflectance image ranging in r.info Red_ToAR -r min=0 max=0.774115699104528 were kinda flattened out r.stats Red_ToAR_recoded_255 100% 0 255 Looking at the image I want to recode r.stats Red_ToAR | head 100% 0-0.003036 0.02125-0.024286 0.024286-0.027322 0.027322-0.030357 0.030357-0.033393 0.033393-0.036429 0.036429-0.039465 0.039465-0.0425 0.0425-0.045536 0.045536-0.048572 I altered the rules file like 0.001:1.0:0:255 This works-out! Now, the recoded image is r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o r.stats Red_ToAR_recoded_255 100% 5 6 7 . .. ... \ Many values in-between ... / .. . 195 196 197 * And the histogram looks nice as well. I didn't grasp that -- from where should I? In the manual there is only an example from int to float (however, indeed, instructing 0.1 as the target min value). Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Object-based classification [was: Re: i.segment: invalid region id 0]
Pietro, On 31/07/13 10:01, Pietro wrote: I'm working to develop a module that use several machine learning technique to classify the segments results... the part concerning the hierarchical segmentation is working quite well... Out of curiosity: which variables are you planning on using for this classification ? FYI, here's a list of variables that colleagues established here as being the ones they use most in objet-based classification: - mean band values - brightness (combination of several band values) - standard deviation of a certain band within an object - length/width ratio of an object - GLCM Homogeneity (Haralick) All of these are implemented in GRASS, except for the length/width ratio. And of the Haralick indicator, r.texture is pixel-based, evaluating texture in a given neighborhood. Don't know how difficult it would be to add the option to calculate the same indicators within the polygons defined in a cover map. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On 01/08/13 13:43, Nikos Alexandris wrote: Michael: What about just using r.rescale to rescale this? Nikos: Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. Moritz: r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Nikos: Didn't work also (tried the previous days) -- I can try again. Moritz: Please be more precise than didn't work... Right, be more precise is the key to freedom :D. Indeed, I used to say (either in a rules file, or directly using ... EOF 0.0:1.0:0:255 This did not work. Both stats and histogram of the recoded raster map, e.g. a Red-Reflectance image ranging in r.info Red_ToAR -r min=0 max=0.774115699104528 were kinda flattened out r.stats Red_ToAR_recoded_255 100% 0 255 Looking at the image I want to recode r.stats Red_ToAR | head 100% 0-0.003036 0.02125-0.024286 0.024286-0.027322 0.027322-0.030357 0.030357-0.033393 0.033393-0.036429 0.036429-0.039465 0.039465-0.0425 0.0425-0.045536 0.045536-0.048572 I altered the rules file like 0.001:1.0:0:255 This works-out! Now, the recoded image is r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o r.stats Red_ToAR_recoded_255 100% 5 6 7 . .. ... \ Many values in-between ... / .. . 195 196 197 * And the histogram looks nice as well. I didn't grasp that -- from where should I? In the manual there is only an example from int to float (however, indeed, instructing 0.1 as the target min value). There does seem to be a bug in r.recode. Your first rule set should work if you set the -d flag. Maybe you can file a ticket ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On Thursday 01 of August 2013 13:42:03 Moritz Lennert wrote:
On 01/08/13 13:43, Nikos Alexandris wrote:
Michael:
What about just using r.rescale to rescale this?
Nikos:
Already tried (in the past) and I don't think it works from DCELL
8-bit. It seems to chew-up (silently, as Moritz mentioned I think
among
the lines in ticket #2^11) values.
It seems that integerising manually, in this case, is the best
approach. With the essential question remaining on how many fine
digits
should be preserved?.
Moritz:
r.rescale is just a frontend to r.reclass. and as such is meant for
CELL
maps. It should'nt make a difference whether it is 8-bit or more,
though.
For DCELL you can try to use r.recode.
Nikos:
Didn't work also (tried the previous days) -- I can try again.
Moritz:
Please be more precise than didn't work...
Right, be more precise is the key to freedom :D. Indeed, I used to
say
(either in a rules file, or directly using ... EOF
0.0:1.0:0:255
This did not work. Both stats and histogram of the recoded raster map,
e.g. a Red-Reflectance image ranging in
r.info Red_ToAR -r
min=0
max=0.774115699104528
were kinda flattened out
r.stats Red_ToAR_recoded_255
100%
0
255
Looking at the image I want to recode
r.stats Red_ToAR | head
100%
0-0.003036
0.02125-0.024286
0.024286-0.027322
0.027322-0.030357
0.030357-0.033393
0.033393-0.036429
0.036429-0.039465
0.039465-0.0425
0.0425-0.045536
0.045536-0.048572
I altered the rules file like
0.001:1.0:0:255
This works-out! Now, the recoded image is
r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o
r.stats Red_ToAR_recoded_255
100%
5
6
7
.
..
... \
Many values in-between
... /
..
.
195
196
197
*
And the histogram looks nice as well. I didn't grasp that -- from where
should I? In the manual there is only an example from int to float
(however, indeed, instructing 0.1 as the target min value).
There does seem to be a bug in r.recode. Your first rule set should work
if you set the -d flag. Maybe you can file a ticket ?
Oh man... I need to rest. The -d flag... that's it :-p
Nikos (learning every day new stuff :-)).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Moritz:
r.rescale is just a frontend to r.reclass. and as such is meant for
CELLmaps. It should'nt make a difference whether it is 8-bit or more,
though. For DCELL you can try to use r.recode.
Nikos:
Didn't work also (tried the previous days) -- I can try again.
Moritz:
Please be more precise than didn't work...
Nikos:
Right, be more precise is the key to freedom :D. Indeed, I used to
say (either in a rules file, or directly using ... EOF
[..]
I altered the rules file like
0.001:1.0:0:255
This works-out! Now, the recoded image is
r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o
r.stats Red_ToAR_recoded_255
100%
5
6
7
.
..
... \
Many values in-between
... /
..
.
195
196
197
*
And the histogram looks nice as well. I didn't grasp that -- from
where
should I? In the manual there is only an example from int to float
(however, indeed, instructing 0.1 as the target min value).
Moritz:
There does seem to be a bug in r.recode. Your first rule set should work
if you set the -d flag. Maybe you can file a ticket ?
Nikos:
Oh man... I need to rest. The -d flag... that's it :-p
On the other hand, even if I would read it (because I did not read carefully
the --help before), it reads:
-d Force output to 'double' raster map type (DCELL)
In this case I have a DCELL Input, recoding in to CELL Output. How is this
related?
N
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2052: r.in.gdal should not by default call first three bands red, green, blue
#2052: r.in.gdal should not by default call first three bands red, green, blue +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.in.gdal, rgb |Platform: Unspecified Cpu: Unspecified | +--- Comment(by hamish): Replying to [comment:6 mlennert]: So the question is: what is less confusion for newcomers: have rgb extensions sometimes not be correct, or always only have numbers ? I'd go with option (c): complain to the data providers until they correct their files. Better result for everyone in the long run. rouault: From the above output, the file must have TIFFTAG_PHOTOMETRIC (wrongly) set to PHOTOMETRIC_RGB. So the problem is more on the producer of the file. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2052#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] Custom GRASS command line prompt
Nkos:
Do you have customised prompts? Any ideas for a more productive
command line?
Hamish:
I'd suggest to put the change in ~/.grass.bashrc instead.
FWIW,
I use now the following
export PS1='\[\e[32m\]G$SHORT_VER\[\e[0m\] [ \[\e[33m\]${GLOCATION}\[\e[0m\]
@\[\e[32;1m\]${GMAPSET}\[\e[0m\] ] : \[\e[36m\]\w \[\e[0m\]
\[\e[32;1m\]\[\e[0m\] '
Apart from the colors (with which I was exeprimenting) I think it's much
cleaner now -- info as a top line and the right below in a new line. It
looks like:
,--%---
G70 [ utm_37s @change_detection ] : .../grassdb/onsight
`---%--
This eats-up one line. But, 1) it gives all the space for longer commands and
2) it works as a useful separator (especially if it is colorised) and makes
searching back in time easier.
Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based classification [was: Re: i.segment: invalid region id 0]
Hi Moritz, On Thu, Aug 1, 2013 at 12:40 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Pietro, On 31/07/13 10:01, Pietro wrote: I'm working to develop a module that use several machine learning technique to classify the segments results... the part concerning the hierarchical segmentation is working quite well... Out of curiosity: which variables are you planning on using for this classification ? At the moment I'm using only the results of r.univar for each raster in the group (RGB) combined with the ratio between (R/G, R/B, G/B) of the mean. and it is working quite well... Add other variables like brightness, length/width ratio, GLCM Homogeneity, skewness, etc. it will consist only to add new columns to a csv file. Or would be nice to add this variables to r.univar... :-) To classify the segments I'm using three different machine learning techniques: Tree, KNN, and SVM. I tested also Parzen but the results were not so good. Best regards. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
On Monday 29 of July 2013 17:29:29 Hamish wrote: Hamish wrote: # example of adding an RGB border color with a #RRGGBB code: echo -ne \033]11;#53186f\007 ... But I think changing the border with a RGB color per mapset or location would scale better if you were having a different color for each mapset/location. Or, for the MASK present I'd prefer a red terminal border to the extra line on the command prompt, so it might be nice to search out what the different escape codes for gnome-terminal et al. might be. hmm, doesn't work so well. this sets the border color in xterm: echo -e \e]11;#aa186f\007 CLEAR='\e[2J\e[1;1H' echo -ne \e[37m\e[40m$CLEAR unset CLEAR ..for the internalBorder Xresource (xterm -b), but as soon as something wraps around column 80 it stops being the border color and becomes the background color. it would be nice to figure a way to get the border color working properly though since it seems like a nice way to do it. Yep, it makes everything magenta-like. A pity this doesn't work as wanted. Really good idea. We can always ask... at stackexchange? Nikos Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass7 nightly builds
2013/8/1 Moritz Lennert mlenn...@club.worldonline.be: OSGeo4w package is not available, But then what is http://wingrass.fsv.cvut.cz/grass70/osgeo4w/ ? sorry, I meant is available, now working on standalone installer. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On 01/08/13 14:01, Nikos Alexandris wrote: Moritz: r.rescale is just a frontend to r.reclass. and as such is meant for CELLmaps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Nikos: Didn't work also (tried the previous days) -- I can try again. Moritz: Please be more precise than didn't work... Nikos: Right, be more precise is the key to freedom :D. Indeed, I used to say (either in a rules file, or directly using ... EOF [..] I altered the rules file like 0.001:1.0:0:255 This works-out! Now, the recoded image is r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o r.stats Red_ToAR_recoded_255 100% 5 6 7 . .. ... \ Many values in-between ... / .. . 195 196 197 * And the histogram looks nice as well. I didn't grasp that -- from where should I? In the manual there is only an example from int to float (however, indeed, instructing 0.1 as the target min value). Moritz: There does seem to be a bug in r.recode. Your first rule set should work if you set the -d flag. Maybe you can file a ticket ? Nikos: Oh man... I need to rest. The -d flag... that's it :-p On the other hand, even if I would read it (because I did not read carefully the --help before), it reads: -d Force output to 'double' raster map type (DCELL) In this case I have a DCELL Input, recoding in to CELL Output. How is this related? Sorry, you're right. Got mixed up with another problem I had when I tried to recode a 0:2047 image to 0.0:1.0. And even if -d solved my problem there AFAICT it shouldn't be necessary. Trying to do too many things at the same time in the last hours before leaving on vacation !! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2043: wxgui data import wizard: format choice before import really necessary ?
#2043: wxgui data import wizard: format choice before import really necessary ? ---+ Reporter: mlennert | Owner: grass-dev@… Type: enhancement| Status: new Priority: minor | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: file import wizard format |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by annakrat): I removed it in r57341 (plus complete rewriting, it was not possible to maintain the code). The file picker has the formats in the filter. Is this OK? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2043#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
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Sorry, I meant r.recode. r.recode infile outfile min:max:0:255 should do it. MIchael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 1, 2013, at 2:28 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/08/13 11:04, Nikos Alexandris wrote: Michael Barton wrote: Nikos, What about just using r.rescale to rescale this? Already tried (in the past) and I don't think it works from DCELL 8-bit. It seems to chew-up (silently, as Moritz mentioned I think among the lines in ticket #2^11) values. It seems that integerising manually, in this case, is the best approach. With the essential question remaining on how many fine digits should be preserved?. r.rescale is just a frontend to r.reclass. and as such is meant for CELL maps. It should'nt make a difference whether it is 8-bit or more, though. For DCELL you can try to use r.recode. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
So r.recode works, although it seems to have a bug.
Maybe that is the key to having i.pansharpen work better with a wider range of
input values. The user would still need to input the min and max possible
range, but it could default to 0 and 255 for 8 bit data.
This changes original values of course. But pan sharpening is not intended to
keep the original values. It is to create a visual output. Of course if the
visual output looks crummy, that's not good either.
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
On Aug 1, 2013, at 6:15 AM, Moritz Lennert mlenn...@club.worldonline.be
wrote:
On 01/08/13 14:01, Nikos Alexandris wrote:
Moritz:
r.rescale is just a frontend to r.reclass. and as such is meant for
CELLmaps. It should'nt make a difference whether it is 8-bit or more,
though. For DCELL you can try to use r.recode.
Nikos:
Didn't work also (tried the previous days) -- I can try again.
Moritz:
Please be more precise than didn't work...
Nikos:
Right, be more precise is the key to freedom :D. Indeed, I used to
say (either in a rules file, or directly using ... EOF
[..]
I altered the rules file like
0.001:1.0:0:255
This works-out! Now, the recoded image is
r.recode in=Red_ToAR out=Red_ToAR_recoded_255 rules=recode_rules --o
r.stats Red_ToAR_recoded_255
100%
5
6
7
.
..
... \
Many values in-between
... /
..
.
195
196
197
*
And the histogram looks nice as well. I didn't grasp that -- from
where
should I? In the manual there is only an example from int to float
(however, indeed, instructing 0.1 as the target min value).
Moritz:
There does seem to be a bug in r.recode. Your first rule set should work
if you set the -d flag. Maybe you can file a ticket ?
Nikos:
Oh man... I need to rest. The -d flag... that's it :-p
On the other hand, even if I would read it (because I did not read carefully
the --help before), it reads:
-d Force output to 'double' raster map type (DCELL)
In this case I have a DCELL Input, recoding in to CELL Output. How is this
related?
Sorry, you're right. Got mixed up with another problem I had when I tried to
recode a 0:2047 image to 0.0:1.0. And even if -d solved my problem there
AFAICT it shouldn't be necessary.
Trying to do too many things at the same time in the last hours before
leaving on vacation !!
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr +--- Reporter: mlennert| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal v.in.ogr gui |Platform: Unspecified Cpu: Unspecified | +--- Comment(by annakrat): The button was removed in r54618. I don't have any strong opinion on this. Perhaps the button might be confusing for users? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#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
Re: [GRASS-dev] Object-based classification [was: Re: i.segment: invalid region id 0]
Moritz Lennert wrote: FYI, here's a list of variables that colleagues established here as being the ones they use most in objet-based classification: - mean band values - brightness (combination of several band values) - standard deviation of a certain band within an object - length/width ratio of an object - GLCM Homogeneity (Haralick) Being an old e-cognition user (I think it's almost 6-7 years ago) I remember using Vegetation Indices as well, wherever applicable. Weighting some bands, e.g. the NIR band, when the final classification-objective was related to related, was also not uncommon. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] seemingly random errors in r.mapcalc
Hi, In the last few revisions of GRASS GIS 7.0 (on Ubuntu 13.04) I am experiencing this seemingly random errors with r.mapcalc. For example: Running the following r.mapcalc computation gave me an ERROR: GRASS 7.0.svn (AEA):~ r.mapcalc --overwrite glc_influence = if(IIASA_crops==100,8.0, if((glc_change5 + glc_change6)==100, 4.0*IIASArev + 8.0*IIASA_crops/100.0, (glc_change1*IIASArev + 2.0*glc_change2*IIASArev + 3.0*glc_change3*IIASArev + 4.0*glc_change4*IIASArev + glc_div + 8.0*IIASA_crops) / 100.0)) --overwrite ERROR: Error reading raster data [Raster MASK present] Rerunning the same, and it goes through fine: GRASS 7.0.svn (AEA):~ r.mapcalc --overwrite glc_influence = if(IIASA_crops==100,8.0, if((glc_change5 + glc_change6)==100, 4.0*IIASArev + 8.0*IIASA_crops/100.0, (glc_change1*IIASArev + 2.0*glc_change2*IIASArev + 3.0*glc_change3*IIASArev + 4.0*glc_change4*IIASArev + glc_div + 8.0*IIASA_crops) / 100.0)) --overwrite 100% [Raster MASK present] This is not always the second time, sometimes it runs fine the first time, but doesn't the second time, or it only runs fine the third time. Initially I though it such errors are more likely to happen when the equation includes double precision / floating rasters and integer rasters. But in the example above all layers were converted to double precision first. I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? Rgds Paulo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2053: r.recode is buggy when minimum from=0.0
#2053: r.recode is buggy when minimum from=0.0
--+-
Reporter: nikosa| Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 7.0.0
Component: Raster| Version: unspecified
Keywords: r.recode, DCELL, CELL, rules |Platform: Unspecified
Cpu: Unspecified |
--+-
Attempting to recode a double precision raster map to an integer by either
using a rules file or directly using ... EOF with the following
sequence 0.0:1.0:0:255 does not work. Both stats and histogram of the
recoded raster map, e.g. a recoded image derived from a Red-Reflectance
image ranging in
{{{
min=0
max=0.774115699104528
}}}
are flattened out! The only values to be found in the recoded image are 0
and 255. However, using a minimum from= value of 0.001 produces the
expected recoded image, i.e. using a rules file that contains
{{{
0.001:1.0:0:255
}}}
produces a recoded image which is composed by many integer values, i.e.
ranging from 5 up to 197. The histogram of this recoded image looks
nice as well.
See also: [http://lists.osgeo.org/pipermail/grass-
dev/2013-August/065280.html]. Tested in GRASS 6.4.4svn, GRASS 7.0.svn
revision=57312
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2053
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] [GRASS GIS] #2042: wxgui: no more menu access to r.in.gdal / v.in.ogr
#2042: wxgui: no more menu access to r.in.gdal / v.in.ogr --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: r.in.gdal, v.in.ogr, gui |Platform: Unspecified Cpu: Unspecified | --+- Changes (by hamish): * keywords: r.in.gdal v.in.ogr gui = r.in.gdal, v.in.ogr, gui Comment: IMO there should always be a small button or submenu to get to the raw module UI interface from the front-end wizards without having to use the command line; nice for experts, old timers, or to work around some other breakage in the wizards debugging. as long as it is well worded it should not be confusing. thanks, Hamish ps- general todo: tooltips on *everything*! :) -- Ticket URL: https://trac.osgeo.org/grass/ticket/2042#comment:2 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] Fw: [Ubuntu] GeoGit
Hi, taking the liberty of fwd'd Tim's email here, as the basic idea can be quite an important one for maintainers of cadastral data. Paper-trails of changes and formal metadata hooks (eg for INSPIRE) remain major missing features in GRASS. regards, Hamish - Forwarded Message - From: Tim Michelsen timmichelsen gmx-topmail de To: ubu...@lists.osgeo.org Cc: Sent: Friday, August 2, 2013 10:32 AM Subject: [Ubuntu] GeoGit Hello, GeoGit seems to be a real nice addition to ou toolboxes: http://geogit.org/ Distributed Version Control for Geospatial Data View project on GitHub Welcome to the GeoGit project, exploring the use of distributed management of spatial data. GeoGit draws inspiration from Git, but adapts its core concepts to handle versioning of geospatial data. Users are able to import raw geospatial data (currently from Shapefiles, PostGIS or SpatiaLite) in to a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories. Now they plan to get into Debian: Debian installer https://github.com/opengeo/GeoGit/issues/365 How is packaging of java based applications done? regards, Timmie ___ UbuntuGIS mailing list Ubuntu lists.osgeo org http://lists.osgeo.org/mailman/listinfo/ubuntu http://trac.osgeo.org/ubuntugis/wiki ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] seemingly random errors in r.mapcalc
Paulo van Breugel wrote: I am really puzzled as to what is going on here. Any idea what I am doing wrong here or what could be the cause? My first suspicion would be hardware issues, e.g. a failing disk drive. While there are certain types of programming error which can cause non-deterministic behaviour (e.g. reading uninitialised memory), neither r.mapcalc nor lib/raster have had any significant changes recently. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2047: GRASS doesn't build on FreeBSD
#2047: GRASS doesn't build on FreeBSD -+-- Reporter: lbartoletti | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: Compiling| Version: 6.4.3 RCs Keywords: |Platform: Other Unix Cpu: x86-64 | -+-- Comment(by lbartoletti): Seems to be only on Amd64 : [https://redports.org/~lbartoletti/20130801210200-5456-135536/grass-6.4.3.log i386 log] [https://redports.org/~lbartoletti/20130802050627-08551-135559/grass-6.4.3.log amd64 log] -- Ticket URL: http://trac.osgeo.org/grass/ticket/2047#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
