Shared Coordinates Incompatible

[Dale.Bartlett]

Further to my previous posts regarding Shared Coordinates and compatible systems:

http://forums.autodesk.com/t5/revit-api/shared-coordinate-system-definition/m-p/5928300/highlight/tr...

http://forums.autodesk.com/t5/revit-api/shared-coordinates-remove/m-p/5961546/highlight/true#M13390

I have drawn some conclusions:
In Real World, a Coordinate System comprises Origin (XYZ) and Rotation
In Revit World, I believe that a Coordinate System comprises Origin (XYZ), Rotation, and a GUID defining its "compatibility". This is passed from document to document via the Acquire/Publish Coordinates process. I'd suggest that a source file name is not part of that compatibility group.

In my testing I set up a series of files, based on the same templates (Autodesk default). Rather than Acquire, I used Specify Coordinates At Point. These files could also not be liked by Shared Coordinates because of the "do not share the same coordinate system" error. This was regardless of both files having the same coordinates specified at the same point; so the physical location is irrelevant. My assumption from this is that "Specify Coordinates" generates a new GUID each time.

Given the number of blog posts and forum questions regarding the Revit Coordinate System, users clearly find it to be an unnecessarily complicated structure. From my experience, we have had many hours lost to resolving coordinate issues that would be trivial to manage via the api.

My questions are:
- Are my assumptions correct?
- Is there any way to resolve the incompatible coordinates error?

PS I began a new post as the previous marked solution was not really such, and I hope 2017 may have someting new.

[Anonymous]

check out my reply in the other thread http://forums.autodesk.com/t5/revit-api/how-to-convert-autocad-point-to-revit-coordinates-using-revi... it doesn't address the shared coordinate Guids, but explains a little of my interpretation of the inner workings of the coordinate system. maybe there's a way to erase the shared coords Guid and set it up manually in the API?

[Dale.Bartlett]

Hi Scott, I did catch your other reply, thanks. I have very little hope of being able to re-set the Shared Coord GUID (if indeed there is one), but badly need a way to manage this system properly. Thanks for the reply.

[Dale.Bartlett]

"These files could also not be liked" - should be "linked" of course...

"someting" = "something" - hoo boy

[jeremytammik]

Dear Dale,

Thank you for your update and starting a new thread for this.

I took a look at the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'].

It has been marked as critical and assigned to a team and a sprint, so it is moving forward.

Furthermore, happily, I can report that the Revit development team is right now undertaking a major overview of all existing wish list items, prioritising and processing them in real earnest.

Therefore, now is a great moment to jump in, update that request, and point out its importance for you and the development community in general.

I took a look at the existing threads and cases related to this issue that you and Scott point to:

• http://forums.autodesk.com/t5/revit-api/shared-coordinate-system-definition/m-p/5928300 --> 11294063 [Shared Coordinate System - Definition] --> CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'] 
• http://forums.autodesk.com/t5/revit-api/shared-coordinates-remove/m-p/5961546 --> 11356339 [Shared Coordinates - Remove] 
• http://forums.autodesk.com/t5/revit-api/how-to-convert-autocad-point-to-revit-coordinates-using-revi...
• http://forums.autodesk.com/t5/revit-api/shared-coordinates-incompatible/m-p/6293171 --> 11746144 [Shared Coordinates Incompatible]

I started, but quickly realised that it is beyond me to effectively summarise what the problem and your exact need is.

Could you possibly do a couple of things to hopefully move this forward real fast?

• Summarise the issue from scratch, without referring to any previous threads, so that I can raise one single coherent issue with the development team.
• Provide a minimal reproducible case so they can easily understand, reproduce and analyse the issue, and also verify that whatever resolution is found really addresses your exact need: 
  
  http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b
  
  
• Provide a business case underlining the importance of this issue for you plus a list of all the developers who contributed to the threads listed above and are also clamouring for the requested functionality.

That would be great and a really big help.

Thank you!

Best regards,

Jeremy

[Dale.Bartlett]

Hi Jeremy,

Apologies for the delay in this reply. I have been too busy fixing coordinate issues...

Test example:

• Create 4 new Revit projects all based on the same template (Autodesk default Architectural)
• Add an AutoCAD origin marker origin to origin
• Create 4 simple walls in same position in each project

Source files for Shared Coordinates:

• SharedCoordinateSource01.rvt
• SharedCoordinateSource02.rvt

 Target files for Shared Coordinates:

• SharedCoordinateTarget01.rvt
• SharedCoordinateTarget02.rvt

 File 01:

• Open SharedCoordinateTarget01.rvt
• Link SharedCoordinateSource01.rvt - origin to origin
• For clarity, move link 10000 east and 5000 north (X, Y)
• Select link and acquire coordinates
• Save and close

 File 02

• repeat with
• SharedCoordinateTarget02.rvt
• SharedCoordinateSource02.rvt
• Save and close

