1 Data - N Annotations

[stonier]

Initially we were talking about 1 annotation, 1 data, but this would be a very useful addition.

[stonier]

Two considerations here:

• We aren't doing meshes initially, so saving size on redundant copies isn't that important.
• Having 20 doors - if you change one property of the door, you have to update each of 20 copies.

[corot]

Current implementation allows 1-N scheme, though we still have no use-cases for it. Till now, our annotations are so lightweight that decoupling doesn't bear any advantage. But hopefully this will change when people start using this for more sophisticated stuff.

[stonier]

:+1:

[corot]

Not sure where I saw that current implementation allows 1-N scheme; it's not true!!! We have a single id for annotation and a single id for data. So how the hell can we have 1-N like this?

On annotations, we need annotation.id + annotation.data_id, the second matching ONE data.id.

This forces important changes in the code, so we really need a good reason to do it!

[jihoonl]

Separation between annotation model and world relation will definitely help in many ways.

if it is 1-1, it would be hard to use same annotation model on the other map.

Similar to @stonier's example, let's assume a polygon object is created and user would like place this polygon on a multiple locations and multiple map. If it is only 1-1 matching, the polygon model would be hard to reuse and it would store the same copy multiple times.

Another usecase is map annotator application, the first design of map annotator includes predefined shapes like table, pickup, and walls. If model get separated, user can select and use a user-defined model stored in database instead of shapes already pre-defined in map annotator.

I think annotating world is like generating Scene Graph. Like ROS draws robot from /base_footprint rather than /map frame, all the model and world relation should be independent.

[jihoonl]

Reference Scene Graph : http://en.wikipedia.org/wiki/Scene_graph

[stonier]

That's an interesting link.

[corot]

Almost done, but it's still not supported by the import/export database file

[jihoonl]

While thinking about the relation between annotation and data, I am questioned the following. These are not for v0.1 development but for long-term view discussion.

Is Room annotatable?

For example, assumes that annotating the Inno Room where has Marcus's Desk, * Daniel's Desk* and Vending Machine. How the current design should represent this?

Can World Canvas represent the relation between two annotations?

Robot is located at Inno room in RnD Office in Namsung Plaza 6th floor. It need to go to KC's office in Yujin Headquarter in Namsung Plaza 12th floor. Can World Canvas represent relation between Inno room and KC's office? Something like the following.

This will allow to generate "global global" path plan something like

Marcus's Desk -> Inno Room -> Rnd Office entrance -> 6th Elevator -> 12th Elevator -> Yujin Headquarter Entrance -> KC's Office -> KC's desk.

Would it be feasible? Or too ambitious?

[corot]

Interesting, but this goes belong the basic 1 Data - N Annotations scheme, so I'll close this one (already implemented) and open a new issue