Quantcast
Channel: SQL Server Spatial forum
Viewing all 364 articles
Browse latest View live

Dynamic SQL, Spatial Intersects, Stored Proc - 1st run - slow; Next runs - better.

$
0
0

dear Readers,

thankyou for taking the time to read this post.   

i had to write a stored procedure where names of tables, (non-spatial) column names to be compared and resulting intersecting acres are determined at run-time.  so i made it dynamic - there are 2 spatial tables considered at any given execution, MyDataLayer table  (does not change) and FilterConditionLayer changes more often. 

An iterative batch of calls from a wcf component executes the stored procedure executes this dynamic stored procedure with the same MyDataLayer and Same keys but a different FilterConditionLayer and different filter conditions to do an intersect.  1st time, this wcf is called from silverlight app, it takes more than 4 seconds per stored procedure run (ave computed) - usually 1st thing in the morning.  Subsequent times, it executes it in 1sec / per stored procedure run.

I have been reading postings and blogs that indicate that the stored procedure's execution/compilation plan caching helps in subsequent execution.  this issue was also found in db2 - not only SQL Server. 

Both types of Layer tables discussed above are fairly static and do not have daily or hourly updates/changes.  MyDataLayer might be updated few times a year - not more than 5.  Further, spatial index(indices) have been built on both types of layers and we felt that there should not be a need to rebuild the index/indices every week or month.

We are using Shape.Intersect(2ndTbl.Shape) to get the intersected area - when this stored procedure is executed, we are zoomed in fairly close to equivalent of street blocks extent / 100s of acres extent. 

we would like to explore ways to improve the performance. 

1. Is there a Microsoft suggested way approach to 'wake up' the stored procedure so that it does not take a long time to execute the 1st time - usually in the morning?

2. is it better to use 'filter' as against intersect to force the spatial index to be used? particularly at this scale - 1:12000 range?

any other suggestions to speed up the execution would be appreciated.

i have pasted the stored procedure below for reference.

regards

ravi.

 

ALTER

PROCEDURE [dbo].[ReturnResultsOfFilterConditionsOnLandUnits]

 

-- Add the parameters for the stored procedure here

 

@ObjectIdString

varchar(8000),
 

@Delimiter4String

varchar(3),
 

@TableNameOfLandUnitLayer

varchar(100),

@TableNameOfFilterLayer

varchar(100),
 

@ColumnNameOfFilterCondition

varchar(1000),

@ComparisonOperator

varchar(10),
 

@ThresholdValue

varchar(20)
 

AS

BEGIN

 

 

 

SETNOCOUNTON;
 

 

 

declare @dynJoinStmtnvarchar(4000)
 

 

declare @AndConditionnvarchar(1000)
 

 

declare @IntAsFlag4AndConditionint

 

 

if(ltrim(rtrim(@ColumnNameOfFilterCondition))<>'')
 

 

begin

 

set @AndCondition=' where ('+ @ColumnNameOfFilterCondition +')'

 

set @IntAsFlag4AndCondition= 1

 

end

 

else

 

begin

 

set @AndCondition=''

 

set @IntAsFlag4AndCondition= 0

 

end

 

 

set @dynJoinStmt='

declare @hasOverlapsFlag varchar(1)

set @hasOverlapsFlag = (select hasOverlaps from nrcsrankingadmin.dbo.ra_layer

where isActive = 1 and tableName = '''

+ @TableNameOfFilterLayer+

''')

 

declare @FilteredLandUnitTable table

(

FilteredShape geometry,

FilteredLandUnitObjId varchar(30),

FilteredArea decimal(10,3),

FilteredUNIONArea decimal (10,3),

FilteringLayerObjId varchar(30)

)

insert into @FilteredLandUnitTable(FilteredShape,

FilteredLandUnitObjId,

FilteredArea,

FilteredUNIONArea,

FilteringLayerObjId)

select geometry::STGeomFromWKB(lu.shape.STIntersection(spFilter.shape).MakeValid().STAsBinary(),4326) ,

lu.objectid,

geography::STGeomFromWKB(lu.shape.STIntersection(spFilter.shape).STAsBinary(),4326).STArea()/4046.875,

0.0,

spFilter.Objectid from '

+

@TableNameOfLandUnitLayer

+' LU '+

 

'inner join '+

@TableNameOfFilterLayer

+' spFilter '+

 

'on LU.Shape.STIntersects(spFilter.Shape)=1

where LU.OBJECTID in (select IndividualItemValue from

dbo.ReturnListOfRecsFromVarchar('''

+ @ObjectIdString+''', '''+

@Delimiter4String

+'''))

 

