| Повече ▼

Намерете най -близката дължина до входната дължина (SQL Server 2008)

Намерете най -близката дължина до входната дължина (SQL Server 2008)


Имам облак от точки в моята база данни (SQL Server 2008 пространствен). Това са около 6 милиона записа. Има 3 колони: id, value, geom. Какъв е оптималният начин за получаване на "стойността" на дължина на входа?

Аз съм нов в пространствените заявки в SQL Server 2008. Може ли някой да публикува прост пример за намиране на точката в колона geom, съвпадаща или най -близка от входната ширина?


Това, което търсите, е най -близкият съседен въпрос. Погледнете следните връзки, мисля, че ще намерите това, което търсите.

Запитване за най -близкия съсед

Най -близките съседи

Оптимизация на най -близкия съсед в SQL Server Denali


Това използва география, а не геометрия (ако данните са с ширина/дължина, данните трябва да са тип география, а не геометрия)

"Географският тип данни на SQL Server съхранява елипсоидални (околоземни) данни, като GPS координати за географска ширина и дължина."

За да изберете 5-те най-близки записа от точка lat/lng (-122,0 37,0), която можете да използвате.

SELECT TOP 5 geography :: STGeomFromText ('POINT (-122.0 37.0)', 4326) .STDistance (p) FROM markers WHERE geography :: STGeomFromText ('POINT (-122.0 37.0)', 4326) .STDistance (p) <25 ORDER BY geography :: STGeomFromText ('POINT (-122.0 37.0)', 4326) .STDistance (p);

Пространствени типове - география

Тип географски пространствени данни, география, е реализиран като .NET общ ​​език по време на изпълнение (CLR) тип данни в SQL Server. Този тип представлява данни в кръгова земна координатна система. SQL Server география типът данни съхранява елипсоидални (околоземни) данни, като GPS координати за географска ширина и дължина.

SQL Server поддържа набор от методи за география тип пространствени данни. Това включва методи за география които са дефинирани от стандарта Open Geospatial Consortium (OGC) и набор от разширения на Microsoft към този стандарт.

Толерантността към грешки за география методите могат да бъдат до 1.0e-7 *. Екстентите се отнасят до приблизителното максимално разстояние между точките на географияобект.


Намерете най -близката дължина до входната дължина (SQL Server 2008) - Географски информационни системи

Затова се опитвах да измисля някои примери, които използват данните за Garmin POI от последния ми пост. Тъй като данните за POI естествено се поддават на запитвания до най-близкия съсед, реших да напиша малко за тях.

Общата форма на заявката за най -близкия съсед е: „Покажи ми най -близките x ресторанти/кръчми/жп гари до това място”Това е моделът на заявка, използван от приложенията, които знаят местоположението, за намиране на POI в близост до текущото местоположение на потребителя, например. Друг модел, за който съм виждал много по -малко примери, е как да актуализираме цяла таблица със записи, за да определим и попълним най -близкия съсед за всеки ред в таблицата (наистина този въпрос възникна в пространствения форум на MSDN само миналата седмица).

Имайки предвид това, реших да демонстрирам практически сценарий: да речем, че планирате да плувате в местния басейн и след като сте преплували 50 дължини, вероятно ще се почувствате малко дръзка - може би в необходимостта от някои рибни чипове. Така че в този пример първо ще импортирам данните за POI на Garmin за басейни и магазини за риболов „чип“ в Обединеното кралство, всеки от които е представен от географски екземпляр Point. След това ще добавя допълнителна колона към масата за плувен басейн и ще я запълня с най -близкия магазин за риба и чипс до всеки басейн.

За начало създайте таблици, съдържащи данните за магазини за риба и чипс и басейни (изтеглете данните от тук). Забележете, че съм включил поле за първичен ключ IDENTITY във всяка таблица, което ще ми трябва, за да добавя пространствен индекс по -късно:

Сега ще добавим няколко допълнителни колони към таблицата за басейни, които ще попълним с информация за най -близкия магазин за рибни и чипове:

Сега не го правите трябва за да добавите пространствен индекс за извършване на заявката за актуализация, но ще бъде много по -бързо с едно, отколкото без. SQL Server може да използва само един пространствен индекс в съединение между таблици, така че няма нужда да добавяте индекс към двете таблици. Ние просто ще добавим един към таблицата Fish And Chips, както следва:

