dusterio Jul 2 2016 at 11:42

Пакет-географ – первая рабочая версия

6 min

24K

Website development *PHP *Geoinformation services *Laravel *

+33

Comments 42

zenn Jul 2 2016 at 12:05

В принципе, вполне годная для использования библиотека, код вполне качественный, да и использовать удобно. Но возникло, как говориться одно «но»:

"php": ">=5.6.0"

да, php 5.5 сейчас уже вышел из «active support» и перешел в «security updates only», но некоторые твердолобые до сих пор его используют и объяснить им что срочно необходимо обновляться до 5.6/7.0 проблематично. Есть ли возможность ввести поддержку 5.5?
Еще 1 вопрос о поддержке laravel/lumen — может стоит оформить отдельным пакетом, а базовый выделить как «standalone» и его уже использовать в require для пакета laravel/lumen?

dusterio Jul 2 2016 at 12:18

Ох, я сходу уже не помню – там что-то требовало 5.6. У меня изначально стояло 5.5, пока не наткнулся :) Я проверю в общем!

Про Laravel/Lumen — да, вероятно вы правы. Кроме того, там настолько простая интеграция — её чуть ли не проще в документации описать :)

zenn Jul 2 2016 at 12:31

Я смотрел, правда очень бегло, но не нашел массового использования основных «фишек» 5.6 — плавающего кол-ва параметров аргументов фу-ии или использования «default», отлова «несуществующих» каллбэков тоже вроде не заметил через try-catch над object, deprecated function вам вовсе рано использовать, так что вам думаю видней в чем там загвоздка была.

dusterio Jul 2 2016 at 12:33

Вспомнил — у меня тесты все в Travis запускаются. И изначально там 5.5 стояло в том числе — оно фейлилось как раз. Сейчас верну в Travis 5.5 и увижу :)

dusterio Jul 2 2016 at 12:40

Нашел — это PhpUnit 5-ый не поддерживает 5.5. Сейчас попробую в 'require' сделать 5.5, а в 'require-dev' 5.6.

В общем, я уже закомиттил и пометил

dusterio Jul 2 2016 at 16:35

Нашлась-таки одна мелочь, не поддерживаемая в 5.5 – в static properties нельзя было использовать оператор конкатенации (.).

Теперь проходят тесты на 5.5

zenn Jul 2 2016 at 16:53

Да, видел, вы это, из теглайна и релизов удалите старый с «support php 5.5» и создайте его снова, чтобы в 'stable' нормально стягивало.

dusterio Jul 2 2016 at 16:58

Ага, готово

ITMatika Jul 2 2016 at 16:35

Вот бы ещё интеграцию с КЛАДР/ФИАС! Но боюсь, что проще будет запилить отдельную библиотеку…

dusterio Jul 2 2016 at 16:36

Подозреваю, что это настолько массивная задача, что должна быть Git под-модулем. Вообще, всё, что не глобальное — должно быть опциональным, а не входить в основной пакет

Delphinum Jul 2 2016 at 17:51

Достаточно в вашем пакете выделить логику чтения и преобразования исходных данных о странах/регионах/городах в интерфейсы, и пользователи сами припишут нужные адаптеры для чтения данных из КЛАДР, а не из массивов.

VolCh Jul 2 2016 at 23:31

Или, как вариант, из базы, доступные редактированию пользователям.

dusterio Jul 3 2016 at 03:40

Базы и так доступны к редактированию :) Выбран формат JSON специально, чтобы было удобно редактировать прямо через web-интерфейс GitHub:
https://github.com/MenaraSolutions/geographer/blob/master/resources/translations/country/ru.json

Долгосрочный план — что пользователи из разных стран сами будут постепенно улучшать базу

Но скорее всего базы надо вынести в отдельные репозитории, чтобы отделить возможные библиотеки на других языках от контента

dusterio Jul 3 2016 at 03:42

там же в КЛАДР, насколько я понимаю, глубже иерархия — улицы и дома.

про интерфейсы Вы правы, спасибо за замечание

webmoder Jul 4 2016 at 17:39

В дальнейшей перспективе неплохо было бы прикрутить (улицы и дома).

t3hk0d3 Jul 3 2016 at 03:35

Честно говоря хотелось бы немного покритиковать API.

