Different Coordinate System for ReferenceIntersector?

[kinjal]

Dear all,

Since a few days i facing a rather strange issue. ReferenceIntersector started returning off-the-chart values (Eg: Referring a floor that is at elevation of 22ft per ProjectBasePoint, it reported -24ft in Reference.GlobalPoint & it's geometry coordinates) for a particular Revit project (works well for other projects).

My understand, with which i am battling the problem: ProjectBasePoint (PBP) and SurveyPoint (SP) are two exposed coordinate system which are ‘linchpined’ on internal coordinate system (aka Origin Point, Project Internal in different articles).

Particulars related to the problem (w.r.t the troubled projects):

• Most of the Revit API (for instance, Elevation value of a Level) reports value that can be reconciled with PBP in Revit UI. However, ReferenceIntersector seems to be returning value that i couldn't reconcile (-24ft as i mentioned for instance).
• A functional Revit thread discusses about Topography affecting coordinate system. 
  Indeed, all the the troubled projects do host topography. Maybe a cause or may as well be a coincidence. Though to report.
• Value returned by ReferenceIntersector, is equivalent to Spot Elevation (origin = Relative, Relative base = CurrentLevel) value reported in 3D View.

What i am looking for is:

• (for understanding) Can someone shed flood light on the origins and mechanism around it? 
  What value Relative SpotElevation is meant to report when set to CurrentLevel and viewed in 3D View? When a SpotElevations (with origin as SP, PBP, and Relative) report three different values in a 3D or Elevation view, how are they associated with each other, how can one reconcile one another?
• (for confirmation) Is it indeed true that Topography elements in main model messes with Revit Origin systems? Ref: forum thread i mentioned above.
• (core question) Jeremy said in this blog, “I'm 99.9% sure it's PI” (about project internal being used for API interactions). Does ReferenceIntersector falls into the 0.1% of items?
• (core question) Most importantly, what handles do API user have to reconcile values returned by ReferenceIntersector with other api functions?
• (for knowledge) Do anyone know of other (other than ReferenceIntersector) API constructs that would use coordinate system/origin other than the main internal one which is used by rest of the API functions?

I have tried to abstract crux of complex situation, please let me know if i have missed any important aspect or if more information in required.

Any explanation, relevant reference links will be hugely helpful and highly appreciated. Looking forward.

Best regards,
Kinjal.

[L.Maas]

I asked moderators if they can move this thread to the Revit API forum as I expect that you will have better chance to get answers to your questions.

[kinjal]

Oh i am so sorry. i thought i was posting it to Revit API forum.

Thanks Louis. I can re-post it to API forum if moving is a lot of trouble.

[kinjal]

Dear all, 

I think this post is lost in the queue before it could have it's share of attention.

Can someone please come into this? @jeremytammik, if you don't mind, can you have a look at the (main) post?

Of course, do let me know if anything is missing or unclear.

Thanks in advance.

Best regards,

Kinjal

[jeremytammik]

Please submit a minimal reproducible case so this can be discussed with and analysed by the development team:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Please provide all the required items.

Thank you!

Cheers,

Jeremy

[kinjal]

Hi Jeremy,

Thanks for your response. Silly enough, but the problem is solved now. Sorry for asking.

I'd lay it out for someone who might benefit from it.

• Topography is not to blame: In last few days i narrowed down the problem to "projects that have moved unclipped PBP". Topography blamed in the functional forum i referred earlier is probably due to wrong conclusions.
• Yesterday, as suggested by Jeremy, i started preparing a minimal model & plugin to share here. While doing so, i accidentally noticed that a portion i didn't suspect at all was returning unexpected values.
  It was Level.Elevation.
  A quick check at Remarks in Api documentation revealed it all. "This property retrieves or changes the elevation above or below the ground level of the project."
  
  For many days (and many active debugging hours) i was deceived by the debug values that pointed finger at ReferenceIntersector for reporting values of some other world. It was interesting setup that led to it, but it is unique to the situation so i will skip that part.

Key learning (for those didn't notice it earlier, like myself)

• Level.Elevation returns value relative to 'ground level', so essentially it is not appropriate (for most cases) to use it for computation that involves most of other positional values returned by API (which are not relative to ground level).
  Instead use, Level.ProjectElevation! (relative to internal project origin)
• 'Ground level' is what you set in Level Type's Elevation Base parameter. PBP or SP.

Offshoot questions

• Like Level.Elevation, are there other similar (=with seemingly absolute property-name but returning relative values) properties/functions in API that returns value relative to anything other than internal project origin?
• When you place a SpotElevation tag (origin = Relative, Relative base = CurrentLevel) in a 3d view, conceptually, what it is supposed to return?
  (It seems to be mapped to internal project origin in this case, but would be good if someone can shed better light)

Thanks Jeremy for being there.

Best regards,
Kinjal.

[jeremytammik]

Dear Kinjal,

Thank you very much for your research, explanation and appreciation.

Yes, indeed, creating a reproducible case may well solve the issue at hand:

http://thebuildingcoder.typepad.com/blog/2017/01/virtues-of-reproduction-research-mep-settings-ontol...

I have heard many dozens of examples of this.

Vary glad to hear the issue is resolved now, and lessons learned.

Cheers,

Jeremy