Fantastic, that worked perfectly. Thanks for taking a look at the data for me. It didn't even occur to me that the data might have a third dimension.
Is there an easy way to check whether a geometry/shapefile has a Z-coordinate element in case I run into a similar issue in the future? I can just test import as 2d as you recommend (or QGIS has an export function that removes z-coordinates), but perhaps there is an easier way to tell? -Sam On Thu, Oct 6, 2016 at 3:32 PM, Markus Metz <[email protected]> wrote: > On Wed, Oct 5, 2016 at 3:05 AM, Sam Snellings <[email protected]> > wrote: > > Markus, > > > > Thank you for the suggestions. I ran the following commands nine times on > > the data, with thresholds .00000000000000000001, 0.0000000001, 0.0000001, > > 0.00001, 0.01, 0.1, 1, 10, and 100. Let me know if I'm not going small > > enough. > > > > v.clean --overwrite input=roads output=roads_snap -c tool=snap > thresh=[see > > above] > > v.net --overwrite input=roads_snap points=schools output=network > > operation=connect thresh=1000 > > v.net.alloc --overwrite input=network output=network_allocation ccats=1-2 > > > > I did not get a complete allocation of road segments from any of them, > and > > as far as I can tell it got stuck at the same vertices on each run. > > > > I will email you a link to the data off-list, thanks for taking a look. > > thanks for providing a link to the data! The problem is that the roads > are 3D with z coordinates not matching at the end of a road segment > and the beginning of another road segment. The solution is to import > roads as a 2D vector with v.in.ogr -2. 2D snapping with v.clean > tool=snap thresh =1 might be helpful. > > Markus M > > > > > -Sam > > > > On Tue, Oct 4, 2016 at 3:53 PM, Markus Metz < > [email protected]> > > wrote: > >> > >> On Tue, Oct 4, 2016 at 5:09 PM, Sam Snellings <[email protected]> > >> wrote: > >> > I've been running some trials through v.net.alloc using town road > >> > networks > >> > as the arc layer and schools as the node layer. I have one set of > >> > roads/schools that breezes through v.net.alloc without issue (Town 1), > >> > while > >> > another one only allocates the first few arcs connected to each school > >> > and > >> > leaves the rest of the network unallocated (Town 2). There is > probably a > >> > problem with the data from Town 2, but I can't figure out what it is. > >> > Does > >> > this issue sound familiar to anyone? > >> > > >> > I am using the GUI. I load each pair of shapefiles into GRASS and then > >> > run > >> > the following statements (I only import two school points to > simplify). > >> > The > >> > two towns are pulled right from the state-wide GIS office, but the > towns > >> > are > >> > in different states (ie - different agencies provide the data). > >> > > >> You do not need this for v.net.alloc: > >> > v.net input=roads output=road_nodes operation=nodes > >> it will create a point for every node, the first point will have > >> cat=1, the second cat=2 which collides with the points you want to > >> attach > >> > >> > v.net input=road_nodes points=schools output=network > operation=connect > >> > thresh=1000 > >> > >> rather use > >> v.net input=roads points=schools output=network operation=connect > >> thresh=1000 > >> > >> > v.net.alloc input=network output=network_allocation ccats=1-2 > >> > >> the real problem is probably a data problem: roads are not properly > >> connected, i.e. the end of one road does not match the beginning of > >> another road. Try v.clean input=roads output=roads_snap -c tool=snap > >> with a very small threshold. This kind of error is quite common with > >> shapefiles (not a fault of the shapefile format but of the software > >> used to create the shapefiles). > >> > >> > > >> > Thanks in advance for any advice, I can also email images/data if that > >> > would > >> > be helpful. > >> > >> If v.clean -c tool=snap does not help, (links to) original data of the > >> schools and road network for Town 2 would be helpful (data please only > >> off-list). > >> > >> Markus M > > > > > > > > _______________________________________________ > > grass-user mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/grass-user >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
