Hi, Iván Sánchez Ortega wrote: > Maybe we could calculate the convex hull of the changeset and use that with > some postgis magic. It should be quicker than comparing all the elements in > the changeset to the bbox, and would not produce so many false positives.
A considerable amount of brain power (99% of which sourced from Matt A.) has gone into determining the current bbox. For example, it needs to take into account not only the new position of a node that has been moved, but also the position it has been moved away from; same with ways. (If you monitor an area and something vanishes from the area, you will want to be alerted.) For relations, this becomes even more difficult; a lot of factors play into this equation. This does not rule out the application of a convex hull but at the time the hull is created, all objects need to be present for the algorithm, whereas the current method can simply expand the bbox with each edit and then forget about the object. It is going to be expensive, and it is not going to avoid false positives altogether, just reduce them... I think an external service that does nothing but compare "subscriptions" to changeset bboxes and the elements therein could be the solution; it can take all the time it needs, and maybe even apply some automatic segmentation to large changesets. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
