Re: [GRASS-dev] Programming in GRASS
dasuni kannangara wrote: thanx. but grass/gis.h is already there. i just added another grass folder to ximgview to check whether it solves.what is the location which i should search for grass/gis.h?? The headers target in lib/Makefile installs the headers from the include directory into dist.arch/include/grass. This is done before any source files are compiled. The GRASS source tree has many ordering requirements, e.g. the lib directory must be built before any modules, the libraries must be built in a fixed order, the headers target must be made before starting to build any of the libraries, etc. If you want to use an IDE, you are going to have to replicate all of these dependencies as part of the project. -- 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] Programming in GRASS
thanx. can u send me that order.am trying to compile it using eclipse for many days now. if u can send me the steps it will be a great assistance. dasuni kannangara wrote: thanx. but grass/gis.h is already there. i just added another grass folder to ximgview to check whether it solves.what is the location which i should search for grass/gis.h?? The headers target in lib/Makefile installs the headers from the include directory into dist./include/grass. This is done before any source files are compiled. The GRASS source tree has many ordering requirements, e.g. the lib directory must be built before any modules, the libraries must be built in a fixed order, the headers target must be made before starting to build any of the libraries, etc. If you want to use an IDE, you are going to have to replicate all of these dependencies as part of the project. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- View this message in context: http://n2.nabble.com/Programming-in-GRASS-tp2588377p2620449.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] Programming in GRASS
dasuni kannangara wrote: thanx. can u send me that order.am trying to compile it using eclipse for many days now. if u can send me the steps it will be a great assistance. Refer to the Makefiles. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #539: Error on Display Map in wxpython
#539: Error on Display Map in wxpython --+- Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: |Keywords: Platform: MSWindows Vista | Cpu: Unspecified --+- Comment (by jef): see also http://trac.osgeo.org/osgeo4w/ticket/37#comment:13 ff -- Ticket URL: http://trac.osgeo.org/grass/ticket/539#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] man/Makefile - include/Make/Man.make ?
[wish] Could man/Makefile be rewritten to include/Make/Man.make ? This would help to obtain a (almost) functional make install target. My Makefile skills are unfortunately too limited... Markus ___ 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: closed Priority: major | Milestone: 6.4.0 Component: Vector | Version: svn-develbranch6 Resolution: worksforme |Keywords: buffer overflow, vector, shapefile, import Platform: Linux | Cpu: x86-64 -+-- Changes (by epatton): * status: new = closed * resolution: = worksforme Comment: I've removed the gdal 1.5.2 version that shipped with Ubuntu 8.10 and compiled gdal 1.6.0 in its place. v.in.ogr is working fine now, so I'm closing this bug. ~ Eric. -- Ticket URL: http://trac.osgeo.org/grass/ticket/402#comment:9 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] Multi-threading and use of multiple processors
I sent a previous mail but it did not go through, so sending it again:
The base concept is that if we are going to parallelize, then the
parallelization can be of two types,
keeping the current algorithm and tweaking it to become more parallel.
Here, a method will be to run the r.cost of two entities in the store(heap I
assume), to a certain depth, and then collecting their values.
Another method is to partition the dataspace into large chunks, and perform
operations on them.
Here the method is to divide the space into say 8 blocks, such that each
block divides the map into 3 entities and any path from block 1 and 3 pass
through block2. Then run the algorithm for each boundary element such that
the cost of each pixel pair on (boundary12 and boundary23) and
(boundary12,12) and (boundary 23,23) cost is known.
The given map is just too big for the second operation, the size of
temporary store being arnd 40 gb.
For smaller image sizes, the method would have worked just fine.
The reference paper for the second method
A simple parallel algorithm for the single source shortest path problem on
planar digraphs.
The assumption I am making is that the algorithm for r.cost is closely
related to dijkstra's algorithm.
On Fri, Apr 10, 2009 at 6:02 PM, Glynn Clements gl...@gclements.plus.comwrote:
Colin Nielsen wrote:
In my experience, the main drain in computation time is the IO not the
actual calculation of the btree. Is there any way to parallelize the
IO by passing rows to different cores or something like that ie. for
(row = 0; row nrows; row++) {?
That's feasible, but r.cost and r.walk aren't row-by-row algorithms.
With a row-by-row algorithm, you still have the issue that you can't
have multiple concurrent invocations of G_get_raster_row() etc on a
single map (in 6.x, you simply can't have multiple concurrent
invocations, even on different maps).
But you can have one thread which reads rows, multiple threads which
each process a particular row, and one thread which writes rows. The
number of useful intermediate threads is limited by the I/O rate.
Or a more efficient segment library sounds good as well. Is there a
way to estimate how much more efficient would it be
Hard to say. The main inefficiencies with the current implementation
are:
1. The tile size isn't restricted to a power of two (so it uses
division/remainder rather than shift/mask).
2. The tile size is set at run-time rather than compile-time.
3. Acess is via function calls rather than macros or inline functions.
The version in r.proj[.seg] doesn't have these issues, although it's
currently read-only.
and would it make use of multiple cores?
Using multiple threads for segment I/O would probably be a net loss,
as you would need to perform locking for every access.
Multi-threading is most effective if you can partition the data such
that you don't need to perform locking.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
JYOTHISH SOMAN
MS-2008-CS
Center for Security, Theory And Algorithm Research (CSTAR)
International Institute of Information Technology
Hyderabad
India
Phone:+91-9966222626
http://www.iiit.ac.in/
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man.
George Bernard Shaw
--
JYOTHISH SOMAN
MS-2008-CS
Center for Security, Theory And Algorithm Research (CSTAR)
International Institute of Information Technology
Hyderabad
India
Phone:+91-9966222626
http://www.iiit.ac.in/
--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man.
George Bernard Shaw
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Multi-threading and use of multiple processors
On Sat, Apr 11, 2009 at 10:23 PM, Jyothish Soman jyothish.so...@gmail.com wrote: ... The assumption I am making is that the algorithm for r.cost is closely related to dijkstra's algorithm. Just a note: in GRASS-Addons is a new module (r.terracost which uses this approach): http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terracost http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terracost/description.html Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Multi-threading and use of multiple processors
Well actually, the paper is in GIS terms what has been given in my reference in graph theoretical terms. Can somebody tell me how exactly are r.cost and r.terraflow different, in terms of cost of traversal between two pixels? On Sun, Apr 12, 2009 at 2:10 AM, Markus Neteler nete...@osgeo.org wrote: On Sat, Apr 11, 2009 at 10:23 PM, Jyothish Soman jyothish.so...@gmail.com wrote: ... The assumption I am making is that the algorithm for r.cost is closely related to dijkstra's algorithm. Just a note: in GRASS-Addons is a new module (r.terracost which uses this approach): http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terracost http://trac.osgeo.org/grass/browser/grass-addons/raster/r.terracost/description.html Markus -- JYOTHISH SOMAN MS-2008-CS Center for Security, Theory And Algorithm Research (CSTAR) International Institute of Information Technology Hyderabad India Phone:+91-9966222626 http://www.iiit.ac.in/ -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [osgeo4w] #37: grass: wxpython gui issues
#37: grass: wxpython gui issues ---+ Reporter: jachym |Owner: osgeo4w-...@lists.osgeo.org Type: defect | Status: new Priority: major |Component: Package Version: | Resolution: Keywords: GRASS | ---+ Comment (by jef): see also http://trac.osgeo.org/grass/ticket/539 -- Ticket URL: http://trac.osgeo.org/osgeo4w/ticket/37#comment:31 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer for the OSGeo stack.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
