Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««4,1884,1894,1904,1914,192»»»

Are the posted questions getting worse? Expand / Collapse
Author
Message
Posted Thursday, October 24, 2013 10:08 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 7:51 AM
Points: 1,141, Visits: 6,238
There are also some zips as I recall used by the government that don't follow the normal expected pattern.
Normally, 1 for east, to 9 for west.
Post #1508142
Posted Thursday, October 24, 2013 10:52 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, April 10, 2014 9:10 AM
Points: 2,694, Visits: 6,895
Greg Edwards-268690 (10/24/2013)
There are also some zips as I recall used by the government that don't follow the normal expected pattern.
Normally, 1 for east, to 9 for west.


Starts with 0 in the NE


--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Post #1508171
Posted Thursday, October 24, 2013 1:16 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 8:57 PM
Points: 817, Visits: 2,479
wolfkillj (10/24/2013)
Greg Edwards-268690 (10/24/2013)
Brandie Tarvin (10/24/2013)
Speaking of maps and geospatial data, which is a better type of data to use? Raster or Vector?


Reading this I would say vector.
Good listing of things to consider.


I think the better answer is "it depends." Of course, SQL Server's spatial data capabilities work with vector data only, so that may render the decision moot in a lot of cases.

If I had to translate the points in that article into recommendations for different use cases, I'd say this:

If you are analyzing the relationships between spatial objects (intersection, containment, distance, etc.) or mapping spatial objects on a "to scale" map, use vector data. You need the accuracy of location.

If you are analyzing or presenting continuous data (values that vary depending on location and area included, e.g., population density) and you have the capability, raster data may be an option.

That being said, just about all the things one would do with raster data can be done as well with vector data, although it may be more cumbersome and resource-intensive. The reverse is not true - raster data can't represent spatial objects like lines and points with complete accuracy.

I agree, vector is most suitable for the majority of cases. However rasters do provide a means to do some very powerful and reasonably quick calculations.

A couple of things to remember with raster layers are:
They are inherently cartesian (flat and square) whereas the world is elliptical, Lat/Longs don't fit well into them and they are likely to be projected. Displaying them in other projections can be process intensive.
They can get very large very quickly, so picking the appropriate cell size (resolution) and coverage for their use is essential.

In the past I've used rasters to determine cut and fill volumes, growth rates and a couple of other similar calculations.
Post #1508232
Posted Thursday, October 24, 2013 2:47 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, April 07, 2014 7:35 AM
Points: 1,172, Visits: 2,413
mickyT (10/24/2013)

I agree, vector is most suitable for the majority of cases. However rasters do provide a means to do some very powerful and reasonably quick calculations.

A couple of things to remember with raster layers are:
They are inherently cartesian (flat and square) whereas the world is elliptical, Lat/Longs don't fit well into them and they are likely to be projected. Displaying them in other projections can be process intensive.
They can get very large very quickly, so picking the appropriate cell size (resolution) and coverage for their use is essential.

In the past I've used rasters to determine cut and fill volumes, growth rates and a couple of other similar calculations.


Thanks for that insight, mickyT. What tool(s) did you use when working with raster data?


Jason Wolfkill
Blog: SQLSouth
Twitter: @SQLSouth
Post #1508274
Posted Thursday, October 24, 2013 3:18 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 8:57 PM
Points: 817, Visits: 2,479
wolfkillj (10/24/2013)

Thanks for that insight, mickyT. What tool(s) did you use when working with raster data?

Mostly I use ESRI's ArcGIS with the spatial analyst extension, however I have also use Safe's FME for this as well. FME is a spatial ETL tool that is extremely flexible, but doesn't do the visualization that well.
Post #1508286
Posted Thursday, October 24, 2013 8:08 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 4:56 PM
Points: 8,271, Visits: 8,717
wolfkillj (10/23/2013)
I've published my first technical blog post. I'd appreciate any feedback from this group on both the technical aspects and the writing. Thanks, everyone!

