Re: [GRASS-user] v.isochrones : error message

2015-04-05 Thread Mark Wynter
from a practical standpoint, it looks like in your image the origin point for the isolines is central Paris, not the yellow dot to north. By way of comparison with your image, what do results look like if you use v.net.iso? This will return lines with each ISO cost value, not a surface. It

Re: [GRASS-user] v.net tools with polygons

2015-03-04 Thread Mark Wynter
that underlie each method. Sing out if you want to test your methodology on me. Just email me.. - mark Sent from my iPhone On 4 Mar 2015, at 7:48 am, Mark Wynter m...@dimensionaledge.com wrote: Hi Daniel, I've done something similar - I call it off road routing, and uses a regular

Re: [GRASS-user] v.net tools with polygons

2015-03-04 Thread Mark Wynter
Hi Daniel The modeling approach I took used a combination of grass and postgis. I ran v.net.iso for every processing plant - or possible processing plant - and every farm centroid. At this point, I did not worry about capacity limitations of the plants - you can assume each is unconstrained.

Re: [GRASS-user] v.net tools with polygons

2015-03-03 Thread Mark Wynter
Hi Daniel, I've done something similar - I call it off road routing, and uses a regular lattice of nodes and arcs. You can then constrain the off road network by closing arcs that cross major watercourses, fence lines or where the terrain or vegetation is non navigatable. For farms, I added

Re: [GRASS-user] v.net parallelisation issues

2015-02-13 Thread Mark Wynter
Hi Moritz, Stefan (and Marcus if you’re around?) Every day is a new day. Not IOPs, Not memory, Not CPU… Hmm, how about reboot... As you have suspected, I get no benefit from additional CPUs. Are you sure the problem is CPU-bound ? I started by testing v.net (the maintenance module) in

Re: [GRASS-user] v.net parallelisation issues

2015-02-13 Thread Mark Wynter
with v.net? Anyone? Mark On 13 Feb 2015, at 7:56 pm, Moritz Lennert mlenn...@club.worldonline.be wrote: On 13/02/15 08:39, Mark Wynter wrote: I’ve encountered a bottleneck somewhere with v.net http://v.net when scaling out with GNU Parallel… not sure if its an underlying issue with v.net

Re: [GRASS-user] v.net parallelisation issues

2015-02-13 Thread Mark Wynter
Getting closer to the bottom of this. On AWS, problems occur once I scale beyond 16 CPUs. c3.4xlarge (16 CPUs, 30GB memory), v.net scales linearly c3.8xlarge (32 CPUs, 60GB memory), v.net doesn't scale AT ALL - the same as having single CPU. I don’t believe its a pg issue, as I run loads of

Re: [GRASS-user] SQLite Error

2015-02-12 Thread Mark Wynter
):~ db.connect -p driver: sqlite database: /var/tmp/test/PERMANENT/sqlite/sqlite.db schema: group: On 12 Feb 2015, at 7:05 pm, Moritz Lennert mlenn...@club.worldonline.be wrote: On 12/02/15 02:14, Mark Wynter wrote: #(2) RESET THE DATABASE DRIVER FOR THE CURRENT MAPSET TO SQLITE db.connect

Re: [GRASS-user] SQLite Error

2015-02-12 Thread Mark Wynter
Thanks Moritz - good suggestion - I just need to these as deliverables out to 2 separate clients (nice to get paid work for this stuff) - then I will write up and contribute back via Wiki. The slow rate of writing out the v.net.allpair results from PostgreSQL was due to the sheer volume of

[GRASS-user] v.net parallelisation issues

2015-02-12 Thread Mark Wynter
I’ve encountered a bottleneck somewhere with v.net when scaling out with GNU Parallel… not sure if its an underlying issue with v.net or the way I’m calling the batch jobs? I’ve got 32 CPUs and commensurate RAM. What I’m observing is v.net CPU utilisation dropping off in accordance with

Re: [GRASS-user] SQLite Error

2015-02-12 Thread Mark Wynter
Haven’t come across anything to that effect Can you set schema='' or something like that ? Moritz I’ve reverted back to using solely PG driver - notwithstanding this SQLite issue. As a prologue to the several issues I encountered with Grass over the last few days… The slow rate of

[GRASS-user] Help with defining DB Drivers for input and outputs

2015-02-11 Thread Mark Wynter
Within the same mapset, is it possible to specify SQLITE as the database for the output layer, whilst using a map as an input that has a PG driver? I’ve read the manual and tried a few approaches, but I found the outputs still get written to PG. May be I’ve missed a critical step? See

[GRASS-user] SQLite Error

2015-02-11 Thread Mark Wynter
grass ERROR: Unable to create table: 'create table grass.temp_8_1 ( cat integer, from_cat integer, to_cat integer, cost double precision)' Segmentation fault On 12/02/15 00:12, Mark Wynter wrote: Within the same mapset, is it possible to specify SQLITE as the database for the output

[GRASS-user] v.out.postgis and v.out.ogr - inconsistencies in output

2015-02-11 Thread Mark Wynter
As context, I’m running analysis using v.net.allpairs, whereby vector geometries are often common to more than 1 origin-destination journey path, hence the line segments appear multiple times but with unique cat values, and from_cat and to_cat combinations. When exporting the output layer of

[GRASS-user] v.out.postgis dropping cats

2015-02-10 Thread Mark Wynter
Hi list Context is I’m running v.net.allpairs over a large road network - the output is all combination origin - destination pairs, and the individual line segments that make up a journey path. Individual line segments will appear more than once where they’re common to more than 1 journey

