Доступен первый публичный выпуск модульного ГИС-движка Turf (http://turfjs.org/), написанного на языке JavaScript и пригодного для использования в браузерных web-приложениях и серверных программах на базе Node.JS. Обработка геопространственных данных осуществляется с использованием формата GeoJSON. Код проекта распространяется (https://github.com/Turfjs/turf) под лицензией MIT.
Для Turf подготовлена (https://github.com/Turfjs/) большая подборка модулей c реализацией средств для расчёта вхождения точек в области, пересечения областей, вычисления расстояний между объектами, определения площади и размера объектов, нахождения оптимальных путей, фильтрации данных, работы с различными геометрическими объектами, решения задач по интерполяции, преобразованию и классификации.URL: https://news.ycombinator.com/item?id=8793266
Новость: http://www.opennet.me/opennews/art.shtml?num=41339
Может, вот оно будущее?! JS - "цветет" и "пахнет"!
Системы контроля за транспортом по GPS модулям давно и плотно сидят на node.js. Участвовал в проекте для конторы с парком в десятки тысяч машин, забавно было в секунду принимать сотни тысяч UDP пакетов, парсить их и писать в базу. Языки с блокировкой I/O захлебнулась бы, а тут на простеньком по нынешнем временам однопроцессорном сервере все стабильно работало.
> секунду принимать сотни тысяч UDP пакетовправда? на ноджс? прям сто тыщ?
А почему нет? Позже добавили еще серверов и сделали кластеризацию. Можете посмотреть вакансии для таких проектов по миру, везде требуют знание node.js
А какая бд? я давненько ищу что-нить под похожую задачу, но что-то все не то, ноджс давненько ковырял, на тот момент он мне не понравился.
MongoDB
мда, почему-то так и думал.
Просто парсить и просто класть в базу. И то наверно не напрямую. Тут да, JS даже не тормозит.
Парсится побитово благодаря модулю Buffer, в чистом JS его нет, но есть в node. И, да, не тормозит.
Я подобное делал на чистом си и epoll.
Совершенно не тормозило на обычной машине, не сервере.
Асинхронники вещь давно известная, нода тут не при чем, важна сама технология. А использовать ее можно на любом языке. Может и не напрямую, а с помощью очередей и воркеров, но можно.
Это понятно, что можно, async модули есть к большинству языков, но в node это есть "из коробки", достаточно гибко и быстро. Плюс node обслуживает множество коннектов не хуже nginx, были сравнения.
curl -I nodejs.org
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 25 Dec 2014 11:35:26 GMT
Content-Type: text/html
Content-Length: 6021
Last-Modified: Wed, 24 Dec 2014 01:35:16 GMT
Connection: keep-alive
Accept-Ranges: bytes
И? Какое отношение html/статик-контент имеет к обсуждаемой теме?
К теме - никакого. К тому, что "node обслуживает множество коннектов не хуже nginx" - есть некоторое отношение, я полагаю.
Nginx там в роли прокси, для обслуживания кластера.
Так если ноджс не хуже - не понятно зачем там нжинкс :)
Кто-то же должен проксировать входящие соединения. У каждого воркера в кластере свой порт.
> но в node это есть "из коробки"С одной стороны да, с другой: в языках это уже давно есть. К тому же коллбечные асинхронники тоже прошлый век. Есть короутины.
А в node есть промисы/деферы. Кому что удобней.
> Языки с блокировкой I/O захлебнулась бы, ...не путайте язык с api.
на всех разумных языках - на тех же сях, например, - всегда была возможность работы с функционалами.
в сях это указатель на функцию.
единственно что лямда-функции поддерживаются не везде и тогда приходится выдумывать им имена.
и второе единственное - для использования функционалов в структурах бывает нужно точно определять тип функций.
в сях, напр., так:
typedef int (*our_fn_t)(int, char*, void*);
-- для использования в структурах в виде
our_fn_t *fn;
привсоение значения в виде
obj.fn = &some_function;
если int some_function (int a, char *s, void *p) { ... },
и вызов в виде
(*obj.fn)(args);
асинхронность в таком случае реализуется передачей функции, осуществляющей что-то асинхронное, указателя на функцию или структуру с укзателем на функцию.
после завершения чего-то асинхронного функция вызовет функцию-обработчик, переданную в аргументах.
с калбэками все же максимально неудобно.
в сях есть брутальные полноценные корутины.
> забавно было в секунду принимать сотни тысяч UDPНе верю!
GPS-трекеры дают очень мало данных, типовой случай - в пути на каждые 200 м., при повороте на > 5 гр., тревогах.
На стоянке через 1-5 минут.
Конечно зависит от настроек, но порядок понятен, полагаю.
Ограничениями скорее служат тарифы сотовых операторов, на gprs разориться можно.
Так что с десятка тысяч машин придет разве что тысяча пакетов в секунду в худшем случае - все в рейсе, едут и т.д.
Чего никогда не бывает.
+ почти все трекеры могут группировать неск. сообщений в один пакет, покрытие не везде, сбрасывают данные при появлении связи.> добавили еще серверов и сделали кластеризацию
ИМХО - показатель неэффективности ноды.
Для такой нагрузки достаточно обычной машины (plain c + epoll)
не может быть чтоб скриптовой язык нацеленный на исполнение в спец среде был быстрее компилируемых языков. да может быть удобен в коротких вызовах программ или узкоспецифичных вещах, но никак не как самостоятельный языкдля написания программ. помойму это должно быть ясно всем. как говорится можно и тупым ножом резать хлеб, но разница в усилиях будет очевидна. так и тут.
Никто и не говорит о (прикладных) программах, тут имеется ввиду серверное применение.
Угу, всем понятно. Но... у скольки процентов острые ножи?
по факту - может.
пример - Форт.
а вообще под сабж на чем только не писали. экзотика с модулой-2, Адой или Обероном - смотрится вызывающе. жаба с ноде.жс - тоже не так чтобы мизерно по оверхэду.
вопрос не совсем по сабжу, может кто подскажет хорошую биюлиотеку/фреймворк/движок для GIS-запросов к БД(ОРМ), манипуляцию с конвертацией различных форматов GIS для Golang?
По моему до leafletjs ему еще далеко...