Re: [OSGeo-Discuss] Re: Staistical analysis support needed

2010-09-14 Thread Dan Putler

Hi Mayank,

In terms of Eclipse integration look at the statet package: 
http://www.walware.de/goto/statet. In terms of Java/R API (really more 
of a glue layer), look at the rJava package: 
http://www.rforge.net/rJava/, which also includes JRI (something this 
thread has already addressed).


Given where you are in this, the R-sig-geo mailing list is really the 
best home for your questions at the point rather than the OSGeo-Discuss 
mailing list. The R-sig-geo mailing list is a very forgiving place by R 
mailing list standards. A word of warning, most R mailing lists are very 
unforgiving of questions whose answers could have been obtained from a 
web search prior to posting.


Dan

On 09/13/2010 10:17 PM, mayank_agarwal wrote:

Thanks everyone for helping me,

I am using R gor statistical analysis, but how does integrate with Eclipse
and how is the API?
   


___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Looking for Yum or RPM Site for GIS Suite for Centos 5.5

2010-09-14 Thread Mathieu Baudier
 Thanks for all the help and advice on this, everybody! Especially for the
 info on EPEL and ELGIS. I guess I had no idea that getting stable and

You can browse the spec files here:
https://projects.argeo.org/elgis/svn/factory/trunk/rpmbuild/

in order to see whether the switches you need are all there.
At first glance I think they are, but if you need some more, I can try
to add them.

 software. And it sounds like QGIS is a non-starter on CentOS. But I've got

I'm still trying to get QGIS fully working on CentOS 5, but as Micha
put it, this may not be worth the effort given that RHEL/CentOS 6 is
around the corner.

For the time being you have QGIS 1.4 working, integrated with GRASS,
BUT without the Python plugins (a big limitation).
We also have SRPMS for QGIS 1.0.2 (their LTS version) but there was
little interest in it, so we dropped it.

 I appreciate the help as always.

Don't hesitate to join the EL GIS mailing-list:
http://lists.osgeo.org/mailman/listinfo/el

This project is very user driven: we support what people actually use,
so this is the right place to send your wish list.
And feedback is very useful for us!
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Java library that can read GML file then port to Java classes

2010-09-14 Thread Justin Deoliveira
Gml 3.2 support is coming in geotools soon, but not quite there yet. If you
are eager for it though you can grab it from my github repository.

  http://github.com/jdeolive/geotools/tree/gml32

I hope to commit the changes back to geotools svn sometime this week.

-Justin

On Tue, Sep 14, 2010 at 12:37 AM, eros gml.check.t...@gmail.com wrote:


 I would like to read a gml file then port to Java classes for further
 processing..
 i've heard geotools has GML3_2 package...

 please help me to decide on what java library to use...

 thanks
 --
 View this message in context:
 http://osgeo-org.1803224.n2.nabble.com/Java-library-that-can-read-GML-file-then-port-to-Java-classes-tp5528885p5528885.html
 Sent from the OSGeo Discuss mailing list archive at Nabble.com.
 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss




-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Bill Thoen

 Steve,

Adding viewsheds to the package would certainly up the computing costs; 
I was wondering if you had a limit to what sort of processing power 
you've got there. ;-)


I also think what you're proposing might be interesting, but you have to 
be careful about what conclusions you can draw from it. At what point 
does the cost due to gradient variations become insignificant to the 
overall cost of a route for a particular type of vehicle? For a trucker 
on an interstate highway it doesn't signify because the statistical 
noise of factors such high speeds and short driving time balanced 
against the higher price of fuel, services and road freight taxes 
completely overwhelms the cost factor contributed by the change in 
gradients. So in those cases you'd be computing numbers but not saying 
anything.


A different scenario, where gradient /is/ a significant factor, would be 
a three-day 100 mile bike ride event through the mountains (like the 
'Ride the Rockies' event they hold around here every year.) The power 
that bicyclists can produce is so low that speeds and endurance are 
strongly affected by grades. But a bicyclist doesn't typically operate 
on the scale of the nation so applying the calculations to the entire 
TIGER file is overkill. Also, the bicyclist operates on such a large 
scale that the source data you're using to calculate gradient (30m DEM) 
may be too coarse to be reliable on the bicyclist's scale.