След това изпълнете UPDATE заявка, за да попълните ClosestFishBar и Разстояние колони, както следва:

Тази заявка вероятно се нуждае от някакво обяснение:

  • Като цяло може да очаквате да използвате корелирана подзаявка, за да получите най -близкия магазин за риба и чипс до всеки плувен басейн. Съпоставените подзаявки обаче могат да върнат само една стойност и искам да извлека както името, така и разстоянието до най -близката рибна лента, затова вместо това използвах CROSS APPLY.
  • В прилаганата функция сортирам таблицата с магазини за риба и чипс по възходящ ред на тяхното разстояние от текущия плувен басейн (ПОРЪЧВАЙТЕ ПО FishAndChips.Location.STDistance (SwimmingPools.Location) ASC) и след това изберете ТОП 1 Име и местоположение (т.е. най -близкият).
  • За да направя заявката ефективна, добавих и подсказка за индекс, за да използвам пространствения индекс в таблицата „Риба и чипс“ - WITH (индекс (sidx_FishAndChips))и включих допълнителен предикат, КЪДЕ FishAndChips.Location.STDistance (SwimmingPools.Location) НЕ Е НУЛ. Този допълнителен предикат ще помогне на оптимизатора на заявки да избере специалния план за заявка за най -близкия съсед, въведен в SQL Server 2012 и SQL Azure.
  • Обърнете внимание, че планът за оптимизиране на пространствения индекс за най-близкия съсед е наличен само в SQL Server 2012/SQL Azure. Ако се опитате да изпълните заявката UPDATE, както е написано по -горе в SQL Server 2008/R2, тогава ще получите грешка:

Процесорът на заявки не може да създаде план за заявка за заявка с подсказка за пространствен индекс. Причина: Пространствените индекси не поддържат сравнителя, предоставен в предиката. Опитайте да премахнете подсказките за индекса или да премахнете SET FORCEPLAN.

Както бе посочено, за да разрешите това, ще трябва да премахнете WITH (индекс (sidx_FishAndChips)) подсказка за индекс (и също така очаквайте вашата заявка да се изпълнява много по -бавно!). Вместо това може да се наложи да опитате един от алтернативните подходи за ефективно намиране на най -близките съседи в SQL Server 2008/R2.

Изпълнението на тази заявка трябва да отнеме няколко секунди (или, ако не създавате/използвате пространствения индекс, няколко минути), след което можете да проверите резултатите, както следва:

И тук имате пълната таблица с басейни, всеки изброен с името и разстоянието до най -близкия магазин за риба и чипс:

Тъй като е на по -малко от 100 метра от излизането от водата до торбата с чипс, ще си помисля, че ще се потапя следващия път в плувния басейн Farnworth….


Пространствена референтна система

Географската ширина и дължина се смятат за абсолютни стойности, които са общоприети, но това не е така. Например, първостепенните меридиани, или нулева степен на дължина, са доста произволни по своята същност. Обикновено се нарича линия Север-Юг, която минава през Гринуич, Лондон, Англия, но всъщност има четири различни първични меридиана, които са били използвани исторически и всъщност преминават през Гринуич. Дори настоящият първичен меридиан, който се използва от GPS системата (и повечето сайтове за картографиране в интернет), всъщност е на 102,5 метра източно от „официалната“ линия, която маркира иначе общоприетия първи меридиан.

След като знаете точните изходни точки на координатната система, която използва набор от данни, ние оставаме с друга дилема, когато се опитваме да изчислим разстоянието между две точки. Поради действието на Земята, която се върти около оста си, тя всъщност няма сферична форма, а по -скоро елипсоидална (тя е по -дебела в средата, отколкото при полюсите). Това усложнява способността за точно изчисляване на разстоянието и площта по еднакъв начин, но не прави невъзможно.

За да измерим разстоянието между две точки на земното кълбо, трябва да знаем радиуса на Земята (т.е. колко далеч е всяка точка от центъра на Земята). Проблемът е, че поради сухоземните маси Земята няма само един единствен радиус, който може да се приложи в световен мащаб. Ако измервате разстоянието между две точки, които са на една степен един от друг на морското равнище, ще получите различен резултат от две точки, които са на една степен един от друг в планините, които може да са на 5000 фута над морското равнище.

