On your problem, I used 'non-driving' constraints (on both X and Y) and name them.

Then you can 'trace' the position of that point. The only risk is user delete it.

I thought of that originally, and in most cases, it might be an acceptable solution. In fact, I'd bet there will almost always be a 'driving' coincident constraint will be available and I could repurpose that, since the user will likely always create closed shapes for templates.

I may use that for now. The only problem is a 'non-driving' constraint can be made to 'drive'. And none of the constraints are really intended for this purpose, driving or not.

Still, I really feel an 'empty' constraint is best - it cannot ever incur any computational overhead nor have any unintended effect on the sketch itself. I just don't know if something like that would be useful to the community as a whole.

1. Is there any other feasible way to create permanent references (by a unique ID or otherwise) to a point in a sketch that will always remain, even if the sketch gains / loses points or that point moves?

2. Can I be sure that when the SketchObjectPython sees a change, that change will be atomic? That is, it won't possibly include multiple changes at once (e.g., a new point, plus an existing point moving).

3. Would it be possible to create an "empty" constraint that applies to a specific point? It's a constraint that does nothing but exist on a point (or edge).That would provide an excellent way to reference sketcher geometry externally by a unique, unchanging reference and save a lot of the hassle I've described above.

This tag will stay the same until you delete the object. Now you close FC and start it again. That object will get a different uuid on restoring, this new uuid will remain the same until you delete the object or close FC.

This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example): example

Maybe Tomorrow (v.19): Maybe we get some ways to make a geometry not move at all.

2) Not my arena. I think that one is for microelly

3) I think this is an inferior solution to 1). I do not think this is the way. If 1) does not fulfil your needs, let me know why and we can find a solution for your problem.

This is a method to define a fix point in the sketch with constraints x y AAA,BBB
Whenever a user deletes it it will be reconstructed:

Hmm.. Maybe not quite what I'm after.

I don't exactly want the point itself to be permanent... I just want to make sure I can always find that point using a consistent, unique identifier, no matter what the user does with the sketch. That is, the index may change if the user adds / deletes other points. The location changes if the user moves it. But in the end, the point itself still exists. I just need a way to identify that point consistently from outside the sketch.

Look, for example, at the sketch template I showed previously. It might represent a single roadway lane of a two-lane road (a typical roadway lane is 12 feet in the US). The sketch origin is at the road's center and the point at the far right would represent the right edge of pavement. I would want to name it 'EOP_RT' so I could permanently refer to it outside the sketch, and so it has a name that's meaningful to the user.

But how do I ensure that the point that I've named is always going to be the same point?

That's why I had the idea that maybe an 'empty constraint' attached to the point might be a solution. It doesn't constrain anything, it just provides a consistent way to reference the actual point from outside the sketch, unless, of course, the point itself (or the constraint) is deleted.

My example defines this point by two named constraints AAA,BBB.
If you delete the point or the constraints, with the next method call the deleted objects are recreated may be with other ids
but using the constraints names you can find the point-geometry and can use it by updating/replacing other constraints which should refert to this point. I do not have one constraint but two for the point. In your example we can call the constraints EOP_RT_X, EOP_RT_Y.
And the values for the constraints can come from some global database.

This tag will stay the same until you delete the object. Now you close FC and start it again. That object will get a different uuid on restoring, this new uuid will remain the same until you delete the object or close FC.

This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example): example

Maybe Tomorrow (v.19): Maybe we get some ways to make a geometry not move at all.

I think I had a request to make the tag consistent (for Sketch geometries) and survive file open and close

I try methods to record these tags and upon file reopen, to match the id against the old and new tag - but this is tedious and make the whole process slow.

I know Realthundar have something in his branch that may tackle im another way, but it seems a consistent tag is more direct solution for sketch geometry.

This uuid is not Sketch specific, but FC global, you won't find a repeated number in any other geometry in FC.

Tomorrow (v.19): If I manage to make Python defined geometry extensions, you will be able to associate whatever you like to a Sketcher Geometry AND this will be serialized.

This is an example of how this could work (the extension is NOT Python defined in this example):
example

This is exactly what I need. Using existing constraints (like microelly outlined) or reference constraints (like paullee suggested) is certainly less preferable. I don't care what happens to the point - whether it gets moved, re-ordered, or deleted. I only care that, so long as it exists, I can identify it without fail using an identifier that is serializable and unique within the scope of the sketch.

In fact, now that I think of it, it's likely going to be necessary to be able to apply a name for every point in template sketches like this... Then I can use the vertex name to provide names for loft edges in the 3D model.

So is your example serializable at the moment? Can I use it in the interim until geometry extensions get figured out? (BTW, I thought geometry extensions were a really fantastic idea when I first read your post!)

I think I had a request to make the tag consistent (for Sketch geometries) and survive file open and close

I try methods to record these tags and upon file reopen, to match the id against the old and new tag - but this is tedious and make the whole process slow.

I know Realthundar have something in his branch that may tackle im another way, but it seems a consistent tag is more direct solution for sketch geometry.

I am not sure I understand all the consequences/implications of serializing a uuid and restore it in the current implementation. I tend to think I will get into trouble (get a higher chance of the new uuids not being unique). This I will have to study and understand first.

A good method for recording whatever together with a geometry will be geometry extensions.

This is exactly what I need. Using existing constraints (like microelly outlined) or reference constraints (like paullee suggested) is certainly less preferable. I don't care what happens to the point - whether it gets moved, re-ordered, or deleted. I only care that, so long as it exists, I can identify it without fail using an identifier that is serializable and unique within the scope of the sketch.

In fact, now that I think of it, it's likely going to be necessary to be able to apply a name for every point in template sketches like this... Then I can use the vertex name to provide names for loft edges in the 3D model.

So is your example serializable at the moment? Can I use it in the interim until geometry extensions get figured out? (BTW, I thought geometry extensions were a really fantastic idea when I first read your post!)

The uuid is not serializable. See reply to paullee.

To be honest with you, I would center in another part of the development until the geometry extensions get merged for two reasons: 1) Geometry extensions will allow you to have whatever you want to have, 2) It is likely that together or immediately after the geometry gets merged, I will include part of the Realthunders idea, which will most likely provide you with a sketch geometry id.

If you do not feel like waiting, of course, you may try to adapt the existing uuid, but it is not going to be straightforward (serialisation), I fear.

To be honest with you, I would center in another part of the development until the geometry extensions get merged for two reasons: 1) Geometry extensions will allow you to have whatever you want to have, 2) It is likely that together or immediately after the geometry gets merged, I will include part of the Realthunders idea, which will most likely provide you with a sketch geometry id.

If you do not feel like waiting, of course, you may try to adapt the existing uuid, but it is not going to be straightforward (serialisation), I fear.

I can probably wait. There's plenty on the to-do list for the moment, anyway. All the same, I could use constraints as a proxy as an interim solution, if I really need to test that before geometry extensions are ready.