| bio | website | arencambre.com |
|---|---|---|
| location | Dallas, TX | |
| age | ||
| visits | member for | 2 years, 7 months |
| seen | May 11 at 21:13 | |
| stats | profile views | 37 |
|
May 11 |
comment |
What is the best way to join lots of small polygons to form a larger polygon? Not sure your syntax is correct. Per postgis.net/docs/ST_Union.html, there is no signature that accepts a number in the 2nd parameter. |
|
May 7 |
awarded | Popular Question |
|
Jan 21 |
awarded | Nice Question |
|
Jan 18 |
awarded | Citizen Patrol |
|
Dec 20 |
comment |
MapGuide or Mapserver for Enterprise? I guess what I was getting at is which is easiest to set up or maintain. Some of these GIS tools are still immature and over-complicated. |
|
Dec 9 |
asked | How to filter or query data in GRASS? |
|
Nov 25 |
accepted | How do I compute v.kernel maps in less than 16 hours? |
|
Nov 25 |
comment |
How do I compute v.kernel maps in less than 16 hours? Just want to confirm that r53983 of 6.4.3 converted the almost-a-day execution into 25.5 minutes! |
|
Nov 24 |
comment |
How do I compute v.kernel maps in less than 16 hours? Is this the same as the v.kernel improvement you put into r53982 and r53983? |
|
Nov 20 |
comment |
How do I compute v.kernel maps in less than 16 hours? Thanks. I'm looking at R mainly, and looks like I might have to mostly spin my own algorithm. I'll keep investigating. |
|
Nov 18 |
comment |
Help needed with the rendering of QGIS Heatmaps Did the lower SD affect processing time? |
|
Nov 18 |
comment |
How do I compute v.kernel maps in less than 16 hours? Do you know of any products that use this faster algorithm? |
|
Nov 17 |
comment |
How do I compute v.kernel maps in less than 16 hours? Yup, I think line 403 is where it traverses the output grid and then does spatial queries to see who is nearby--if I'm reading correctly. |
|
Nov 17 |
comment |
How do I compute v.kernel maps in less than 16 hours? That is an interesting article. Seems like input-centric has advantages where you don't have a good index or when you have far more points than output grid squares, but that's beside the point, I guess, since you found great speed advantages with the FFT. Regrettably, my math education doesn't extend beyond a Mathematics BA, so this is challenging. Anyway, the comments in v.kernel's main.c (trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c) indicate use of a "moving kernel", so I wonder if GRASS uses the output-centric method? |
|
Nov 16 |
comment |
How do I compute v.kernel maps in less than 16 hours? Concerning your comments about algorithm efficiency: I'm not sure kernel density maps are as fast as you think? I've also tried with Quantum GIS's built in heatmap feature, and it's even slower. And conceptually, this seems like an O(n^2) difficulty problem? |
|
Nov 16 |
awarded | Critic |
|
Nov 16 |
comment |
How do I compute v.kernel maps in less than 16 hours? Correction: it's taking closer to 25 minutes to do the v.kernel on the high resolution small area. |
|
Nov 16 |
comment |
How do I compute v.kernel maps in less than 16 hours? I guess I'm still lost here. I selected a pretty small region of the map, probably about 5% of the total map area. It was not "hot" on the original heatmap, closer to being one of the weaker areas. I ran v.kernel, and it took about 1 minute. Then I increased the resolution by about tenfold in the GRASS region. Re-running v.kernel on this small area, it's going to take about 10 minutes. So I'm still not clear where you are coming from on how increasing the resolution is going to make this faster. |
|
Nov 14 |
awarded | Commentator |
|
Nov 14 |
comment |
How do I compute v.kernel maps in less than 16 hours? OK, thanks. Are you recommending perhaps a random sample of data, then slowly build up the sample size and grid size? But even then, what am I looking for? The right v.kernel parameters to produce the desired output in an acceptable amount of time? The right balance between # of points and grid size? |