Така че, когато дадено място се изследва и точките се идентифицират от гледна точка на глобални координати, те се основават на модел на Земята, който е доста точен за тази локализирана област, но може би не е толкова точен другаде. Параметрите, които определят конкретния модел на Земята, са известни като пространствена референтна система. Важно е да знаете коя пространствена референтна система се използва за набор от данни, защото не винаги можете да смесвате данни от един набор с друг и да получите точни резултати.

С повсеместното разпространение на GPS данни бих казал, че най -често използваната пространствена референтна система днес е WGS84.


Свързани задачи

Създавайте, конструирайте и заявявайте геометрични екземпляри
Описва методите, които можете да използвате с екземпляри от типа данни за геометрия.

Създавайте, конструирайте и заявявайте географски екземпляри
Описва методите, които можете да използвате с екземпляри от типа данни за география.

Заявете пространствени данни за най -близкия съсед
Описва общия модел на заявка, който се използва за намиране на най -близките пространствени обекти до конкретен пространствен обект.

Създаване, промяна и отпадане на пространствени индекси
Предоставя информация за създаване, промяна и отпадане на пространствен индекс.


Улесняване на окото

Маркетинговият екип е много щастлив, че вече може да види къде се извършват всичките им продажби и следователно да взема по -добри бизнес решения. Съществува обаче проблем, тъй като някои области се справят по -добре от други и бутоните са една върху друга, което прави картата много трудна за четене. За да разрешим това и да улесним окото, ще използваме предимствата на функционалността за групиране на API. При включено клъстериране Bing Maps ще групира всички онези бутони, които са много близо един до друг и показват специална икона. Това позволява на потребителя да знае, че на това място има множество бутони. Ако потребителят приближи, API започва автоматично да разгрупира всички бутони. В този пример ще използваме същата заявка като последния пример и автоматично ще го свалим при зареждането на страницата. Единствената разлика е, че ние автоматично ще групираме резултатите и ще оставим потребителите да решат дали искат да видят кластеризирани или некластеризирани приставки. Фигура 17 показва GetMap javascript функцията, която се различава малко от предишната ни.

map.SetCenterAndZoom (нов VELatLong (43.79488907226601, -121.014), 6)

Фигура 17: GetMap JavaScript функция, която автоматично групира всички резултати.

За да включим клъстерирането, трябва да добавим слой в горната част на картата, да зададем конфигурацията за клъстериране на слоя и rsquos на VEClusteringType.Grid и добавете всички бутони към слоя вместо картата. Включването или изключването на клъстерирането е само въпрос на промяна на конфигурацията на клъстериране на слоя и rsquos Решетка да се Нито един. Фигура 18 показва как да направите това, а фигура 19 и 20 показват крайния резултат.

Фигура 18: Javascript за групиране и разглобяване

Фигура 20: Увеличено с оглед на групирани щифтове


Намерете най -близката дължина до входната дължина (SQL Server 2008) - Географски информационни системи

Мисля, че Microsoft трябва да покаже повече доказателства в подкрепа на това тълкуване на спецификацията. Това тълкуване ще има много високи разходи за клиентите по отношение на оперативната съвместимост и бариерата за възприемане на технологиите на Microsoft.

Останалата част от индустрията е тълкувала стандарта като lon/lat, ако Microsoft ще интерпретира това по различен начин, те трябва да предоставят защитно обяснение, обосноваващо защо те са една от единствените реализации, използващи lat/lon подреждане в SQL.

Разбирам, че мнозинството от членовете на OGC са тълкували този стандарт като lon/lat. така че дори и Microsoft да е прав в тълкуването си, комисията гласува значението на стандарта със своите клавиатури. Мисля, че би било неразумно Microsoft да води тази битка за спазване на изискванията, използвайки своята клиентска база-това трябва да се случи в задимените зали на срещите на OGC.

Можете ли да покажете къде този документ, страница, параграф и изречение, където се посочва, че стандартът се прилага само за равнинни системи или по друг начин изключва географските системи? Прочетох документа няколко пъти и колегите ми също го бяха прегледали. нищо не е накарало никой от нас да вярва, че географските критерии са изключени.