Nice article. I liked seeing the use of STR for conversion as one option for solving the problems. Most people who write about approximate muneric problems appear to assume that the problem is rounding errors in the floating point arithmetic rather than conversion errors and representation errors, but you have spotted that the thing that needed addressing to fix these examples was conversion error (because convert and cast and implicity conversion can all cause errors by doing too much rounding and sometimes by rounding incorrectly, but STR doesn't because you can specify the precision wanted).
Until we get modern floating point in SQL, it will be sensible to use exact numerics for latitudes and longitudes; and even when we do we may still find that we have to use STR to avoid conversion errors if we use approximate numerics.


Tom
Post #1508315
Posted Thursday, October 24, 2013 10:52 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 8:57 PM
Points: 817, Visits: 2,479
L' Eomot Inversé (10/24/2013)
wolfkillj (10/23/2013)
I've published my first technical blog post. I'd appreciate any feedback from this group on both the technical aspects and the writing. Thanks, everyone!

Nice article. I liked seeing the use of STR for conversion as one option for solving the problems. Most people who write about approximate muneric problems appear to assume that the problem is rounding errors in the floating point arithmetic rather than conversion errors and representation errors, but you have spotted that the thing that needed addressing to fix these examples was conversion error (because convert and cast and implicity conversion can all cause errors by doing too much rounding and sometimes by rounding incorrectly, but STR doesn't because you can specify the precision wanted).
Until we get modern floating point in SQL, it will be sensible to use exact numerics for latitudes and longitudes; and even when we do we may still find that we have to use STR to avoid conversion errors if we use approximate numerics.
You've hit the nail on the head.
It would also be nice to see the internals of geometry and geography types use exact numerics internally or apply a tolerance that eliminates the float issues. There is nothing more frustrating than unioning a couple of perfectly adjacent polygons and having tiny slivers appearing because of float inaccuracies. It has got better with 2012, but still happens occasionally. As a person that deals with spatial data the vertex it is really important and should not change because of some operation.
Post #1508325
Posted Friday, October 25, 2013 7:00 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 1:12 PM
Points: 3,297, Visits: 2,340
mickyT (10/24/2013)
L' Eomot Inversé (10/24/2013)
wolfkillj (10/23/2013)
I've published my first technical blog post. I'd appreciate any feedback from this group on both the technical aspects and the writing. Thanks, everyone!

Nice article. I liked seeing the use of STR for conversion as one option for solving the problems. Most people who write about approximate muneric problems appear to assume that the problem is rounding errors in the floating point arithmetic rather than conversion errors and representation errors, but you have spotted that the thing that needed addressing to fix these examples was conversion error (because convert and cast and implicity conversion can all cause errors by doing too much rounding and sometimes by rounding incorrectly, but STR doesn't because you can specify the precision wanted).
Until we get modern floating point in SQL, it will be sensible to use exact numerics for latitudes and longitudes; and even when we do we may still find that we have to use STR to avoid conversion errors if we use approximate numerics.
You've hit the nail on the head.
It would also be nice to see the internals of geometry and geography types use exact numerics internally or apply a tolerance that eliminates the float issues. There is nothing more frustrating than unioning a couple of perfectly adjacent polygons and having tiny slivers appearing because of float inaccuracies. It has got better with 2012, but still happens occasionally. As a person that deals with spatial data the vertex it is really important and should not change because of some operation.

This is something I've been interested in learning for a long time, but never had the opportunity to actually do work in the area. Sigh.



Tally Tables - Performance Personified
Best practices on how to ask questions
Post #1508445
Posted Friday, October 25, 2013 7:30 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:06 PM
Points: 6,543, Visits: 8,751
wolfkillj (10/23/2013)
I've published my first technical blog post. I'd appreciate any feedback from this group on both the technical aspects and the writing. Thanks, everyone!


Jason - this was a good article from both points of view.
Has Steve hit you up to follow this up for an article for SSC?


Wayne
Microsoft Certified Master: SQL Server 2008
If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
Links: For better assistance in answering your questions, How to ask a question, Performance Problems, Common date/time routines,
CROSS-TABS and PIVOT tables Part 1 & Part 2, Using APPLY Part 1 & Part 2, Splitting Delimited Strings
Post #1508457
Posted Friday, October 25, 2013 8:12 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, April 07, 2014 7:35 AM
Points: 1,172, Visits: 2,413
WayneS (10/25/2013)
wolfkillj (10/23/2013)
I've published my first technical blog post. I'd appreciate any feedback from this group on both the technical aspects and the writing. Thanks, everyone!


Jason - this was a good article from both points of view.
Has Steve hit you up to follow this up for an article for SSC?


I think Steve's mind has been on the ski slopes this week and his body has now followed, so no, not yet.

Thanks for the feedback on the blog post, too. I'm feeling my way through this blogging process and like to know whether I'm on the right track or not.


Jason Wolfkill
Blog: SQLSouth
Twitter: @SQLSouth
Post #1508477
« Prev Topic | Next Topic »

Add to briefcase «««4,1884,1894,1904,1914,192»»»

Permissions Expand / Collapse