POST
|
Thanks Bill and Jamal, I was indeed a bit too fast. it makes me clear, however, that IDW is not exactly the same as what is called the market potential in spatial economics which I need. That is not an average of surrounding points (like for example rainfall etc) like IDW does, but the sum of all markets, inverse weighed with distance. That term is normally not divided by the denominator mentioned by Bill and Jamal above and then, of course, the dimension of distance becomes important. But then, how do I calculate only the nominator w(1)*Z(1) + ... + w(n)*Z(n) given some specified distance in w(i) = 1/Distance(P, P(i))^p. ?? Any tips or scripts that do that? Thanks for your help Dirk Stelder
... View more
05-31-2013
04:28 AM
|
0
|
0
|
1011
|
POST
|
Hi, (Hope Bill reads this) the old post about this mentiones the following from Bill Huber: start quote================= The very name, "inverse distance weighted," practically describes the formula. The objective is to interpolate a value Z at a location P, given values Z(1), ..., Z(n) at distinct other locations P(1), ..., P(n), respectively. The interpolated value is a weighted average of the Z's. That is, it develops a sequence of numbers (the "weights") w(1), ..., w(n) and forms Z = [w(1)*Z(1) + ... + w(n)*Z(n)]/[w(1)+...+w(n)] The division by the sum of the weights is what makes this a true average. A formula like this applies to many interpolators, such as Kriging; the issue is how the weights are computed. With IDW it's simple and straightforward: you select a power 'p', usually around 2, and compute w(i) = 1/Distance(P, P(i))^p. That is, the weights are inversely proportional to the power 'p' of the distances between the point of interpolation and the data locations. That's all there is to it. end quote =============== however: what distance? if it is in kilometers the surface is smoother than when it is in meters. let me know??? thanks, Dirk Stelder t.m.stelder@rug.nl
... View more
05-30-2013
06:18 AM
|
0
|
0
|
1632
|
POST
|
Yes all non-road cells are NoData and all roads are just one cell wide. With one source point I do Costdistance which takes 45 seconds -not bad-. The only thing is I have to do that 400 times, which I do with Python. Some people say Python is very slow;)
... View more
10-24-2010
11:36 PM
|
0
|
0
|
426
|
POST
|
😉 Yes of course! But just for fun a little more background on this: we are working on digitizing historical road maps and found that just drawing lines of different colours and converting them into a costraster saves a lot of time compared to building a full network. The costraster has all the information so "letting the mouse look for the cheese" over the raster does the same job as network analyst. Here's one we did for the Netherlands for 1848. Only the drawing alone took more than a week and make it a perfect network would add another week or more. [IMG width="500" height="699"]http://www.regroningen.nl/stelder/1848.jpg[/IMG] cheers Dirk
... View more
10-20-2010
11:45 PM
|
0
|
0
|
426
|
POST
|
😉 Yes of course! But just for fun a little more background on this: we are working on digitizing historical road maps and found that just drawing lines of different colours and converting them into a costraster saves a lot of time compared to building a full network. The costraster has all the information so "letting the mouse look for the cheese" over the raster does the same job as network analyst. Here's one we did for the Netherlands for 1848. Only the drawing alone took more than a week and making it a perfect network would add another week or more. http://www.regroningen.nl/stelder/1848.jpg cheers Dirk
... View more
10-20-2010
11:40 PM
|
0
|
0
|
426
|
POST
|
Thanks for your clarification Bill. I found an older discussion on this with one of your contributions (http://forums.esri.com/Thread.asp?c=93&f=995&t=151830&mc=8#443651) which describes exactly what I had in mind of doing with some other software. What we should have in this case is defining the graph only once over the 44 mln raster cells, and then do the loop (assuming SP(i,j)=SP(j,i): for i=1,400 for j=i,400 findSP(i,j) end end What I have to do now in ArcGis is defining the graph 400 times, set each time the next location as the source and get all 44 mln SP's. That cannot be efficient, but anyway, I followed your tip on creating "holes": the raster, which is a road raster, now has Nodata for all non-road cells. doing one run for one source now is 1 minute so I'm fine. thanks again but really somebody should find a more efficient way
... View more
10-20-2010
02:59 AM
|
0
|
0
|
426
|
POST
|
Thanks Bill, indeed you need the info of the whole cost raster because you don't know where the shortest path will go. My understanding of what is going on, however, is that the long computing time does not stem from that but from the fact that the SP's from ALL raster cells to the source point are calculated. My result should not be 44 million numbers but just one: the length of the SP from point A to point B. Because I cannot specify a "from" point and a "to" point but just a source the result now is that I get 44 million SP's of which I only need to know one.
... View more
10-18-2010
11:49 PM
|
0
|
0
|
426
|
POST
|
Hi everyone, as always simple questions may have difficult answers. I just have this: 1) a set of 400 points, for which I need to find the shortest paths between them over a cost raster. Not really the path itself but just the total cost of the path. 2) a cost raster If I do spatial analyst/shortest path I cannot specify " from" and "to" , just a source. I now choose one location, make it a separate point file and run it with this one as the source, but that in effect leads to calculating the SP for each individual cell of the reference raster (= cost raster with 44 million cells) to that single location (takes 10 minutes for that one alone!). I just need to do that for the 400 cells that matter. Now my code runs 48 hours because of all these superfluous calculations. So in short: whats the code for the SP from a single point A to a single point B over a cost raster? thanks for any help on this cheers, Dirk
... View more
10-18-2010
05:01 AM
|
0
|
5
|
595
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|