Coordinate systems

[doofy]

I'm thinking of writing my own Entity Relationship software in C#. I've
seen some of these, and some drawing programs too, where it seems you
can just keep adding stuff at any border and you always have room, like
an ever expanding palette.

I'm wondering if these programs internally go by a coordinate system
where the center of the "universe" is 0,0, rather than the upper left
being 0,0 (as GDI does). Then, anything anywhere can be plus or minus
and there is no boundary. so, one object in the upper left might be at
-1, +1, and an object in the lower left might be at -1, -1, and so on.

Does anyone know if this is the case?

Or are all objects automatically shifted around when something is added
outside the boundary?

 

[christery]

I'm thinking of writing my own Entity Relationship software in C#.  I've
seen some of these, and some drawing programs too, where it seems you
can just keep adding stuff at any border and you always have room, like
an ever expanding palette.

I'm wondering if these programs internally go by a coordinate system
where the center of the "universe" is 0,0, rather than the upper left
being 0,0 (as GDI does).  Then, anything anywhere can be plus or minus
and there is no boundary.  so, one object in the upper left might be at
-1, +1, and an object in the lower left might be at -1, -1, and so on.

Does anyone know if this is the case?

Or are all objects automatically shifted around when something is added
outside the boundary?

Where the 0 point is is mostly for your convinience ()top/left is
standard), I´d go for 4/5 levels, x,y,z and time/duration, the last
one for taking things away but keep them in the database,,, and being
able to see enterd deleted... or maybe start/stop maybe easyer to use
two values for start/stop. See it as building a ancester tree, the z
might not be obvious but may be used for zooming in on details
constraints, pk, index whatever...
//CY

 

[Peter Duniho]

I'm thinking of writing my own Entity Relationship software in C#. I've
seen some of these, and some drawing programs too, where it seems you
can just keep adding stuff at any border and you always have room, like
an ever expanding palette.

I'm wondering if these programs internally go by a coordinate system
where the center of the "universe" is 0,0, rather than the upper left
being 0,0 (as GDI does). Then, anything anywhere can be plus or minus
and there is no boundary. so, one object in the upper left might be at
-1, +1, and an object in the lower left might be at -1, -1, and so on.

Does anyone know if this is the case?

I doubt that there's actually a good general answer to the question.
There is no particular reason to implement it one way versus the other,
and so it's entirely possible that of the various programs that implement
functionality like that, they all do it differently.

Or are all objects automatically shifted around when something is added
outside the boundary?

Define "automatically shifted around". After all, for something like what
you're talking about, there's no good reason that the objects must
maintain specific coordinates relative to some world coordinate system
anyway. For example, if an object's position is always defined as
relative to some other object, except for "root" objects, then the program
could just layout all the objects when it's time to draw. It could cache
some information to make this easier/faster, but otherwise wouldn't need
to store coordinates for each object at all.

They could of course do something like what you suggest, and that would
work fine too. In that case, it's likely that the code would use the
Graphics.Transform property when drawing in order to get things to draw in
the correct location, according to the state of the UI and the object
graph. That would support scrolling (if desired) and scaling (zoom in and
out, or just auto-fit the entire graph so it always can be drawn within
the available space.

Basically, the question you're asking is somewhat vague. The exact
internal representation of the data would depend on a variety of things,
some related to the specific drawing implementation, and some not (for
example, the data structure might have features that are needed to support
higher-level features in the program, as opposed to the visual
representation).

And of course, all of the above ignores the "model-view-controller" and
related design patterns where the model data structure has little or
nothing to do with how the data is represented visually to the user
(except when the model data is, of course, specifically representing
visual data).

Pete