Timeline for About speed, commitChanges too slow. How avoid this?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 14, 2016 at 15:54 | vote | accept | Juanma Font | ||
| Dec 14, 2016 at 13:47 | comment | added | mgri |
Ok, if you are sure of that (i.e. only one more point within 15 m), you may indiscriminately use nearestNeighbors() or intersects() (but I think that with intersects() you can avoid any oversight). Therefore, tell me if you don't know how to populate an empty memory layer and I will edit my answer to help you (don't forget to "accept" it as answer if it helped you ;) ).
|
|
| Dec 14, 2016 at 12:51 | comment | added | Juanma Font | In the original data source almost all the points are duplicated, and I have verified that always the second duplicate point is less than 10m (almost superimposed), to avoid working with many points I established the limitation of 2 points and 15m, 2 points because nearestNeighbors() returns the point itself and the closest one (I test this so). None of the original points are triplicated or more. | |
| Dec 14, 2016 at 12:40 | comment | added | Juanma Font | Thanks very much, I'm gonna try with your code and try to populate layerB (not deleting). Thanks for the link ;) about speeding. | |
| Dec 14, 2016 at 11:13 | history | edited | mgri | CC BY-SA 3.0 |
improved formatting
|
| Dec 14, 2016 at 11:04 | history | edited | mgri | CC BY-SA 3.0 |
edited coding
|
| Dec 14, 2016 at 10:53 | history | answered | mgri | CC BY-SA 3.0 |