I have a bunch of roads that I want to place mile markers on.
Actually they are curvy streets that I want to place markers every 50
meters along. OK if just a dot, but even better if a computed number.
They will be the guide for house number planning by distance, not grid,
appropriate for mountainous areas.
I have managed to put the map on the screen
wget http://www.moiland.gov.tw/land/map/25k_file/95211SW.EXE
unzip 95211SW.EXE
find *.dxf -exec v.in.dxf dxf={} \; #and even uglier:
g.list type=vect|xargs -n1|grep 95211sw|sed s/^/'v.support map='/|sh -e
g.region w=224000 e=229000 s=2686500 n=2689000
# v.cadlabels?
g.list type=vect|xargs -n1|grep 95211sw04|grep -v TXT|\
sed 's/^/d.vect map=/'|sh -e
Now how can I recursively go down each branching road placing markers
every 50 meters? I will give an origin point...
v.distance (to get starting point) + v.segment + some script.
Maybe also v.build.polylines.
Radim
Dan Jacobson wrote:
I have a bunch of roads that I want to place mile markers on.
Actually they are curvy streets that I want to place markers every 50
meters along. OK if just a dot, but even better if a computed number.
They will be the guide for house number planning by distance, not grid,
appropriate for mountainous areas.
I have managed to put the map on the screen
wget http://www.moiland.gov.tw/land/map/25k_file/95211SW.EXE
unzip 95211SW.EXE
find *.dxf -exec v.in.dxf dxf={} \; #and even uglier:
g.list type=vect|xargs -n1|grep 95211sw|sed s/^/'v.support map='/|sh -e
g.region w=224000 e=229000 s=2686500 n=2689000
# v.cadlabels?
g.list type=vect|xargs -n1|grep 95211sw04|grep -v TXT|\
sed 's/^/d.vect map=/'|sh -e
Now how can I recursively go down each branching road placing markers
every 50 meters? I will give an origin point...
On Thu, Nov 18, 2004 at 06:41:50AM +0800, Dan Jacobson wrote:
I have a bunch of roads that I want to place mile markers on.
Actually they are curvy streets that I want to place markers every 50
meters along. OK if just a dot, but even better if a computed number.
They will be the guide for house number planning by distance, not grid,
appropriate for mountainous areas.
I have managed to put the map on the screen
wget http://www.moiland.gov.tw/land/map/25k_file/95211SW.EXE
unzip 95211SW.EXE
find *.dxf -exec v.in.dxf dxf={} \; #and even uglier:
g.list type=vect|xargs -n1|grep 95211sw|sed s/^/'v.support map='/|sh -e
g.region w=224000 e=229000 s=2686500 n=2689000
# v.cadlabels?
g.list type=vect|xargs -n1|grep 95211sw04|grep -v TXT|\
sed 's/^/d.vect map=/'|sh -e
Now how can I recursively go down each branching road placing markers
every 50 meters? I will give an origin point...
Maybe
v.plant help
v.plant fills in intermediate points on arcs with a specified spacing
Take care: the original file is replaced with the new one
Markus
I seems all the neat solutions mentioned are not available here in
ancient Debian sid grass 5.0.3. Don't have the bandwidth to download
source nor the brains to compile. Maybe instead I can give the roads a
constant incline, and then create contour labels or something.
On Sat, Nov 20, 2004 at 11:56:43AM +0800, Dan Jacobson wrote:
I seems all the neat solutions mentioned are not available here in
ancient Debian sid grass 5.0.3. Don't have the bandwidth to download
source nor the brains to compile. Maybe instead I can give the roads a
constant incline, and then create contour labels or something.
Just for comparison:
Source code:
Size
17.5 MB grass-5.0.3_src.tar.gz
20.4 MB grass-5.4.0.tar.gz
6.5 MB grass-5.7.0.tar.gz
7.6 MB grass-5.7 CVS snapshot
Precompiled binaries Linux:
36.7 MB G5.0
7.2 MB G5.7 (thanks to shared libraries)
Markus
It seems to me I did this in GRASS 5.0 using r.cost and r.mapcalc. I can't remember the exact sequence, but you set the pixel value of the the roads to something equal to the cell resolution. Then you can use r.cost to generate a map that shows the cumulative distances between each cell and a input point, your starting point. Use r.mapcalc to select out only the cells that are an even multiple of a mile, and convert them to sites. Not a vector solution, such as is all the rage now, but effective.
Dave
On Friday, November 19, 2004, at 07:56 PM, Dan Jacobson wrote:
I seems all the neat solutions mentioned are not available here in
ancient Debian sid grass 5.0.3. Don't have the bandwidth to download
source nor the brains to compile. Maybe instead I can give the roads a
constant incline, and then create contour labels or something.
To use Mr. Mahoney's, idea I must first convert vector maps to raster.
However, as the vector maps were made with v.in.dxf, they lack
categories. As v.to.rast says, "An empty raster map layer will also be
created if the vector map layer has not been assigned
category/attribute labels (e.g., through use of the v.digit program)."
However, the v.digit program is no place for Limited Edition brain me.
One might think some variation of v.out.ascii|sed s/$/1/|v.in.ascii
would give all my roads category 1, but of course there is no simple
way. Odd how d.vect will show the roads, but that's all one can do.
I was able to get my roads into gnuplot with makefile
A=~/tmp/grassdata/dongshi/jidanni/dig_ascii
%.gp:$A/%
perl -anwle 'print "$$F[1] $$F[0]" if /^ /' $? > $@
%.gnp:%.gp
echo "plot '$?'"|nohup >&- gnuplot -persist
Maybe there or in GMT[version 3] I can proceed.
Probably in the end it will be the Xerox machine, ruler, and red pencil.
On Tue, 23 Nov 2004, Dan Jacobson wrote:
To use Mr. Mahoney's, idea I must first convert vector maps to raster.
However, as the vector maps were made with v.in.dxf, they lack
categories. As v.to.rast says, "An empty raster map layer will also be
created if the vector map layer has not been assigned
category/attribute labels (e.g., through use of the v.digit program)."
However, the v.digit program is no place for Limited Edition brain me.
One might think some variation of v.out.ascii|sed s/$/1/|v.in.ascii
would give all my roads category 1, but of course there is no simple
way.
I think v.llabel is the simple way to do this---have you tried it? If you care which labels are assigned to which roads though, you would of course need v.digit then.
A grass upgrade can't be as simple as just a 6MB download, else the
pros would have long ago put it in Debian.
Got http://grass.itc.it/grass57/binary/linux/snapshot/
but nonetheless, "libogdi31.so: cannot open shared object file".
libgdal1 etc. all installed as per instructions. Debian sid.
Radim> v.distance (to get starting point) + v.segment + some script.
Radim> Maybe also v.build.polylines.
Comparing v.distance.html's DESCRIPTION:
5.0.3:
v.distance uses a binary vector file (map=name) and user specified
coordinates to calculate the distance from the given point(s) to the
nearest line or point in vector layer.
5.7:
v.distance finds features from one vector (from=) feature to another
vector (to=) nearest feature. Various information about relation
(distance, ...) may be uploaded to attribute table attached to first
vector map or printed to 'stdout'. A new vector map may be created
where lines connecting nearest points on features are written.
Sounds complicated. Same with v.segment. Deep. Dark. Wait,
Hamish> you should check out Radim's LRS modules:
Hamish> http://mpa.itc.it/radim/lrs/index.html
Hey, that's just what I need. But all there are are PDF's, no modules
to be found.
On Thu, Nov 25, 2004 at 10:50:18AM +0800, Dan Jacobson wrote:
Got http://grass.itc.it/grass57/binary/linux/snapshot/
but nonetheless, "libogdi31.so: cannot open shared object file".
libgdal1 etc. all installed as per instructions. Debian sid.
Please have a look at my yesterday's message:
http://grass.itc.it/pipermail/grassuser/2004-November/027081.html
Markus
Dan Jacobson wrote:
Radim> v.distance (to get starting point) + v.segment + some script.
Radim> Maybe also v.build.polylines.
Comparing v.distance.html's DESCRIPTION:
5.0.3:
v.distance uses a binary vector file (map=name) and user specified
coordinates to calculate the distance from the given point(s) to the
nearest line or point in vector layer.
5.7:
v.distance finds features from one vector (from=) feature to another
vector (to=) nearest feature. Various information about relation
(distance, ...) may be uploaded to attribute table attached to first
vector map or printed to 'stdout'. A new vector map may be created
where lines connecting nearest points on features are written.
Sounds complicated. Same with v.segment. Deep. Dark. Wait,
Hamish> you should check out Radim's LRS modules:
Hamish> http://mpa.itc.it/radim/lrs/index.html
Hey, that's just what I need. But all there are are PDF's, no modules
to be found.
v.distance and v.segment are not complicated.
LRS is not less complicated. I have created source code package
(http://mpa.itc.it/radim/lrs/index.html)
but it is REALLY WITHOUT ANY WARRANTY OR SUPPORT, as I don't have
time to teach people how to use that neither to write a documentation.
I hope that you get it working and you write a documentation
or tutorial.
Radim
On Thu, Nov 25, 2004 at 10:50:18AM +0800, Dan Jacobson wrote:
Got http://grass.itc.it/grass57/binary/linux/snapshot/
but nonetheless, "libogdi31.so: cannot open shared object file".
libgdal1 etc. all installed as per instructions. Debian sid.
I have modified the GDAL installation on grass.itc.it.
As the introduction of GDAL dependencies was reverted today,
above mentioned problem as well as
http://grass.itc.it/pipermail/grassuser/2004-November/027040.html
should be solved now.
Cheers
Markus
Glad to hear the libogdi31.so bug is fixed. But can someone confirm
that http://grass.itc.it/grass57/binary/linux/snapshot/ will really
work on Debian sid before I try the long download again. Do test all
areas, e.g., d.vect. As a wild guess experiment I tried
cd grass5.7.cvs-i686-pc-linux-gnu-24_11_2004
ln -s libgrass_datetime.5.7.cvs.so libogdi31.so
but this only revealed a new
libgrass5.so.0: cannot open shared object file
which I hope won't greet me on the next download.
So I then did
ln -s libgrass_datetime.5.7.cvs.so libgrass5.so.0
but now d.vect says I have no vector files.
Of course a real .deb would be even neater. However sizes like
$ aptitude -v show grass
Version: 5.0.3-5.1
Compressed Size: 34.3M
mean I would only be able to get it on one of my rare
http://jidanni.org/comp/apt-offline/index_en.html
trips to town.
Odd, 7MB for source on
http://grass.cis.sinica.edu.tw/grass57/source/snapshot/
sounds like the 7MB for binary on
http://grass.itc.it/grass57/binary/linux/snapshot/
and not the several times larger file one sees with
apt-get source grass --print-uris
Hmmm, how did it get so slim and trim?
Well if I Use The Source, then I would have been immune from the above
problems in the first place?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Confirmed. Downloaded, tested, and the version 25_11_2004 works on Debian
Sarge.
Please note, however, that a bit of a hack is necessary:
vi /etc/ld.so.conf
Add grass path, e.g.:
/usr/local/grass5.7.cvs-i686-pc-linux-gnu-25_11_2004/lib
ldconfig
grass57 is much smaller because it used shared libraries, AFAIK.
All the best.
pc
At 00:57, venerdì 26 novembre 2004, Dan Jacobson has probably written:
Glad to hear the libogdi31.so bug is fixed. But can someone confirm
that http://grass.itc.it/grass57/binary/linux/snapshot/ will really
work on Debian sid before I try the long download again. Do test all
Of course a real .deb would be even neater. However sizes like
$ aptitude -v show grass
Version: 5.0.3-5.1
Compressed Size: 34.3M
mean I would only be able to get it on one of my rare
http://jidanni.org/comp/apt-offline/index_en.html
trips to town.
Odd, 7MB for source on
http://grass.cis.sinica.edu.tw/grass57/source/snapshot/
sounds like the 7MB for binary on
http://grass.itc.it/grass57/binary/linux/snapshot/
and not the several times larger file one sees with
apt-get source grass --print-uris
Hmmm, how did it get so slim and trim?
- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBptIM/NedwLUzIr4RArjmAJoDzSIoBFfGbt9E9NQQqsFIMAcCnwCglcAe
Ta5vEc7a2B9z5zN+NE7+aWk=
=Ixcg
-----END PGP SIGNATURE-----
Hello Dan,
On Fri, 26 Nov 2004 07:57:26 +0800 Dan Jacobson <jidanni@jidanni.org>
wrote:
Odd, 7MB for source on
http://grass.cis.sinica.edu.tw/grass57/source/snapshot/
sounds like the 7MB for binary on
http://grass.itc.it/grass57/binary/linux/snapshot/
I would recommend downloading the Source-snapshot of GRASS 5.7 which
comes with a proper debian/-folder to build your own .deb on the
debian-way.
source-snapshot:
http://grass.itc.it/grass57/source/snapshot/ (7.2mb)
You can easily update from CVS with this snapshot, so no long downloads
anymore...
Give it a try.
I did that on my (heaviliy modified) debian sid box successfully once.
and not the several times larger file one sees with
apt-get source grass --print-uris
Hmmm, how did it get so slim and trim?
Well if I Use The Source, then I would have been immune from the above
problems in the first place?
Hope that helps.
Cheers
Stephan
--
Stephan Holl
Check headers for GnuPG Key!
http://www.gdf-hannover.de
On Fri, Nov 26, 2004 at 08:08:16AM +0100, Stephan Holl wrote:
Hello Dan,
On Fri, 26 Nov 2004 07:57:26 +0800 Dan Jacobson <jidanni@jidanni.org>
wrote:
> Odd, 7MB for source on
> http://grass.cis.sinica.edu.tw/grass57/source/snapshot/
> sounds like the 7MB for binary on
> http://grass.itc.it/grass57/binary/linux/snapshot/
I would recommend downloading the Source-snapshot of GRASS 5.7 which
comes with a proper debian/-folder to build your own .deb on the
debian-way.
source-snapshot:
http://grass.itc.it/grass57/source/snapshot/ (7.2mb)
You can easily update from CVS with this snapshot, so no long downloads
anymore...
I have submitted some changes from Stephan to 5.7-CVS:
debian/rules
debian/control
The next Saturday's snapshot (27 Nov 2004) will contain
these changes (and many others...).
Markus
"S" == Stephan Holl <sholl@gmx.net> writes:
S> I would recommend downloading the Source-snapshot of GRASS 5.7 which
S> comes with a proper debian/-folder to build your own .deb on the
S> debian-way. http://grass.itc.it/grass57/source/snapshot/ (7.2mb)
Then do dpkg-checkbuilddeps to see the additional packages you will
need to compile it. They ought to put this where you can see it
before you download. [Took several wget -c's throughout the night just
to find out.]:
Build-Depends: autoconf (>=2.13), autotools-dev, bison | byacc, csh,
debhelper (>= 4.0.2), doxygen, fftw3-dev, flex, libc6-dev,
libfreetype6-dev, libgdal1-dev, libjpeg62-dev | libjpeg-mmx-dev,
libncurses5-dev, libpng12-dev, libreadline4-dev, libtiff4-dev,
postgresql-client, postgresql-dev, proj (>= 4.4.7), tcl8.3-dev,
tk8.3-dev, unixodbc-dev, xlibmesa-gl-dev, xlibmesa-glu-dev, xlibs-dev,
zlib1g-dev, libgdal1
(Note how csh is there and not virtual c-shell, etc.)
I will now try the third alternative,
http://bullhorn.org unstable/main libgrass5.7 5.7.0-4, grass5.7 5.7.0-4
Radim> LRS is not less complicated. I have created source code package
Radim> (http://mpa.itc.it/radim/lrs/index.html)
I doesn't look like I will be able to compile grass, having to make
another modem call each dependency I discover. Therefore can someone
make these into something I can use on debian, as there is perhaps a
chance I will be able to use the bullhorn.org .debs.