6.1 описва архитектурата на модела Geometry, който ясно заявява, че всеки геометричен обект е свързан с „quotSpatial Reference System“. това не ограничава това до проектиране на координатни системи.

Раздел 9 описва WKT представянето на пространствени референтни системи. Това обхваща както географските, така и проектираните системи. Никъде не ограничава спецификацията само до равнинни системи.

В допълнение Б.8 към SFA част 1 се посочва & quotlatitude_of_origin & quot & quot; географската ширина е избрана като начало на y-координатите & quot. фалшив изток/север имат подобна дефиниция. Този раздел противоречи на всяка представа за използване на CRS подреждане за X и Y, тъй като изрично дефинира X/Y в проектирана координатна система.

Как Microsoft разрешава конфликта, при който CRS може да проектира географската ширина в X вместо в географска дължина? Придържате ли се към определението, предоставено в стандарта, или се придържате към най-добрите практики?

Както беше посочено, WKT, както е определено от спецификацията на SFA, не използва подходяща нотация за непланарни системи. Така че, ако трябва да приемем, че Microsoft е прав и SFA се прилага само за равнинни, тогава би било нестандартно да се представя всяка географска координатна система, използваща WKT според SFA. В този случай Microsoft трябва да се придържа към стандартните стандарти.

Ако Microsoft реши да се справи сам в това изпълнение, бих предложил да го направим абсолютно ясноче SQL Server внедрява стандарта OGC 05-126, използвайки най-добрата практика от юни 2005/06-135r1 и че този стандарт се различава значително от OGC 99-049.

В такъв случай тогава трябва да има режим на съвместимост с OGC 99-049, който реализира конвенцията lon/lat. Когато използвате стандарта OGC 99-049, дълъг/широк е правилно тълкуване на стандарта, както е видно от сертификатите на OGC за други пространствени продукти.

Неуспешното включване на OGC 99-049 съвместима реализация би създало сериозен проблем с оперативната съвместимост, който би попречил на организацията ми да приеме SQL Server.

Разбираме проблема с оперативната съвместимост и търсим как да улесним преодоляването на тази пропаст. Нека се опитам да обясня защо взехме това решение. Като отправна точка:

Тези взети заедно изглежда хвърлят съмнение относно правилния начин за справяне с това. Стандартите обаче влизат в действие:

По време на заключителното пленарно заседание на ТК за юни 2005 г. присъстващите членове се съгласиха, че:

1. Занапред за нови спецификации стойностите на координатите се изброяват в реда на оста, както е посочено от референтната координатна референтна система (CRS).

2. Занапред, когато RWG работи върху редакции на съществуваща приета спецификация, свързана с CRS и ред на оси, стойностите на координатите се изброяват в реда на оста, определен от референтната координатна референтна система (CRS).

  • И накрая, стандартният EPSG списък на CRS, който приемаме за типа география, равномерно използва ред за географска ширина/дължина за всички географски координатни системи.

Осъзнаваме, че това ще причини някои проблеми на хората и търсим начини да ги смекчим, но се надявам, че това ще ви помогне да разберете нашите разсъждения.

Нека първо да повторя, че осъзнавам, че правим нещо малко по -различно от останалите играчи и че това причинява известна болка. Вслушваме се в приноса, който получаваме за това, и гледаме как можем да улесним импорта/експорта на данни между нас и други системи.

Въпреки това, не съм съгласен по отношение на стандартите. Мисля, че те казват много малко за географските координати и това, което казват, изглежда ни подкрепя.

Първо, нека да разгледаме OGC 99-049. Въпреки че съм съгласен, че те не заявяват изрично, че изключват географските системи, те казват, че & quotfeatures се основават на 2D геометрия с линейна интерполация между върховете & quot [началото на раздел 1]. Това ми показва, че работят в самолета.

Също така, ако приемем, че спецификацията обхваща географски координати, установяваме, че спецификацията е ужасно неадекватна. Напр .:

