Well, it is basically 'tree of a trees'. Imagine you are working with sum queries. Then lets create for each x coordinate ordinary sum query segment tree. Now you can compute answer for each query/modification for a [math]\mathcal{O}(n \cdot \log m)[/math] time, where [math]n[/math] is number of [math]x[/math] coordinates and [math]m[/math] is number of [math]y[/math] coordinates in your table. How to achieve a [math]\mathcal{O}(\log n \log m)[/math] complexity? Easy, now you need to build a segment tree over [math]x[/math] coordinates to substitute '[math]n[/math]' for '[math]\log n[/math]'. So, for each vertice of the [math]x[/math]-coordinate (outer) segment tree lets store a segment tree on [math]y[/math] coordinates that corresponds to strip [math][x_l, x_r][/math], meaning that it will store for some fixed [math]x_l, x_r[/math] all the sums of rectangles [math][x_l, x_r] \times [y_l, y_r][/math] where [math][y_l, y_r][/math] is a valid atomic segment tree segment. To do so you will need to sum-up two segment trees without going for naive solution or use partial sums for subqueries.

Now while answering queries you basically first traverse by outer tree until you find [math]\mathcal{O}(\log n)[/math] segments that fits your [math]x[/math]-part-of-a-query and then for each such segment you are traversing in corresponding segment tree until you find a set of segments that match your y-part-of-a-query. Regarding update, AFAIK 2D-tree works only with a point-wise updates. You should first update inner trees traversing from a leaf to the root of [math]x=x_q[/math] tree, then traverse from a leaf to the root of a tree that is parent in outer tree of [math]x=x_q[/math] tree and so on having totally to visit [math]\mathcal{O}(\log n \cdot \log m)[/math] nodes of the segment trees.

Please refer to the 'first', 'next' and 'then' more as explanatory words since from implementation side of view both querying the 2d segment tree and modifying it will require just a one recursive dfs.

As an application advice: don't do overengineering. Before writing a 2D-segment tree you should consider using partial sums, 2D-Fenwick tree or [math]\mathcal{O}(1)[/math]-static-rmq for 2D since all of them are like 10[math]\times[/math] shorter and usually faster. For example, 2D-sum-segment-tree [which we were considering] is easy to substitute by 2D-Fenwick, and if we don't have modification queries we should rather solve sum queries for [math]\mathcal{O}(1)[/math] than [math]\mathcal{O}(\log n)[/math] using partial sums. If you have queries on minimum element in rectangle without modification you can use binary jumps to answer a query in [math]\mathcal{O}(1)[/math].