Test results:

• Open SharedCoordinateTarget01.rvt
• Link SharedCoordinateTarget02.rvt - by Shared Coordinates

Link insert will fail with message:
The document and the imported instance do not share the same coordinate system.
Default center-to-center positioning will be used.

Test files for the above example are here:

https://dl.dropboxusercontent.com/u/20668879/SharedCoordinateTestFiles.zip

My Assumptions:
In Real-World, a Coordinate System comprises Origin (XYZ) and Rotation
In Revit-World, I believe that a Coordinate System comprises Origin (XYZ), Rotation, and a GUID defining its "compatibility". This is passed from document to document via the Acquire/Publish Coordinates process. I'd suggest that a source file name is not part of that compatibility group.
In my testing I set up a series of files, based on the same templates (Autodesk default). Rather than Acquire, I used Specify Coordinates At Point. These files could also not be liked by Shared Coordinates because of the "do not share the same coordinate system" error. This was regardless of both files having the same coordinates specified at the same point; so the physical location is irrelevant. My assumption from this is that "Specify Coordinates" generates a new GUID each time.
Given the number of blog posts and forum questions regarding the Revit Coordinate System, users clearly find it to be an unnecessarily complicated structure. From my experience, we have had many hours lost to resolving coordinate issues that would be trivial to manage via the api.

Via the API, it should be possible to specify the XYZ and Rotation at a datum point, and additionally guarantee "compatibility" with other models.

I hope this is sufficient to push the issue along.

Regards,

Dale

[Dale.Bartlett]

Hi Jeremy + Dev Team,

Any progress? Even if there is no open API (which there should be), an explanation of what gets pushed to a link file when Publish Coordinates is executed would be very helpful. Thanks.

[Dale.Bartlett]

Bad timing in the middle of AU2016, but here goes:

Any progress? Ask the experts?

Thanks , Dale

[jeremytammik]

Dear Dale,

Thank you for very much for your update and re-prompting.

I am sorry to say that this critical wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'] is still unresolved and I have not had any feedback yet on it from the development team.

Have you checked and made sure that an entry for it also exists in the Revit Idea Station, marked as an API issue?

If not, I would definitely recommend you do so.

Sorry about that.

The good news is that the development team themselves are looking actively at that, and there is no need for me or anyone else to act as an intermediary and manually funnel the information back and forth.

There is no need to resubmit the sample files and descriptions there, since you can point to this thread, the other related preceding ones and above all to the existing wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'] in the development database.

It might help to succinctly summarise the problem there as well, though, to ensure that it is clear what you are talking about.

Thank you!

Best regards,

Jeremy

[Dale.Bartlett]

Hi Jeremy,

Any progress with:

Wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system']?

We have large linear projects (metros) with several facilities (stations), that each contain several models from several different consultants. All models need to be accurately geo-referenced. Access to the underlying coordinate system would save countless hours of both initial work, and remedial work. If you want me to beg, I am more than happy to do so. Or send me the fellow's name who is in charge of coordinates and I will arrange a shipment of beer. Regards, Dale

[jeremytammik]

Dear Dale,

Thank you again for your update and re-prompting.

I am sorry to say that I have not heard any news yet on this critical wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'].

I am prompting the development team for some feedback.

I'll let you know as soon as I hear back from them.

Have you submitted it to the Revit Idea Station and ensured it has as many votes as possible?

Thank you!

Best regards,

Jeremy

[jeremytammik]

Dear Dale,

Do you have access to the pre-release of the next major release coming out?

The development team ask: Would the new SiteLocation.IsCompatibleWith() method solve this issue?

Can you check?

Thank you!

Best regards,

Jeremy

[Dale.Bartlett]

Thanks for the response Jeremy. I will look into the beta as suggested. SiteLocation.IsCompatibleWith() sounds promising, but if it only tells us that the two files are incompatible, with no means to change the compatibility, it may not be useful. I shall keep my fingers crossed and report back. Regards, Dale 

[jeremytammik]

Dear Dale,

Thank you for your update and clarification, which I added to the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system'].

Cheers,

Jeremy

[jeremytammik]

Dear Dale,

More feedback from the development team on your update this morning to the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system']:

The request listed here is very clearly (based on title and description) the ability to check for similar coordinates, not the ability to set them. As you are aware, we provide the ability to set the same coordinate system in models using publish/acquire coordinates. We cannot maintain the behavior of shared coordinates for two systems that look similar but are not identified as the same. I recommend that you check out the beta as there are a few other capabilities related to shared coordinates added to the API and determine if what is needed is available or not. If not, it would help to know exactly what is needed. If the request is essentially to rewrite how shared coordinates work in Revit that's not a request that's likely to be granted in the short term. If there are specific missing APIs that would help accomplish the workflow, we may be able to consider adding those going forward.

I hope you find everything you need to achieve your goals.

Cheers,

Jeremy

