Gps Coordinates
Jiandao Amazona
Hi,
I have created some points in Python that I would like to import in Grasshopper. The excel file has 3 columns that represent the x,y,z of each point. How can I import these coordinates in order to display the points (in the order that are displayed in the excel file)?
Please help, what is wrong with this tool in AC25? The project has to move to construction phase, and I must get to a solution to have the correct coordinates in the Topo format X: 000.000.000 / Y: 000.000.000
I don't think you can add an offset to the survey point in 25, it always sets the real world 0; 0, so to make it work the coordinates it shows have to actually be a negative of what you want your project origin to be.
jan_filipec's workflow is absolutely correct. The new Survey Point in Archicad 25 will require some changes in the workflow. The main idea is to model the project close to the origin, and move the Survey Point to the position according to the required coordinates for the project.
We have problem about Coordinate tool. We placed our land and project according to the Map engineer documents World coordinates. We moved our Survey Point close to the Building and the Land. We set the survey points location as described above solution already.
We gave the Coordinates of somethings and property Boundary lines with Coordinate dimensions 25 object. It shows them According to the Project Orgin. Everything was good. It gives corrects coordinates.
Just wondering how to adjust the coordinates from linked models?
They seem to use project base point for site and building model, therefore they are off.
What can I do to realign?
Cheers
image19201019 211 KB
Thanks Ehsan. Sure.
On the left is a Revit site model with a building file linked in.
The building model is actually located on the toposurface, but when I reference that linked models mass, the preview is obviously lower. It seems as though it is reading the project base point location of both models.
Do i need to somehow specify the shared link coordinates?
This is a common problem of too big numbers. There are only so many digits one can use in a float, computer number. In civil engineering this can easily become a problem when the coordinates can be in the millions. Someone better versed can correct me and explain it more accurately.
This problem just gets weirder. I was showing someone the model, and this time it looks fine
image939667 96.8 KB
My trick to see if the model has coordinates that are too high is to derive an outline from it. But that also looks fine. But if I take the lines and triangulate them, the world coordinates problem comes back.
image757658 114 KB
I'm Judy from Revit support and I see you've got a question about what when wrong when you acquired coordinates from a linked architectural model. I'll see if I can answer your question, and I'll need to get some information from you first.
If you still have the original file that they sent you, and a little free time, you might try creating a new project (not your current one) and linking the architect's model using different options to verify to see whether the PBP is the same in your model after you acquire the coordinates. That might give you some insight into the issue. If you do this test, I'd suggest creating a new blank project for each different attempt, as once you acquire coordinates, you can't really "un-acquire" them.
So... that worked! As you mentioned, initially I inserted the architectural model using "Auto - Origin to Origin" then acquired the coordinates. My elevation was 2ft off. I also tired "Auto - Center to Center" and same result.
Does this mean I should use "Auto - Project Base Point to Project Base Point" over other options? Correct me if I am wrong but I thought insertion point does not really matter since I am acquiring coordinates from the inserted Arch model so my coordinates will adjust to match theirs. So still not sure why insertion point affect the acquired coordinates?
It seems like we, as an industry, were trained back in 2009 to link models as Origin to Origin, and I don't believe linking Auto - PBP to PBP was even an option until more recently. Does anyone know when Auto - PBP to PBP was introduced, or was it always an option? This method seems to be best way to link models in most cases, now that we understand the possible discrepancy when acquiring coordinates after linking Origin to Origin.
Just jumping in to support this idea. I found the template picking in cryosparc to be very efficient for some projects. It would be really great to export the coordinates for extraction e.g. with relion.
It is after some iterations of heterogeneous and homogeneous refinement, yes. Therefore being able to track back the original coordinates would be helpful.
However, I can fully understand your limited motivation if structura will implement an export job soon.
Thanks for your efforts so far!
I have a relatively simple (I believe) macro that asks the user for an x coordinate and a y coordinate as input (among other things) and from there draws a rectangle based on these coordinates, measures the content of the rectangle and then iterates through the slides of an AVI movie. This works fine for my purposes at this point in time.
is it possible in Napari to get the coordinates of the mouse when it is clicked over an image/labels layers?. In particular, I am interested in implementing a method that would be triggered when I click over an image/labels layers, and inside that method I would use the coordinates of the mouse to extract information about the pixel at that particular locations, e.g., image[x, y], labels[x,y], and then show some additional information on the status bar (is it possible to modify/append the text shown on the status bar?).
Hi Huan!
When I try to append a callback function to mouse_drag and print coordinates of event (event.pos), I get the coordinates of a view (or scene?), and not those of a pixel in the image.
Am I doing something wrong? How to get the coordinates of a pixel?
layer.position and layer.coordinates are deprecated (#2443). Instead, use viewer.cursor.position for the position in world coordinates, and layer.world_to_data(viewer.cursor.position) for the position in data coordinates.
I have done some searching online but I am not entirely sure how to convert the fiducial coordinates (in mm) from RAS to LPS using Slicer (assuming its possibile). Hoping someone can point me in the right direction.
The print returns the exact same position as went in so obviously I'm not doing this right, but I have tried a number of different constellations but with pretty much no result; the coordinates remain the same. I have also tried let myPoint = CGPoint(x: UIScreen.main.bounds.maxX, y: UIScreen.main.bounds.maxY) but same there; no conversion.
Anyway, if you really want to do something like "put a square in the top-left corner of the screen", then you can take the point in the view's frame and convert it to scene coordinates and set the square's position to that.
MNI coordinates determined using SPM2 and FSL/FLIRT with the ICBM-152 template were compared to Talairach coordinates determined using a landmark-based Talairach registration method (TAL). Analysis revealed a clear-cut bias in reference frames (origin, orientation) and scaling (brain size). Accordingly, ICBM-152 fitted brains were consistently larger, oriented more nose down, and translated slightly down relative to TAL fitted brains. Whole brain analysis of MNI/Talairach coordinate disparity revealed an ellipsoidal pattern with disparity ranging from zero at a point deep within the left hemisphere to greater than 1-cm for some anterior brain areas. MNI/Talairach coordinate disparity was generally less for brains fitted using FSL. The mni2tal transform generally reduced MNI/Talairach coordinate disparity for inferior brain areas but increased disparity for anterior, posterior, and superior areas. Coordinate disparity patterns differed for brain templates (MNI-305, ICBM-152) using the same fitting method (FSL/FLIRT) and for different fitting methods (SPM2, FSL/FLIRT) using the same template (ICBM-152). An MNI-to-Talairach (MTT) transform to correct for bias between MNI and Talairach coordinates was formulated using a best-fit analysis in one hundred high-resolution 3-D MR brain images. MTT transforms optimized for SPM2 and FSL were shown to reduced group mean MNI/Talairach coordinate disparity from a 5-13 mm to 1-2 mm for both deep and superficial brain sites. MTT transforms provide a validated means to convert MNI coordinates to Talairach compatible coordinates for studies using either SPM2 or FSL/FLIRT with the ICBM-152 template.
The coordinates package provides classes for representing a varietyof celestial/spatial coordinates and their velocity components, as well as toolsfor converting between common coordinate systems in a uniform way.
The best way to start using coordinates is to use the SkyCoordclass. SkyCoord objects are instantiated by passing in positions (andoptional velocities) with specified units and a coordinate frame. Sky positionsare commonly passed in as Quantity objects and the frame isspecified with the string name.
SkyCoord and all other coordinates objects also supportarray coordinates. These work in the same way as single-value coordinates, butthey store multiple coordinates in a single object. When you are goingto apply the same operation to many different coordinates (say, from acatalog), this is a better choice than a list of SkyCoord objects,because it will be much faster than applying the operation to eachSkyCoord in a for loop. Like the underlying ndarray instancesthat contain the data, SkyCoord objects can be sliced, reshaped, etc.,and can be used with functions like numpy.moveaxis, etc., that affect theshape:
This form of transform_to also makes itpossible to convert from celestial coordinates toAltAz coordinates, allowing the use of SkyCoordas a tool for planning observations. For a more complete example ofthis, see Determining and plotting the altitude/azimuth of a celestial object.
f448fe82f3