Също така имайте предвид, че въпреки че се опитваме да се придържаме към 99-049 колкото е възможно повече с нашия тип география, ние не се стремим към съответствие, което е само трудна цел с нашия тип геометрия. Ние бихме казали, че спазването на 99-049 за географските системи няма особен смисъл и бихме искали да видим стандарт, който да се отнася до географските системи.

И накрая, по отношение на 05-126, макар че цитатът, който издърпате, е точен, не го считам за релевантен: не мисля, че някой спори, че в (повечето) картографски проекции географската ширина е представена по оста y на сюжет. Намирам за интересно, че раздел 6.4.2 гласи, че & quot; Пространствена референтна система, наричана още координатна система, е географска (ширина дължина), проектирана (X, Y) или геоцентрична (X, Y, Z) координатна система. & quot [акцент мой]

С OGC 99-049 OGC сертифицира други системи за използване с географски координатни системи, използващи подреждане по дължина/ширина на ос за географски системи. Дори ако вашето тълкуване е правилно според буквата на стандарта, то е неправилно въз основа на практиката, прилагането и тестването на стандарта. Комитетът демонстрира намерението си да приложи този стандарт към географските системи.

Да-абсолютно сте прав, че 99-049 е ужасно недостатъчен за географски координати. Ако го накарам да звучи така, сякаш вярвам в друго, аз се извинявам, тъй като това никога не е било моето намерение.

Недостатъчността или неяснотата обаче не е умисъл. Вярвам, че действията на OGC wrt 99-049 наистина показват намерението на OGC при прилагането на този стандарт-и нищо, което казахте, не показва друго (вие посочихте това, което подозирах-стандартните стандарти на OGC са наполовина изпечени и има нужда от много работа, за да бъде & quotgood & quot). Освен ако не можете да докажете, че OGC неправилно е сертифицирала други системи или че тяхното сертифициране изключва географските части на внедряванията, тогава мисля, че позицията на Microsoft все още е погрешна.

Цитатът е доста актуален. Посочвам, че има неясноти в рамките на стандарта за геометричните системи-не само в географските системи. Как ще разрешите тези неясноти и/или конфликти? Или, по -важното, ще изберете изпълнение, различно от останалата част от индустрията?

Ако все още работите за спазване на 99-049 (Проста спецификация на характеристиките за SQL), тогава срещата от юни 2005 г. няма да се приложи (като стандарт, който предвижда тази среща-актуализациите не се считат за нови). Ако работите към 05-126/06-104r3 (Спецификация за внедряване за Geo Info-прост достъп до функции), тогава срещата през юни 2005 г. може да се приложи, тъй като това е нов стандарт, който замества 99-049.

Все още вярвам, че най-доброто решение е да се позволи на клиентите да избират дали искат да използват оттегления 99-049, както се прилага от останалата част от индустрията, или 06-104r3, както се прилага в Katmai от ноември CTP.

Моля, не забравяйте да отразите кой стандарт поддържате в помощните си документи, тъй като те изискват 06-104r3.

Не мога да добавя много към дискусията за стандартите. През годините, като ГИС мениджър, ги наблюдавах, за да видя дали ще бъдат от полза в организацията, в която работя, но ги намерих полезни само в областта на основната (имам предвид основната) оперативна съвместимост.

Сега това, което очаквам от Katmai, е функционалност и гъвкавост от перспективата за самостоятелна база данни. Проблемът, който имам въз основа на моя ограничен опит с подреждането по широчина/дължина на координатите в географския тип, е по -малко подреждането (Забележка: Google Карти използва Lat/Long - какво използва Виртуалната Земя?), Но че няма налични функции за картографиране между геометрия и география или гъвкав API за достъп до геометрията/географските обекти. Например, в момента не мога да актуализирам координатите на геометрия/география, освен чрез хакване на низове WKT (които са 2D ограничени и не включват SRIDS). Обърнете внимание, че казах UPDATE, а не READ. Да, можем да ЧЕТЕМ координати чрез STPointN, но не можем лесно да направим нещо като надграждане на 2D обект до 3D (или обратно), освен като използваме WKT. Забележете, че някои обработки на обекти не изискват да знаете дали обработвате външния или вътрешния пръстен на многоъгълник и част в многоделен низ.

