|
|
|
карты +
|
|||
|---|---|---|---|
|
#18+
Dima TЭто лишнее Код: sql 1. напутал, не лишнее, так хотел написать Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 16:23 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
ок >ЮИ еще вопрос, если отсюда выкинуть условие "and t.px <= П and (t.px + z.pw ) >= Л", то много выберется записей? т если карта существенно шире запроса, то много лишних. потестить надо, но карты лежат на флопиках, в парадоксе, насколько я помню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 16:45 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
2а) множество одинаковых квадратов (или прямоугольников) области накрытия, половинками по вертикали накладывющиеся друг на друга - специальное накрытие карты, для каждого из масштабов. вид со стороны оси y Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Для текущего масштаба М будем вынимать области из масштаба М-1 и выше до Ласт (пусть от 0 до 16, 16 масштабов достаточно). Чем выше номер масштаба, тем больше размер тайлов. список проекций увеличится в два раза от 6 до 26. В худшем случае Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. на 15 масштабе 14 26 15 13 из 38 точек. от 40 до 80 точек. получаем вместо 1 селекта объединение до 16 или последовательное выполнение до 16 селектов. поскольку индекс начинается с масштаба - запросы идут по возрастанию Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 17:27 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
3) множество неодинаковых прямоугольников надо рассовать прямоугольники по областям накрытия, в зависимости от размера прямоугольника. таблица областей ниразу не нужна, нужна таблица обьектов, которые рассортированы по областям накрытия, в разные масштабы, в зависимости от вхождения объекта. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. и нужны функции а) пересчета реальных координат в условные пиксели LngToX: Int -> Int и AttToY: Int -> Int б) пересчета реальных координат в координаты областей накрытия SzToEnv: (Int >< Int) >< (Int >< Int) -> UChar >< (Int >< Int) по реальному левому верхнему и правому нижнему углу прямоугольника на местности получить масштаб и левый, верхний угол области в условных пикселях. Грубый отбор прямоугольников == 16 запросов меняются на такие .f Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. .^ дальше по первому запросу строим любезно подсказанное Майтоном РдеревоМатьЕгоТак с грубо отобранными прямоугольниками и их айдями, которое и используется для окончательного отображения в окне тайлов карты и считанных объектов в условных координатах. Если рамка запроса сдвигается и или меняется масштаб - то надо, в рДеревеМатьЕгоТак, стереть объекты (или не стереть если много памяти) не попадающие в новый запрос прямоугольники, а затем дочитать новые. фух ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 18:12 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
tchingiz поскольку индекс начинается с масштаба - запросы идут по возрастанию Думаю оптимизатору пофиг как они идут - как идут так и будет выполнять (отдельно каждый сам по себе) и склеивать результат. В данном запросе я бы точно выкинул zoom, т.е. сначала Код: sql 1. затем сгенерить запрос только из environs с кучей union. что-то конкретнее сказать не могу, плохо соображаю вечером, утром еще гляну. Не надо считать индекс панацеей для оптимизации, он хорошо ускоряет запросы если помогает выбрать 3-5% записей, если больше, то индекс может превратится в тормоз, т.к. полный скан таблицы быстрее, чем получить из индекса указатель на запись, проверить соответствие остальным неоптимизируемым критериям, получить из индекса указатель на следующую запись и т.д. Поэтому не всегда надо максимально подходящий индекс. Возможно менее полный индекс окажется быстрее. я про (zm, py) вместо (zm, py, px) В любом случае надо тестить на реальных данных, смотри план выполнения запроса, там видно что будет в реале: использован индекс или скан по таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 18:49 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
http://gis-lab.info/projects/osm_dump/index.html конвертилка osm - sqlite3 если не лень, ткните пальцем как с опенстрит скачать карту, например, киевской области - ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2014, 14:31 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
список прямоугольников, содержащих линии на карте киевской области http://agp1.hx0.ru/kbd/kr.zip и УССР http://agp1.hx0.ru/kbd/USSR.zip сами точки http://agp1.hx0.ru/kbd/kievRegion.1.zip http://agp1.hx0.ru/kbd/UkSSR.1.zip ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2014, 13:31 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
ну, вот так выглядела в 1994 году ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2014, 13:47 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
tchingizну, вот так выглядела в 1994 году Похоже на телёнка с крыльями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2014, 15:03 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
а мне медвеженка напоминал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2014, 16:47 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
maytonА чего кверху ногами? потому что на экране вертикальная координата увеличивается от нуля вниз. пысы оно еще пока зеркальное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2014, 16:48 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
Прям какой-то тест Роршаха. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2014, 16:53 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
нагенерировали первую версию бд на sqlite из этих файлов на бд удалось протестировать схема спай (schemaSpy_5.0.0.jar ) генератор документации по схеме бд. в частности получилась такая картинка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2015, 18:02 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
SQLite летает аж свист стоит, с парадоксом из 96 года не сравнить. тут 25 тыщ линий и полмиллиона точек, может и не надо морочить голову с ускорением запросов? -- на sqlite вся бд отображалась за 22 секунды, из файловой системы за 10 мин, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2015, 17:59 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
в таблице sgmstr по паре (sgm, sgmPoint) пришлось индекс сделать, ибо Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2015, 18:04 |
|
||
|
карты +
|
|||
|---|---|---|---|
|
#18+
на бд с киевской областью (50к сегментов и 1 млн точек) тестировали скорость выполнения запросов по выбору точек из таблицы SgmStr либо из блоба таблицы Segment для разного количества точек в запросе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 22:44 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38970080&tid=1340983]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
169ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 506ms |

| 0 / 0 |
