Markus Neteler wrote:
> > It also means that, for VARCHAR columns, you cannot determine the
> > maximum width that can be stored in the column.
>
> But doesn't v.in.ascii scan for column lengths in any case?
It does.
> Maybe make that switchable and use the extracted info?
If you don't use th
#222: v.in gns broken in grass 7.0 trunk
-+--
Reporter: gisix | Owner: gisix
Type: defect | Status: assigned
Priority: major | Milestone: 6.3.1
Component: Vector | Version: svn
#222: v.in gns broken in grass 7.0 trunk
-+--
Reporter: gisix | Owner: gisix
Type: defect | Status: assigned
Priority: major | Milestone: 6.3.1
Component: Vector | Version: svn
#222: v.in gns broken in grass 7.0 trunk
-+--
Reporter: gisix | Owner: gisix
Type: defect | Status: assigned
Priority: major | Milestone: 6.3.1
Component: Vector | Version: svn
#222: v.in gns broken in grass 7.0 trunk
-+--
Reporter: gisix | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.3.1
On Mon, Jul 7, 2008 at 8:34 PM, Glynn Clements <[EMAIL PROTECTED]> wrote:
...
> It also means that, for VARCHAR columns, you cannot determine the
> maximum width that can be stored in the column.
But doesn't v.in.ascii scan for column lengths in any case?
Maybe make that switchable and use the ext
#222: v.in gns broken in grass 7.0 trunk
--+-
Reporter: gisix | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.3.1
Ivan Shmakov wrote:
> > Operators such as || which operate on strings normally accept any
> > operand types. Anything that isn't a string will be converted to one.
> > But the result is always a string.
>
> > Typically, an operator is selected according to its operand types,
> > and the ope
Thanks for these important points Glynn.
Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
vo
Martin Landa wrote:
> I have updated Makefile in lib/nviz based on lib/ogsf/Makefile, maybe
> it can help, I can compile on my Linux box without problems.
Note that lib/nviz/render.c contains unconditional references to glX
functions, so it won't compile with non-X11 versions of OpenGL.
To make
Michael Barton wrote:
> I found it and this may be the issue. This refers back to an issue
> that William raised with Martin over compiling for Mac. The OpenGL
> that GRASS uses is located in /usr/X11/include/GL/gl.h.
>
> That is, it uses the X11 version of GL for NVIZ. If the new lib is
>
> Glynn Clements <[EMAIL PROTECTED]> writes:
>>> IIRC, the main problem is that sqlite3_column_decltype() only works
>>> for actual columns, not expressions, subselects etc, but the code
>>> in question has to be able to describe the format of rows returned
>>> by arbitrary SELECT statemen
To all devs:
I will be beginning survey operations at sea from July 9 to July 26, and will
not have access to the Grass mailing lists during this time, and hence will not
be able to address documentation-related issues as they arise. Please submit
any requests into Trac, and I'll try to get the
Markus Neteler pisze:
On Sat, Jul 5, 2008 at 7:43 PM, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
I'm trying to cleanup i.rectify manual. I don't see any difference
between -a (Rectify all images in group) set and not set - in either
case all raster maps in the group are rectified. Is this a bug
#204: warnings printed on GRASS startup when selecting Location and Mapset
---+
Reporter: msieczka | Owner: martinl
Type: defect| Status: closed
Priority: minor | Mileston
15 matches
Mail list logo