if ('

+cast(@IntAsFlag4AndConditionasvarchar(3))+

' = 1)

begin

delete from @FilteredLandUnitTable where FilteringLayerObjId

not in (select X.FilteringLayerObjId from @FilteredLandUnitTable X inner join '

+

@TableNameOfFilterLayer

+' filtLayer

on X.FilteringLayerObjId = filtLayer.OBJECTID '

+

@AndCondition

+'

)

end

if (@hasOverlapsFlag = ''N'')

begin

select FilteredLandUnitObjId ,sum(FilteredArea)

from @FilteredLandUnitTable group by FilteredLandUnitObjId

end

else

begin

select FilteredLandUnitObjId

,geography::STGeomFromWKB(dbo.UnionAggregate(FilteredShape.MakeValid()).STAsBinary(),4326).STArea()/4046.875 as [New Area]

from @FilteredLandUnitTable group by FilteredLandUnitObjId

end

'

 

exec(@dynJoinStmt)

 

--print @dynJoinStmt

 

 

return@@error

END


Sr GIS App Developer Dallas Fort Worth area, TX

Polygon not a valid geography instance

$
0
0

I am trying to create and insert data from ESRI shape files. This is one of the many features in the shape file, you can copy paste it and try it yourself:

DECLARE @g geography;
SET @g = geography::STPolyFromText('POLYGON ((28.397422886819093 70.5432251792964, 28.570915861286892 70.512498993109844, 28.540819573464251 70.4456402666085, 28.486718688957893 70.433538619104056, 28.353077926613448 70.512911092846991, 28.397422886819093 70.5432251792964))', 4326);
SELECT @g.ToString();

If I try to create a geography object from this on SQL Server 2008, it fails with the following error:

Msg 6522, Level 16, State 1, Line 2 A .NET Framework error occurred during execution of user-defined routine or aggregate "geography": System.ArgumentException: 24200: The specified input does not represent a valid geography instance. System.ArgumentException: at Microsoft.SqlServer.Types.SqlGeography.ConstructGeographyFromUserInput(GeoData g, Int32 srid) at Microsoft.SqlServer.Types.SqlGeography.GeographyFromText(OpenGisType type, SqlChars taggedText, Int32 srid)

What is wrong with this shape?


Very poor performance when intersecting points with multipolygon

$
0
0

(SQL 2012 Enterprise, BTW)

So, we have a geography multipolygon. It has a large total extent - maybe 100 miles * 100 miles.

It contains a lot of small 'child' polygons:

  NumberGeometries   NumberPoints

  3553                     30468

You can conceptualise these child polygons as postcodes. These child postcodes are not contiguous.

We also have a table of 237,000 houses, each one with a geography point (location). We have a spatial index on this location field:

  CREATESPATIALINDEX[IX_Location_AUTO]ON[search].[Address]

  ([Location])USING  GEOGRAPHY_AUTO_GRID

  WITH(CELLS_PER_OBJECT= 4096)

We’re trying to find which houses are within these postcodes

The performance is truly dreadful, taking 2m:54s to return the 3,700 houses that are in the multipolygon.

The query plan seems to indicate that a Filter is taking place first against the spatial index, then its eliminating points outside the bounding box of the multipolygon, then doing an STIntersect against the remaining set.

sp_help_spatial_geography_indexreturns the following information about the spatial index:

-- Results

Total_Number_Of_ObjectCells_In_Level1_For_QuerySample  2

Total_Number_Of_ObjectCells_In_Level2_For_QuerySample  2

Total_Number_Of_ObjectCells_In_Level3_For_QuerySample  4

Total_Number_Of_ObjectCells_In_Level4_For_QuerySample  26

Total_Number_Of_ObjectCells_In_Level5_For_QuerySample  257

Total_Number_Of_ObjectCells_In_Level6_For_QuerySample  2992

Total_Number_Of_ObjectCells_In_Level7_For_QuerySample  3940

Total_Number_Of_ObjectCells_In_Level8_For_QuerySample  1287

Total_Number_Of_ObjectCells_In_Level8_In_Index  115289

Total_Number_Of_Interior_ObjectCells_In_Level5_For_QuerySample       3

Total_Number_Of_Interior_ObjectCells_In_Level6_For_QuerySample       148

Total_Number_Of_Interior_ObjectCells_In_Level7_For_QuerySample       282

Total_Number_Of_Intersecting_ObjectCells_In_Level1_For_QuerySample   2

Total_Number_Of_Intersecting_ObjectCells_In_Level2_For_QuerySample   2

Total_Number_Of_Intersecting_ObjectCells_In_Level3_For_QuerySample   4

Total_Number_Of_Intersecting_ObjectCells_In_Level4_For_QuerySample   26

Total_Number_Of_Intersecting_ObjectCells_In_Level5_For_QuerySample   254

Total_Number_Of_Intersecting_ObjectCells_In_Level6_For_QuerySample   2839

Total_Number_Of_Intersecting_ObjectCells_In_Level7_For_QuerySample   1287

Total_Number_Of_Intersecting_ObjectCells_In_Level8_For_QuerySample   270

Total_Number_Of_Intersecting_ObjectCells_In_Level8_In_Index   114713

Total_Number_Of_Border_ObjectCells_In_Level6_For_QuerySample  5

Total_Number_Of_Border_ObjectCells_In_Level7_For_QuerySample  2371

Total_Number_Of_Border_ObjectCells_In_Level8_For_QuerySample  1017

Total_Number_Of_Border_ObjectCells_In_Level8_In_Index  576

Number_Of_Rows_Selected_By_Primary_Filter 18318

Number_Of_Rows_Selected_By_Internal_Filter      4844

Number_Of_Times_Secondary_Filter_Is_Called      13474

Number_Of_Rows_Output      13930

Percentage_Of_Rows_NotSelected_By_Primary_Filter       93.3059744853771

Percentage_Of_Primary_Filter_Rows_Selected_By_Internal_Filter 26.4439349273938

Internal_Filter_Efficiency 34.7738693467337

Primary_Filter_Efficiency  76.0454198056556

Is there anything glaringly obvious that we’re doing wrong? Or does anyone have a generic approach we should be taking to improve the performance?

I’d be grateful for any input at all

How to pick the right Points to draw the Polygon

$
0
0

Hi,

I need to draw a polygon with the Latitude and Longitude Points. I am getting all the points from SQL Server 2008 from the Table. How to pick the Border Points to draw polygon.  Is there any method to pick the outer Border points to draw polygon. Thank's in Advance.

 

Thanks and Regards

Parthiban. R

Merging valid geography polygons generate invalid polygon?

$
0
0

Using Microsoft SQL Server 11.0.3128 (SQL Server 2012 Express)

I have 2 valid geography polygons that can be merged with other polygons except each other. Individually both return STIsValid()=1, and when merged they ALSO return STIsValid()=1. However, Spatial Results can only display them individually. When clicking the Spatial Results tab on the merged results the following error comes up:

24144: this operation cannot be completed because the instance is not valid. Use MakeValid to convert the instance to a valid instance. Note that MakeValid may cause the points of a geometry instance to shift slightly. (Microsoft.SqlServer.Types)

Is the merged result really invalid? or is it that Spatial Results has a bug?

merge function being used:

  • geography::UnionAggregate([Geo])
  • geography::UnionAggregate([Geo].MakeValid())

Polygon A:

GEOMETRYCOLLECTION (LINESTRING (-118.28436600000003 33.708803999999844, -118.28463400000008 33.708732000000055), LINESTRING (-118.28429600000008 33.708813999999883, -118.28436600000003 33.708803999999844), LINESTRING (-118.28476500000014 33.708691999999822, -118.28483099999998 33.708677999999964), LINESTRING (-118.28363899999991 33.708910999999958, -118.28389400000013 33.708883999999962, -118.28425900000009 33.708826000000158), LINESTRING (-118.28176230499078 33.708838455359775, -118.28203200000004 33.708877999999864), POLYGON ((-118.28232021585335 33.708904222275287, -118.28225400000021 33.708900999999841, -118.28203200000004 33.708877999999864, -118.28225399999988 33.708900999999926, -118.28232021585335 33.708904222275287)), POLYGON ((-118.28168069190481 33.708824935432695, -118.28165399999966 33.708816999999904, -118.28158399999992 33.708806000000195, -118.2816540000001 33.708817000000096, -118.28168069190481 33.708824935432695)), LINESTRING (-118.28065300044184 33.708680500538492, -118.28098399999995 33.708731000000121, -118.28129199999987 33.708734999999976), POLYGON ((-118.27946299999988 33.708426999999979, -118.27941400000033 33.7084179999999, -118.27913500000021 33.708348999999991, -118.27889699999983 33.708197999999804, -118.27913499999988 33.708349000000062, -118.27941399999999 33.708417999999988, -118.27946299999988 33.708426999999979)), POLYGON ((-118.29291899999994 33.70535600000008, -118.29279400000003 33.705018000000067, -118.29263599999992 33.705070000000205, -118.29257400000017 33.705095000000085, -118.29195400000006 33.70511800000007, -118.29183799999994 33.705152999999974, -118.291719 33.705196999999735, -118.29151799999981 33.705215000000109, -118.291403 33.70518, -118.29132900000016 33.705123999999842, -118.29128599999984 33.704994000000092, -118.29127799999996 33.704968999999849, -118.29125500000021 33.704917999999957, -118.291173 33.704849000000117, -118.29115799999992 33.704855999999808, -118.29111499999991 33.704876000000183, -118.29091800000003 33.705019999999912, -118.29079500000032 33.705034999999967, -118.29069200000004 33.705112999999812, -118.29051500000017 33.705199999999977, -118.29046600000008 33.705213999999714, -118.29030900000005 33.705241000000036, -118.2902720000001 33.705229999999879, -118.29021500000003 33.705224000000143, -118.29005900000028 33.705230000000128, -118.28970100000006 33.705261000000206, -118.28961500000008 33.705293000000054, -118.28958600000027 33.705296000000018, -118.28947899999977 33.705358000000039, -118.28940500000013 33.705365000000263, -118.28876999999979 33.705349999999868, -118.28865899999998 33.705347999999788, -118.28855999999982 33.705410000000043, -118.28847600000003 33.705467, -118.28837299999982 33.705516000000287, -118.28800500000003 33.705761999999972, -118.28798199999999 33.7057770000002, -118.28795400000017 33.70579100000014, -118.28753400000004 33.70608799999998, -118.28714999999995 33.70637400000011, -118.28710200000016 33.706404000000191, -118.28701999999994 33.706442999999794, -118.28695400000001 33.706466000000148, -118.28678599999998 33.706511000000063, -118.2866989999999 33.706520999999988, -118.28664599999996 33.7065390000002, -118.28655999999988 33.706549000000081, -118.28650599999992 33.706565999999995, -118.28638699999988 33.706582999999853, -118.28611600000021 33.706658000000004, -118.28599200000002 33.706775999999856, -118.285984 33.7068100000002, -118.2859590000001 33.706837000000235, -118.28595099999994 33.706871000000127, -118.28588500000006 33.706955, -118.28587699999996 33.706989000000149, -118.28583599999989 33.707030000000053, -118.28580699999972 33.707106999999851, -118.28578199999986 33.707156999999825, -118.28577199999997 33.707213000000024, -118.28573699999988 33.707409999999939, -118.2857199999999 33.707451000000155, -118.28543999999988 33.7076859999999, -118.28542400000012 33.707707000000234, -118.28540700000008 33.707761000000069, -118.28541499999989 33.707987999999943, -118.28538200000011 33.708079000000076, -118.28518499999988 33.708247999999891, -118.28530299999981 33.708597999999888, -118.28336900000006 33.70933799999996, -118.28393100000017 33.70996300000008, -118.2840920000001 33.709924000000122, -118.28425400000008 33.709917000000104, -118.28447300000008 33.709965999999881, -118.28461299999992 33.710008, -118.28473800000008 33.710045000000051, -118.28512200000004 33.710215999999939, -118.28533799999998 33.710295000000123, -118.28520600000004 33.71048600000006, -118.28564600000006 33.710808000000057, -118.28565600000002 33.710932000000042, -118.28569099999996 33.711043000000032, -118.28581299999988 33.7110809999999, -118.28588099999992 33.711244000000065, -118.28606799999991 33.711454000000074, -118.2860839999999 33.711586999999994, -118.28609399999985 33.71164799999999, -118.28606400000015 33.711848999999937, -118.28574600000012 33.71245200000002, -118.285633 33.712665999999949, -118.28548499999992 33.712949000000116, -118.28548699999992 33.712997000000023, -118.28565100000017 33.713334000000081, -118.285798 33.7136239999999, -118.28575799999989 33.713992999999967, -118.28593600000006 33.714203000000019, -118.28592699999987 33.714256999999989, -118.28587800000005 33.714694999999963, -118.28591499999992 33.714976999999926, -118.2856250000001 33.715868999999913, -118.2854499999999 33.716334000000039, -118.28545000000007 33.716569999999933, -118.28549399999994 33.716625000000029, -118.28434999999992 33.718110999999951, -118.28416299999984 33.718403999999929, -118.28396199999999 33.718645999999886, -118.28344899999992 33.719261999999922, -118.28338000000011 33.719780000000057, -118.28306600000009 33.720315000000092, -118.28311100000003 33.720415000000131, -118.28329599999995 33.72074699999996, -118.28356300000011 33.721252000000014, -118.28391399999998 33.721861000000132, -118.28411000000014 33.722331999999973, -118.28420099999987 33.722606000000034, -118.28430699999998 33.72297999999995, -118.28440999999991 33.723537999999976, -118.28442300000003 33.723630000000014, -118.28463099999993 33.723572999999938, -118.28478600000017 33.723521000000034, -118.28488199999988 33.723503999999927, -118.28571300000009 33.723231999999932, -118.28606800000001 33.723126999999963, -118.28687400000005 33.722897999999915, -118.28694600000006 33.722877999999874, -118.28730800000007 33.722772999999926, -118.28743200000012 33.722736999999881, -118.28769400000022 33.722661000000087, -118.28798000000012 33.722582999999986, -118.287978 33.721749999999872, -118.28797699999994 33.721479999999879, -118.28797699999998 33.720970000000122, -118.28797600000013 33.720689000000107, -118.28797000000003 33.720606999999916, -118.28793800000004 33.720172999999917, -118.28793699999993 33.718926999999944, -118.28793700000008 33.718793000000083, -118.287935 33.716971000000129, -118.28793399999986 33.716025999999907, -118.28793300000012 33.715165000000049, -118.28793100000006 33.713352000000022, -118.28793000000006 33.711524000000054, -118.28792899999979 33.710575999999918, -118.28792799999997 33.70962800000008, -118.29063999999988 33.709626000000064, -118.29121599999992 33.709624999999896, -118.29284299999993 33.709624000000133, -118.29284200000001 33.708744999999936, -118.29284199999996 33.707864999999913, -118.29284099999981 33.706978999999968, -118.29284099999985 33.706501999999958, -118.29291899999994 33.70535600000008)), POLYGON ((-118.2772759999993 33.70789399999996, -118.27705599999973 33.707805000000029, -118.27702299999993 33.7077820000001, -118.27654599999985 33.707535000000149, -118.27611100000017 33.707299999999925, -118.27563400000018 33.707052999999824, -118.27528899999976 33.706864999999858, -118.2738189999999 33.706046000000065, -118.27180399999988 33.704964000000281, -118.27193500000008 33.705136000000081, -118.27709799999995 33.707905000000075, -118.27725400000016 33.707900000000016, -118.2772759999993 33.70789399999996)))

Polygon B:

POLYGON ((-118.28798 33.722583, -118.287694 33.722660999999995, -118.287432 33.722736999999995, -118.287308 33.722773, -118.286946 33.722878, -118.286874 33.722898, -118.286068 33.723127, -118.285713 33.723231999999996, -118.284882 33.723504, -118.284786 33.723521, -118.28463099999999 33.723573, -118.284423 33.72363, -118.284474 33.723994999999995, -118.284566 33.724441, -118.284697 33.724407, -118.284779 33.724385, -118.284804 33.724489999999996, -118.284855 33.724737, -118.28491700000001 33.725041, -118.284888 33.725141, -118.284602 33.726047, -118.283906 33.726952, -118.28358399999999 33.72721, -118.282782 33.727854, -118.281068 33.728755, -118.280929 33.728828, -118.28048 33.728997, -118.28047699999999 33.729659999999996, -118.280472 33.730567, -118.280468 33.731474, -118.281389 33.731477, -118.283563 33.731485, -118.28573399999999 33.731493, -118.287939 33.731501, -118.287941 33.730593, -118.287946 33.729686, -118.287953 33.728778999999996, -118.287957 33.727872, -118.28796 33.726966, -118.287964 33.726058, -118.287968 33.725151, -118.287973 33.724244, -118.287977 33.723338, -118.287979 33.722992999999995, -118.28798 33.722837, -118.28798 33.722583))



How to improve the performance of Spatial Query?

$
0
0

Hi Everyone,

       We are looking for the way's to improve the performance of the Spatial query inSQL Server 2008 R2.

       Scenario:-

        Table A having Geom column with 87 rows and Table B having Geom column with 50000 rows

        We are calculating A.geom.STIntersects(B.Geom), this simple query taking almost an hours to execute.

         I checked the execution plan its using clustered index not the spatial index. So tried to add the hint with option

SELECT A.geom.STIntersects(B.geom)  FROM A WITH(INDEX(geom_sidxB)),    B WITH(INDEX(geom_sidxB))  WHERE A.id=1 and B.id=2

         But its giving me an error

"The query processor could not produce a query plan for a query with a spatial index hint.  Reason: The spatial parameter references a column that is defined below the predicate.  Try removing the index hints or removing SET FORCEPLAN."
     

         So how i can use the spatial index hints in SQL Query and optimize it or is there any other ways to do it.

          Thanks in advance.

Regards

Swap       

Insert Binary directly into Geometry column

$
0
0

Hi All,

I'm new to spatial data.

I've imported some ESRI files into my database using the OSGeo4W application.

I now want to deploy these maps to some of our client servers without using the OSGeo4W application. As I only have 9 maps, I was hoping to simply insert the data like this.

IF NOT EXISTS (SELECT * FROM MAPS WHERE MAP_NAME = 'Queensland') INSERT INTO MAPS VALUES (0xE610000001..., 3, 'Queensland');

However, I receive the following error:

A .NET Framework error occurred during execution of user-defined routine or aggregate "geometry":

System.FormatException: 24210: Geometry type with an unexpected version of 0 received; only versions up to 2 are accepted.

System.FormatException:

   at Microsoft.SqlServer.Types.GeoData.Read(BinaryReader r, SerializationVersion maxVersion, String strUnexpectedVersion, Boolean isGeography)

   at Microsoft.SqlServer.Types.SqlGeometry.Read(BinaryReader r)

   at SqlGeometry::.DeserializeValidate(IntPtr , Int32 , CClrLobContext* )

I then tried using this:

DECLARE @MapDetail geometry
SET @MapDetail = geometry::STGeomFromWKB(0xE610000001040......, 4326)However, I got this error: 

Msg 6522, Level 16, State 1, Line 2

A .NET Framework error occurred during execution of user-defined routine or aggregate "geometry":

System.FormatException: 24115: The well-known binary (WKB) input is not valid.

System.FormatException:

   at Microsoft.SqlServer.Types.WellKnownBinaryReader.ParseWkb(OpenGisType type)

   at Microsoft.SqlServer.Types.WellKnownBinaryReader.Read(OpenGisType type, Int32 srid)

   at Microsoft.SqlServer.Types.SqlGeometry.GeometryFromBinary(OpenGisType type, SqlBytes binary, Int32 srid)

Note - I had to truncate the binary data to stay within the post limit.

Please help.

Cheers, Clay

Plotting driving distance in Reporting services

$
0
0

I'm fairly a newbie to  Sql server spatial area. So please pardon me if i ask nonsense questions..

I've created a RS map control to plot  data points. I have a business location (circle) and contractors (pushpins) on the image below. I've used STbuffer to add layer to see which contractor is nearest to the Business location. But My goal is to plot the driving route from each contractors location to the business point. Is it possible? Any help will be appreciated


Querying points within a radius of point x

$
0
0

Hi,

Complete beginner to this and am keen to learn. Could someone to get me started (I've tried googling but really didnt help), explain what SQL query i would need to write to find a list of records which contain Geography points within a 1 mile circle of point X?

 

Thanks,

Matt

SQL Server spatial types redistributable

$
0
0

Hi,

I know this question has been previously asked here:

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/174a3f81-60be-4da2-9a12-ab81d91c4cd9/are-the-spatial-dlls-redistributable

but I don't think there was a satisfactory answer and the thread was subsequently hijacked with unrelated problems. Does anyone have an up to date answer? Can I redistribute the following dll's with my software?

Microsoft.SqlServer.Types.dll

SQLServerSpatial.dll 

Thanks

Very poor performance when intersecting points with multipolygon

$
0
0

(SQL 2012 Enterprise, BTW)

So, we have a geography multipolygon. It has a large total extent - maybe 100 miles * 100 miles.

It contains a lot of small 'child' polygons:

  NumberGeometries   NumberPoints

  3553                     30468

You can conceptualise these child polygons as postcodes. These child postcodes are not contiguous.

We also have a table of 237,000 houses, each one with a geography point (location). We have a spatial index on this location field:

  CREATESPATIALINDEX[IX_Location_AUTO]ON[search].[Address]

  ([Location])USING  GEOGRAPHY_AUTO_GRID

  WITH(CELLS_PER_OBJECT= 4096)

We’re trying to find which houses are within these postcodes

The performance is truly dreadful, taking 2m:54s to return the 3,700 houses that are in the multipolygon.

The query plan seems to indicate that a Filter is taking place first against the spatial index, then its eliminating points outside the bounding box of the multipolygon, then doing an STIntersect against the remaining set.

sp_help_spatial_geography_indexreturns the following information about the spatial index:

-- Results

Total_Number_Of_ObjectCells_In_Level1_For_QuerySample  2

Total_Number_Of_ObjectCells_In_Level2_For_QuerySample  2

Total_Number_Of_ObjectCells_In_Level3_For_QuerySample  4

Total_Number_Of_ObjectCells_In_Level4_For_QuerySample  26

Total_Number_Of_ObjectCells_In_Level5_For_QuerySample  257

Total_Number_Of_ObjectCells_In_Level6_For_QuerySample  2992

Total_Number_Of_ObjectCells_In_Level7_For_QuerySample  3940

Total_Number_Of_ObjectCells_In_Level8_For_QuerySample  1287

Total_Number_Of_ObjectCells_In_Level8_In_Index  115289

Total_Number_Of_Interior_ObjectCells_In_Level5_For_QuerySample       3

Total_Number_Of_Interior_ObjectCells_In_Level6_For_QuerySample       148

Total_Number_Of_Interior_ObjectCells_In_Level7_For_QuerySample       282

Total_Number_Of_Intersecting_ObjectCells_In_Level1_For_QuerySample   2

Total_Number_Of_Intersecting_ObjectCells_In_Level2_For_QuerySample   2

Total_Number_Of_Intersecting_ObjectCells_In_Level3_For_QuerySample   4

Total_Number_Of_Intersecting_ObjectCells_In_Level4_For_QuerySample   26

Total_Number_Of_Intersecting_ObjectCells_In_Level5_For_QuerySample   254

Total_Number_Of_Intersecting_ObjectCells_In_Level6_For_QuerySample   2839

Total_Number_Of_Intersecting_ObjectCells_In_Level7_For_QuerySample   1287

Total_Number_Of_Intersecting_ObjectCells_In_Level8_For_QuerySample   270

Total_Number_Of_Intersecting_ObjectCells_In_Level8_In_Index   114713

Total_Number_Of_Border_ObjectCells_In_Level6_For_QuerySample  5

Total_Number_Of_Border_ObjectCells_In_Level7_For_QuerySample  2371

Total_Number_Of_Border_ObjectCells_In_Level8_For_QuerySample  1017

Total_Number_Of_Border_ObjectCells_In_Level8_In_Index  576

Number_Of_Rows_Selected_By_Primary_Filter 18318

Number_Of_Rows_Selected_By_Internal_Filter      4844

Number_Of_Times_Secondary_Filter_Is_Called      13474

Number_Of_Rows_Output      13930

Percentage_Of_Rows_NotSelected_By_Primary_Filter       93.3059744853771

Percentage_Of_Primary_Filter_Rows_Selected_By_Internal_Filter 26.4439349273938

Internal_Filter_Efficiency 34.7738693467337

Primary_Filter_Efficiency  76.0454198056556

Is there anything glaringly obvious that we’re doing wrong? Or does anyone have a generic approach we should be taking to improve the performance?

I’d be grateful for any input at all

Merging valid geography polygons generate invalid polygon?

$
0
0

Using Microsoft SQL Server 11.0.3128 (SQL Server 2012 Express)

I have 2 valid geography polygons that can be merged with other polygons except each other. Individually both return STIsValid()=1, and when merged they ALSO return STIsValid()=1. However, Spatial Results can only display them individually. When clicking the Spatial Results tab on the merged results the following error comes up:

24144: this operation cannot be completed because the instance is not valid. Use MakeValid to convert the instance to a valid instance. Note that MakeValid may cause the points of a geometry instance to shift slightly. (Microsoft.SqlServer.Types)

Is the merged result really invalid? or is it that Spatial Results has a bug?

merge function being used:

  • geography::UnionAggregate([Geo])
  • geography::UnionAggregate([Geo].MakeValid())

Polygon A:

GEOMETRYCOLLECTION (LINESTRING (-118.28436600000003 33.708803999999844, -118.28463400000008 33.708732000000055), LINESTRING (-118.28429600000008 33.708813999999883, -118.28436600000003 33.708803999999844), LINESTRING (-118.28476500000014 33.708691999999822, -118.28483099999998 33.708677999999964), LINESTRING (-118.28363899999991 33.708910999999958, -118.28389400000013 33.708883999999962, -118.28425900000009 33.708826000000158), LINESTRING (-118.28176230499078 33.708838455359775, -118.28203200000004 33.708877999999864), POLYGON ((-118.28232021585335 33.708904222275287, -118.28225400000021 33.708900999999841, -118.28203200000004 33.708877999999864, -118.28225399999988 33.708900999999926, -118.28232021585335 33.708904222275287)), POLYGON ((-118.28168069190481 33.708824935432695, -118.28165399999966 33.708816999999904, -118.28158399999992 33.708806000000195, -118.2816540000001 33.708817000000096, -118.28168069190481 33.708824935432695)), LINESTRING (-118.28065300044184 33.708680500538492, -118.28098399999995 33.708731000000121, -118.28129199999987 33.708734999999976), POLYGON ((-118.27946299999988 33.708426999999979, -118.27941400000033 33.7084179999999, -118.27913500000021 33.708348999999991, -118.27889699999983 33.708197999999804, -118.27913499999988 33.708349000000062, -118.27941399999999 33.708417999999988, -118.27946299999988 33.708426999999979)), POLYGON ((-118.29291899999994 33.70535600000008, -118.29279400000003 33.705018000000067, -118.29263599999992 33.705070000000205, -118.29257400000017 33.705095000000085, -118.29195400000006 33.70511800000007, -118.29183799999994 33.705152999999974, -118.291719 33.705196999999735, -118.29151799999981 33.705215000000109, -118.291403 33.70518, -118.29132900000016 33.705123999999842, -118.29128599999984 33.704994000000092, -118.29127799999996 33.704968999999849, -118.29125500000021 33.704917999999957, -118.291173 33.704849000000117, -118.29115799999992 33.704855999999808, -118.29111499999991 33.704876000000183, -118.29091800000003 33.705019999999912, -118.29079500000032 33.705034999999967, -118.29069200000004 33.705112999999812, -118.29051500000017 33.705199999999977, -118.29046600000008 33.705213999999714, -118.29030900000005 33.705241000000036, -118.2902720000001 33.705229999999879, -118.29021500000003 33.705224000000143, -118.29005900000028 33.705230000000128, -118.28970100000006 33.705261000000206, -118.28961500000008 33.705293000000054, -118.28958600000027 33.705296000000018, -118.28947899999977 33.705358000000039, -118.28940500000013 33.705365000000263, -118.28876999999979 33.705349999999868, -118.28865899999998 33.705347999999788, -118.28855999999982 33.705410000000043, -118.28847600000003 33.705467, -118.28837299999982 33.705516000000287, -118.28800500000003 33.705761999999972, -118.28798199999999 33.7057770000002, -118.28795400000017 33.70579100000014, -118.28753400000004 33.70608799999998, -118.28714999999995 33.70637400000011, -118.28710200000016 33.706404000000191, -118.28701999999994 33.706442999999794, -118.28695400000001 33.706466000000148, -118.28678599999998 33.706511000000063, -118.2866989999999 33.706520999999988, -118.28664599999996 33.7065390000002, -118.28655999999988 33.706549000000081, -118.28650599999992 33.706565999999995, -118.28638699999988 33.706582999999853, -118.28611600000021 33.706658000000004, -118.28599200000002 33.706775999999856, -118.285984 33.7068100000002, -118.2859590000001 33.706837000000235, -118.28595099999994 33.706871000000127, -118.28588500000006 33.706955, -118.28587699999996 33.706989000000149, -118.28583599999989 33.707030000000053, -118.28580699999972 33.707106999999851, -118.28578199999986 33.707156999999825, -118.28577199999997 33.707213000000024, -118.28573699999988 33.707409999999939, -118.2857199999999 33.707451000000155, -118.28543999999988 33.7076859999999, -118.28542400000012 33.707707000000234, -118.28540700000008 33.707761000000069, -118.28541499999989 33.707987999999943, -118.28538200000011 33.708079000000076, -118.28518499999988 33.708247999999891, -118.28530299999981 33.708597999999888, -118.28336900000006 33.70933799999996, -118.28393100000017 33.70996300000008, -118.2840920000001 33.709924000000122, -118.28425400000008 33.709917000000104, -118.28447300000008 33.709965999999881, -118.28461299999992 33.710008, -118.28473800000008 33.710045000000051, -118.28512200000004 33.710215999999939, -118.28533799999998 33.710295000000123, -118.28520600000004 33.71048600000006, -118.28564600000006 33.710808000000057, -118.28565600000002 33.710932000000042, -118.28569099999996 33.711043000000032, -118.28581299999988 33.7110809999999, -118.28588099999992 33.711244000000065, -118.28606799999991 33.711454000000074, -118.2860839999999 33.711586999999994, -118.28609399999985 33.71164799999999, -118.28606400000015 33.711848999999937, -118.28574600000012 33.71245200000002, -118.285633 33.712665999999949, -118.28548499999992 33.712949000000116, -118.28548699999992 33.712997000000023, -118.28565100000017 33.713334000000081, -118.285798 33.7136239999999, -118.28575799999989 33.713992999999967, -118.28593600000006 33.714203000000019, -118.28592699999987 33.714256999999989, -118.28587800000005 33.714694999999963, -118.28591499999992 33.714976999999926, -118.2856250000001 33.715868999999913, -118.2854499999999 33.716334000000039, -118.28545000000007 33.716569999999933, -118.28549399999994 33.716625000000029, -118.28434999999992 33.718110999999951, -118.28416299999984 33.718403999999929, -118.28396199999999 33.718645999999886, -118.28344899999992 33.719261999999922, -118.28338000000011 33.719780000000057, -118.28306600000009 33.720315000000092, -118.28311100000003 33.720415000000131, -118.28329599999995 33.72074699999996, -118.28356300000011 33.721252000000014, -118.28391399999998 33.721861000000132, -118.28411000000014 33.722331999999973, -118.28420099999987 33.722606000000034, -118.28430699999998 33.72297999999995, -118.28440999999991 33.723537999999976, -118.28442300000003 33.723630000000014, -118.28463099999993 33.723572999999938, -118.28478600000017 33.723521000000034, -118.28488199999988 33.723503999999927, -118.28571300000009 33.723231999999932, -118.28606800000001 33.723126999999963, -118.28687400000005 33.722897999999915, -118.28694600000006 33.722877999999874, -118.28730800000007 33.722772999999926, -118.28743200000012 33.722736999999881, -118.28769400000022 33.722661000000087, -118.28798000000012 33.722582999999986, -118.287978 33.721749999999872, -118.28797699999994 33.721479999999879, -118.28797699999998 33.720970000000122, -118.28797600000013 33.720689000000107, -118.28797000000003 33.720606999999916, -118.28793800000004 33.720172999999917, -118.28793699999993 33.718926999999944, -118.28793700000008 33.718793000000083, -118.287935 33.716971000000129, -118.28793399999986 33.716025999999907, -118.28793300000012 33.715165000000049, -118.28793100000006 33.713352000000022, -118.28793000000006 33.711524000000054, -118.28792899999979 33.710575999999918, -118.28792799999997 33.70962800000008, -118.29063999999988 33.709626000000064, -118.29121599999992 33.709624999999896, -118.29284299999993 33.709624000000133, -118.29284200000001 33.708744999999936, -118.29284199999996 33.707864999999913, -118.29284099999981 33.706978999999968, -118.29284099999985 33.706501999999958, -118.29291899999994 33.70535600000008)), POLYGON ((-118.2772759999993 33.70789399999996, -118.27705599999973 33.707805000000029, -118.27702299999993 33.7077820000001, -118.27654599999985 33.707535000000149, -118.27611100000017 33.707299999999925, -118.27563400000018 33.707052999999824, -118.27528899999976 33.706864999999858, -118.2738189999999 33.706046000000065, -118.27180399999988 33.704964000000281, -118.27193500000008 33.705136000000081, -118.27709799999995 33.707905000000075, -118.27725400000016 33.707900000000016, -118.2772759999993 33.70789399999996)))

Polygon B:

POLYGON ((-118.28798 33.722583, -118.287694 33.722660999999995, -118.287432 33.722736999999995, -118.287308 33.722773, -118.286946 33.722878, -118.286874 33.722898, -118.286068 33.723127, -118.285713 33.723231999999996, -118.284882 33.723504, -118.284786 33.723521, -118.28463099999999 33.723573, -118.284423 33.72363, -118.284474 33.723994999999995, -118.284566 33.724441, -118.284697 33.724407, -118.284779 33.724385, -118.284804 33.724489999999996, -118.284855 33.724737, -118.28491700000001 33.725041, -118.284888 33.725141, -118.284602 33.726047, -118.283906 33.726952, -118.28358399999999 33.72721, -118.282782 33.727854, -118.281068 33.728755, -118.280929 33.728828, -118.28048 33.728997, -118.28047699999999 33.729659999999996, -118.280472 33.730567, -118.280468 33.731474, -118.281389 33.731477, -118.283563 33.731485, -118.28573399999999 33.731493, -118.287939 33.731501, -118.287941 33.730593, -118.287946 33.729686, -118.287953 33.728778999999996, -118.287957 33.727872, -118.28796 33.726966, -118.287964 33.726058, -118.287968 33.725151, -118.287973 33.724244, -118.287977 33.723338, -118.287979 33.722992999999995, -118.28798 33.722837, -118.28798 33.722583))



How to improve the performance of Spatial Query?

$
0
0

Hi Everyone,

       We are looking for the way's to improve the performance of the Spatial query inSQL Server 2008 R2.

       Scenario:-

        Table A having Geom column with 87 rows and Table B having Geom column with 50000 rows

        We are calculating A.geom.STIntersects(B.Geom), this simple query taking almost an hours to execute.

         I checked the execution plan its using clustered index not the spatial index. So tried to add the hint with option

SELECT A.geom.STIntersects(B.geom)  FROM A WITH(INDEX(geom_sidxB)),    B WITH(INDEX(geom_sidxB))  WHERE A.id=1 and B.id=2

         But its giving me an error

"The query processor could not produce a query plan for a query with a spatial index hint.  Reason: The spatial parameter references a column that is defined below the predicate.  Try removing the index hints or removing SET FORCEPLAN."
     

         So how i can use the spatial index hints in SQL Query and optimize it or is there any other ways to do it.

          Thanks in advance.

Regards

Swap       

Insert Binary directly into Geometry column

$
0
0

Hi All,

I'm new to spatial data.

I've imported some ESRI files into my database using the OSGeo4W application.

I now want to deploy these maps to some of our client servers without using the OSGeo4W application. As I only have 9 maps, I was hoping to simply insert the data like this.

IF NOT EXISTS (SELECT * FROM MAPS WHERE MAP_NAME = 'Queensland') INSERT INTO MAPS VALUES (0xE610000001..., 3, 'Queensland');

However, I receive the following error:

A .NET Framework error occurred during execution of user-defined routine or aggregate "geometry":

System.FormatException: 24210: Geometry type with an unexpected version of 0 received; only versions up to 2 are accepted.

System.FormatException:

   at Microsoft.SqlServer.Types.GeoData.Read(BinaryReader r, SerializationVersion maxVersion, String strUnexpectedVersion, Boolean isGeography)

   at Microsoft.SqlServer.Types.SqlGeometry.Read(BinaryReader r)

   at SqlGeometry::.DeserializeValidate(IntPtr , Int32 , CClrLobContext* )

I then tried using this:

DECLARE @MapDetail geometry
SET @MapDetail = geometry::STGeomFromWKB(0xE610000001040......, 4326)However, I got this error: 

Msg 6522, Level 16, State 1, Line 2

A .NET Framework error occurred during execution of user-defined routine or aggregate "geometry":

System.FormatException: 24115: The well-known binary (WKB) input is not valid.

System.FormatException:

   at Microsoft.SqlServer.Types.WellKnownBinaryReader.ParseWkb(OpenGisType type)

   at Microsoft.SqlServer.Types.WellKnownBinaryReader.Read(OpenGisType type, Int32 srid)

   at Microsoft.SqlServer.Types.SqlGeometry.GeometryFromBinary(OpenGisType type, SqlBytes binary, Int32 srid)

Note - I had to truncate the binary data to stay within the post limit.

Please help.

Cheers, Clay

Looking for a comprehensive sample DB of Spatial Data

$
0
0

I’m looking for a really comprehensive sample DB of Spatial Data.  Basically, I want to practice with the sample data, like finding distances between longitude & latitude coordinates, and the like. This is just for fun, and for my own education.  Anything that works like Google Maps would be perfect!! Does anyone know if there is something out there like this?  I searched on the web for such a thing, but didn’t find anything interesting.

 

Thanks everyone!!

 


Knowledge is the only thing that I can give you, and still retain, and we are both better off for it.


How to find the distance between coordinates?

$
0
0

How to find the distance between coordinates?

 

I found a nice sample script online that calculates the distance between 2 points, using longitude and latitude.

 

DECLARE@LAT1decimal(10,06)

DECLARE@LAT2decimal(10,06)

DECLARE@LON1decimal(10,06)

DECLARE@LON2decimal(10,06)

 

SET@LAT1= 40.742828

SET@LON1= -73.952418

SET@LAT2= 0.008064

SET@LON2= 0.020664

 

DECLARE@CAS decimal(12,08)

 

DECLARE@TAS decimal(16,10)

 

SET@C= 57.29577951

 

SET@T=(SIN(@LAT1/@C)*SIN(@LAT2/@C))

+(COS(@LAT1/@C)*COS(@LAT2/@C)*COS(ABS(@LON2-@LON1)/@C))

 

SELECTATAN(SQRT(1-SQUARE(@T))/@T)

 

 

If I enter ‘To’ and ‘From’ in Google Maps (from midtown Manhattan to downtown Manhattan) I get something like this.

https://maps.google.com/maps?saddr=350+Madison+Avenue,+New+York,+NY,+United+States&daddr=60+Wall+Street,+New+York,+NY,+United+States&hl=en&sll=37.0625,-95.677068&sspn=36.368578,84.638672&geocode=FercbQIdVy6X-ymTZePhAVnCiTG8ykPoBHrMBw%3BFZ0gbQIdKLiW-ylfb3VPFlrCiTEb1iRjXUyTXQ&oq=60+wall+street+&mra=ls&t=m&z=13

 

 

I’m wondering why I get a a completely different answer when using Google maps and when using the SQL above.


Knowledge is the only thing that I can give you, and still retain, and we are both better off for it.

sql spatial data gives wrong answer

$
0
0
DECLARE @g geography = geography::STGeomFromText('POLYGON((1 1, 3 1, 3 3, 1 3, 1 1))',4326)
DECLARE @g2 geography =geography::STGeomFromText( 'POLYGON((0 0, 2 0, 2 2, 0 2, 0 0))',4326)
Declare @union  geography  =  @g2.STUnion(@g)
Declare @diff  geography  =  @g2.STDifference(@g)

SELECT @g.STArea() + @g2.STArea() - @union.STArea()
SELECT  @union.STArea()+@diff.STArea()



ret: "12306061878,1564" "123060620496,501" 
note: Decimal number - 11/12 before the coma. How can it happen?

 select @union.ToString()


ret
POLYGON ((0 2, 0 0, 2 0, 2.0000000000000591 1.0001522971041397, 3 1, 3 3, 1 3, 1.0000000000000655 2.0003044086154023, 0 2))

What did I do wrong?

Select Features Within N Distance of Each Other

$
0
0

I have a spatial table containing polygons that represent buildings in my county.  There are over 255,000 polygons in my table.

I would simply like to query that table to find all buildings within n distance of each other.  This seems like it should be fairly basic, but the solution has eluded me.

I am looking to answer questions such as:  

How many buildings are within 5 or n feet of each other?

Any suggestions are appreciated.  Thanks.

JP

SQL 2005 - Storing GPS tracking data in a database

$
0
0

Hi all

I have a requirement to store GPS lat/lon tracking data in a SQL database. I am competely new to GPS and geometry positioning with regards SQL, so have been reading up on the subject. I have also created a SQL database to hold the information (DB is called GPS_Data). However, to begin with, I am still not sure how to get the data into the database. I have tracking units installed on about 60 of our vehicles, which are setup to transmit GPS data every 5 minutes to a specified IP address and port, and this IP and port is for our SQL Server. However, from there, I am not sure how I go about getting the data actually into SQL. Any clues as to where I can look for more info, what I should do, etc??

Many thanks for all help

Naz

Error 8646 while transfering a GEOMETRY column via UPDATE from table A to table B

$
0
0

Hello,

I am currently migrating from from SQLServer 2008R2 to SQLServer 2012. The following UPDATE statement:

updateTAB_B set GEOMETRY_LL84=a.GEOMETRY_LL84
fromTAB_B as b innerjoinTAB_A as a ona.ID=b.ID;

, where GEOMETRY_LL84 is a spatially indexed GEOMETRY column, runs well in an SQLServer2008 database, but fails in an SQLServer2012 database with a severe error 8646.

The content of the TAB_A.GEOMETRY_LL84 seems to be ok, and the statement:

select iD, GEOMETRY_LL84 into TAB_C from TAB_A;

works successfully. What could be the reason for my problem, especially in an UPDATE statement?

Regards,

Klaus

Viewing all 364 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>