I have a two numeric fields one is called Lat and the other is called Long (see the attached image). When tableau reads the data, it assigns the geo role (as indicated by the data symbol) to the field of Lat but not the Long field. Is there a way I can make Tableau AUTOMATICALLY assign the geo role to the field of Long too?
I understand that I can always manually switch a field to the geographic data type or used the field of Longitude (generated). However, for my particular task on hand, it is best I can just use the field of Long as geographic data automatically.
If this information helps: The original dataset is based on a Txt file. The Lat and Long field in the original Txt file are String datatype, they were then transformed to Double in an ETL software.
Any help would be greatly appreciated!
Name your field Longitude instead of Long, and Tableau will automatically assign it the appropriate geographic role.
You might want to then also use Latitude instead of Lat for consistency.
Related
A database organises/structures bits of data into tables, records and fields. The name of each table and field gives semantic meaning to the data they contain. So, for example, a datatable called 'individuals' may well have a field called 'firstName', and as a result we know that the string "john" found in that field on one record in that table is the first name of an individual. As a result, the string "john" has a meaning and as a result could be referred to as a piece of data.
That datatable could be represented on an excel or other spreadsheet with the records as rows and the fields given as column headers at the top of the sheet, so that we know that all the bits of info under the header "firstName" are first names.
Now, imagine that same sheet, but without the field names in the first row. We have a structured list of values, organised into rows and columns. We can see that in one column there are a series of values "john", "jim", "sue", etc. We might guess that they are first names but we don't KNOW that they are. My question is: what is the correct terminology for this kind of data which has no ostensible meaning.
In other fields of human endeavour one might be faced with an undifferentiated mass of meaningless or unimportant static or "noise", and with skill identify some meaningful intelligence or "signal". I am looking for the equivalent data management term for that undifferentiated mass containing both signal and noise.
Essentially, I am looking for a synonym for data, but a name that implies "non-information" in that the items are essentially collection of strings, numbers, whatever that have no obvious meaning (...yet!). Words such as values, info, content all seem to convey too great a sense of importance or meaning, whereas dross, rubbish, noise are also too pejorative. Any suggestions?
I call SPO Rest API and in response I found two type of dates. I am not able to find any documentation on their difference especially the one with Dot (.)
Both Dates are shown here
We want to use one with Dot as its in standard format, but not sure about its authenticity. We are using RenderListDataAsStream as end point to get data.
Any documentation of properties coming with Dot(.) will be helpful to understand it. In attached image count is also another same example having dot.
P.S: here are the differnt ways to access them
I think the value of the normal named key (like technical field name) represents the value shown in UI to a user. So it is affected by the regional settings of the web.
The value of the additional "."-key (technical field name plus ".") represents the UTC-0 value in ISO format (like the data is stored in DB internaly).
For example:
"Created": "0;#2022-09-07 06:17:37", // timestamp by Regional Settings
"Created.": "2022-09-07T13:17:37Z", // UTC-0 in ISO format
so my company wants me to learn ABAP for SAP and I have started on the road to learn this. My background is mainly VB.net and sqlserver with T-SQL but also have experience in c#.
With ABAP though I am needing some clarification or confirmation on the understanding of Data Types and Domain. If anyone can help.
My understanding currently is we have a table, in the table we have fields and the fields have data types and lengths if needed. Example: We have a table Customer, I could have a customerNumber field with the data type of char(10). To me this mean in the table customer we have a field called CustomerNumber that will have 10 characters.
However with ABAP we have Domains, Data elements then the field, does this mean we have a field named whatever we want. As the field could mean anything we assign a data element which has the descriptions of the sort of data stored within the field. However to store the format and data type we need to assign the Domain to the Data element.
For example I call a field ZCUSNO, currently this means nothing however if I assign the ZCTNMR (with description of customer number) Data element this tells us that the field ZCUSNO is ZCTNMR so ZCUSNO is a customer number field.
Now within the data elements we would have a domain and for our example ZCTNMR data element (the customer number) we could assign ZCTDOM as the domain which would be what I recognise as the data types so Char 20, Char 100 or integer field etc.
Is my understanding correct on this? and could someone give me a clear indication of what the difference between a Domain > Data Element is against what I would know as data types in sqlserver.
Thanks
I don't know if it's 100% correct, but that's is the way I use, like you say.
You can reuse the Domain, If you don't plan to reuse you can use direct the Data Element and refer this to a built-in-type.
Data Element is to define semantic of the field, like label, translation, etc
Domain is to define techinical info of the field, like Type, conversions, predefined Values,e tc
E.G.
Domain:
DOM_VALUE you define it's 10 position and 2 Decimals
Data Element:
UNIT_VAL you refer it to DOM_VALUE and define label as "Unit Value"
TOTAL_VAL you refer it to DOM_VALUE and define label as "Total Value"
Your understanding is pretty correct and not much can be added here.
You should clearly get the main thing.
Domains store technical data (decimal points, length, type, predefined values and so on)
Data elements store semantic data (labels, texts, search help binding, etc.)
Not every table field has data element (they can possess builtin type) but every field has type (either primitive or wrapped in data element).
If you wanna use your field in screens (Dynpros), ALV grids or other reports, then create data elements that will bear business meaning of your field.
If you use this field just for calculations or other utility internal tasks, then don't bother yourself.
As usual table date field (type of variable) uses data element which uses domain.
When you create fields in table and use predefined types instead of data elements you will have some problems in future, when you'll need to see the data on alv_grid.
Actually, you will see that you have some problems even before this (when you will try to make a maintenance view the header will have something like "+" symbol).
And of course we usually try to create 1 domain for 2 and more Data Elements.
In domain you talk about main logic.
In Data Element I always talk about Field label settings (how it'll show in future and some other things)
Final: Actually, the good practice, as I think to create a domain for data element, it may help you in future.
I hope that it helps you. Good luck!
Since some of the open data has to do with property and each city has a unique identifier for a property, is there an easy way to map those unique identifiers in Socrata?
Visually, given a list of property unique identifiers in the open data, I'd like to see the properties on a map in one step.
More examples: If you go to http://api.us.socrata.com/api/catalog/v1?column_names=bbl you will see hundreds of references because this is what New York City calls it's unique identifier for a property.
What would be helpful is if we could easily see these properties on a map. We know that datasets should have latitude and longitude, but they usually do not. Plus for a property it is better to see the outline of the property and not just a point on a map.
In order to make it easier to do this, there is a tool at https://map.tidalforce.org/ it allows you to paste a comma delimited NYC BBLs (borough, block and lot) list. For example, https://map.tidalforce.org/?1pNFsY5rnHcsFEpLW2CJ this maps the socrata dataset at https://data.cityofnewyork.us/City-Government/Open-Article-7-Petitions/aht6-vxai
Is there a way to integrate with Socrata to make it easier to map properties for each area, city, state, etc. Or does this functionality already exist.
Please pardon my ignorance, I'm new to spatial data. I've been tasked with creating a map report in SSRS. When finished, the report will show locations of stores participating in the same promotion.
Currently, my database doesn't contain this information, so I have to create a table first. Luckily, I have a spreadsheet that does contain this information, so I can just import it. However, I'm not convinced that my spreadsheet has all the information I need. It shows basic information such as store name and address, but no geographical information (which I'm assuming I need).
So my question: What kind of data does a SQL table need in order to build a map report in SSRS?
You can create a custom table with the specific information that you want, but there are an inportant information that you mustn't forget, for example:
From the spatial data source:
SpatialData - A field that has spatial data that specifies the latitude and longitude of the city.
Name - A field that has the name of the city.
Area - A field that has the name of the region.
From the analytical data source:
Population - A field that has the city population.
City - A field that has the name of the city.
Area - A field that has the name of the territory, state, or region.