Re: [GRASS-user] SQLITE db locking problem

2015-01-22 Thread Mark Wynter
Thanks Marcus - am I right in understanding that read and write resulted in the db being opened twice? Was this confined to just v.patch? Anything a user needs to do differently, apart from update? ___ grass-user mailing list

Re: [GRASS-user] SQLITE db locking problem - update

2015-01-19 Thread Mark Wynter
feature - thanks Martin Landa!!! -- Message: 1 Date: Mon, 19 Jan 2015 00:53:58 +1030 From: Mark Wynter m...@dimensionaledge.com To: grass grass-user@lists.osgeo.org Subject: [GRASS-user] SQLITE db locking problem Message-ID

[GRASS-user] SQLITE db locking problem

2015-01-18 Thread Mark Wynter
Hi everyone I’m having issues with SQLITE as the db driver - I encounter this BUSY warning. Only occurs when patching a particular map, in this case “temp_nbt_cleaned which is the largest of the datasets being patched. If I work with smaller datasets, it works fine. Pre-patching, SQLITE DB

Re: [GRASS-user] Checking and fixing roads for network analysis

2015-01-16 Thread Mark Wynter
Hi Daniel - not sure why you’re getting that error - I’ll leave that to someone more familiar with the backend workings to comment on. In the interests of you moving forward, one approach might be that you simply manually add nodes in say QGIS before running v.snap. By that, I mean: 1) In

[GRASS-user] SOLVED: Compilation Errors Installing GRASS 70 on Centos 6.5

2014-09-25 Thread Mark Wynter
Re-checked out SVN Clean install directory Installed without a hitch :-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Compilation Errors Installing GRASS 70 on Centos 6.5

2014-09-24 Thread Mark Wynter
Upon running ‘make’, I get errors consistent with the message below. Any clues as to the source of the Error 1 messages, and what the fix is? Thanks Mark # make -C v.centroids || echo /home/grass/grass70/releasebranch_7_0/scripts/v.centroids /home/grass/grass70/releasebranch_7_0/error.log

[GRASS-user] v.net multi-threaded parallel processing

2013-06-27 Thread Mark Wynter
Curious to hear if anyone has considered or is considering v.net in a high performance computing environment? - Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] speeding up v.clean for large datasets

2013-04-26 Thread Mark Wynter
Thanks Markus for the explanation. I've set PostGIS as my backend. Will revert as I get more into v.net On 22/04/2013, at 8:20 PM, Markus Metz wrote: On Mon, Apr 22, 2013 at 11:03 AM, Mark Wynter m...@dimensionaledge.com wrote: Thanks Marcus. Tried sqlite backend suggestion

Re: [GRASS-user] Grass7 - Inconsistencies with v.out.ogr and v.out.postgis

2013-04-26 Thread Mark Wynter
Do you have fresh installation from svn? Thanks Martin. Good advice - I just pulled the latest from svn! v.out.postgis now works, generating correct feature count and SRID=2193 yet... v.out.ogr when writing directly to PostGIS assigns SRID 900915 to the geometry column - when it should be

Re: [GRASS-user] Grass7 - Inconsistencies with v.out.ogr and v.out.postgis

2013-04-26 Thread Mark Wynter
v.out.ogr in=roadsmajor dsn=PG:dbname=pgis_grass format=PostgreSQL - $ db.select data=pgis_grass dri=pg sql=select count(*) from roadsmajor -c 355 db.select data=pgis_grass dri=pg sql=select srid from geometry_columns where f_table_name = 'roadsmajor' -c 900914 (new srid added to

Re: [GRASS-user] speeding up v.clean for large datasets

2013-04-22 Thread Mark Wynter
Thanks Marcus. Tried sqlite backend suggestion - no improvement - then read that that sqlite is the default backend for grass7. I suspect the complexity of the input dataset may be the contributing factor. For example, I ran v.clean over the already cleaned OSM dataset (2.6M lines), and it

[GRASS-user] speeding up v.clean for large datasets

2013-04-19 Thread Mark Wynter
Hi All, we're looking for ways to speed up the cleaning of a large OSM road network (relating to Australia). We're running on a large Amazon AWS EC2 instance. What we've observed is exponential growth in time taken as number of linestrings increases. This means it's taking about 3 days to

Re: [GRASS-user] speeding up v.clean for large datasets

2013-04-19 Thread Mark Wynter
of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 On 19/04/2013, at 6:07 PM, Markus Metz wrote: On Fri, Apr 19, 2013 at 9:06 AM, Mark Wynter m...@dimensionaledge.com wrote: Hi All, we're looking for ways to speed up the cleaning of a large OSM road network (relating

Re: [GRASS-user] Problem accessing GRASS from GRASS from PostgreSQL9.1/PostGIS2.0 via pg-python or plpythonu

2012-07-19 Thread Mark Wynter
Thanks Andrew I suggest running a test script that reports sys.path to confirm that the actual Python module search path seen by the Postgres server's environment is as expected. From the python console, logged in as posgres user postgres@ip-10-252-74-140:/home/ubuntu$ python -c

[GRASS-user] Problem accessing GRASS from PostgreSQL9.1/PostGIS2.0 via pg-python or plpythonu

2012-07-18 Thread Mark Wynter
My requirement is to connect to GRASS from PostgreSQL9.1/PostGIS2.0 via the pg-python or plpythonu procedural language. I'm wondering whether I have a permissions issue? I'm running my stack on Ubuntu 12.04 LTS I've added the following environmental variables to /etc/bash.bashrc export