My problem is the value of CPC displayed after a multiplication "not correct"
Example : my CPC = 0.02 $
and i want to multiply the CPC by 10.5
i tried to do CPC * 10.5 but the result is 0.17 instead of 0.21
For information : i get data from google ads
thank you a lot in advance
The Decimal Precision in Scorecards is set to 2 places by default, thus one possibility is that the value of 0.02 in the CPC moy field is rounded from 0.0165.
Google Data Studio Report and a GIF to elaborate:
Related
using Microsoft SQL Server 2019
So I have parsed out several columns from a large text field and will need to use the parsed data as a multiplier to other fields
here is a single parsed column mostly for context
SUBSTRING(curv.curv_data,
CHARINDEX('PctUsage', curv.curv_data, CHARINDEX('||1', curv.curv_data)) + 9,
(CHARINDEX(')())', curv.curv_data, CHARINDEX('PctUsage', curv.curv_data, CHARINDEX('||2', curv.curv_data))) - 9) - CHARINDEX('PctUsage', curv.curv_data, CHARINDEX('||1', curv.curv_data) + 9)) PctUsage1
Here is the output.
PctUsage1
5
3.5
0.5
6.5
5
9
1
1.3
1.5
25.
4
0.0
1.2
so given there are 0s and 0.5 I am having a hard time turning this column into something useful. the end result I would like is to turn these into usable percentages for example 5 turns into .05 and so on.
I am going to be using the SQL above in a sub-select that will then be used as a multiplier for my working hours field here is an example of my multiplier field
Working_hours
51.600006
0.000000
20.799993
8.399999
28.799999
86.027731
5.199999
This is the line I would like to be able to use
PctUsage1*Working_hours curved_hours,
So working_hours is an Integer already but Pctusage1 is a varchar
Thank you in advance for the help
Okay so i think i have a solution, sorry for any of the trouble you guys have taken i guess writing out my problem really helped me work through it. i used a case statement with try_cast that helped filter out the different problems i was having with using only one solution. the last problem with this is making sure my multiplier is correct for that i had to use CHARINDEX with an imbedded case statement
case when try_cast(PctUsage1 as int) is null then case when CHARINDEX('.',PctUsage1) = 3 then cast(replace(PctUsage1, '.','') as Decimal(5,2))/100 when CHARINDEX('.',PctUsage1) = 2 then cast(replace(PctUsage1, '.','') as Decimal(5,2))/1000 end else try_cast(PctUsage1 as decimal(5,2))/100 end PctUsage1_converted,
I did a binary logistic regression and in the output (in the saction "Variables in the equation") I find the B coefficient and its standard error (ex S.E. = .859). However, I need the range of the beta standard erorr, somthing like: beta ± SE 0.05 ± 0.09.
How can I get Spss to show this value in the output or compute this value on my own?
You can get the data from the output table into a new dataset - using OMS command, then you can use it to make calculations:
DATASET DECLARE mydata.
OMS /SELECT TABLES
/IF COMMANDS=['Logistic Regression'] SUBTYPES=['Variables in the Equation']
/DESTINATION FORMAT=SAV OUTFILE='mydata' .
*run your analysis here.
omsend.
dataset activate mydata.
I have the following proj4 projection string defining an Oblique Mercator projection :
+proj=omerc +lat_0=45 +lonc=-80 +x_0=0 +y_0=0 +alpha=45 +gamma=0 +k_0=1
For my input coordinate, I was using 0, 0. When I alter the alpha angle from 45 to the range 90 to 270 inclusive, the projected point changes from the expected 80W, 45N to a point that proceeds easterly around the earth at the same latitude until the alpha is > 270, where I then get expected results again.
invproj +proj=omerc +lat_0=45 +lonc=-80 +x_0=0 +y_0=0 +alpha=45 +gamma=0 +k_0=1
0 0
80dW 45dN (this is expected)
invproj +proj=omerc +lat_0=45 +lonc=-80 +x_0=0 +y_0=0 +alpha=89 +gamma=0 +k_0=1
0 0
80dW 45dN (this is expected)
invproj +proj=omerc +lat_0=45 +lonc=-80 +x_0=0 +y_0=0 +alpha=91 +gamma=0 +k_0=1
0 0
77d10'18.699"W 45dN (this is not expected)
I'm not sure why I should be getting these different results, as a workaround, I could reverse the angle from 91 to 271, but I think I might need to also reverse the u, v in the projected system, it would be nice if Proj4 did this.
Is specifying alpha from 90-270 not supported?
Or, is there something I need to do with my parameters?
Edit: I've created an issue at Github for this at : https://github.com/OSGeo/proj.4/issues/331
It looks like there was a regression between Proj4 versions 4.7 and 4.8 that introduced a bug for this scenario, I found the following in the mailing list archives:
http://lists.maptools.org/pipermail/proj/2012-June/006331.html
Mikael Rittri wrote :
Not what I would expect. As far as I can understand, these weird results appear when alpha
is southish (in the closed interval 90 to 270). The omerc of Proj 4.7.0 did not behave this way.
This coincides with my observations. My solution was to reverse the alpha and add a pre/post processing layer that inverses the sign of the easting and northing values.
I created a very simple polygon in the middle of Germany to demonstrate my problem.
You can visualize it in geojsonlint using the following GeoJSON
{"type":"Polygon","coordinates":[[
[10.439844131469727,51.17460781257472],
[10.430574417114258,51.1753073564544],
[10.429565906524658,51.17179607723465],
[10.438792705535889,51.170706315523866],
[10.439372062683105,51.17267055874809],
[10.43975830078125,51.17439256616884],
[10.439844131469727,51.17460781257472]]]G}
When calculating the surface with online tools (e.g. http://www.daftlogic.com/projects-google-maps-area-calculator-tool.htm, but I tried several),
I get the following numbers (these are based on a similar drawing of the polygon, but not the exact same one, as I couldn't copy it over to these tools):
276583.39 m²
0.28 km²
68.35 acres
27.66 hectares
2977118.86 feet²
0.08 square nautical miles
Now I want to calculate these areas using POSTGIS, but I always get wrong and not matching numbers.
First I started without transformation using the examples given here:
http://postgis.net/docs/ST_Area.html
SELECT ST_Area(the_geom) As sqft, ST_Area(the_geom)*POWER(0.3048,2) As sqm
FROM (SELECT ST_GeomFromText('
POLYGON ((51.17460781257472 10.439844131469727,
51.1753073564544 10.430574417114258,
51.17179607723465 10.429565906524658,
51.170706315523866 10.438792705535889,
51.17267055874809 0.439372062683105,
51.17439256616884 10.43975830078125,
51.17460781257472 10.439844131469727))',4326) ) As foo(the_geom);
--> sqft = 3.52643124351653e-05 and sqm = 3.27616182873666e-06
How can I interprete these numbers?
Then I tried to transform it to WGS 84 / UTM zone 33N 32633
SELECT ST_Area(the_geom) As sqft, ST_Area(the_geom)*POWER(0.3048,2) As sqm
FROM (SELECT ST_Transform(ST_GeomFromText('
POLYGON ((51.174661624019286 10.440187454223633,
51.17067940750161 10.438899993896484,
51.17197097486416 10.429544448852539,
51.17536116708255 10.430488586425781,
51.174661624019286 10.440187454223633))',4326),32633) ) As foo(the_geom);
--> sqft = 662918.939349234 and sqm = 61587.1847391195
But even these numbers don't come close.
The coordinates of the polygon were accidentally loaded as lat,lon instead of lon, lat.
http://postgis.net/2013/08/18/tip_lon_lat
says
In spatial databases spatial coordinates are in x = longitude, and y = latitude
I converted the coordinates into EPSG: 31467, see epsg:31467 which is projected to meters and applies to the area of Germany covered by your geometry.
select st_area(st_transform(st_setsrid(st_geomfromtext('POLYGON((10.439844131469727
51.17460781257472,10.430574417114258 51.1753073564544,10.429565906524658
51.17179607723465,10.438792705535889 51.170706315523866, 10.439372062683105
51.17267055874809, 10.43975830078125 51.17439256616884, 10.439844131469727
51.17460781257472))'),4326),31467));
and got the answer: 274442.27 m2 which is within 0.007% of your original answer.
Measurements are usually more accurate in projected coordinate systems that use a geoid appropriate to that region. If you run this query on the spatial reference system table in Postgis for that projection:
select * from spatial_ref_sys where srid=31467;
you will see some more details, such as the fact that it uses the Bessel 1841 spheroid.
EDIT: your original geojson has coordinates in x/y, but for some reason you flipped them when putting them into Postgis.
I have an SSRS report pulling data in from a column of type DECIMAL(9,3). I want to display these values to the number of decimal places used to enter the data into the system.
For example:
Data Output
------- -------
123.456 123.456
123.450 123.45
123.400 123.4
123.006 123.006
120.000 123
120.000 120
100.000 100
I know you can format numeric data to a specific number of decimal places using the Format property for the column (e.g. N3 for 3dp), and I know that in C# the format string "{0:###}" would achieve the desired result.
I feel like it should be easy to do, but so far I've not found the right syntax to combine the two concepts in SSRS. What am I missing?
You can use the 0.### mask. In this case, it will produce the following results:
0.510 -> 0.51
6.581 -> 6.581
9.10 -> 9.1
Just checked it, works on SSRS 2008/2008 R2.