2D tags are a lot more accessible to developers who don't eat matrices for breakfast. If the camera is orthogonal to the tag plane, transformation matrices are a not so necessary complication (there are many such application in the real world, e.g. all the tabletop interfaces), when most of the time, all we care about is the center of the tag.
However we'd probably making our life as maintainer more complicated than it needs to be, because we could just do everything in 3D, and just give acces to a 2D project, that would by default assume an plane parallel to the image plane for example. Then we can get rid (internally) of 2D filtering, users can have "tag assemblies" in 2D too, we remove the inconsistance between tagIds as int and as "tag_##" strings...
We'd just have to check that the 3d estimation wouldn't hit performance too much in case we don't (really) need it.
2D tags are a lot more accessible to developers who don't eat matrices for breakfast. If the camera is orthogonal to the tag plane, transformation matrices are a not so necessary complication (there are many such application in the real world, e.g. all the tabletop interfaces), when most of the time, all we care about is the center of the tag.
However we'd probably making our life as maintainer more complicated than it needs to be, because we could just do everything in 3D, and just give acces to a 2D project, that would by default assume an plane parallel to the image plane for example. Then we can get rid (internally) of 2D filtering, users can have "tag assemblies" in 2D too, we remove the inconsistance between tagIds as int and as "tag_##" strings...
We'd just have to check that the 3d estimation wouldn't hit performance too much in case we don't (really) need it.