Moritz Lennert wrote:
On 11/02/09 12:54, Markus Metz wrote:
IMHO LFS support for vector libs is not necessarily good, currently.
In order to manipulate large vectors, a very fast CPU, fast hard
drives and lots of RAM is needed, or a lot of patience, because it
can take days or weeks to run
Glynn Clements wrote:
One relatively recent change that may cause a slow-down is that the
display library no longer tries to automatically simplify vectors
(reduce consecutive short line segments with a single segment). This
could have a significant impact when viewing detailed vectors at low
Glynn Clements wrote:
Markus Metz wrote:
The dglib is still a mystery to me. I don't even know what modules use
it. The other vector libs don't use it, that I'm relatively sure of.
The vector library (libgrass_vect, aka lib/vector/Vlib) uses it
(graph.c, net.c), as does
Moritz Lennert wrote:
On 11/02/09 12:54, Markus Metz wrote:
Maybe I should rather try to fix bugs than to add new features...
here are my two top candidates:
- Keep topology and spatial index in file instead of in memory in
the vector ToDo. The fact that it is in memory makes simple
Joining the previous comments, I think too that this looks really great!
I use ps.map regularly and was sometimes missing these features.
Sticking to grass command naming conventions, this enhanced version of
ps.map may better be called ps.map2 and not ps3.map, unless there is new
PostScript3
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched spidx.diff
gives me an empty spidx.diff, patched spatial index is identical to
original spatial index
Waiting
G. Allegri wrote:
Hello list.
Yesterday I needed to use v.rast.stats on a 1793 areas covering a
4415x6632 raster (with resolution 50m/pixel). I've used it without
extended statistics but the processing time was, with an euphemism,
very very long. After 5 hours it wasn't finished yet. As I
Markus Metz wrote:
Markus Metz wrote:
It seems to work, at least I got past the segfault when breaking
polygons, but I still have to check spatial index dumps.
diff spidx.dump.orig spidx.dump.patched spidx.diff
gives me an empty spidx.diff, patched spatial index is identical to
original
Markus Neteler wrote:
Hi Markus,
On Sun, Feb 22, 2009 at 1:56 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
This segfault in the rtree lib doesn't happen often, and I don't
know if I should submit that patch also to develbranch_6 and
releasebranch_6_4. For now I have submitted
Wouter Boasson wrote:
#494
I checked my swapfile, and under Mac OS there was certainly enough memory
available (4GB RAM and virtually unlimited swap, 64bit address space). This
did not help the clean action to complete successfully. Then, as you
suggested, I decided to recompile the 6.5dev
Yann Chemin wrote:
Hello list,
(GRASS SVN of this morning)
Importing a vector of 400Mb (GADM http://biogeo.berkeley.edu/gadm/,
country level only)
v.in.ogr broke with the following error message:
-
Break polygons:
ERROR: G_realloc: unable
Wouter Boasson wrote:
Dear Markus, Markus and Jens,
My MacBook survived the burn-in test :-) After 29 hours under full load,
alternating processor and disk access limited, I got my mega-vector file
cleaned. Thank you for the support and suggestions to solve my problems
with the large vector
Does someone know what isles are *exactly* in the grass vector model?
Isles in contrast to areas. I'm only interested in the definition of
first-generation isles, not an island in a lake on an island in a lake
I guess, an isle consists of one or more areas located within a larger
area, and
Michael Barton wrote:
Comment (by mmetz):
There is a good reason *not* to add this option/flag, nicely illustrated
by Dylan creating this ticket. The purpose of negative accumulation
values
is to make people wonder what on earth is going here, then figure out
that
not the whole catchment
Michael Barton wrote:
A much more direct way is to give a warning for each problematic
basin in the output:
WARNING: part of basin XX extends beyond region extent; accumulation
values may be too low.
IMHO not very practical. When thousands of basins are calculated, you
would get flooded
Michael Barton wrote:
On Mar 7, 2009, at 8:50 PM, Helena Mitasova wrote:
There is no question that the default should be kept negative,
although checking whether the result
is correct would not hurt - we can look at it with our Panama
experiments, others using
r.watershed could provide
Based on the discussion in this list, I have added experimental LFS
support to trunk in r36392. It works on Linux 32bit and 64bit, both
tested with and without --enable-largefile. I can not test on other
systems, unfortunately.
Vectors created with the new libs are fully backwards compatible to
Maciej Sieczka wrote:
Markus,
Thanks for your v.in.gshhs GRASS 6 port.
I have a problem: when importing full GSHHS extent, strange horizontal
lines through the whole longitudal extent are present in the output
GRASS vector map, which are *visible only in v.digit or QGIS*, but never
on the
Maciej Sieczka wrote:
I personally like the way QGIS or MapServer handles it - they just don't
care and don't try to treat lat-long data as connected at the datum
border.
So they stop displaying maps beyond -180 or 180? West of Alaska is
nothing? If Asia is displayed west of Alaska and Alaska
Maciej Sieczka wrote:
Markus Metz pisze:
I thought this is true for GRASS. Generally, if you zoom/pan beyond
the extend of the feature (raster or vector), nothing is displayed.
This should not happen in latlon,
Why not?
Because it does not happen in GRASS:-) and because latlon
If it's tested, at least I have no objections.
Not sure if it will give problems when char buf[200] is treated as char
result[GPATH_MAX].
Just two remarks. First, please work with latest svn version which is
r36445 since 2009-03-21 10:19:54 +0100 i.e. yesterday, because I'm also
busy with
Ivan Shmakov wrote:
Basically, this one introduces three tiny new functions to be used
instead of coding the construction of the vector map-related
filenames explicitly. Like:
- sprintf (buf, %s/%s, GRASS_VECT_DIRECTORY, map_info-name);
+ Vect_map_file_name_rel (buf, map_info);
Maciej Sieczka wrote:
It's not that every application is different, but that GRASS is
different than all the rest in this regard - it seems. Again, I'm not
saying GRASS or you are wrong, but could there be an optional switch to
constrain GSHHS geometry exactly to -180 - 180 in v.in.gshhs to
Hi all,
I have tried to make topology building in grass7 a bit faster, with
limited success. Some functions are now a bit faster, but there are no
drastic changes. Some other functions are now a bit slower, and there I
would like to know if there are objections against these changes.
The
Maciej Sieczka wrote:
Markus Metz pisze:
That would be the fool proof solution to avoid horizontal lines. But
then you have vertical lines...
If you decide it's worth your time to provide that *as an option* in
v.in.gshhs it'd be cool.
Not right now, first I want to get grass7 topology
Breaking polygons was in my tests the worst cleaning procedure in
v.in.ogr with regard to memory consumption. Vect_break_polygons() is
changed in trunk and should now use about 50% - 70% less memory, at the
same time it is considerably faster. The function uses now a balanced
binary search
Colin Nielsen wrote:
Furthermore, I launched r.cost on a 295 rows, 378 cols matrix, and it's
taking 1h, whereas I did the same previously and it ran in tens of
seconds.
The speed of r.cost depends not just on the number of cells but also
the complexity of the surface. Smoother surfaces
Paolo Cavallini wrote:
Paolo Cavallini ha scritto:
Markus Metz ha scritto:
Could it be that the binary tree implementation in r.cost is not
balanced? If yes, the search tree may degenerate on smooth surfaces
towards a linked list, search time going from O(log n) to O(n). BTW
Helena Mitasova wrote:
There are several problems that v.surf.rst has with large files
(we have same problem too I just did not have
time to look for the fix - I may ask Markus M for help because it is
related to things
that he has been dealing with):
Glynn is the expert on LFS, I just
dasuni kannangara wrote:
i am using ubuntu 8.10. I have downloaded grass 6.2.3 source code. I referred the INSTAL file and installed all pre requisites. I am trying to compile the source code now. But when i enter the command 'make', it says,
Makefile:22: include/Make/Platform.make: No such
Moritz Lennert wrote:
On 15/04/09 19:22, Dylan Beaudette wrote:
On Wednesday 15 April 2009, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+
- Reporter: helena | Owner:
Markus Neteler wrote:
(moving to grass-dev)
[Martina - we need to investigate a bit]
On Wed, Apr 15, 2009 at 10:42 PM, Martina Schäfer
martina.scha...@ebc.uu.se wrote:
Interesting discussion!! I've created the centroids but unfortunately, the
visibility network module repeatedly crashed
Glynn Clements wrote:
Dylan Beaudette wrote:
3. Allow the user to specify what they would like NULL cells encoded as.
Unless I am overlooking something, it would seem reasonable to export a CELL
map to a signed integer format, and use some obvious negative value for NULL:
If you're
Markus Neteler wrote:
On Thu, Apr 16, 2009 at 8:28 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Markus Neteler wrote:
...
I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky uninitialised byte(s) problem appears... (inline also a
debug msg
Markus Neteler wrote:
On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
I'm missing Vect_destroy_line_struct(sites) and
Vect_destroy_cats_struct(cats) in visibility.c, report() and main.c,
count(). Maybe that helps.
added
Markus Neteler wrote:
...
And again the new valgrind output:
...
==17614== 1,200 bytes in 3 blocks are indirectly lost in loss record 4 of 16
==17614==at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==17614==by 0x5D3F976: dig__alloc_space (allocation.c:81)
==17614==by 0x5D4D415:
Glynn Clements wrote:
Markus Metz wrote:
I remember a discussion in the dev ml, I think with the osgeo4w
installer, that memory allocated with malloc/calloc/realloc should be
free-d with free, not G_free. If this is the case, then there is a
problem in the vector libs, because space
This is now a mix of r.in.gdal and r.out.gdal. The two modules
complement each other, and I guess a minimum requirement would be that
something exported with r.out.gdal and then imported again with
r.in.gdal should be identical (taking into consideration the region
settings during export) and
Moritz Lennert wrote:
In the current state is there a possibility of using gdal's acceptance
of unvalid nodata ? And can we force a nodata value which exists in
the map ?
I would agree with Dylan that this kind of brute-force method should
remain possible, be it through the suggested -f
Glynn Clements wrote:
Markus Metz wrote:
I guess a minimum requirement would be that
something exported with r.out.gdal and then imported again with
r.in.gdal should be identical (taking into consideration the region
settings during export) and not have any data loss, be it due
Glynn Clements wrote:
Markus Metz wrote:
OK, but I have tested r.out.gdal with type = GDT_Int32 and nodata =
0x8000. Same result: NULL cells become -2147483648 but the nodata
value in the metadata says 2147483648 (gdalinfo on the export output),
Yes. I know. Running r.out.gdal
Glynn Clements wrote:
Markus Metz wrote:
I think I slowly begin to understand. You suggest to use
(GDT_Int32)0x8000 for both the GDAL metadata info and the GDAL
raster data although GDAL metadata nodata is double?
Yes; for the latter, the value would be:
(double
Glynn Clements wrote:
Markus Metz wrote:
so the user will have to understand the conversion issues even if they
never use an out-of-range value. Ultimately, its either usability or
flexibility.
Without the -f flag I would opt for usability, with the -f flag for
flexibility
GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical
Glynn Clements wrote:
Markus Metz wrote:
- all floating point: IEEE's NaN
Problem with NaN? According to IEEE 754, x == y is always FALSE if
either x or y or both are NaN. Assuming (nodata =
GDALGetRasterNoDataValue()) == NaN,
Sorry, should have been nodata
Glynn Clements wrote:
Markus Metz wrote:
Considering this, rather use e.g. raster_min - 1 as default nodata value
for GDAL floating point datatypes?
If fabs(raster_min) is large, raster_min - 1 won't be exactly
representable, and may be rounded to raster_min. You would need to
subtract
According to the Open Geospatial Consortium, there are some ISO
standards [1]. Of particular interest may be
- ISO/IEC 13249-3:2003, Information technology — Database languages —
SQL multimedia and application packages — Part 3: Spatial
- ISO 19107:2003, Geographic information ― Spatial
doug_newc...@fws.gov wrote:
I guess my point is that lidar datasets are getting quite massive. If
we are going to be working with the lidar data as point data in the
GRASS vector framework, go with the most scalable options. Scalability
in working with large data sets is a huge benefit in
Martin Landa wrote:
Hi Markus,
2009/7/7 Markus Metz markus.metz.gisw...@googlemail.com:
[...]
For the time being, the only reasonable way to deal with these massive
datasets is to *not* build topology. It's not not only the spatial index
that is getting out of hand, also topology
Markus Neteler wrote:
On Fri, Jul 10, 2009 at 3:50 PM, Martin Landalanda.mar...@gmail.com wrote:
2009/7/10 Markus Neteler nete...@osgeo.org:
Traceback (most recent call last):
File
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/scripts/v.rast.stats,
line 275, in module
Moritz Lennert wrote:
On 25/06/09 08:51, Markus GRASS wrote:
I would suggest that I first implement a new version were the spatial
index is always written out when a new or modifed vector is closed.
Intermediate data are still stored in memory. Opening an old vector in
read-only mode would
Martin Landa wrote:
Hi,
2009/7/13 Markus Metz markus.metz.gisw...@googlemail.com:
To work with an existing vector in grass7, topology needs to be rebuilt
because a support file is missing, the spatial index. After that
everything is fine and grass6 can read the vector again
Moritz Lennert wrote:
Some testing:
[...]
3) erm_roads: 1883345 lines, 1883345 primitives
time v.build erm_roads
GRASS6.4:
real1m54.298s
user1m49.107s
sys0m2.888s
GRASS7:
real2m54.266s
user2m40.606s
sys0m6.688s
(Note the fact that here GRASS6.4 is
g.region rast=mymap
r.mapcalc mymap.copy = mymap
Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster modules.
grass7 updated today, no changes in my local copy, two different
independent
Martin Landa wrote:
Hi,
2009/7/15 Markus Metz markus.metz.gisw...@googlemail.com:
g.region rast=mymap
r.mapcalc mymap.copy = mymap
Displaying both maps or r.univar gives vastly different results.
This corrupted output is not restricted to r.mapcalc but seems to be
true for all raster
Glynn Clements wrote:
Splitting libgis into libgis and libraster means splitting G_gisinit()
into G_gisinit() and Rast_init(). Obviously, if you split the function
in two, any calls to the function also need to be split.
I'll look into doing one-shot initialisation within the raster
library.
Glynn Clements wrote:
Markus Metz wrote:
Splitting libgis into libgis and libraster means splitting G_gisinit()
into G_gisinit() and Rast_init(). Obviously, if you split the function
in two, any calls to the function also need to be split.
I'll look into doing one-shot initialisation
Markus Neteler wrote:
I spoke to Gilberto Camara last week at the
OGRS2009 conference in Nantes (www.ogrs2009.org) about the
pros and cons of replacing the GRASS raster library with Terralib [1].
He promised to check with his engineers, maybe there is some
interesting advantage. To be
Hamish wrote:
Markus Metz wrote:
There were quite a few posts in the list about vista problems,
maybe you find some hints there. I'm only using Linux, can't
help there.
IIRC it was more generic memory problems which only showed up on
MS Windows. In those cases valgrind reported
GRASS GIS wrote:
#634: v.out.ogr error on Vista
--+-
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major
I will look into it, it's the new spatial index.
Markus M
Markus Neteler wrote:
On Tue, Aug 4, 2009 at 8:54 AM, GRASS GISt...@osgeo.org wrote:
#548: grass7: v.reclass segfaults on string column
...
{{{
v.db.connect boundary_county -g
}}}
?
I suppose DBF driver. Then it
Markus Neteler wrote:
#gdb:
Program received signal SIGSEGV, Segmentation fault.
0x7f979f9a3d69 in rtree_load_from_sidx (fp=0x7fffa8a8c5c8,
rootpos=179105, t=0xe67010, off_t_size=4)
at spindex_rw.c:735
735 newnode-branch[j].child = NULL;
Fixed in
Glynn Clements wrote:
Vector maps no longer work:
$ v.info fields
ERROR: Spatial index was written with LFS but this GRASS version does not
support LFS. Try to rebuild topology or upgrade GRASS.
Can't reproduce. This was fields from spearfish I assume. Without
building topo I get
Glynn Clements wrote:
Markus Metz wrote:
Without building topo I get
ERROR: Unable to open vector map fie...@permanent on level 2. Try to
rebuild vector topology by v.build.
So I do
v.build map=fields
v.info fields now produces standard output
Running v.build requires that you
Hamish wrote:
Glynn wrote:
Vector maps no longer work:
$ v.info fields
ERROR: Spatial index was written with LFS but this GRASS version does not
support LFS. Try to rebuild topology or upgrade GRASS.
Hi,
I've got nothing to add about that; just while on the subject: it
Hamish:
Hamish:
it would be nice if v.info could work (even partially) for maps
without topology built. e.g. massive LIDAR datasets.
MMetz:
It could be useful if more vector modules could support vectors without
topology, most importantly all v.surf.* modules. Not a new
Glynn Clements wrote:
Markus Metz wrote:
Yes, if you want to work with vectors not in the current mapset using
grass7, you have to rebuild topology for all vectors in the
corresponding mapset first.
So it's intentional that GRASS7 is no longer compatible with previous
vector maps
Hamish:
[...] it would
be nice if v.info could work (even partially) for maps without topology
built. e.g. massive LIDAR datasets.
Try trunk r38644, new -l flag for v.info to open vector map on level 1.
Markus M
___
grass-dev mailing list
Glynn Clements wrote:
Glynn Clements wrote:
Ah, ok, you use the grass57 dataset. I have now changed the version
number and compatibility info, you should now get reasonable
warnings/errors with the spearfish57 dataset.
Okay, I'll check it.
Nope. As of r38644, the error
Glynn:
Breaking backwards compatibility is allowed in 7.0. We'll probably be
breaking raster compatibility at some point (but in a far more
fundamental way; old rasters won't be recognised at all).
Something this fundamental should have been announced (maybe it was
and I missed it). Also, the
Glynn Clements wrote:
Markus Metz wrote:
d.vect, etc use the libraries and VECT_CFLAGS, so it isn't just v.*
modules which need to be checked. It might just be v.* modules which
need to be fixed; I don't know.
OK. I will check all modules including grass/vector.h or any
Glynn:
[...]
However, as a result of the LFS changes, the code has some type
mismatches on 32-bit systems with LFS enabled.
Most of these are due to passing off_t's to G_debug() with %ld as the
format (it needs to be %lld for a 64-bit off_t on a 32-bit platform;
we really need a macro for
Glynn:
[...] An integer literal without a
trailing suffix is an int. Using a larger type to hold the value
where necessary is a gcc extension. Other compilers may simply
truncate the value to an int, even if off_t is 64 bits.
The latest change:
#define OFF_T_TEST 0x0102030405060708LL
Glynn:
Markus:
Is it possible that configure sets LFS_FLAGS as a result of the LFS
tests which are stolen from cdrtools and in aclocal.m4?
It would be easier if configure could check if all we need is
_FILE_OFFSET_BITS and not also conditionally _LARGE_FILES,
_LARGEFILE_SOURCE, -n32 for
Soeren Gebbert wrote:
Dear Devs,
i found a strange behavior in r.out.gdal while updating the GRASS test
suite.
Im using the grass6.4svn snapshot:
grass-6.4.svn_src_snapshot_2009_08_01.tar.gz.
on openSuse 10.3 Linux 2.6.22.19-0.2-bigsmp
gdal version 1.6.1
Using grass6.4svn with gdal1.6.0
From the DTED specs:
A data file of DTED Level 0, DTED Level 1 or
DTED Level 2 is a 1° by 1° cell defined by whole degree latitude and
longitude
lines on WGS. A DTED file shall not cross whole degree latitude or longitude
lines.
Matrix intervals for DTED Level 0.
ZONE LATITUDE latitude x
Glynn Clements wrote:
Markus Metz wrote:
[...] An integer literal without a
trailing suffix is an int. Using a larger type to hold the value
where necessary is a gcc extension. Other compilers may simply
truncate the value to an int, even if off_t is 64 bits.
The latest change
gshhs 2.0 is not yet supported, unfortunately. The latest supported
version is 1.6, v.in.gshhs is awaiting updating.
Markus M
Jamie Adams wrote:
I grabbed the 2.0 version of gshhs, released 2009-07-15, but can't
import it into GRASS. The module doesn't return much in terms of
error
2009/8/11 Markus Metz markus.metz.gisw...@googlemail.com
mailto:markus.metz.gisw...@googlemail.com
From the DTED specs:
A data file of DTED Level 0, DTED Level 1 or
DTED Level 2 is a 1° by 1° cell defined by whole degree latitude and
longitude
lines on WGS. A DTED file shall
Glynn Clements wrote:
Markus Neteler wrote:
I got carried away (replacing all fseek/ftell occurrences I could find
with G_fseek/G_ftell, adjusting off_t as you showed above) and also made
r3.in|out.v5d LFS-safe, but did not submit. Should I?
Yes; ideally, we should use
Hi,
I've updated v.in.gshhs, it supports now GSHHS data versions 1.4 through
to 2.0, and issues an error if a version is not supported, telling
exactly that, no more non-descript error reading data.
v.in.gshhs imports exported as shapefiles display now properly in QGIS,
no more strange
Hamish wrote:
Hi,
I'm a bit frustrated by this change:
https://trac.osgeo.org/grass/changeset?new=grass%2Ftrunk%2Flib%2Fvector%2FVlib%2Fbreak_lines.c%4034284old=grass%2Ftrunk%2Flib%2Fvector%2FVlib%2Fbreak_lines.c%4033769
Eliminate non-standard logging mechanism
basically Vect_break_lines()
Hamish wrote:
Hi,
I notice a probable problem parsing v.db.connect's -g output. An
extra term containing the layer-name (if present) is added to the
first data column. e.g. if layer 1 had the name layer_name
...
I am not an expert in these things so I ask: under what conditions
would a
Glynn Clements wrote:
Markus Neteler wrote:
[...]
r39136, Fix diglib warnings
These mostly fix warnings related to Markus Metz' LFS changes, so
shouldn't be applicable to 6.4.
Thanks, I couldn't come up with something that works on both 32 bit and
64 bit. Interesting solution you
AFAIKT, r38992 Vect_get_num return long has no effect because the number
of features (for each type) is stored as plus_t which is int. If you
want to prepare the vector libs to support more than INT_MAX objects, I
would suggest to use
plus_t Vect_get_num_primitives(const struct Map_info *,
Hi Daniel,
nice job you did with the new network analysis modules! Obviously you
have understood dglib, this is very good news :-) Maybe you could have a
look at BUG2 [1] for network analysis? I have an idea but am not sure if
it is correct. There is also a wish to have costs as type double
Glynn Clements wrote:
Markus Metz wrote:
r39136, Fix diglib warnings
Thanks, I couldn't come up with something that works on both 32 bit and
64 bit. Interesting solution you chose with PRI_OFF_T, I didn't know
that is possible.
My compiler (gcc 4.3.2) on Linux 64bit now
Glynn Clements wrote:
Markus Metz wrote:
AFAIKT, r38992 Vect_get_num return long has no effect because the number
of features (for each type) is stored as plus_t which is int. If you
want to prepare the vector libs to support more than INT_MAX objects, I
would suggest to use
plus_t
Hamish wrote:
why should the boundary type be limited to 2D?
if boundary is allowed to be 3D there is no need for some new edge
feature type. I understand that it may make the topology code trickier,
but adding the new type seems redundant to me.
I have recently imported shapefiles from the
Michael Barton wrote:
r.watershed can produce a map of drainage directions.
The values of a direction map are in the range of -8 - +8
Can someone tell me what these numbers refer to? That is, what
direction is 3 or -3? I've tried to run some correlations against an
aspect map and am not
, on module level or on library level.
Markus M
Daniel
On Mon, Sep 14, 2009 at 12:31 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Hi Daniel,
nice job you did with the new network analysis modules! Obviously you have
understood dglib, this is very good news :-) Maybe you could have
Michael Barton wrote:
Martin,
Can you send me the multi-layer vector file that gives you trouble?
I'll test it specifically.
Taken from ticket 577:
https://trac.osgeo.org/grass/attachment/ticket/577/test_5.gpx?format=raw
After import with v.in.ogr, the vector has no features in layer 1, 1
Benjamin Ducke wrote:
Dear all,
in an attempt to better understand the GRASS vector and topology
model, I imported a set of 3 polygons from an ESRI Shapefile (see
attachment). The polygon in the upper left has 4 holes (called
islands for some reason by GRASS), the lower one consists of 3
parts
Jarosław Jasiewicz wrote:
Hi all
I tried to add to svn add-ons new module but I did it probably wrong.
In raster directory I created new dir:
svn add r.stream.del
svn ci -m New module r.stream.del
You can also do
svn mkdir https://svn.osgeo.org/grass/grass-addons/raster/r.stream.del
Martin Landa wrote:
Hi,
I am thinking how to implement direct write access to OGR datasources
from the user point of view. One approach would be to implement global
flag '--u' for updating existing vector map (i.e. OGR datasource).
E.g.
v.out.ogr input=test dsn=. type=point -n
v.external
Martin Landa wrote:
Hi,
2009/10/16 Markus Metz markus.metz.gisw...@googlemail.com:
Not sure if I understand right: updating an existing vector map, be it OGR
or native, works for some but not all modules. Some modules first copy all
or selected primitives from input to output, then modify
Hi,
Martin:
Markus:
Then rather implement --u as an option for some modules but not all and not
make it global?
Then we end up with the need to update manually every module which can
support update mode. Probably we could build a list of modules where
make sense to have update mode
Martin:
Markus:
[...]
yes, also olayer would be required. But it would make sense only for
OGR format, not the native format, am I right?
Thinking about it, there may be problems because some modules may produce
several output layers in the same output vector map if feature cats
It seems that GV_FORMAT_OGR refers now to both OGR layers linked with
v.external and direct OGR access, but these two require different
handling. Add new GV_FORMAT_OGR_DIRECT ? See temporary workaround in [1].
Markus M
[1] https://trac.osgeo.org/grass/changeset/39545
Martin Landa wrote:
Hi,
2009/10/17 Markus Metz markus.metz.gisw...@googlemail.com:
It seems that GV_FORMAT_OGR refers now to both OGR layers linked with
v.external and direct OGR access, but these two require different handling.
Add new GV_FORMAT_OGR_DIRECT ? See temporary workaround
401 - 500 of 1175 matches
Mail list logo