В примерах меня сильно удивило следующее:

return Geographer::findOneByCode($countryCode)
->setLanguage($language)
->getName();

Если Geographier::findOneByCode() возвращает объект страны то метод setLanguage вызывает попаболь.
Любой человек подумает что вы меняете язык у страны, а не локализацию строк. Но даже setLocale/getLocale вызвало бы одно недоумение.

Имхо более разумный подход с локалями:

Geographer::setDefaultLocale = 'ru'
…
Geographer::Country::findByCode($countryCode)
->getName($locale);

dusterio Jul 3 2016 at 03:39

Это дело вкуса, я думаю. Очевидно же, что язык, на котором говорят люди в стране, нельзя поменять методом в ООП :)

Насчет второго замечания — это и так возможно: Geographer::setLanguage('ru')
Так как это singleton во фреймворках (Laravel и др), то изменение настроек отразится на всех последующих вызовах

Я еще подумаю насчет language vs locale, спасибо за мысль!

t3hk0d3 Jul 3 2016 at 15:51

C точки зрения API Язык в стране можно поменять — это всего лишь данные.

Но если есть setLanguage, то я так понимаю getLanguage присутствует тоже, верно? А вот тут уже начинает один сплошной конфуз.

ИМХО все таки локалализация строк в результатах методов не должна быть свойством объекта.

dusterio Jul 3 2016 at 15:55

Хм, Вы правы — конфуз есть ;-) getLanguage() есть только у страны, но тем не менее.

На объектах городов-областей-стран этот метод для удобства, он в нем не реализован. Идея в том, чтобы можно было на любой стадии «исправить» положение. Это достаточно распространенная практика

t3hk0d3 Jul 3 2016 at 16:04

Если смотреть по use-кейсам то получается что в большинстве случаев локаль достаточно установить один раз за запрос. Исключение — получение нативного имени, однако тут лучше сделать отдельный метод getNativeName().

Russia (Россия)
Japan (日本)

dusterio Jul 3 2016 at 16:07

В большинстве случаев — да

Что если надо вывести названия одной и той же страны на разных языках? :) (не только на текущем и нативном)

Я, кстати, не спорю. Я с этой целью и публиковал статью, чтобы ценные рекомендации получать :)

t3hk0d3 Jul 3 2016 at 16:20

Если надо вывести название страны в произвольной локали — то есть опциональный параметр метода, например getName($locale = NULL), что я и пропагандирую :)

Предлагаю взглянуть на аналоги:
https://github.com/hexorx/countries

dusterio Jul 3 2016 at 16:24

Да, логично. Возможно, на этом и остановлюсь! :)

Когда я начинал делать библиотеку, я даже не знал — будут ли еще какие-то куски информации переводимыми. Поэтому я последовал старому правилу «не оптимизируй заранее»

А сейчас все похоже на то, что только имена и переводятся. Вполне логично туда локаль (язык) и вставить

iqiaqqivik Jul 4 2016 at 10:55

applyLanguage и/или useLanguage

dusterio Jul 4 2016 at 10:56

я пока таки склоняюсь к setLocale() и к возможности дать параметром в getName()

UFO just landed and posted this here

kashey Jul 3 2016 at 16:31

Вы конечно молодцы, и выпустили удобный продукт… Но давайте класс Earth отправим на глубокий рефактор.
Есть список макрорегионов (https://ru.wikipedia.org/wiki/Макрорегионы_мира_(ООН)), на основе которого и надо именовать методы.
Регионов дефакто немного больше, они немного по другому разбиты. И Micro — это микронезия, не надо ее обижать.
PS: Связь стран и макрорегионов можно взять из экспорта http://data.esosedi.org/

dusterio Jul 3 2016 at 16:37

Сейчас есть только континенты в Earth, и они определены международным обществом :)

Не уверен, что кому-то пригодится вывести список стран макрорегиона? Если честно, даже и про континент не уверен – просто это было в исходной базе Geonames, не стал убирать.

Вы можете привести пример, когда будет полезно вывести список стран макрорегиона?

