While I looked into possibilities to optimize v.in.ogr I noticed that
grass does not support coor files larger than 2 GB. With topological
information stored in that file, and often many dead lines wasting
space, the coor file can easily exceed 2 GB nowadays. While v.in.ogr was
cleaning one
#37: grass: wxpython gui issues
--+-
Reporter: jachym | Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
#37: grass: wxpython gui issues
--+-
Reporter: jachym | Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
#37: grass: wxpython gui issues
--+-
Reporter: jachym | Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
#473: GRASS fails to compile without curses
-+--
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major|
How can I propos a modifition of diag_up.eps pattern?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ejtizado wrote:
How can I propos a modifition of diag_up.eps pattern?
see http://grass.osgeo.org/wiki/AreaFillPatterns
If you have an improved version, post it here or to the bug/wish tracker.
Hamish
___
grass-dev mailing list
#474: r.quantile: segfaults with percentile=100
+---
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone:
#475: r.stats: last bin always has a single cell
--+-
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
#416: r.le.patch crashes on long filenames
--+-
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major| Milestone:
Hamish wrote:
r.info -s outputs DMS, when it should probably
use decimal (-g uses decimal for n/s/e/w).
g.region and libgis accept res=DD:MM:SS, so why should it use decimal?
So that everything which uses it doesn't have to explicitly convert it
to decimal.
Usually for lat/lon
Markus Metz wrote:
If the coor file size stored in the topo file is indeed needed to
properly process the coor file, the respective variables must be
something else than long in order to support coor files larger than 2
GB, maybe long long? Same for all intermediate variables in the
#473: GRASS fails to compile without curses
---+
Reporter: marisn| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major |
13 matches
Mail list logo
