OK, lets set aside the Here button and focus on what the OP wants to do, which is to set the location of an existing file to Armenia, Greece or somewhere in the USA. Let’s use your sample file for this.
So either the sample file I downloaded from Youtrack is not representative of the OP’s troublesome ones, or the OP’s files should allow location changes to stick if he follows the same steps and is using the latest release of Rhino 7.
Thanks for trying that. It seems like the sample file no longer represents a reproducible case. I reduced the OP’s file from the original 118 MB to something that still reliably reproduced the issue here but that is only 289 KB. I suppose that’s 4 hours of trouble-shooting down the drain…
Just to make sure, are you opening that file in Rhino 7 or in Rhino 8?
When I opened that reduced Rhino 7 file in Rhino 8, the issue went away but I was still able to reproduce the issue with the original user’s file on Rhino 8.
[FWIW; a link to the original file is in a private comment to the developer in that YT item, so they’ll have to use that, I guess]
-wim
As a side issue, could the “Here” button be relabelled to “Or here” or “Use default” or something and/or be moved, to show that it is an alternative to the list and not a button to cement a choice from the list?
I’ll restrict my comments to the Beta. I think the location crosshair introduced in R8 is better than the word “Here”. Let’s have it in both places.
I have a different problem with the new R8 “Now” position. I take it to mean that I want to set the time settings to the present moment. But by moving it next to the two time boxes and giving it the same appearance I am led to believe the boxes are buttons for setting the time to common values - which, of course, they aren’t because their content changes to reflect the current value. Its a papercut.
Incidentally, the daylight savings minutes scrollbox currently resizes from too small to see any content to ridiculously wide, depending on the width of the panel. Would be nice to see the width clamped.
The following may be too simple, but is a possibile cause of the OP’s difficulty.
@ar00302 Are you saving the file (Save or SaveAs) after setting the location but before closing the file? The location is file property. That means if the file is not saved then the location change in the file will be not be retained when the file is closed.
Of course, I save the file after setting the location. Basic Windows operations. I wouldn’t expect to hold the location if I just set it and then closed it without saving.
I haven’t tried to make a save as. I will also remove the SketchUp file which I have attached as a block, to see if that affects the problem.
Here is a button that reads the position from the operating system and finds the nearest town. It’s helpful not to try to find the location in the drop-down menu. Alternatively, you can set manual lat and long. This is more precise but it does not make any huge difference even in a country size. (except huge countries like USA of course)
I made simultaneously a save as and a block removal and now it holds the location. I will check again and I will report which of the two caused the problem.
If I remove the block set the location and close the file, when I reopen the location remains as expected. Then if I reimport the file and save it after reopening the location is again set in the USA.
Download the SketchUp File from this link: moscow-metro817176.skp
It’s a model from Trimble warehouse on which I have made a few modifications.
It has no geolocation.
However I found that changing the block type from ‘Linked’ to ‘Embedded and Linked’ allows a location change to stick.
Changing it back to ‘Linked’ immediately sets the location back to Denver and location changes no longer stick.
@wim, hopefully this helps pin it down. nb. The OneDrive location doesn’t affect this - I have the OP’s Sketchup block file on my desktop. It is specific to the OP’s Sketchup block as I tried with a linked DXF block and that did not prevent location changes. Unfortunately I don’t have any other Sketchup files to try.
Regards
Jeremy
[Conspiracy theory fodder: Trimble are headquartered in Colorado…]
Not fixed in the 9/21 beta. I think you may have two issues going on here: the one described in the devs’ narrative and one centred on the influence of the Sketchup file.
Notwithstanding the devs’ dismissal, adding the Sketchup file as a linked block instance still changes the location to Denver, as described above.
Regards
Jeremy
Edit: Original file was R7: the bug occurs in both R7 and R8 format files.
It looks like Rhino is picking up the location from the Sketchup file. While, as @ar00302 says, it shows no Geolocation. it does appear to have a location default of Boulder ready to set manually:
As you see from my comment in that YT issue, I was able to reproduce the issue without the SketchUp file (which wasn’t reproducible on your end) but NOT with that SketchUp file.
As both Tim and @johnc mention in the YT report, this issue is tricky to reproduce. Please list all the steps you take to make this behave this way on your system.
-wim
Here are two files, a Rhino Beta model and a Sketchup file (just to show it’s not just the OP’s specific files): Where is Wim.3dm (568.1 KB) Wim woz ere.skp (193.2 KB)
Test 1:
Open the Rhino file in the Beta and satisfy yourself that the location is London. Close the Beta without saving.
Open the Rhino file in the Beta again. Do NOT check the location.
Insert a Block Instance comprising the Sketchup file. Select the Linked option. Accept the default import parameters.
Check the location and it is now Denver.
Test 2:
Open the Sketchup file in the Beta. Accept the default import parameters
Check the location and it is Denver.
Here’s another Sketchup file you can use in the same way, just to show it doesn’t have to be in Denver. Wim is in Athens.skp (773.6 KB)
Hope that helps nail it. My guess, fwiw, is that the Sketchup import code has been designed to bring in a new model and someone has, reasonably, deemed it helpful to include the Sketchup location info. However the same code is being used to import Sketchup models as elements of a larger Rhino picture and is setting the location. Normally that is not the end of the world because if you catch it you can reset it to the correct location. However, using a Linked block you are importing the Sketchup data every time you open the model, so you are repeatedly overwriting the location.
Regards
Jeremy
Addendum:
The location being collected from the Sketchup files by Rhino is not their assigned Geolocation. The files don’t have one. Rather, it is a default value that will be used if you choose to set a manual geolocation (as opposed to selecting one from a map). If you set a geolocation from the map then that becomes the default for the next manual selection. If you clear the assigned geolocation then the value remains as the default for future manual assignment (which is how I was able to change the default from Denver to Athens).
Note that Sketchup requires a default with valid latitude and longitude to be present - you can’t work around the Rhino problem by deleting the values.
There are definitely two unrelated (in terms of code) issues going on here. @jeremy5 I didn’t mean to dismiss your Sketchup issue, but the problem I was looking at was entirely to do with the Options pages and had nothing to do with Sketchup. I wasn’t yet aware that there were actually two problems interacting with each other. I’ve reopened the issue and I will attempt to find and fix the issue about the SKP file. Thanks for the extensive explanation and clear steps.