Моят приятел Ананд Канан от MapInfo ми изпрати T-SQL, за да обърна XY, Lat/Long, който разчита на WKT за обработка на низ. Погледнах към писането на подобна функция и стигнах до същия извод: това ще изисква хакване на низове (скриптът на Ананд пристигна на следващия ден, след като бях решил, че няма да слизам по този маршрут). Това е грозно, бавно и има други трудности (напр. Интернационализация и използване на запетаи като десетични точки в Европа и т.н.).

Написал съм много и много допълнителни функции в PL/SQL на Oracle, точно защото имам достъп до всеки аспект на формата за съхранение. Не искам да пиша C# (за четене/запис на WKB или WKT) и да разгръщам кода в базата данни, ако мога да му помогна.

Така че, ако сме закъсали с подреждането на дълги/дълги мои основни молби е да видим много повече енергия, внедрена в базата данни за T-SQL обработка чрез много по-богат API, който в момента се покрива от всеки OGC или SQL/MM стандарт. Аз от една страна не искам да координирам GIS пакет за дебел клиент (дебел клиент не е за унищожаване) и процес на база данни, за да обработвам данни.

Радвам се да те видя тук! :-) Но трябва да не се съглася с горното: Редът на координатите за & quotLatitude / Longitude & quot (известен също като & quotlat / lon & quot) проекция в KML, дефиниран от Google, е lon / lat.

Позволете ми да превключвам, за да защитя Microsoft, който според мен е несправедливо разсеян в тази тема с дискусия за синтактичния анализ на OGC. Това не е смисълът. Въпросът е за нов тип, ГЕОГРАФИЯ, който може да улесни живота на някои потребители. Това е различна мисия от нещо като GEOMETRY, предоставено за използване със съществуващи GIS данни от опитни GIS хора.

Имам чувството, че някои хора, които четат тази нишка, са нови за геопространствените данни и не осъзнават, че общата английска фраза & quotLatitude / Longitude & quot data е точно противоположна на начина, по който данните всъщност са подредени в света на GIS данните. Не сте сами, ако това очаквате.

Това не е замислено като критика, защото вместо това е много солиден аргумент за това координатите да се подреждат така, както е в типа ГЕОГРАФИЯ, ако това наистина е предназначено за хора, които не са ГИС. Ако смисълът да имате ГЕОГРАФИЯ е да имате нещо за типове, които не са ГИС, подреждането (lat, lon) има пълен смисъл.

Най -естественото нещо в света за някой, който е нов в геопространствените данни, е да мисли, не, да * очаква *, че когато някой каже, че има данни & quotLatitude / Longitude & quot, че подреждането на координатите за тези данни наистина е в (lat, lon) ред само както английската фраза, която обикновено се използва за описване, казва, че е така. Хората, запознати с геопространствените данни, разбират, че английската фраза е просто фраза, а не математическо описание на подреждането на координатната ос, но начинаещите обикновено не знаят това. Manifold е продал повече тежки ГИС на нови потребители, отколкото всички други доставчици на ГИС, взети заедно, така че уверявам читателите, че това е много реално явление.

Част от това, което SQL Server може да направи чрез добавяне на пространствени разширения, разширява ползата от геопространствената технология за много по -широка аудитория. Microsoft има възможността да направи това, както другите доставчици не могат. Съчетаването на очакванията на геопространствените начинаещи (дори и да са експерти в СУБД, а изобщо не начинаещи в програмирането) с натрупаната практика в терабайта от ГИС данни не е лесно, но наличието на два типа е полезна иновация, която може да го осъществи.

Ако Microsoft може да направи живота по -лесен за хора, които са нови за геопространствените данни с подреждане на координати в GEOGRAPHY, което е различно от наследените GIS данни, това е напълно добре и достатъчно добра причина за мен. Каквото и да е, ние ще го подкрепим. Microsoft също е въвела GEOMETRY за тези, които използват GIS данни, така че няма недостатък за тези, които работят с GIS данни.

Както вече заявих, ако използвате GIS данни, по -добре е да ги съхранявате в GEOMETRY, за да не загубите съществена информация, като например дата, необходима за точност. Използвайте GEOMETRY с GIS данни, независимо дали е & quotLatitude / Longitude & quot проекция или не, и няма никакъв проблем с подреждането по координати. Затова моят съвет към Саймън би бил да използва ГЕОМЕТРИЯ и да се радва, че го имате.