[Dale.Bartlett]

Hi Jeremy,

The response from the development team is not helpful. Whilst the wish-list item may have said to "check for similar coordinates, not the ability to set them", I think my description and supporting files are perfectly clear. Being told that two files do not have a compatible coordinate system (which the UI already does), with no explanation as to why, nor a means to fix it with the API, is clearly of no help. I am not asking for Revit's coordinate system to be rewritten, simply expose what is recorded when a coordinate system is "acquired". We have projects comprising hundreds of models, from multiple consultants, over several countries, with hundreds of Revit technicians of varying skills. Maintaining "compatible" coordinates without API control, and worse, with no knowledge of what constitutes a compatible system, is a job without end.

Perhaps I am missing something, but to summarise:

• Specify survey coordinates at a point in multiple files via the API
• Link those files to each other via Shared Coordinates
• All files position correctly
• Do NOT receive "do not share the same coordinate system" error

I appreciate your continued efforts to assist, but everything needed to understand and test this issue has been provided previously. I have yet to run up a VM to test the 2018 beta, but will do so. Thanks again.

[jeremytammik]

Dear Dale,

Thank you for your feedback and sorry to hear about your disappointment.

I'll add these notes to the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system' -- 11294063, 11746144].

Hopefully, we will all still be pleasantly surprised by the upcoming new functionality.

Cheers,

Jeremy

[jeremytammik]

Dear Dale,

I pass on a new response from the development team to your feedback on the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system' -- 11294063, 11746144]:

I appreciate the difficulty of managing many different files and keeping them in order. This is why we are continuously adding new APIs including for shared coordinates.

>I am not asking for Revit's coordinate system to be rewritten, simply expose what is recorded when a coordinate system is "acquired".

It is not clear to me what is meant by "expose what is recorded"

Acquiring coordinates does not simply record something - it sets up a permanent relationship between the two models, this includes update dependencies, etc. In other words, future changes to coordinate systems are propagated between the two files. This is a different operation from just matching/copying coordinates.

> Given that acquiring coordinates should simply comprise adding a new origin and rotation relative to Revit's native origin and rotation, then some other factor defines "same coordinate system".

As mentioned above, acquire coordinates is not the same as copying coordinates from one model to another. "Same coordinate system" is defined by actually having the same definition - this can only be accomplished by acquiring coordinates. To make sure I am 100% clear, "the same" is defined as having been added via acquire coordinates. This is a critical step as it's the only way Revit can ensure that the coordinates are truly the same.

Including some of the APIs available in the beta, at this point I believe we have APIs to sufficient for establishing this relationship - if there is something missing please let us know.

> Specify survey coordinates at a point in multiple files via the API

> Do NOT receive "do not share the same coordinate system" error

What is not clear to me is why acquire coordinates is not an acceptable solution since this is the supported approach to the problem of managing multiple files located in the same place?

Looking forward to hearing more and continuing this discussion once you had a chance to explore the pre-release functionality.

Thank you!

Cheers,

Jeremy

[Dale.Bartlett]

Apologies Jeremy, I appear to have missed this response (by some months). I will speak frankly, and not mean any offense. I am of the opinion that the developer providing this response has not worked in a complex production environment as I have described. What may be straightforward in a classroom or laboratory environment is very different in the wilds. I believe that I have described the needs clearly, and provided adequate test material, so am not going to repeat it all. If the developers think that Revit's shared coordinate system is perfectly adequate as-is, then they should Google the countless blog sites offering instructions.

Here is a simple business case example of how the API could be used: Any number of models could contain a single datum family with coordinate parameters. An addin could batch process all of the models, collect the coordinate data from the datum family, and apply that data to each shared coordinate system. Moving a facility in the real-world would be as simple as editing the datum family parameters and re-running the addin.  

Regarding the response:

"acquire coordinates is not the same as copying coordinates from one model to another. "Same coordinate system" is defined by actually having the same definition - this can only be accomplished by acquiring coordinates. To make sure I am 100% clear, "the same" is defined as having been added via acquire coordinates. This is a critical step as it's the only way Revit can ensure that the coordinates are truly the same." 

It makes no sense to say the only way to guarantee sameness is to acquire coordinates. What is acquired? GUID? Source file name? Origin? Why can't this be applied via the API?

Disclosure: I have yet to test R2018.

Thanks again for your continued support, I trust this will be considered constructive criticism and not just criticism.

[jeremytammik]

Dear Dale,

Thank you very much for your very valid and constructive response.

It comes as no surprise to me, and I frequently see a significant mismatch between the perspectives of the internal development team and the requirements of external add-in developers, so it is very important and very kind of you to help clarify so patiently and persistently.

I added it to the wish list item CF-3730 [API wish: determine 'doc and imported instance do not share coordinate system' -- 11294063, 11746144] and look forward to hearing what the development team responds this time around.

Cheers,

Jeremy