Всё что надо, чтобы получить лучше чем это, это разместить точку POI внутри полигона здания. Всё остальное получается автоматически и является задачей клиента. Можно даже такой же список вывести. Определить какие POI находятся в здании можно простым геометрическим алгоритмом.
А почему лучше? Потому, что остаётся еще и информация в какой части здания находится POI. Это удобно, если здание большое и имеет множество входов. А в викимапии места для этой информации нет.
Порог вхождения в OSM и так ниже плинтуса! Откройте OpenStreetBugs найдите место, кликните мышкой и опишите что там не так. Обычно занимает 10-15 секунд. Кривая обучения — вы всё уже умеете. Регистрация не нужна. Знание тегов не нужно. Поставили багу => уже помог проекту.
А потлач и тем более JOSM не определяют порог вхождения, а, скорее, высоту роста после вхождения. Последний — это вообще photoshop в OSM. В нём можно, используя клавиатуру, вносить информацию в сумашедшем темпе. А источники информации не ограничиваются только снимками. Там есть и треки и фотки и подложки и аудио метки и интеграция с OpenStreetBug и еще куча всего. И, как и фотошоп, он трубует обучения. Потлач и флешная компания — эта серединка.
Интересно, какая вероятность того, что все андроидоводы расчехлят свои патенты и подадут на MS в суд? Ведь не очень же умно ждать, пока MS будет разбиратся со всеми по одному, а вместе это уже сила.
Технически невозможно :) Чтобы ZFS всё дедуплицировало, нужно как минимум скопировать файл на сервер. А тут даже копирования не было. Похоже собственные проверки. Что-то типа rsync-а :)
У них хитрая система дедупликации по всем пользователям. Помню как-то случайно кинул фильм в Dropbox, несколько секунд посчитала хеш суммы и сказало «SYnchronized». Уже был у кого-то значит :)
Я, возможно, что-то пропустил, но разве Skype и Facebook не заняли первые позиции в своих сферах уже? А в таком случае после объединения… скажу так:
Когда два равных лодочника, которые уже точно знают, как надо плыть быстрее всех, садятся в одну лодку, мы можем увидеть и очень быстрое движение, и тормоза и разворот и даже караблекрушение. Всё зависит от их совместимости.
Он приводит в пример очереди. Покупатели, которые выстраиваются в очереди еще ночью одержимы мыслью «хочу», а не оценкой «это лучший продукт и сервис за эту цену». Просто потому, что это первый день продаж. Никто не знает что это за продукт. Был только PR.
Лучшие продукты за свою цену получают распространенность постепенно, сарафанным радио, а желаемые скачком в первую же неделю продаж.
Зря он сравнивает продукцию Apple и свой Parallels. Джобс сделал из своих гаджетов символ успеха, достатка, а Parallels это просто программка. Никто не скажет (или не подумает) «Вау! У тебя параллельс? », только увидев иконку программы. У Parallels ничего этого нет. Всё что есть — показатель качество/цена, который подвинулся на второе место.
А у аналитиков, которые попытались изобрести объяснение, «маркетинг головного мозга». Конец бренда, размытость бренда никак не означает конец платформе. Вон у PC уже 20 лет нет чёткого бренда, однако умирать архитектура не собирается, а даже наоборот, потихоньку другие, «более чёткие», кушает.
При работе с сабмодулями есть несколько «как не надо делать», о которых надо знать. Это один из таких моментов. О других можно почитать здесь: book.git-scm.com/5_submodules.html
Не знаю, как в svn привязывается к ревизии, но в гите всё примерно так, как надо:
Заходишь в submodule а там как в обычном репозитории:
git fetch; git checkout master|branch|tag|revision или git pull
а потом если выйти в родителя, то git diff покажет, что этот сабмодуль перепривязался к новому комиту, а git commit сохранит новую привязку.
Сразу для всех что-то делать можно через git submodule foreach.
Кроме того, чтобы что-то поправить в библиотеке, не надо отдельно её клонировать, править можно прямо в сабмодуле. Там же можно изменения закоммитить и запушить на сервер. А затем закоммитьи и запушить новую привязку в родителе. (только не наоборот!:)
Разложите библиотеки по отдельным репозиториям.
В проекты, в которых они нужны, просто вставьте их как submodule.
Должно работать, плюс submodule привязывается не к репозиторию, а к отдельному коммиту. Т.е. возможна такая ситуация:
Когда вы правите библиотеку, не нужно проверять что сломалось, а что нет во всех проектах, которые использую её. Они привязаны к уже проверенным коммитам. А когда будет время можно любой проект перепривязать на свежую версию и тщательно протестить.
> А я не воевал, а радовался во всю. В чем подвох?
Вы попробовали git после svn, а develop7 после hg. Ни у hg ни у git-а нет таких сильных преимуществ перед друг-другом, как, например, перед svn, но внутренности достаточно разные. И эта разница диктует немного разный workflow.
Поэтому, обычно получается такая ситуация: программист после svn пробует или git или hg, радуется удивляется новым возможностям и сильно изменяет свой workflow под выбранный DVCS. Он видит, что усилия потраченные на это действие потом окупятся.
Потом программист пробует конкурирующий DCVS, но там крутых плюсов нет, поэтому нет и особой радости, и workflow меняется через немогу (зачем что-то менять, если выгоды не видно?). Программист пытается делать по старому, и натыкается на проблемы, а плюсы не находит потому, что плюсы проявляются в другом, родном для этой системы, workflow. В итоге программист всегда видит у конкурента больше минусов чем плюсов не зависимо от того, с какой DCVS начал ;)
Вот так и получается, что одни ищут легкий hg serve, а другие легкие бранчи и плюются на местные аналоги.
А почему лучше? Потому, что остаётся еще и информация в какой части здания находится POI. Это удобно, если здание большое и имеет множество входов. А в викимапии места для этой информации нет.
А можно пример?
А потлач и тем более JOSM не определяют порог вхождения, а, скорее, высоту роста после вхождения. Последний — это вообще photoshop в OSM. В нём можно, используя клавиатуру, вносить информацию в сумашедшем темпе. А источники информации не ограничиваются только снимками. Там есть и треки и фотки и подложки и аудио метки и интеграция с OpenStreetBug и еще куча всего. И, как и фотошоп, он трубует обучения. Потлач и флешная компания — эта серединка.
Когда два равных лодочника, которые уже точно знают, как надо плыть быстрее всех, садятся в одну лодку, мы можем увидеть и очень быстрое движение, и тормоза и разворот и даже караблекрушение. Всё зависит от их совместимости.
Лучшие продукты за свою цену получают распространенность постепенно, сарафанным радио, а желаемые скачком в первую же неделю продаж.
А у аналитиков, которые попытались изобрести объяснение, «маркетинг головного мозга». Конец бренда, размытость бренда никак не означает конец платформе. Вон у PC уже 20 лет нет чёткого бренда, однако умирать архитектура не собирается, а даже наоборот, потихоньку другие, «более чёткие», кушает.
При работе с сабмодулями есть несколько «как не надо делать», о которых надо знать. Это один из таких моментов. О других можно почитать здесь: book.git-scm.com/5_submodules.html
Заходишь в submodule а там как в обычном репозитории:
git fetch; git checkout master|branch|tag|revision или git pull
а потом если выйти в родителя, то git diff покажет, что этот сабмодуль перепривязался к новому комиту, а git commit сохранит новую привязку.
Сразу для всех что-то делать можно через git submodule foreach.
Кроме того, чтобы что-то поправить в библиотеке, не надо отдельно её клонировать, править можно прямо в сабмодуле. Там же можно изменения закоммитить и запушить на сервер. А затем закоммитьи и запушить новую привязку в родителе. (только не наоборот!:)
В проекты, в которых они нужны, просто вставьте их как submodule.
Должно работать, плюс submodule привязывается не к репозиторию, а к отдельному коммиту. Т.е. возможна такая ситуация:
Когда вы правите библиотеку, не нужно проверять что сломалось, а что нет во всех проектах, которые использую её. Они привязаны к уже проверенным коммитам. А когда будет время можно любой проект перепривязать на свежую версию и тщательно протестить.
Вы попробовали git после svn, а develop7 после hg. Ни у hg ни у git-а нет таких сильных преимуществ перед друг-другом, как, например, перед svn, но внутренности достаточно разные. И эта разница диктует немного разный workflow.
Поэтому, обычно получается такая ситуация: программист после svn пробует или git или hg, радуется удивляется новым возможностям и сильно изменяет свой workflow под выбранный DVCS. Он видит, что усилия потраченные на это действие потом окупятся.
Потом программист пробует конкурирующий DCVS, но там крутых плюсов нет, поэтому нет и особой радости, и workflow меняется через немогу (зачем что-то менять, если выгоды не видно?). Программист пытается делать по старому, и натыкается на проблемы, а плюсы не находит потому, что плюсы проявляются в другом, родном для этой системы, workflow. В итоге программист всегда видит у конкурента больше минусов чем плюсов не зависимо от того, с какой DCVS начал ;)
Вот так и получается, что одни ищут легкий hg serve, а другие легкие бранчи и плюются на местные аналоги.