[PythonCAD] pythoncad points

Art Haas ahaas at airmail.net
Tue Jul 27 20:17:39 CEST 2004

On Tue, Jul 27, 2004 at 12:13:54PM -0500, Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Art Haas
> # on Tuesday 27 July 2004 10:53 am:
> >> If this is associative or relational drafting, then you have a circle with
> >> a center point, and a segment which uses that same point plus another
> >> point. If you move the circle, the segment moves. ?If you move the
> >> segment, the circle moves. ?(Actually, you are moving the point, which is
> >> being shared between entities.) ?Is this a behavior you were aiming for?
> note, the above is a scenario describing what happens IF this is 
> relational/associative drawing.
> >No. I just tried doing some simple moves things and only the one entity
> >I click on to move is moved. I made a circle, then drew a segment which
> >used the center point, then when to 'Modify'->'Move'->'Horizontal'. I
> >then made two mouse clicks to define the distance, then I clicked on the
> >circle. It moved, and the segment did not. Doing a move operation on the
> >segment left the circle in place.
> >
> >How are you doing the move? Are you drawing a box around the entities?
> You misunderstand.  My point is that pythoncad doesn't work that way.  That's 
> why I don't understand the reason for storing points in a table and 
> referencing the same point from more than one entity.
> I can understand storing points in a table, provided that each point is 
> referenced by one and only one entity.  But, then it is just an issue of 
> file-format human-readability.
> See the xml file referenced in my previous message.  It loads with an error 
> "Failed to add object: <Generic.segment.Segment object at 0x40c8f76c>: 
> Segment p1 Point not found in Layer."
> If I draw a circle, and then a segment which uses the circle's center as one 
> end, saving this drawing results in a point table with two entries.  This 
> implies that the entities are associated to the same point (e.g. dependent on 
> each other.)
Yes, because they segment endpoint is the same as the circle center.

> But, if I move the circle or move the segment, saving results in a point
> table with three entries.  This implies that the entities are independent.
They are now independent because neither of the segment endpoints falls
on the circle center.

> Unless I can select the point and use it to simultaneously move the circle 
> while moving just that end of the segment, the point association is 
> inconsistent.
> Are you are planning to support the movement of points in the future?  If so, 
> the interface to selecting and moving might be tricky.
I just took a look at the move code in 'Generic/move.py'. The
'move_objects' function is called when a boxed selection is called. It
omits the case when a point is included in the boxing, and that looks
like the root cause of this discrepancy. Adding a bit of code to this
function to retrieve all the entities associated with a point and move
them whether or not they were within the boxed region would not be a big
deal I believe.

> A related note, I just made a circle, and then did modify->move and selected 
> only the point (this is not possible with line segments.)  Pythoncad 
> duplicated and moved the point, but did not move the circle.  This also gives 
> me some ugly error messages on closing.
> Back to the associated points table.  If this is a disk-space efficiency 
> thing, I'm afraid it is a false economy.  Let's say you draw a pattern of 360 
> radial lines, each 1 degree apart with a common center point.  If the lines 
> each have two point stored at ~60 characters per point, then we have 359 
> points that wouldn't be stored if we used a shared point for one end of each 
> line (center of the pattern.)  That's only 21k saved before compression.
I don't think saving 21K is a bad thing. I have a personal beef against
file formats that have gotten larger and larger, and even today when
disk space is cheap, I want the file to be as small as I can make it.

> There is validity to both approaches, but if you aren't making pythoncad into 
> an associative program, I think associating common points is inconsistent 
> with that design philosophy and capable of opening several corner cases that 
> you wouldn't have if you simply treat each entity as self-contained.
> I think it comes down to this:  Do the entities own the points or the points 
> own the entities?  If the points own the entities and are capable of owning 
> more than one entity, the interface would eventually need to support editing 
> points as such and orphaning entities (giving them a new parent point.)

When trying to answer this, I want to say that "entities control points"
and I also want to say "points control entities", so I need to sit and
figure out when "entities control points" is more true than "points
control entities", and visa-versa.
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822

More information about the PythonCAD mailing list