Интеграция с Notimaps

[kityan]

Коллеги, кажется почтой ни до кого не достучаться, а ответивший [email protected] отправил меня сюда.
Позвольте уж изложу, хотя мне кажется это может быть расценено как спам. Ну, значит, удалите.

В общем, мы запустили проект notimaps.com, который позволяет подписываться на участки карты и получать уведомления о новых точках и полигонах, которые там появляются (пока только в телегу). Мы ориентированы на интеграцию с большим количеством очень разных источников. В том числе хотелось бы интегрироваться с вами — с вашим потоком новых точек. Детали я уже несколько раз изложил письмом, но уточню по запросу. Мы готовы это делать безвозмезндо. А вы с одной стороны сможете довести информацию до людей, заинтересованных в конкретных местах на карте, но может быть не знающих про PastVu. С другой — ваша текущая аудитория может использовать сервис подписки, если захочет.

Нам всё понятно насчёт API, но есть несколько технических уточнений и главное — ваше разрешение. Пока мне не удалось получить никакого ответа...

[aeifn]

Я думаю, что нет никаких существенных препятствий для агрегации данных с PastVu. Единственное, метода для запроса последних добавленных точек нет, его нужно будет дописать.

[kityan]

Именно так. Я бы даже сказал, что нужно только одно — крайний актуальный идентификатор. Остальное можем и перебором, если такая нагрузка будет приемлема. Просто сейчас если идти перебором без знанания этого конечно cid, непонятно как обработать ситуацию, когда данных нет — это конец или пробел из-за (насколько я понял) отклонённых/удалённых фотографий.

Я ещё надеялся — может быть есть лента свежедобавленных, но нашёл только ленту свежих комментариев.

Так что вот эту деталь и хотелось уточнить. Спасибо за ответ!

Мы планировали сделать так: на первой итерации получить последнее актуальное значение cid. На всех последующих — раз в 12 или 24 часа, запрашивать новый cid и последовательными вызовами giveForPage вытаскивать всю выборку. Если мы до этого момента дойдем-таки, ещё уточню правильно ли я понял, какие поля JSON мы можем зайдействовать, чтобы собрать у нас заголовок объекта (текст + годы). Ну а пермалинк на вас формируется очевидным образом из cid.

[kityan]

Либо другой вариант: giveForPage должен явно дифференцировать случаи, когда запрос сделан к материалу, который ещё не существовал от случев, когда материал был, но его удалили/отклонили. Тогда мы просто сможем идти до ошибки первого типа, игнорируя ошибки второго. Сейчас она единая, как я понял: NO_SUCH_PHOTO.

Посмотрю в код репозитория внимательно. Пока просто рассуждаю на основе документации.

Хотя этот вариант конечно хуже в плане возможности сломать кому-то, кто уже пользуется вашим API, совместимость по коду ошибки.

[kabalin]

Просто трудно найти время вам ответить :)

Для потока новых точек вы можете использовать незадокументированный метод https://pastvu.com/api2?method=photo.givePS&params={"limit":100}, это те же данные что используются в галереи. Для анонимного пользователя он отдает последние max 100 публичных фото (сортированных по времени, первая самая новая). Эти фото/картины уже прошли модерацию, опубликованы и доступны всем. Вам придется самому отсекать часть данных, которые вы уже обработали в предыдущем запросе.

При запросе по cid (https://pastvu.com/api2?method=photo.giveForPage&params={"cid":5}), свойство type указывает тип изображения - 1 - фото, 2 - картина. Это вам возможно пригодится. Остальное из описанного в письме вроде бы вы все поняли правильно.

[kabalin]

Еще можно взять только фото (исключить картины) https://pastvu.com/api2?method=photo.givePS&params={"limit":100,"filter":"t!1"}. Формат фильтра можете подсмотреть (или сгенерировать) открыв галерею https://pastvu.com/ps и изменяя различные параметры (параметр &f=... в строке запроса будет показывать примененный фильтр).

[kityan]

Тем более благодарю за ответ. Просто совсем без ответа непонятно — то ли в спаме, то ли в игноре, почта — дело такое.

Насчёт типизации изображения — спасибо, картины скорее всего не будем брать
Помнить, что взяли и отсекать данные самим — разумеется. Мы так и делаем в парсерах, которые сейчас пишутся. API мало у кого есть.

Но вот я взглянул на ответ метода givePS — если точки отсортированы по датам, то непонятно почему очередность cid не соблюдена. И у первого - самого нового - cid меньше, чем у некоторых ниже по массиву. Как будто какие-то застряли на этапе модерации надолго :)

Благодарю за совет, попробуем из ответа этого метода выяснять максимальный cid. будем периодически запрашивать выборку последних 100 и у себя соответственно отмечать, какие уже обработаны.

[kabalin]

Cортировка по времени публикации. Модерация распределенная, по регионам и городам - где-то обрабатывается быстрее, где-то медленнее, кое-что еще и отклоняется. В общем на очередность cid вы не рассчитывайте :)

[kityan]

Коллеги, ещё раз благодарю за отклик и пояснения, запустили агрегацию — пока без проблем.