I'm not saying it isn't worth doing, I'm just saying you'll need to 
qualify the precision of your results before you can say much about 
applying this to any real-world problems.


- Bill Thoen


On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:

Bill,

Thanks for the ideas. I might try to do something with the viewshed 
idea in the future. It would need a LOT of computing to process all 
the road segments in a National dataset like Tiger.


But for now I would like to figure out the routing costs.

One idea I had was to compute the grade for a segment and then compute 
cost as:


cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

This would have the effect of causing segments with a lot of grade to 
have a higher cost of traversal.


Or similarly, if you want to pick roads with a lot of elevation 
changes then use cost factor like:


cost = (time or distance) * scalefactor /
   abs(sum_elevation_changes_over_the_segment)

This would have the effect of decreasing the traversal cost for 
segments that have a lot of elevation changes.


These are pretty crude estimates and probably would need some fine 
tuning to get reasonable results.


Thanks,
  -Steve W

On 9/13/2010 4:24 PM, Bill Thoen wrote:

Stephen Woodbridge wrote:

Hi all,

(This is cross posting from the pgrouting list, sorry for the dups.)

I have preprocessed some shapefile data and added elevation
information in the Z value of the coordinates. I'm wondering how to
best utilize that in routes and would like any thoughts or ideas you
might be willing to share.

The obvious answer is to wrap the elevation data into the cost values
as this is simple and straight forward and does not require code
changes. This brings me to what have other people done or thought
about doing in this regard?

Since you seem to enjoy large database problems, have you considered
loading the DEM data together with the roads and sample the viewshed
every few km? You could then create an objective cost factor for
scenic, proportional to the amount of land visible, with some
adjusting factor that distinguishes morphology, land cover, or other
weighted factors from each sample point. Creating a scale of scenic
and picturesque as it goes form ho-hum flatland to precipitous,
brake-burning, wheel-gripping adventurous might be fun all by itself.