Постскрипт за тези, които обичат обсъжданията на техническите подробности:

Просто за да знаят всички, че не капризно твърдя, че подреждането в GEOGRAPHY е ОК, защото не разбирам, че (lon, lat) подреждането е универсално, нека да цитирам някои примери и да коригирам някои погрешни схващания, които може да са се промъкнали в тази нишка, като се започне с идеята, че всеки трябва да се интересува какво прави OGC или погрешно схващане за това, което GML или EPSG определя.

Първо, OGC & quottandards & quot са почти безполезни в реалния живот. Исак удари нокътя по главата, когато пише & quot; Също така, ако приемем, че спецификацията обхваща географски координати, откриваме, че спецификацията е ужасно неадекватна. & Quot Добре казано!

Говорейки за почти безполезни OGC & quottandards & quot, който извежда GML, който е известен като "може би най-лошият формат за геопространствени данни, на второ място след брайловото писмо." Като се има предвид, че GML представлява може би по-малко от една милионна част от геопространствените данни не мисля, че изобщо има значение в практически смисъл каква координатна поръчка използва GML. Но ако разделяме космите и се преструваме, че GML има значение, трябва с уважение да не се съглася с предложението, че GML определя (lat, lon) подреждане.

Стандартът GML гласи, че редът на координатите трябва да следва този на проекцията. Не е много полезно от практическа гледна точка. Така че, въпреки че GML включва средства за изрично определяне на реда на координатните оси, той не избира изрично (lat, lon) ред над (lon, lat) ред. Във всеки случай използването на GML за данни за широчина/дължина е толкова рядко, че все още не сме видели GML файл в реалния свят с данни за ширина/дължина, независимо от реда на координатите.

Що се отнася до EPSG, аз също с уважение не съм съгласен, че това обикновено се третира като (lat, lon) подреждане: Момчетата от EPSG са проектирали своята система така, че осите, използвани от координатна система, са номерирани. Никога не съм чувал някой (Oracle и т.н.) да отразява реда на тези оси върху действителните координатни стойности. Виждам смисъла на SQL Server да го прави така, както го прави в GEOGRAPHY и уважавам това на 100%, но мисля, че всичко, от което се нуждаете, е, че това е как се прави в SQL Server, тъй като това как се прави там става de фактически стандарт, който ще следваме.

В миналото бях предизвикан да заявя, че (lon, lat) подреждането е & quotuniversal & quot практика в GIS данните, така че нека да уточня защо заявявам, че е така: Други забележителни формати, които използват (lon, lat) подреждане за така- наречени & quotLatitude / Longitude & quot проекции:

1. Координатите в наборите от данни TIGER/Line, произведени от Бюрото за преброяване на САЩ, са в лат./Дл. Редът на координатите е lon/lat.

2. Координатите в наборите от данни на NTAD, произведени от Бюрото за статистика на транспорта на САЩ, са в лат./Дл. Редът на координатите е lon/lat.

3. Координатите в GDF и други набори от данни, произведени от TeleAtlas, голяма европейска картографска компания, са на лат./Лон. Редът на координатите е lon/lat.

4. Координатите в наборите от данни VMap, създадени от Министерството на отбраната на САЩ, могат да бъдат в няколко различни координатни системи. За координатни системи ширина/дължина редът на координатите е дълъг/широк.

5. Координатите в SHP (ESRI & quotshapefiles & quot), MIF (MapInfo) и други файлове, произведени от текущите ГИС пакети, могат да бъдат в много различни координатни системи. За координатни/широк координатни системи редът на координатите е дълъг/широк в тези системи.

6. Координатите в DGN (Intergraph, Bentley), DWG (Autodesk и много други), DXF и подобни файлове, произведени от текущите CAD пакети, могат да бъдат в много различни координатни системи. За координатни системи ширина/дължина редът на координатите е дълъг/широк.

7. Координатите в стойности на WKB / WKT, съхранявани в традиционни бази данни като Oracle, DB / 2, PostgreSQL и MySQL (които нямат еквиваленти на типа GEOGRAPHY, но въпреки това се използват за съхраняване на много данни в текущо обръщение), могат да бъдат в много различни координатни системи. За координатни/широк координатен ред редът на координатите е дълъг/широк.