По поводу семантики в случае с 'micro' — мне самому вариант не понравился, но ничего лучше не нашел. Мысль такая, что большинству разработчиков в большинстве случаев не нужны крохотные страны с крохотным населением. Искал термин для таких стран (а ля Гибралтар) — не нашел. Но префикс «микро» иногда используется: https://en.wikipedia.org/wiki/European_microstates

jabocrack Jul 4 2016 at 10:56

1) подозреваю, что коды стран все-таки по ISO 3166, а не по ISO 3611
2) хотелось бы поддержки кодов стран по ISO 3166 numeric, а не только ISO 3166-1 alpha-2 и ISO 3166-1 alpha-3

dusterio Jul 4 2016 at 11:00

Точно — не помню откуда copy/paste сделал такой. Сам усомнился — а теперь точно вижу что там была ошибка.

Цифровые добавим сегодня-завтра, спасибо за совет!

dusterio Jul 4 2016 at 11:56

Поправил первый пункт и добавил цифровые коды, спасибо еще раз

nikolay_karelin Jul 4 2016 at 11:55

Интересное решение, спасибо!

Есть два предложения:
1) Отделить библиотеку от ресурсов (т.е. другой репозиторий для ресурсов), чтобы можно было делать другие реализации, например, на другом языке программирования, и
2) (Попробовать) использовать для перевода формат gettext — в нем сразу содержится и оригинал и перевод, что на мой взгляд гораздо удобнее для поддержки переводов, чем возня с цифровыми кодами.

dusterio Jul 4 2016 at 11:56

Первое уже запланировано, и в статье где-то упоминается вскользь :)

Про второе неуверен — gettext, насколко я знаю, популярностью ныне не пользуется, входной порог будет выше

nikolay_karelin Jul 4 2016 at 12:06

Ясно, спасибо! Я видел упоминание, но потом посмотрел на репозиторий, и получил непонимание :)

И надо будет поискать что-то дружественное, но современное для переводов.

sango Jul 5 2016 at 01:26

А где вы берете данные?

dusterio Jul 5 2016 at 01:27

Geonames, Wikipedia и бесплатные онлайн-словари

morozovsk Jul 6 2016 at 11:34

При достижении достаточной популярности, можно ожидать от пользователей разных стран внесения поправок в переводы через pull-запросы – справочники будут сами постоянно улучшаться, подобно wiki.

Не пробовали osm? Пользователи разных стран уже вносят туда правки ежедневно. Все данные доступны для экспорта. Есть переводы городов на множество языков. Есть координаты городов, что даёт возможность создать геоиндекс, о котором вы писали в статье.

Я изначально тоже собирал из Geonames, Wikipedia и других источников, но как всё это потом обновлять и поддерживать в актуальном состоянии? В тоже время сообщество osm достаточно активное, т.о. можно не дублировать работу по актуализации данных.

dusterio Jul 7 2016 at 11:23

Немного порылся и пока не нашел источников у OSM :(

Координаты у меня уже есть, они все в базе. Алгоритм простой для геоиндексации тоже придумал

morozovsk Jul 7 2016 at 12:33

Например, можно выкачать данные здесь: http://planet.openstreetmap.org/
А с помощью osmosis можно извлекать только те данные, которые нужны http://wiki.openstreetmap.org/wiki/RU:Osmosis

dusterio Jul 7 2016 at 12:54

Догадываюсь, что у них нет склонений — им они не нужны?

Как обстоят дела с областями — есть ли все области всех стран мира? У Geonames с этим туго, сейчас приходится с Wikipedia скрейпить

morozovsk Jul 7 2016 at 14:31

Догадываюсь, что у них нет склонений — им они не нужны?

Да и не во всех языках они есть. Но у меня нет под руками данных, чтобы посмотреть, есть ли они в базе.

Как обстоят дела с областями

С этим у них гораздо лучше, чем у других гео-проектов. У них есть не только области, у них есть все точки их границ. Есть границы городов и их районов. В городах есть остановки и даже просто лавочки.
Это большое сообщество как википедия и оно вносит каждый день огромное число данных.

dusterio Jul 7 2016 at 15:08

Ну, границы — это уже наверное лишнее для меня :) Все-таки я не пакет для картографии предлагаю, а просто базу данных административных делений

А вот области обязательно посмотрю. Если у них имеются коды вроде ISO/FIPS/Geonames — смогу автоматически импортнуть