Most databases have some kind of geographic data and there is a growing need to present topographical information in a reporting solution. There are two important components of geographic data: its geographic position and its attributes or properties. In other words, spatial data (where is it?) and attribute data (what is it?). This session provides information about working with geographic data from start to finish, the step-by-step means of preparing and presenting geographic data, and how you can "clean up" and validate your geographic data or create interactive reports.
This session will begin with the tasks necessary to model a dimensional data structure to maintain and present geographic data. We will discuss various requirements that can affect a data model such as granularity, surrogate keys, slowly changing dimensions. Real life examples and solutions will provided to give better context to each step in the process.
After the data structure has been created we will focus on how to best “clean” and validate the geographic data. We will focus on using SSIS to obtain latitude and longitude and then how this can be converted SQL Server spatial types.
Finally we will cover presenting this data using SSRS and Power Map and how to create dynamic and aesthetically pleasing graphical reports. This portion of the session concentrates on presenting reports using the geographic data type that answer specific questions such as:
Events that occurred at a specific address, zip code, and even block range and events within a mile radius.
5. BACKGROUND•Within Public Safety many reports are geographically based and visual reports are helpful•Pin maps became the de facto standard of geographic maps•Looks kewl, but no so easy to automatw•Crime clusters•Burglaries within a xxradius•Focused patrol areas•Traffic crashes with injuries•YES we target problem areasNOT people•Traffic crashes without injuries•Granularity based on the reason for the first harmful event•Did He do that too??? •Locate similar crimes in the area where suspects are arrested•Car hoppers!!! •AKA job security!!
6. DEALING WITH LOCATION•What location information do you deal with? •Country•State/Providence•Zip code•City •Address•Block range•What do you need to report on•Granularity!!! •How does it have to be reported? •Aggregations•Non-map based•Visual representation
10. HOW IS LOCATION RECEIVED/STORED•How do you receive and store your date•Fully parsed address•Full address•Lon and Lat•SQL Spatial•The higher the level of receipt/storage the more analysis and cleansing•TAKE THE TIME TO DO EXHAUSTIVE EVALUATION•Look for the rules and then find the most common exceptions•Generally the more granular the storage/receipt the easier it is to validate and piece together
11. WHAT IS BEING REPORTED? •Review how the geographic data is being reported•Granularity•Zip•Block ranges •Latitude and longitude/Point•Strive to drill down to the lowest level•Does it require visualization (SSRS Map Component) •“14 Crashes in the 100 Block North Del Prado”
12. CREATE YOUR DIMENSION•Based on the reporting needs will drive the schema of the dimension tableCREATETABLE[dbo].[DimGeography]( [geoid][int]IDENTITY(1,1)NOTNULL, [commitedkey][int]NULL, [inci_id][varchar](14)NULL, [block][int]NULL………… •Review DDL Example
15. EVALUATE DATA SOURCES•Where is geographic data being stored•SQL•Excel (SORRY BRO!!) •ESRI•CSV•Fox Pro (REALLY!! Why not Aramaic?) •Can separate sources be maintained•Based on the ability to present as a whole and consistency and accuracy•Is location parsed? •If not evaluate the need/ability to parse during the transformation•Eases presenting and cleansing
16. IMPORTING•If possible parse the data to its most granular segments•Street number•Street•Street prefix•Street Suffix•City•Zip•State•Clean it up!! •Find most common inconsistencies•Str, S, or Street should all be “St” •Del Prdo, D.P., Dele Prado should all be “Del Prado” •REVIEW DEMO T-SQL CODE
17. TRANSFORMATIONS•Based on the source data not all data sets may be present•Block range•VIEW DEMO CODE•Longitude/Latitude•Cross street(s) •Address accuracy is critical at this point!! •Accurate and consistent!
18. HOW DO I GET LAT/LON? •You can manually enter each address•http://itouchmap.com/latlong.html•http://stevemorse.org/jcal/latlon.php•C’MonMan!! Really?!?! •Automate!! •Google Maps API•https://developers.google.com/maps/documentation/geocoding/#geocoding•Limits usage•Free 2,500 within 24 hours•Business 100,000 within 24 hours•Will also begin to throttle based on requests submitted within a minute threshold•MelissaData•Native SSIS transformation•Provides extensible transformation•US and International•DEMO
20. KEWL, BUT NOW WHAT?!? •I got latand lon!! Now what?!?! •Power Pivot/ Power Map Demo•Address only •THIS IS WHY WE NEED LAT LON•Latlonin Power Map•We can do better!! •SQL Server spatial data type supports•Native functions•SSRS map control•Provides dynamic visualization of geographic data
22. SQL SPATIAL PRIMER•Introduced in SQL 2008•Based on CLR user defined type•System provided•Does not require enabling CLR•Geography •Supports methods•Open Geospatial Consortium (OGC) standard•Set of Microsoft extensions to that standard•Geometry•Supports methods•Open Geospatial Consortium (OGC) standard•Set of Microsoft extensions to that standard
25. WHY USE SPATIAL•Provides the ability create SSRS reports using the Map Control•Better than address and latitude and longitude•More exact•Spatial functions can be applied•All points within the radius of a point•Once longitude and latitude is obtained we can convert this to geography data type•Geography column can be set using an UPDATE statement•DEMO