8. Изобразяването на координати в растер (екранът на Virtual Earth е пример за това) почти винаги следва XY нотация, която за растер lat/lon почти винаги означава lon/lat.

9. Когато хората започнат да използват SQL Server 2008 за съхранение на пространствени данни, много от тях ще използват типа GEOMETRY, въпреки че данните им са на ширина/дължина, по различни причини. За тези хора редът на координатите отново ще бъде lon/lat и този ред ще бъде запазен, когато тези данни се използват в продуктите на ГИС.

Уау! . това имам предвид под & quotuniversal & quot употреба, както съдържат горните формати, какво? 99,99%? на данните там. Ако някой може да посочи дори едно -единствено хранилище на данни & quotLatitude / Longitude & quot, което използва (lat, lon) подреждане вместо (lon, lat) подреждане, ще съм много благодарен да види URL адреса на това хранилище.

За всичко по -горе изборът на Microsoft за поръчка за GEOGRAPHY е на място, ако наистина това може да помогне на хора, нови за геопространствените данни, които приемат фразата & quotLatitude / Longitude & quot буквално, както обикновено правят. Колкото и да се гордее с използването на ГИС досега, дори 100% от всички тези данни не са 1% от това, което идва, тъй като геопространствената технология се превръща в мейнстрийм, така че това, което хората, които са нови в областта на изкуството, не очаква леко да се отстъпва .

Ако бях аз, вероятно щях да съм конвенционален и да се придържам към (lon, lat) поръчки. Но тогава няма съмнение, че бих се заел със задачата да обяснявам отново и отново на стотици милиони хора в бъдеще (нито един от които няма да чете никаква документация), че под & quotLatitude / Longitude & quot наистина исках да разберат че трябва да поставят координатите си в ред & quotLongitude / Latitude & quot. Всеки, който критикува Microsoft при този избор, трябва да помисли два пъти как биха се справили с това.


Ако приемем, че колоната е индексирана, следното трябва да бъде разумно ефективно.

С две търсения по 10 реда и след това нещо като (до) 20 върнати.

(т.е. потенциално нещо като по -долу)

Или друга възможност (която намалява броя на сортираните редове до максимум 10)

NB: Горният план за изпълнение е за проста дефиниция на таблица

Технически, Сортирането в долния клон също не трябва да е необходимо, тъй като това също е наредено от Diff и би било възможно да се обединят двата подредени резултата. Но не успях да реализирам този план.

The query has ORDER BY Diff ASC, YourCol ASC and not just ORDER BY YourCol ASC , because that was what ended up working to get rid of the Sort in the top branch of the plan. I needed to add the secondary column in (even though it won't ever change the result as YourCol will be the same for all values with the same Diff) so it would go through the merge join (concatenation) without adding a Sort.

SQL Server seems able to infer that an index on X seeked in ascending order will deliver rows ordered by X + Y and no sort is necessary. But it is not able to infer that travelling the index in descending order will deliver rows in the same order as Y-X (or even just unary minus X). Both branches of the plan use an index to avoid a sort but the TOP 10 in the bottom branch are then sorted by Diff (even though they are already in that order) to get them in the desired order for the merge.

For other queries/table definitions it may be trickier or not possible to get the merge plan with just a sort of one branch - as it relies on finding an ordering expression that SQL Server:


How to Best Implement nearest neighbour search in mysql?

I have 100k biz record each with lattitude and longitude. I see that MySQL actually support a data type called point. Should I use that instead?

Is it best to use point data type rather than regular float data type to store latitutude and longitude?

Eventually I want to find things like the first 100 restaurants closest to points 105,6 for example and my databases contains a lot of biz and points. Obviously computing the distance one by one for every records and for every points would be O(n) and hence sucks.

Notice that I am aware of a simpler solution described in How do Application Like Yelp Retrieve distance information from data base efficiently and will implement that my self too for a start. That's a good answer.

However, I think there is one creme of the crop answer that should outperform that right? In fact, storing location based on latitude and longitude and finding stuffs nearest to it is a very common problem I expect mysql to have a special design pattern for that. Does it have that?