If you're looking for 3D ideas, there's a GIS consulting company across
the hall from me that specializes in 3D information, visualization and
analysis, and I know they are working on web services to deliver the
sort of data that an application like yours would consume. Their website
is full of 3D imagery, articles and examples that you might want to
check out for ideas or inspiration There's a particularly good
demonstration of using fog instead of shadow to create a visual
representation of ridge lines, if your 're using those to determine a
topographic index (see http://ctmap.com/serendipity/index.php).

*Bill Thoen*
GISnet - www.gisnet.com http://www.gisnet.com/
1401 Walnut St., Suite C
Boulder, CO 80302
303-786-9961 tel
303-443-4856 fax
bth...@gisnet.com

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



--
*Bill Thoen*
GISnet - www.gisnet.com
303-786-9961
___
Discuss mailing list
Discuss@lists.osgeo.org

[OSGeo-Discuss] Links to FOSS4G Presentations?

2010-09-14 Thread Fawcett, David (MPCA)
Is there a central location with links to presentations and workshop materials 
from FOSS4G 2010?

I understand that materials from every workshop won't be made available, but it 
would be great to have a location to browse and see what is available.  

Also, have the WMS Shootout results been posted anywhere?

David.

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Richard Greenwood
I think cruvyness might also be a useful resistance factor, and it
is often associated with grade, as in steep mountain roads with lots
of switchbacks. After attending FOSS4G last week my wife and I have
been driving and biking in the Pyrenees and experiencing the effects
of both cruvyness and grade on our travel times.

Rich

On Tue, Sep 14, 2010 at 10:31 AM, Stephen Woodbridge
wood...@swoodbridge.com wrote:
 On 9/14/2010 11:43 AM, Bill Thoen wrote:

  Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

 It is not unlimited, so part of the problem that is interesting to me is how
 to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

 Agreed, doing anything for the trucking industry that would be useful
 probably requires a lot more understanding of the industry and regulations
 required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

 Right, these points are all valid and have crossed my mind at one point or
 another. Applying this to the Tiger data set is not that big of a deal. I
 already have the Tiger data in XYZ so computing grades is not that
 difficult. Another reason for applying it to the whole data set is to build
 a web portal with US coverage. Granted any single route will not have
 continental scope, but individual routes might be anywhere on the continent.

 I'm not saying it isn't worth doing, I'm just saying you'll need to
 qualify the precision of your results before you can say much about
 applying this to any real-world problems.

 I'll post a link back if I get anything working. Meanwhile, thanks for the
 ideas and thoughts.

 -Steve

 - Bill Thoen


 On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:

 Bill,

 Thanks for the ideas. I might try to do something with the viewshed
 idea in the future. It would need a LOT of computing to process all
 the road segments in a National dataset like Tiger.

 But for now I would like to figure out the routing costs.

 One idea I had was to compute the grade for a segment and then compute
 cost as:

 cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

 This would have the effect of causing segments with a lot of grade to
 have a higher cost of traversal.

 Or similarly, if you want to pick roads with a lot of elevation
 changes then use cost factor like:

 cost = (time or distance) * scalefactor /
 abs(sum_elevation_changes_over_the_segment)

 This would have the effect of decreasing the traversal cost for
 segments that have a lot of elevation changes.

 These are pretty crude estimates and probably would need some fine
 tuning to get reasonable results.

 Thanks,
 -Steve W

 On 9/13/2010 4:24 PM, Bill Thoen wrote:

 Stephen Woodbridge wrote:

 Hi all,

 (This is cross posting from the pgrouting list, sorry for the dups.)

 I have preprocessed some shapefile data and added elevation
 information in the Z value of the coordinates. I'm wondering how to
 best utilize that in routes and would like any thoughts or ideas you
 might be willing to share.

 The obvious answer is to wrap the elevation data into the cost values
 as this is simple and straight forward and does not require code
 changes. This brings me to what have other people done or thought
 about doing in this regard?

 Since you seem to enjoy large database problems, have you considered
 loading the DEM data together with the roads and sample the viewshed
 every few km? You could then create an objective cost factor for
 scenic, proportional to the amount of land visible, with some
 adjusting factor that distinguishes morphology, land cover, or other
 weighted factors from each sample point. Creating a scale of 

Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Stephen Woodbridge
Yes, this is another good factor to look at. Curvature can be computed 
as the 2nd derivative or the rate of change in angle along the road. 
This is a little harder to compute with segments as you need to join 
adjacent segments to compute this or you get disconnects where they 
join. And you have to figure out what are through streets at 
intersections of more then two segments. But still a good measure.


Also curvyness can often com into play when following rivers and 
streams even when there is not significant grade.


-Steve

On 9/14/2010 12:52 PM, Richard Greenwood wrote:

I think cruvyness might also be a useful resistance factor, and it
is often associated with grade, as in steep mountain roads with lots
of switchbacks. After attending FOSS4G last week my wife and I have
been driving and biking in the Pyrenees and experiencing the effects
of both cruvyness and grade on our travel times.

Rich

On Tue, Sep 14, 2010 at 10:31 AM, Stephen Woodbridge
wood...@swoodbridge.com  wrote:

On 9/14/2010 11:43 AM, Bill Thoen wrote:


  Steve,

Adding viewsheds to the package would certainly up the computing costs;
I was wondering if you had a limit to what sort of processing power
you've got there. ;-)


It is not unlimited, so part of the problem that is interesting to me is how
to find and compute economical way to do it.


I also think what you're proposing might be interesting, but you have to
be careful about what conclusions you can draw from it. At what point
does the cost due to gradient variations become insignificant to the
overall cost of a route for a particular type of vehicle? For a trucker
on an interstate highway it doesn't signify because the statistical
noise of factors such high speeds and short driving time balanced
against the higher price of fuel, services and road freight taxes
completely overwhelms the cost factor contributed by the change in
gradients. So in those cases you'd be computing numbers but not saying
anything.


Agreed, doing anything for the trucking industry that would be useful
probably requires a lot more understanding of the industry and regulations
required for that. Luckily it is not my main focus :)


A different scenario, where gradient /is/ a significant factor, would be
a three-day 100 mile bike ride event through the mountains (like the
'Ride the Rockies' event they hold around here every year.) The power
that bicyclists can produce is so low that speeds and endurance are
strongly affected by grades. But a bicyclist doesn't typically operate
on the scale of the nation so applying the calculations to the entire
TIGER file is overkill. Also, the bicyclist operates on such a large
scale that the source data you're using to calculate gradient (30m DEM)
may be too coarse to be reliable on the bicyclist's scale.


