[Plugin] Export Cpoints to CSV v1.0 20110913
-
Hi again TIG,
Just discovered a small issue, the Z coordinate comes out with only one decimal i.e. -2.0 whereas in the drawing when using the "Query Tool" I can see there are 3 decimals, is it possible to increase to 2 decimals for Z (x.xx).
There are no changes even if I try to change the Units under the "Model Info" to "Precision" of 0,00 or 0,000 before exporting?
I really need to show 2 decimals like 2.35 t.ex.Best regards
Jesper -
Hi TIG,
Don't you think it will be good to combine this scrit with "exportvertices2csv.rb" you wrote some time ago ?
Regards, -
@jemagnussen said:
Hi again TIG,
Just discovered a small issue, the Z coordinate comes out with only one decimal i.e. -2.0 whereas in the drawing when using the "Query Tool" I can see there are 3 decimals, is it possible to increase to 2 decimals for Z (x.xx).
There are no changes even if I try to change the Units under the "Model Info" to "Precision" of 0,00 or 0,000 before exporting?
I really need to show 2 decimals like 2.35 t.ex.Best regards
JesperThe XYZ values are returned to the same accuracy as your Model Info > Units settings - here is an example in meters to 3dp so you get 1.234 BUT if the value has fewer significant figures they get missed off so 1.230 becomes 1.23 and 1.000 becomes 1 !
The values in the CSV file are therefore correct if reused as numbers later...
If you want to use them in a report with consistent formating you can do that in Excel ?
-
Hi again TIG,
Sorry for being late in responding, but I'm situated in west Africa at the moment and went home from work. I have tried the same file at home and the result I get is the same regardless of the settings in "Units" under "Model Info". her is the data as shown in the Excel sheet (Excel 2010 here and at work Excel 2000) same result both places:
310522.0,678294.0,1.0
and here is a screen dump of the model where the point is shown with the data and here it can be seen as ~1.17 as opposed to the 1.0 in the excel file...
What am I doing wrong....?
Best regards
Jesper -
Read the CSV file using Notepad.exe and report the Z values again... See if they are what you get when querying the cpoint in the SKP itself...
The accuracy in the Excel version seems to be rounding things ?
Are the units in meters ?
If so the points are a very long way from the SKP origin [0,0,0]!
Sketchup/OpenGL have problens with very small and very large dimensions - perhaps this is a reason?The attached version is for testing - swap it with the original - it prints the contents of the CVS file in the Ruby Console as well as opening it in Excel...exportcpoints2csv.rb
-
Hi TIG,
It also show’s the Z value rounded up to the nearest "whole" (not sure if this is the right expression in English) figure i.e. 1.23 becomes 1.0 and 0,635 also becomes 1.0 and shown as that in the Ruby Console as well as the Excel sheet.
It is, as you pointed out, probably due to the fact that the model is Geo Located and therefore rather far away from the 0,0,0. As you can see from the points I'm drawing in 1:1 at the right location as this makes it much easier to swap data with our surveyor's.
Is there an easy workaround this issue...?Best regards
Jesper -
When you 'geo-locate' your SKP its origin [0,0,0] represents a real world location - taken from the set long/lat.
You do not model hundreds of kilometers away from that origin [unlike how you might in AutoCAD].
As I said... very large [or very tiny] distances will break Sketchup/OpenGL which is designed to model things like furniture, windows, buildings, city-blocks etc, BUT not entire countries or swiss-watches!
Model everything within the [0,0,0] origin logically - perhaps at a corner etc.
Make sure everything is visible and unlocked and move what you have picking a point and typing in [0,0,0] - i.e. with the []
When you have the exported CSV data tell the recipient that [0,0,0]=>[123456.1,789012.3,123.4] or whatever OR the long/lat data from the geo-location info...
When you import survey data in CAD format do NOT preserve the origin - especially if you know it's located miles away!
If you want to keep the CAD origin - because perhaps you have earlier under/overlay CAD info that must align - then relocate the imported parts to be nearer [0,0,0] before starting SKP work on them.
Also check that none of the imported objects [CAD-blocks] have the axes [insertion-points] far far away from their geometry - this can also mess with the SKP... and is one of the causes of the clipping-plane issue when parts of your model vanish as you zoom...
-
Hi again,
Ok, so I will have to re-locate the model and then make a sort of converter for the data that I take out from the cpoints to be able to reference them back in their origins. Reason for the csv file was to have the correct Lat/Lon and Z data so it is possible to continue work with them in AutoCad Civil 3D that our surveyors use. It is a bit strange that the Lat/Lon data comes out fine but not the Z levels, when it is possible to see the right level in a Querry from the tools menu, but that's probably something that we normal mortal creatures should not understand anyway... :O)
Thank's again for all your help, it's really appreciated,
Best regards
Jesper -
There's a command in AutoCAD called 'BASE' which allows the users to specify an adjusted 'origin' in the DWG file - so then the kilometer sized coordinates >> [1,2,3] (a bit like using a UCS). The DWG's contents are still located in the world correctly... BUT it makes using a sensible 'site' based coordinate system easier to handle, all taken from a local datum. Perhaps they'd simply need to agree with you what they do with that, when they import your data - or they simply relocate it to suit afterwards by an amount you can advise... It's be easy enough to write a short script at the CAD end - alternatively apply some factors to your CSV's XYZ columns using three simple Excel formulas to convert them back to their crazy 'world' coordinate-system, and give them that adjusted CSV file...
Incidentally there's a tool of mine - 'coords text tag tool from datum' - that let's you set an XYZ 'datum' relative to the SKP's origin and then you can export those as a CSV with long/lat or whatever... it has several tools to import/export and add cpoints etc - see http://forums.sketchucation.com/viewtopic.php?p=284829#p284829
-
Hi TIG,
Need to bother you a bit more. I have now relocated the model to the 0,0,0 in Sketchup World and placed in the right height to be able to take out the Z value of the CPoints only in this location.
Could you have a look to see what is wrong - as it just won't work...? I still get only the Z values rounded up to nearest whole number... even as you can see from the with a red circle marked point the values in querry shows -17.482, 197.420, -1.293 (lon/lat/Z)Best regards
Jesper
-
I get no such problems.
Since the units setting are in the SKP it's not that.
Do you get the curtailed values in the Ruby Console as well as in the CSV ?
I've attached the CSV file [zipped] that I got and here is an extract...test_cpoints.zip
-
Hi TIG,
Strange... Yes the Ruby Console shows the same as in the csv file, it has removed the decimals and rounded up on all figures....
7.0,129.0,0.0
7.0,130.0,0.0
6.0,137.0,0.0
6.0,140.0,0.0
4.0,140.0,1.0
0.0,138.0,2.0
0.0,140.0,2.0
15.0,196.0,-1.0Best regards
Jesper -
- and the Excel sheet has all 3 figures in same column "A"... could it be some language issue as the Danish Excel version I use use "," as decimal seperator and "." as thousand seperator....?
Normally not a problem as I anyway most of the time has to work with formatting csv files, most of the time I get the data as Lon/Lat and Z and not Lat/Lon and Z and with lots of spaces in between instead of ","'s but that's normally no problem.
Brgds
Jesper - and the Excel sheet has all 3 figures in same column "A"... could it be some language issue as the Danish Excel version I use use "," as decimal seperator and "." as thousand seperator....?
-
In the SKP do you have a decimal-separator as '.' or ',' ?
I have '.' ??
The code will [should] write the CSV as 1.234,45.678,9.012 etc
If you open the .rb file with Notepad you can edit the two lines
sep="," ### <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ext="csv" ### <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
to read
sep="\t" ### <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ext="tsv" ### <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Then the file will be a TabSeparatedVariable TSV file, rather than a CommaSeparatedVariable CSV file; both will open in Excel.
1.234,45.678,9.012 >>> 1.234\t45.678\t9.012 [\t is a 'TAB']
You could open the resultant TSV file in Notepad and do a find+replace for '.'>>>','
Then open it in Excel as a Danish-friendly version ?
1.234\t45.678\t9.012 >>> 1,234\t45,678\t9,012
-
Hi TIG,
After changing the file it now says: exportcpoints2csv.new
Error: #<NameError: undefined local variable or method `exportcpoints2csv' for main:Object>
(eval):982Brgds
Jesper -
What have you done ???
Here's a new version that does it as a TSV file with ',' as the decimal separator!
Exportcpoints2tsv.rb -
Hi TIG,
Yes, one could wonder what happened, I believe I just did as you instructed, changed the "," to "\t" in the first line and "csv" to "tsv" in second line, but something must have gone wrong. Maybe it has to do with the fact that I did a classic! I was too quick to use Notepad to edit the rb file and forgot to remove the "Use always this program" så now all the rb files is shown as "Notebook" files...
(Here is the result of the new file you made:
7,0 129,0 0,0
6,0 140,0 0,0
0,0 138,0 2,0
0,0 140,0 2,0
15,0 196,0 -1,0
1,0 180,0 2,0
22,0 169,0 -1,0
-8,0 168,0 -1,0
21,0 189,0 0,0
-16,0 180,0 0,0As you can see it still round up all figures, so it must have something to do with the exporting as Sketchup itself shows it with 3 decimals, the setting is with 3 decimal in Model Info and it can't have anything to do with Excel as the file now is exported to a text file... this is strange...
Brgds
Jesper -
Hi again,
Just a question, is it somehow possible to force the numbers of decimals to say fixed 3 decimals on all the 3 figures (LLZ)?
Best regards
Jesper -
@jemagnussen said:
Hi again,
Just a question, is it somehow possible to force the numbers of decimals to say fixed 3 decimals on all the 3 figures (LLZ)?
Best regards
JesperTo export to 3dp always including trailing .000 would be possible... BUT the XYZ code would need revisiting - I'll come back later today when I have a moment...
-
Here's the updated version
(c) TIG 2011
Type
Exportcpoints2tsv.new
in the Ruby Console.
Exports all Cpoints is a Selection to a X,Y,Z 'TSV' file.
The sep="\t", the decsep=',' and ext='tsv'.
Change decsep='.' IF you want 1.234 rather than 1,234 OR run with arguments
as shown below...
Model Units are used and get exported to the TSV in say meters as 1,234 -
it always forces 3dp even when not needed - e.g. 0,100
Check that your locale Excel uses ','/'.' matching your output.
You can affect output by adding an argument to the command line, e.g.
It returns XYZ format by default BUT if you type
Exportcpoints2tsv.new 1
it will then use YXZ format.
To change from ',' to '.' as the decimal separator, type
Exportcpoints2tsv.new 2
To change from ',' to '.' as the decimal separator AND use YXZ, type
Exportcpoints2tsv.new 31.0 20110914 First issue.
1.1 20110915 Forces 3dp always, command-line argument to change format.Exportcpoints2tsv.rb
Advertisement