Re: [GRASS-dev] v.in.ogr fails to import from PostGIS with schema
Hi Markus Sorry, good to know. It was HTML indeed. So here is the problem-description in plain ASCII: When I try to import a vector map containing (lots of) lines from a certain schema in a PostGIS-database, i get the following error messages: v.in.ogr dsn=PG:host=myserver dbname=gisdata layer=n50_2013_utm33n.n50_2013_arealdekke_lines output=Test (...) DBMI-SQLite driver error: Error in sqlite3_prepare(): unrecognized token: 3insert DBMI-SQLite driver error: Error in sqlite3_prepare(): unrecognized token: 3insert ERROR: Cannot insert new row: insert into Test values ( 3insert into Test values ( 3, NULL, NULL, NULL, NULL, NULL, NULL, 'FiktivDelelinje', '1000-01-01 0:00:00', NULL, 101 ) While other formats with the same data work just fine: ogr2ogr -f SQLite /home/stefan/tmp/N50/n50_2013_arealdekke_lin.sqlite PG:host=myserver dbname=gisdata n50_2013_utm33n.n50_2013_arealdekke_lines v.in.ogr dsn=/home/stefan/tmp/N50/n50_2013_arealdekke_lin.sqlite output=N50_2013_arealdekke_linThis gave no errors... Forgot to mention in my earlier post, that also importing polygons from the same PostGIS database (and schema) as the lines works fine: v.in.ogr dsn=PG:host=myserver dbname=gisdata layer=n50_2013_utm33n.n50_2013_arealdekke_polygons output=Test_pol Gave no error messages either... So, maybe it is something with the geometry type? Cheers Stefan -Original Message- From: neteler.os...@gmail.com [mailto:neteler.os...@gmail.com] On Behalf Of Markus Neteler Sent: 31. mai 2013 00:22 To: Blumentrath, Stefan Subject: Re: [GRASS-dev] v.in.ogr fails to import from PostGIS with schema Hi Stefan, you message (HTML?) did not contain the relevant error... see below. It is better to send in pure ASCII... Best Markus On Thu, May 30, 2013 at 9:51 PM, SBL stefan.blumentr...@nina.no wrote: Hi When I try to to import a vector map containing (lots of) lines from a certain schema in a PostGIS-database, i get the following error messages: While other formats with the same data work just fine: This gave no errors... I was using GRASS 7 (compiled about a month ago) and PostGIS 2.0.1 / PostgreSQL 9.1 on Ubuntu 12.04 LTS Server. Looks like something got mixed up in the insert statement. Is that a known issue or shall I file a ticket? Cheers Stefan -- View this message in context: http://osgeo-org.1560.x6.nabble.com/v-in-ogr-fails-to-import-from-Post GIS-with-schema-tp5057034.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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Pietro wrote:
Why the ctypes version return 'PERMANENT' instead of 'user1'?
Glynn Clements wrote:
The $GISRC file is read the first time that an environment lookup is
made. There is no way to force it to be re-read.
This means that I can't use instructions like
# retrieve existing Spectral bands
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]')
# alternative naming...
if not landsat_elements['Spectral Bands']:
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]0')
# no results?
if not landsat_elements['Spectral Bands']:
print No Spectral bands named after a B? or B?0 pattern found!
in a function (pasted below) which I call from within a for loop to go
through Mapsets that potentially contain raster maps named differently? I
need to use another way to feed raster maps in a dictionary, right? I need to
change the way raster maps are fed in a dictionary, i.e. use something like
data['Spectral Bands'] = list(zip(*grass.mlist_pairs('rast', 'B[123457]'))
[0])
?
And then, what will be the role of pygrass' Mapset() function?
Thank you (Pietro Glyyn),
Nikos
The following function is called from within a for loop over different
Mapsets:
#
# List Resolution of Landsat Rasters, Controllers for expected names ==
def retrieve_landsat_rasters(verbose = False):
landsat_elements = dict()
# retrieve existing Spectral bands --
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]')
# alternative naming...
if not landsat_elements['Spectral Bands']:
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]0')
# no results?
if not landsat_elements['Spectral Bands']:
print No Spectral bands named after a B? or B?0 pattern found!
# resolution of Spectral bands
landsat_elements['Resolution Spectral'] = \
int(grass.raster_info(landsat_elements['Spectral Bands'][0])['nsres'])
# retrieve existing Temperature channels
landsat_elements['Temperature Channels'] = \
Mapset().glist('rast', pattern = 'B6[12]')
# no results?
if not landsat_elements['Temperature Channels']:
print There are no Landsat Temperature channels named B61, B62!
# temperature channels (resolution = 30 or 60m)
landsat_elements['Resolution Temperature'] = \
int(grass.raster_info(landsat_elements['Temperature Channels'][0])
['nsres'])
# retrieve existing Panchromatic channels ---
landsat_elements['Panchromatic Channel'] = \
Mapset().glist('rast', pattern = 'B8')
# alternative naming
if not landsat_elements['Panchromatic Channel']:
landsat_elements['Panchromatic Channel'] = \
Mapset().glist('rast', pattern = 'B80')
# no results?
if not landsat_elements['Panchromatic Channel']:
print There is no Landsat Panchromatic channel named B8 or B80!
# panchromatic channels (resolution = 15m)
landsat_elements['Resolution Panchromatic'] = \
int(grass.raster_info(landsat_elements['Panchromatic Channel'])['nsres'])
if verbose:
for key in sorted(landsat_elements.keys()):
print %s: %r % (key, landsat_elements[key])
return landsat_elements
#
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: v.net.path and xml.etree.ElementTree ParseError
On Thu, May 23, 2013 at 7:12 PM, Anna Petrášová kratocha...@gmail.com wrote: ... Please try r56388, there should be no error. But on Linux, pipe does not seem to work as expected, anyway. I had finallz the possibilty to try the latest version via OSGeo4W, the error is gone. Thanks! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1985: wxGUI: Find module in Search module tab fails on Windows
#1985: wxGUI: Find module in Search module tab fails on Windows ---+ Reporter: neteler| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: Search_module |Platform: MSWindows 7 Cpu: Unspecified| ---+ Comment(by neteler): Replying to [comment:1 annakrat]: There is some problem with key events in wx.SearchCtrl widget. Since we cannot fix this, I used wx.TextCtrl for Windows instead. Try r56484. This helps, working now. There is another problem on Windows with Ctrl+Enter shortcut (run found command). It only changes focus to Run button. Is this some special Windows shortcut? (any Windows expert here?) -- Ticket URL: http://trac.osgeo.org/grass/ticket/1985#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] Subgroups in i.segment
Recently I did some tests (with Pietro Z) using i.segment on an RGB orthophoto sample. If am not wrong, the module works with groups only. Driven by the discussion ticket #1984: i.pca should accept also group names as input (like r.out.gdal) I wonder whether the module will support subgroups at some point as well. Thank you, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1961: wxNVIZ: error if no raster map selected
#1961: wxNVIZ: error if no raster map selected +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.3 Component: wxGUI | Version: svn-develbranch6 Keywords: wxnviz |Platform: All Cpu: x86-64 | +--- Comment(by hamish): Replying to [comment:8 annakrat]: Replying to [comment:6 hamish]: and then if I manually go to the Data tab - Vector controls and tick the box to have it render on the newly selected raster map, it stays at z=0 below. Height above surface there also appears to work as a multiplier, not in map units? but of what? the archsites map is not 3D. the cat number? interesting raindrop effect, but not so good for accurate alignment. It should be in map units. The problem appears only when there is no surface to drape the points on. Should be fixed in r56515. ps- Perspective still needs a hard upper-bound at 180 degrees. currently if you type e.g. `325` degrees in the box and move the slider you can see where it crosses over itself and the geometry inverts. interesting, but not really usable. done in r56514 if you confirm that these fixes help, I will backport them. Hi, I tested both of these in trunk, seems ok. I also tested adding points without a surface, the first time I again got the repeating Gtk-CRITICAL **: gtk_range_set_range: assertion `min max' in the terminal, but quitting the gui and restarting it then worked. I'll try to test that more later. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1961#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
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Nikos Alexandris wrote: Why the ctypes version return 'PERMANENT' instead of 'user1'? Glynn Clements wrote: The $GISRC file is read the first time that an environment lookup is made. There is no way to force it to be re-read. This means that I can't use instructions like [...] in a function (pasted below) which I call from within a for loop to go through Mapsets that potentially contain raster maps named differently? You can modify the current process' environment with G_setenv(). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