Right, these points are all valid and have crossed my mind at one point or
another. Applying this to the Tiger data set is not that big of a deal. I
already have the Tiger data in XYZ so computing grades is not that
difficult. Another reason for applying it to the whole data set is to build
a web portal with US coverage. Granted any single route will not have
continental scope, but individual routes might be anywhere on the continent.


I'm not saying it isn't worth doing, I'm just saying you'll need to
qualify the precision of your results before you can say much about
applying this to any real-world problems.


I'll post a link back if I get anything working. Meanwhile, thanks for the
ideas and thoughts.

-Steve


- Bill Thoen


On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:


Bill,

Thanks for the ideas. I might try to do something with the viewshed
idea in the future. It would need a LOT of computing to process all
the road segments in a National dataset like Tiger.

But for now I would like to figure out the routing costs.

One idea I had was to compute the grade for a segment and then compute
cost as:

cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

This would have the effect of causing segments with a lot of grade to
have a higher cost of traversal.

Or similarly, if you want to pick roads with a lot of elevation
changes then use cost factor like:

cost = (time or distance) * scalefactor /
abs(sum_elevation_changes_over_the_segment)

This would have the effect of decreasing the traversal cost for
segments that have a lot of elevation changes.

These are pretty crude estimates and probably would need some fine
tuning to get reasonable results.

Thanks,
-Steve W

On 9/13/2010 4:24 PM, Bill Thoen wrote:


Stephen Woodbridge wrote:


Hi all,

(This is cross posting from the pgrouting list, sorry for the dups.)

I have preprocessed some shapefile data and added elevation
information in the Z value of the coordinates. I'm wondering how to
best utilize that in routes and would like any thoughts or ideas you
might be willing to share.

The obvious answer is to wrap the elevation data into the cost values
as this is simple and straight forward 

Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Bob Basques
All, 

One thought just occurred to me related to this thread, what would street 
construction type add to the equation?  Dirt/gravel/blacktop/concrete, add on 
to that age of road/ADT and roughness might start becoming a factor as well.  I 
know these are getting a bit right or left of the original question, but if the 
data is available . . . 

Might be able to auto extract such things from high resolution photography, 
also spectral photogrphy is also a viable tool here. 

bobb 



 Stephen Woodbridge wood...@swoodbridge.com wrote:

Yes, this is another good factor to look at. Curvature can be computed
as the 2nd derivative or the rate of change in angle along the road.
This is a little harder to compute with segments as you need to join
adjacent segments to compute this or you get disconnects where they
join. And you have to figure out what are through streets at
intersections of more then two segments. But still a good measure.

Also curvyness can often com into play when following rivers and
streams even when there is not significant grade.

-Steve

On 9/14/2010 12:52 PM, Richard Greenwood wrote:
 I think cruvyness might also be a useful resistance factor, and it
 is often associated with grade, as in steep mountain roads with lots
 of switchbacks. After attending FOSS4G last week my wife and I have
 been driving and biking in the Pyrenees and experiencing the effects
 of both cruvyness and grade on our travel times.

 Rich

 On Tue, Sep 14, 2010 at 10:31 AM, Stephen Woodbridge
 wood...@swoodbridge.com  wrote:
 On 9/14/2010 11:43 AM, Bill Thoen wrote:

   Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

 It is not unlimited, so part of the problem that is interesting to me is how
 to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

 Agreed, doing anything for the trucking industry that would be useful
 probably requires a lot more understanding of the industry and regulations
 required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

 Right, these points are all valid and have crossed my mind at one point or
 another. Applying this to the Tiger data set is not that big of a deal. I
 already have the Tiger data in XYZ so computing grades is not that
 difficult. Another reason for applying it to the whole data set is to build
 a web portal with US coverage. Granted any single route will not have
 continental scope, but individual routes might be anywhere on the continent.

 I'm not saying it isn't worth doing, I'm just saying you'll need to
 qualify the precision of your results before you can say much about
 applying this to any real-world problems.

 I'll post a link back if I get anything working. Meanwhile, thanks for the
 ideas and thoughts.

 -Steve

 - Bill Thoen


 On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:

 Bill,

 Thanks for the ideas. I might try to do something with the viewshed
 idea in the future. It would need a LOT of computing to process all
 the road segments in a National dataset like Tiger.

 But for now I would like to figure out the routing costs.

 One idea I had was to compute the grade for a segment and then compute
 cost as:

 cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

 This would have the effect of causing segments with a lot of grade to
 have a higher cost of traversal.

 Or similarly, if you want to pick roads with a lot of elevation
 changes then use cost factor like:

 cost = (time or distance) * scalefactor /
 abs(sum_elevation_changes_over_the_segment)

 This would have the effect of decreasing the traversal cost for
 segments that have a lot of elevation changes.

 These are 

RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Andy Turner
Hi OSGeo Discussions, (cc Steve, Justin),

In terms of the computing of viewsheds, both Steve Carver 
(http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell 
(http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I 
don't know the latest...

It can be useful to compute which bits of road can be seen from other bits of 
road and what impact roads have on the perception of wilderness from off the 
road. Same true with vehicles on roads although these are usually moving.

I think the viewshed work though is somewhat orthogonal to including elevation 
in routing application outwith surveillance and visual impact contexts.

One further thought: it is much nicer to have junctions (where traffic is to 
slow and potentially stop for ordered inetrsection) well laid out at the top of 
small hills. This is for network flow and general economy and safety reasons. 
So in the analysis of a route, some quantification of junction impact taking 
into account elevation might be good.

HTH

Andy
http://www.geog.leeds.ac.uk/people/a.turner/
 

-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Stephen Woodbridge
Sent: 14 September 2010 17:31
To: discuss@lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

On 9/14/2010 11:43 AM, Bill Thoen wrote:
   Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

It is not unlimited, so part of the problem that is interesting to me is 
how to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

Agreed, doing anything for the trucking industry that would be useful 
probably requires a lot more understanding of the industry and 
regulations required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

Right, these points are all valid and have crossed my mind at one point 
or another. Applying this to the Tiger data set is not that big of a 
deal. I already have the Tiger data in XYZ so computing grades is not 
that difficult. Another reason for applying it to the whole data set is 
to build a web portal with US coverage. Granted any single route will 
not have continental scope, but individual routes might be anywhere on 
the continent.

 I'm not saying it isn't worth doing, I'm just saying you'll need to
 qualify the precision of your results before you can say much about
 applying this to any real-world problems.

I'll post a link back if I get anything working. Meanwhile, thanks for 
the ideas and thoughts.

-Steve

 - Bill Thoen


 On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:
 Bill,

 Thanks for the ideas. I might try to do something with the viewshed
 idea in the future. It would need a LOT of computing to process all
 the road segments in a National dataset like Tiger.

 But for now I would like to figure out the routing costs.

 One idea I had was to compute the grade for a segment and then compute
 cost as:

 cost = (time or distance) * scalefactor * max(abs(grade), 1.0)

 This would have the effect of causing segments with a lot of grade to
 have a higher cost of traversal.

 Or similarly, if you want to pick roads with a lot of elevation
 changes then use cost factor like:

 cost = (time or distance) * scalefactor /
 abs(sum_elevation_changes_over_the_segment)

 This would have the effect of decreasing the traversal cost for
 segments that have a lot of elevation changes.

 These are pretty crude estimates and probably would need some fine
 tuning to get reasonable results.

 Thanks,
 -Steve W

 On 9/13/2010 4:24 PM, Bill Thoen wrote:
 Stephen Woodbridge wrote:
 Hi all,

 (This is cross 

RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Andy Turner
On reflection, viewshed analysis might be used for route choice if for example 
one might want the view of something on a route (this could be something 
relatively precisely located e.g. the tip of the Eiffel Tower, or something 
imprecisely located e.g. the sea). Elevation and landcover and details of 
season etc may well come into such a calculation...


From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On 
Behalf Of Andy Turner [a.g.d.tur...@leeds.ac.uk]
Sent: 14 September 2010 18:53
To: discuss@lists.osgeo.org
Cc: Stephen Carver; Justin Washtell
Subject: RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

Hi OSGeo Discussions, (cc Steve, Justin),

In terms of the computing of viewsheds, both Steve Carver 
(http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell 
(http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I 
don't know the latest...

It can be useful to compute which bits of road can be seen from other bits of 
road and what impact roads have on the perception of wilderness from off the 
road. Same true with vehicles on roads although these are usually moving.

I think the viewshed work though is somewhat orthogonal to including elevation 
in routing application outwith surveillance and visual impact contexts.

One further thought: it is much nicer to have junctions (where traffic is to 
slow and potentially stop for ordered inetrsection) well laid out at the top of 
small hills. This is for network flow and general economy and safety reasons. 
So in the analysis of a route, some quantification of junction impact taking 
into account elevation might be good.

HTH

Andy
http://www.geog.leeds.ac.uk/people/a.turner/


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Stephen Woodbridge
Sent: 14 September 2010 17:31
To: discuss@lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

On 9/14/2010 11:43 AM, Bill Thoen wrote:
   Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

It is not unlimited, so part of the problem that is interesting to me is
how to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

Agreed, doing anything for the trucking industry that would be useful
probably requires a lot more understanding of the industry and
regulations required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

Right, these points are all valid and have crossed my mind at one point
or another. Applying this to the Tiger data set is not that big of a
deal. I already have the Tiger data in XYZ so computing grades is not
that difficult. Another reason for applying it to the whole data set is
to build a web portal with US coverage. Granted any single route will
not have continental scope, but individual routes might be anywhere on
the continent.

 I'm not saying it isn't worth doing, I'm just saying you'll need to
 qualify the precision of your results before you can say much about
 applying this to any real-world problems.

I'll post a link back if I get anything working. Meanwhile, thanks for
the ideas and thoughts.

-Steve

 - Bill Thoen


 On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:
 Bill,

 Thanks for the ideas. I might try to do something with the viewshed
 idea in the future. It would need a LOT of computing to process all
 the road segments in a National dataset like Tiger.

 But for now I would like to figure out the routing costs.

 One idea I had was to compute the grade for a segment and then compute
 cost as:

 cost = (time or 

RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Bob Basques
All, 

The view of road, got me thinking about auto-placement of bridges and their 
locations, and even what road is above what other road.  While not being able 
to tell exactly how long a bridge might be, it would be usefull for locating 
(and styling) a bridge location along a roadway, at least down to all but the 
highest level of resolution. 

Might also be a tunnel extraction method here with the right sort of DEM 
available. 

I also just thought of a question, in a high resolution environment (I have one 
foot contours/DEM data for our City), it might be beneficial to describe the 
line along it's length in some manner, where breaks in elevation occur, etc.  
Country and rural roads might not have breaks in them for some measure of 
distance, but have many vertical undulations along the space horizontal 
distance. 

bobb 



 Andy Turner a.g.d.tur...@leeds.ac.uk wrote:

Hi OSGeo Discussions, (cc Steve, Justin),

In terms of the computing of viewsheds, both Steve Carver 
(http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell 
(http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I 
don't know the latest...

It can be useful to compute which bits of road can be seen from other bits of 
road and what impact roads have on the perception of wilderness from off the 
road. Same true with vehicles on roads although these are usually moving.

I think the viewshed work though is somewhat orthogonal to including elevation 
in routing application outwith surveillance and visual impact contexts.

One further thought: it is much nicer to have junctions (where traffic is to 
slow and potentially stop for ordered inetrsection) well laid out at the top of 
small hills. This is for network flow and general economy and safety reasons. 
So in the analysis of a route, some quantification of junction impact taking 
into account elevation might be good.

HTH

Andy
http://www.geog.leeds.ac.uk/people/a.turner/


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Stephen Woodbridge
Sent: 14 September 2010 17:31
To: discuss@lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

On 9/14/2010 11:43 AM, Bill Thoen wrote:
   Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

It is not unlimited, so part of the problem that is interesting to me is
how to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

Agreed, doing anything for the trucking industry that would be useful
probably requires a lot more understanding of the industry and
regulations required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

Right, these points are all valid and have crossed my mind at one point
or another. Applying this to the Tiger data set is not that big of a
deal. I already have the Tiger data in XYZ so computing grades is not
that difficult. Another reason for applying it to the whole data set is
to build a web portal with US coverage. Granted any single route will
not have continental scope, but individual routes might be anywhere on
the continent.

 I'm not saying it isn't worth doing, I'm just saying you'll need to
 qualify the precision of your results before you can say much about
 applying this to any real-world problems.

I'll post a link back if I get anything working. Meanwhile, thanks for
the ideas and thoughts.

-Steve

 - Bill Thoen


 On 9/13/2010 5:28 PM, Stephen Woodbridge wrote:
 Bill,

 Thanks for the ideas. I might try to do something with the viewshed
 idea in the future. It would need a LOT of computing to process all
 the road 

[OSGeo-Discuss] WMS and layer stacking.

2010-09-14 Thread Bob Basques
All, 

does anyone know if there is a layer hierarchy setting in the WMS service, 
which layers are on top of which layers (Z value=)? 

Thanks 

bobb 

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] WMS and layer stacking.

2010-09-14 Thread Balint Persics
Hi,

IMHO layer Z-order is defined by clients who use the maps. Think about
it: when using PosGIS, Oracle Spatial or any other geoinfor resource,
the Z order is undefined by the resource server, it is up to resource
clients to display them to any Z order the define.

Cheers,
Balint

On Tue, Sep 14, 2010 at 20:59, Bob Basques bob.basq...@ci.stpaul.mn.us wrote:
 All,

 does anyone know if there is a layer hierarchy setting in the WMS service,
 which layers are on top of which layers (Z value=)?

 Thanks

 bobb

 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss





-- 
Persics Balint
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Re: [OSGeo-Discuss] WMS and layer stacking.

2010-09-14 Thread Bob Basques
Balint?, 

I was after something for a definition related to a image class, background, 
foreground, label, marker, etc. 

We've been using things with respect to stacking with Client side ordering for 
the most part for quite a long while now. 

I'm working on a AutoCAD OGC importer (besides just MAP 3D based) and the 
ordering aspects are time consuming if left up to the users.  So any sort of 
ordering would have helped.  It looks like the ordering is based on how the 
service advertises it's layers from what I've been able to find. 

bobb 




 Balint Persics persi...@gmail.com wrote:

Hi,

IMHO layer Z-order is defined by clients who use the maps. Think about
it: when using PosGIS, Oracle Spatial or any other geoinfor resource,
the Z order is undefined by the resource server, it is up to resource
clients to display them to any Z order the define.

Cheers,
Balint

On Tue, Sep 14, 2010 at 20:59, Bob Basques bob.basq...@ci.stpaul.mn.us wrote:
 All,

 does anyone know if there is a layer hierarchy setting in the WMS service,
 which layers are on top of which layers (Z value=)?

 Thanks

 bobb

 ___
 Discuss mailing list
 Discuss@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/discuss





--
Persics Balint
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing

2010-09-14 Thread Geoff Hay
Hi All
I seem to remember reading somewhere that UPS delivery routes are constructed 
with only right turns (or left depending on the country) so as to make use of 
'free' turns to avoid waiting at traffic lights.
Geoff


From: discuss-boun...@lists.osgeo.org [discuss-boun...@lists.osgeo.org] On 
Behalf Of Bob Basques [bob.basq...@ci.stpaul.mn.us]
Sent: Wednesday, 15 September 2010 6:26 a.m.
To: discuss@lists.osgeo.org
Cc: Stephen Carver; Justin Washtell
Subject: RE: [OSGeo-Discuss] Thoughts on how to use elevation in routing


All,


The view of road, got me thinking about auto-placement of bridges and their 
locations, and even what road is above what other road.  While not being able 
to tell exactly how long a bridge might be, it would be usefull for locating 
(and styling) a bridge location along a roadway, at least down to all but the 
highest level of resolution.


Might also be a tunnel extraction method here with the right sort of DEM 
available.


I also just thought of a question, in a high resolution environment (I have one 
foot contours/DEM data for our City), it might be beneficial to describe the 
line along it's length in some manner, where breaks in elevation occur, etc.  
Country and rural roads might not have breaks in them for some measure of 
distance, but have many vertical undulations along the space horizontal 
distance.


bobb



 Andy Turner a.g.d.tur...@leeds.ac.uk wrote:

Hi OSGeo Discussions, (cc Steve, Justin),

In terms of the computing of viewsheds, both Steve Carver 
(http://www.geog.leeds.ac.uk/people/s.carver/) and Justin Washtell 
(http://www.comp.leeds.ac.uk/washtell/) have done some work on this, but I 
don't know the latest...

It can be useful to compute which bits of road can be seen from other bits of 
road and what impact roads have on the perception of wilderness from off the 
road. Same true with vehicles on roads although these are usually moving.

I think the viewshed work though is somewhat orthogonal to including elevation 
in routing application outwith surveillance and visual impact contexts.

One further thought: it is much nicer to have junctions (where traffic is to 
slow and potentially stop for ordered inetrsection) well laid out at the top of 
small hills. This is for network flow and general economy and safety reasons. 
So in the analysis of a route, some quantification of junction impact taking 
into account elevation might be good.

HTH

Andy
http://www.geog.leeds.ac.uk/people/a.turner/


-Original Message-
From: discuss-boun...@lists.osgeo.org [mailto:discuss-boun...@lists.osgeo.org] 
On Behalf Of Stephen Woodbridge
Sent: 14 September 2010 17:31
To: discuss@lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Thoughts on how to use elevation in routing

On 9/14/2010 11:43 AM, Bill Thoen wrote:
   Steve,

 Adding viewsheds to the package would certainly up the computing costs;
 I was wondering if you had a limit to what sort of processing power
 you've got there. ;-)

It is not unlimited, so part of the problem that is interesting to me is
how to find and compute economical way to do it.

 I also think what you're proposing might be interesting, but you have to
 be careful about what conclusions you can draw from it. At what point
 does the cost due to gradient variations become insignificant to the
 overall cost of a route for a particular type of vehicle? For a trucker
 on an interstate highway it doesn't signify because the statistical
 noise of factors such high speeds and short driving time balanced
 against the higher price of fuel, services and road freight taxes
 completely overwhelms the cost factor contributed by the change in
 gradients. So in those cases you'd be computing numbers but not saying
 anything.

Agreed, doing anything for the trucking industry that would be useful
probably requires a lot more understanding of the industry and
regulations required for that. Luckily it is not my main focus :)

 A different scenario, where gradient /is/ a significant factor, would be
 a three-day 100 mile bike ride event through the mountains (like the
 'Ride the Rockies' event they hold around here every year.) The power
 that bicyclists can produce is so low that speeds and endurance are
 strongly affected by grades. But a bicyclist doesn't typically operate
 on the scale of the nation so applying the calculations to the entire
 TIGER file is overkill. Also, the bicyclist operates on such a large
 scale that the source data you're using to calculate gradient (30m DEM)
 may be too coarse to be reliable on the bicyclist's scale.

Right, these points are all valid and have crossed my mind at one point
or another. Applying this to the Tiger data set is not that big of a
deal. I already have the Tiger data in XYZ so computing grades is not
that difficult. Another reason for applying it to the whole data set is
to build a web portal with US coverage. Granted any single route will
not have continental scope, but 

Re: [OSGeo-Discuss] Looking for Yum or RPM Site for GIS Suite for Centos 5.5

2010-09-14 Thread Bill Thoen
 Thanks! I've still got to finish getting the machine built and the 
RAID system set up and get PostgreSQL sorted out. Then I should be in 
position to start loading up on GIS tools. I'll probably be asking 
plenty of questions then.


- Bill Thoen
.
On 9/14/2010 5:41 AM, Mathieu Baudier wrote:

Thanks for all the help and advice on this, everybody! Especially for the
info on EPEL and ELGIS. I guess I had no idea that getting stable and

You can browse the spec files here:
https://projects.argeo.org/elgis/svn/factory/trunk/rpmbuild/

in order to see whether the switches you need are all there.
At first glance I think they are, but if you need some more, I can try
to add them.


software. And it sounds like QGIS is a non-starter on CentOS. But I've got

I'm still trying to get QGIS fully working on CentOS 5, but as Micha
put it, this may not be worth the effort given that RHEL/CentOS 6 is
around the corner.

For the time being you have QGIS 1.4 working, integrated with GRASS,
BUT without the Python plugins (a big limitation).
We also have SRPMS for QGIS 1.0.2 (their LTS version) but there was
little interest in it, so we dropped it.


I appreciate the help as always.

Don't hesitate to join the EL GIS mailing-list:
http://lists.osgeo.org/mailman/listinfo/el

This project is very user driven: we support what people actually use,
so this is the right place to send your wish list.
And feedback is very useful for us!
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss



--
*Bill Thoen*
GISnet - www.gisnet.com
303-786-9961
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss