Про тему POI (бензоколонки, кафе, больницы и пр. )
Правила форума
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
Для предотврашения спама первые сообщения вновь зарегистрированных пользователей проходят ручную премодерацию.
Re: начнем
Ого... Это надо осмыслить. Пока навскидку.
Думаю, стоит сразу ориентироваться на интернациональное использование, ведь этот механизм будет удобен и восточным европейцам, также лишённым Metro Guide, как и мы. В связи с этим предлагаю избавиться от слова "русский" в описании, применив вместо него, где нужно, слово "локальный". В качестве кодировки для локальных языков предлагаю использовать UTF8. Понятное дело, это скажется на длинах полей, но иначе совместить кириллицу и, например, польский алфавит, не получится. Для классов нужно будет создать подчинённую таблицу с локальными названиями.
Не вижу смысла хранить краткое локальное название точки, поскольку возникать точки будут в приборах у пользователей, а там локализацией пока не пахнет. Да и вообще для многих типов объектов название точки не будет иметь особой смысловой нагрузки: не всякая АЗС имеет своё название.
Далее, не все приборы настолько убоги, что позволяют отводить под название всего 8 символов. Например, в Vista их уже 10.
Для всяких развлекательных объектов, типа кегельбанов, кабаков и т. п. может быть полезным наличие контактных телефонов.
P. S. Кстати, почту почитай.
Думаю, стоит сразу ориентироваться на интернациональное использование, ведь этот механизм будет удобен и восточным европейцам, также лишённым Metro Guide, как и мы. В связи с этим предлагаю избавиться от слова "русский" в описании, применив вместо него, где нужно, слово "локальный". В качестве кодировки для локальных языков предлагаю использовать UTF8. Понятное дело, это скажется на длинах полей, но иначе совместить кириллицу и, например, польский алфавит, не получится. Для классов нужно будет создать подчинённую таблицу с локальными названиями.
Не вижу смысла хранить краткое локальное название точки, поскольку возникать точки будут в приборах у пользователей, а там локализацией пока не пахнет. Да и вообще для многих типов объектов название точки не будет иметь особой смысловой нагрузки: не всякая АЗС имеет своё название.
Далее, не все приборы настолько убоги, что позволяют отводить под название всего 8 символов. Например, в Vista их уже 10.
Для всяких развлекательных объектов, типа кегельбанов, кабаков и т. п. может быть полезным наличие контактных телефонов.
P. S. Кстати, почту почитай.
|
||
![]() |
Re: начнем
При делении на регионы, думаю, можно обойтись двумя (максимум тремя) уровнями. Привязываться, умаю, лучше к административным регионам, тем более что их границы в векторном виде в принципе можно добыть и определять принадлежность точки к региону автоматически.
Re: начнем
>Думаю, стоит сразу ориентироваться на интернациональное использование
я за
>В связи с этим предлагаю избавиться от слова "русский"
>в описании, применив вместо него, где нужно, слово "локальный".
предлагаю поле русского варианта не вычеркивать, поле "локальный" добавить. Кстати, украинские векторные карты именно таким макаром и организованы: названия идут в трех вариантах: русский, украинский, латиница. Чиста на взгляд - больше всего названий на русском ;).
>В качестве кодировки для локальных языков предлагаю использовать UTF8
я не знаю что такое UTF8, наверное поэтому мне Unicode немного ближе - как минимум тем, что там все кирилистические языки сгруппированы в одну таблицу, - аналогично - для европейских :)
>Для классов нужно будет создать подчинённую таблицу с локальными названиями.
таблица вроде есть (CLASSES). Остается добавить поле локального варианта названия.
>Не вижу смысла хранить краткое локальное название точки,
>поскольку возникать точки будут в приборах у пользователей,
>а там локализацией пока не пахнет
категорически возражаю. Гарминами сферу применения ограничивать не след - если возиться только за ради их, то структура вааще должна быть однотабличной.
можно добавить поле "краткого приборного названия" char[8] - 8 залезет в любой прибор, 10 - только в некоторые :)
Поля названий - расширить до 15 или даже 20 символов. Популярные точки как правило имеют народные ники или вывески - кафе "Зустрич", (более известное в народе как "Встреча" :), п/б "Капкан", гастроном "На горке". Все местные эти ники знают. Именно для такой информации я предполагал использовать поля названий, причем английский вариант - для возможности загрузки в приемники.
>Для всяких развлекательных объектов, типа кегельбанов,
>кабаков и т. п. может быть полезным наличие контактных телефонов.
телефоны полезны для всего. Я о них просто забыл.
в таблицу POI нужно добавить след. поля:
phone - char[20] +123-[123]-1234567
phone2- char[20]
fax- char[20]
phone/fax- char[20]
Также, почитав почту, вижу, что забыл не просто об адресах, а POI, находящихся в населенных пунктах.
Для их хранения можно использовать поля:
POI::trace_id, но при этом в TRACE хранить также названия улиц
и
POI::poi_km - причем это поле имеет смысл переименовать в poi_loc и сменить его тип на char[15] для того, чтобы иметь возможность хранить в нем не только номер километра трассы, но и номер дома, например "8K1" - для "дом 8, корп.1"
Далее: где-то нужно хранить названия НП - можно в таблице REGIONS. Но здесь двумя уровнями не обойтись (минимум - деревня - район - область - страна). Соответственно, нужно подумать о том, как грамотно подправить структуру. Раз пошла такая пьянка, REGIONS имеет смысл позаимствовать из NIMA - они, вроде, это разрешают.
>P. S. Кстати, почту почитай
почитал. Структуру, думаю, правильнее обсуждать здесь. На флуд в конце концов можно и не отвлекаться. В крайнем случае - создавать группу. Практика показывает, что по почте совместная работа идет не очень - письма имеют обыкновение теряться, группа - увеличивать численность. К тому-же практически невозможно организовать доступ к рабочим материалам проекта.
Кстати, о рабочих материалах: не возьмется ли кто отмакетировать описанное на акцессе? полагаю, Access есть у всех? :)
оргпредложение - наверное, нужно будет ориентироваться на институт "администраторов регионов" - по каждому району подбирать людей, которые будут следить за группой ПОИ в регионе.
я за
>В связи с этим предлагаю избавиться от слова "русский"
>в описании, применив вместо него, где нужно, слово "локальный".
предлагаю поле русского варианта не вычеркивать, поле "локальный" добавить. Кстати, украинские векторные карты именно таким макаром и организованы: названия идут в трех вариантах: русский, украинский, латиница. Чиста на взгляд - больше всего названий на русском ;).
>В качестве кодировки для локальных языков предлагаю использовать UTF8
я не знаю что такое UTF8, наверное поэтому мне Unicode немного ближе - как минимум тем, что там все кирилистические языки сгруппированы в одну таблицу, - аналогично - для европейских :)
>Для классов нужно будет создать подчинённую таблицу с локальными названиями.
таблица вроде есть (CLASSES). Остается добавить поле локального варианта названия.
>Не вижу смысла хранить краткое локальное название точки,
>поскольку возникать точки будут в приборах у пользователей,
>а там локализацией пока не пахнет
категорически возражаю. Гарминами сферу применения ограничивать не след - если возиться только за ради их, то структура вааще должна быть однотабличной.
можно добавить поле "краткого приборного названия" char[8] - 8 залезет в любой прибор, 10 - только в некоторые :)
Поля названий - расширить до 15 или даже 20 символов. Популярные точки как правило имеют народные ники или вывески - кафе "Зустрич", (более известное в народе как "Встреча" :), п/б "Капкан", гастроном "На горке". Все местные эти ники знают. Именно для такой информации я предполагал использовать поля названий, причем английский вариант - для возможности загрузки в приемники.
>Для всяких развлекательных объектов, типа кегельбанов,
>кабаков и т. п. может быть полезным наличие контактных телефонов.
телефоны полезны для всего. Я о них просто забыл.
в таблицу POI нужно добавить след. поля:
phone - char[20] +123-[123]-1234567
phone2- char[20]
fax- char[20]
phone/fax- char[20]
Также, почитав почту, вижу, что забыл не просто об адресах, а POI, находящихся в населенных пунктах.
Для их хранения можно использовать поля:
POI::trace_id, но при этом в TRACE хранить также названия улиц
и
POI::poi_km - причем это поле имеет смысл переименовать в poi_loc и сменить его тип на char[15] для того, чтобы иметь возможность хранить в нем не только номер километра трассы, но и номер дома, например "8K1" - для "дом 8, корп.1"
Далее: где-то нужно хранить названия НП - можно в таблице REGIONS. Но здесь двумя уровнями не обойтись (минимум - деревня - район - область - страна). Соответственно, нужно подумать о том, как грамотно подправить структуру. Раз пошла такая пьянка, REGIONS имеет смысл позаимствовать из NIMA - они, вроде, это разрешают.
>P. S. Кстати, почту почитай
почитал. Структуру, думаю, правильнее обсуждать здесь. На флуд в конце концов можно и не отвлекаться. В крайнем случае - создавать группу. Практика показывает, что по почте совместная работа идет не очень - письма имеют обыкновение теряться, группа - увеличивать численность. К тому-же практически невозможно организовать доступ к рабочим материалам проекта.
Кстати, о рабочих материалах: не возьмется ли кто отмакетировать описанное на акцессе? полагаю, Access есть у всех? :)
оргпредложение - наверное, нужно будет ориентироваться на институт "администраторов регионов" - по каждому району подбирать людей, которые будут следить за группой ПОИ в регионе.
группа poi2002
Group home page : http://groups.yahoo.com/group/poi2002 Группа открыта для всех. Пока предназначена для обсуждения вопросов по проекту создания POI сервера. В последствии ее можно переорганизовать на обсуждение вопросов ведения информации о POI. Язык группы - русский, кодировка - KOI-8 Group email : Post message: poi2002@yahoogroups.com Subscribe: poi2002-subscribe@yahoogroups.com Unsubscribe: poi2002-unsubscribe@yahoogroups.com List owner: poi2002-owner@yahoogroups.com
Re: начнем
: >В связи с этим предлагаю избавиться от слова "русский"
: >в описании, применив вместо него, где нужно, слово "локальный".
: предлагаю поле русского варианта не вычеркивать, поле "локальный" добавить.
: Кстати, украинские векторные карты именно таким макаром и организованы: названия идут в трех вариантах: русский, украинский, латиница. Чиста на взгляд - больше всего названий на русском ;).
Я в курсе этой наследственности в украинской картографии, и более того, я не настаиваю на том, чтобы локальные названия в Украине были исколючительно на украинском. Под локальным я понимаю любой язык, имеющий хождение на данной территории. Реально вполне логино ожидать, что в восточной Украине большинство названий будет на русском, а в западной -- на украинском. В связи с чем ещё раз предлагаю не плодить "русский" и "локальный".![Smiley :-)](./images/smilies/jsmiley.gif)
: >В качестве кодировки для локальных языков предлагаю использовать UTF8
:
: я не знаю что такое UTF8, наверное поэтому мне Unicode немного ближе - как минимум тем, что там все кирилистические языки сгруппированы в одну таблицу, - аналогично - для европейских :)
UTF8 это способ кодирования Unicode символами с переменной длиной (в байтах). Преимущество в обратной совместимости с ASCII: первая половина таблицы отображается одним байтом. Хотя мы вряд ли рассчитываем на японских, китайских и корейских пользователей (для кодирования символов алфавитов которых, насаколько я помню, используется более двух байт), так что вполне можно остановиться на двубайтном Unicode.
: >Для классов нужно будет создать подчинённую таблицу с локальными названиями.
:
: таблица вроде есть (CLASSES). Остается добавить поле локального варианта названия.
Объекты привязаны к территориям (локалиям). Для них достаточно иметь локальное название на одном языке (одном из тех, что используются на этой территории). Классы же используются на всех территориях, потому для каждого класса нужно иметь название на _каждом_ языке, а для этого одного поля не достаточно. Нужна таблица, в которой была бы ссылка на класс, ссылка на язык (локалию), и собственно название этого класса для этого языка.
: >Не вижу смысла хранить краткое локальное название точки,
: >поскольку возникать точки будут в приборах у пользователей,
: >а там локализацией пока не пахнет
:
: категорически возражаю. Гарминами сферу применения ограничивать не след - если возиться только за ради их, то структура вааще должна быть однотабличной.
Согласен.
: можно добавить поле "краткого приборного названия" char[8] - 8 залезет в любой прибор,
В жёлтый eTrex не залезет -- там 6.
: 10 - только в некоторые :)
Тут есть ньюанс. Даже два. Первый: многие приборы идентифицируют точку по названию, то есть, в них нельзя загрузить две точки с одинаковым названием. А такая ситуация возникать будет, например, фастфуды типа McDonald's. Поэтому при создании waypoint'ов к названию нужно будет добавлять какой-то уникализатор (например, число). А значит, либо название должно быть короче, чем позволяет прибор, либо должно обрезаться.
Второй ньюанс: в некоторых приборах довольно бедные наборы значков для обозначения точек, а значит, обозначение типа точки прийдётся выносить в название. Что тоже его укоротит.
Думаю, 8 в данном случае это нормальный компромисс. Просто стоит иметь в виду эти ньюансы.
: Поля названий - расширить до 15 или даже 20 символов. Популярные точки как правило имеют народные ники или вывески - кафе "Зустрич", (более известное в народе как "Встреча" :), п/б "Капкан", гастроном "На горке". Все местные эти ники знают. Именно для такой информации я предполагал использовать поля названий, причем английский вариант - для возможности загрузки в приемники.
Эти названия можно использовать для создания POI, ведь там, по сути, ограничений на длину названия нет.
: >Для всяких развлекательных объектов, типа кегельбанов,
: >кабаков и т. п. может быть полезным наличие контактных телефонов.
:
: телефоны полезны для всего. Я о них просто забыл.
: в таблицу POI нужно добавить след. поля:
: phone - char[20] +123-[123]-1234567
: phone2- char[20]
: fax- char[20]
: phone/fax- char[20]
Не думаю, что имеет смысл записывать номера факсов. Как и адреса, впрочем. Как и адреса, впрочем. Мы ведь не Жёлтые страницы строим. Назначение данной базы -- помочь выбрать и найти подходящий объект, находясь в движении, а в этом случае номер факса не нужен вообще, а адрес не нужен потому, что поиск осуществляется с помощью GPS (или я что-то напутал? :) ).
: Также, почитав почту, вижу, что забыл не просто об адресах, а POI, находящихся в населенных пунктах.
: Для их хранения можно использовать поля:
: POI::trace_id, но при этом в TRACE хранить также названия улиц
А зачем? Я так понял, что поле trace_id нужно для того, чтобы пользователь мог выбрать точки для загрузки по названию трассы, по которой он собирается ехать.
: и
: POI::poi_km - причем это поле имеет смысл переименовать в poi_loc и сменить его тип на char[15] для того, чтобы иметь возможность хранить в нем не только номер километра трассы, но и номер дома, например "8K1" - для "дом 8, корп.1"
Зачем?
: Далее: где-то нужно хранить названия НП - можно в таблице REGIONS. Но здесь двумя уровнями не обойтись (минимум - деревня - район - область - страна). Соответственно, нужно подумать о том, как грамотно подправить структуру. Раз пошла такая пьянка, REGIONS имеет смысл позаимствовать из NIMA - они, вроде, это разрешают.
Я не знал, что есть общедоступный классификатор, потому не предлагал. Но я считаю, что не стоит в принципе напрягать пользователя указанием информации, к какому региону относится точка, а вычислять это по имеющимся границам регионов. А с границами населённых пунктов могут возникнуть трудности, да и не нужно это, по-моему.
: >в описании, применив вместо него, где нужно, слово "локальный".
: предлагаю поле русского варианта не вычеркивать, поле "локальный" добавить.
: Кстати, украинские векторные карты именно таким макаром и организованы: названия идут в трех вариантах: русский, украинский, латиница. Чиста на взгляд - больше всего названий на русском ;).
Я в курсе этой наследственности в украинской картографии, и более того, я не настаиваю на том, чтобы локальные названия в Украине были исколючительно на украинском. Под локальным я понимаю любой язык, имеющий хождение на данной территории. Реально вполне логино ожидать, что в восточной Украине большинство названий будет на русском, а в западной -- на украинском. В связи с чем ещё раз предлагаю не плодить "русский" и "локальный".
![Smiley :-)](./images/smilies/jsmiley.gif)
: >В качестве кодировки для локальных языков предлагаю использовать UTF8
:
: я не знаю что такое UTF8, наверное поэтому мне Unicode немного ближе - как минимум тем, что там все кирилистические языки сгруппированы в одну таблицу, - аналогично - для европейских :)
UTF8 это способ кодирования Unicode символами с переменной длиной (в байтах). Преимущество в обратной совместимости с ASCII: первая половина таблицы отображается одним байтом. Хотя мы вряд ли рассчитываем на японских, китайских и корейских пользователей (для кодирования символов алфавитов которых, насаколько я помню, используется более двух байт), так что вполне можно остановиться на двубайтном Unicode.
: >Для классов нужно будет создать подчинённую таблицу с локальными названиями.
:
: таблица вроде есть (CLASSES). Остается добавить поле локального варианта названия.
Объекты привязаны к территориям (локалиям). Для них достаточно иметь локальное название на одном языке (одном из тех, что используются на этой территории). Классы же используются на всех территориях, потому для каждого класса нужно иметь название на _каждом_ языке, а для этого одного поля не достаточно. Нужна таблица, в которой была бы ссылка на класс, ссылка на язык (локалию), и собственно название этого класса для этого языка.
: >Не вижу смысла хранить краткое локальное название точки,
: >поскольку возникать точки будут в приборах у пользователей,
: >а там локализацией пока не пахнет
:
: категорически возражаю. Гарминами сферу применения ограничивать не след - если возиться только за ради их, то структура вааще должна быть однотабличной.
Согласен.
: можно добавить поле "краткого приборного названия" char[8] - 8 залезет в любой прибор,
В жёлтый eTrex не залезет -- там 6.
: 10 - только в некоторые :)
Тут есть ньюанс. Даже два. Первый: многие приборы идентифицируют точку по названию, то есть, в них нельзя загрузить две точки с одинаковым названием. А такая ситуация возникать будет, например, фастфуды типа McDonald's. Поэтому при создании waypoint'ов к названию нужно будет добавлять какой-то уникализатор (например, число). А значит, либо название должно быть короче, чем позволяет прибор, либо должно обрезаться.
Второй ньюанс: в некоторых приборах довольно бедные наборы значков для обозначения точек, а значит, обозначение типа точки прийдётся выносить в название. Что тоже его укоротит.
Думаю, 8 в данном случае это нормальный компромисс. Просто стоит иметь в виду эти ньюансы.
: Поля названий - расширить до 15 или даже 20 символов. Популярные точки как правило имеют народные ники или вывески - кафе "Зустрич", (более известное в народе как "Встреча" :), п/б "Капкан", гастроном "На горке". Все местные эти ники знают. Именно для такой информации я предполагал использовать поля названий, причем английский вариант - для возможности загрузки в приемники.
Эти названия можно использовать для создания POI, ведь там, по сути, ограничений на длину названия нет.
: >Для всяких развлекательных объектов, типа кегельбанов,
: >кабаков и т. п. может быть полезным наличие контактных телефонов.
:
: телефоны полезны для всего. Я о них просто забыл.
: в таблицу POI нужно добавить след. поля:
: phone - char[20] +123-[123]-1234567
: phone2- char[20]
: fax- char[20]
: phone/fax- char[20]
Не думаю, что имеет смысл записывать номера факсов. Как и адреса, впрочем. Как и адреса, впрочем. Мы ведь не Жёлтые страницы строим. Назначение данной базы -- помочь выбрать и найти подходящий объект, находясь в движении, а в этом случае номер факса не нужен вообще, а адрес не нужен потому, что поиск осуществляется с помощью GPS (или я что-то напутал? :) ).
: Также, почитав почту, вижу, что забыл не просто об адресах, а POI, находящихся в населенных пунктах.
: Для их хранения можно использовать поля:
: POI::trace_id, но при этом в TRACE хранить также названия улиц
А зачем? Я так понял, что поле trace_id нужно для того, чтобы пользователь мог выбрать точки для загрузки по названию трассы, по которой он собирается ехать.
: и
: POI::poi_km - причем это поле имеет смысл переименовать в poi_loc и сменить его тип на char[15] для того, чтобы иметь возможность хранить в нем не только номер километра трассы, но и номер дома, например "8K1" - для "дом 8, корп.1"
Зачем?
: Далее: где-то нужно хранить названия НП - можно в таблице REGIONS. Но здесь двумя уровнями не обойтись (минимум - деревня - район - область - страна). Соответственно, нужно подумать о том, как грамотно подправить структуру. Раз пошла такая пьянка, REGIONS имеет смысл позаимствовать из NIMA - они, вроде, это разрешают.
Я не знал, что есть общедоступный классификатор, потому не предлагал. Но я считаю, что не стоит в принципе напрягать пользователя указанием информации, к какому региону относится точка, а вычислять это по имеющимся границам регионов. А с границами населённых пунктов могут возникнуть трудности, да и не нужно это, по-моему.
|
||
![]() |
Помнится было обещано помочь бестолковым с Яхой. :-)))
Послал письмишко по poi2002-subscribe@yahoogroups.com Получил ответ. А дальше чего делать на http://groups.yahoo.com/group/poi2002 невидать и единственного сообщения в Aug Сергей.
Re: начнем
>Я в курсе этой наследственности в украинской картографии, и >более того, я не настаиваю на том, чтобы локальные названия >в Украине были исколючительно на украинском. Под локальным я >понимаю любой язык, имеющий хождение на данной территории. >Реально вполне логино ожидать, что в восточной Украине >большинство названий будет на русском, а в западной -- на >украинском. В связи с чем ещё раз предлагаю не плодить "русский" >и "локальный".
Лично мне в голову может и придет поискать г.Львов как что-то типа Львiв, но, признаюсь, я не уверен какие буквы правильно набирать. Аналогично - с Киевом (Кiев? Кiiв? - вроде там была какая-то буква с двумя точками...). Это я все к тому, что по-русски название набрать сможет каждый, а в локальном виде - далеко не все. Тем не менее, локальные названия хранить нужно. Поэтому я и предлагаю хранить лишний вариант, учитывая то, что ресурс предполагается русскоязычный. По мере появления пользователей, не владеющих русским языком можно будет добавлять поля с приемлимыми для них языками. >Классы же используются на всех территориях, потому для каждого класса нужно иметь название на _каждом_ языке, а для этого одного поля не достаточно. согласен. >Нужна таблица, в которой была бы ссылка на класс, ссылка на язык (локалию), и собственно название этого класса для этого языка. не нужна. Количество языков ограниченно, поэтому нужны дополнительные поля. Пока речь идет об английском, русском и, может быть, украинском. >Не думаю, что имеет смысл записывать номера факсов имеет-не имеет я не знаю. Нет смысла делать это поле обязательным для заполнения. аналогично - для адресов. Возможность реализовать не трудно, а будет она востребована или нет покажет жизнь. >Но я считаю, что не стоит в принципе напрягать пользователя указанием информации, к какому региону относится точка, а вычислять это по имеющимся границам регионов. А с границами населённых пунктов могут возникнуть трудности, да и не нужно это, по-моему. см. выше. Принадлежность точки области или даже району, возможно, будет можно рассчитывать автоматом (по украине такая инфа есть, где взять по россии я не знаю). Но дать возможность пользователю "ручками" пришивать ее к НП вполне оправдано. Это не есть напряг, потому как поле необязательно для заполнения (стоит подумать о таком аттрибуте полей). Если я еду в Крым по трассе Москва-Сиферополь, я могу не обращать внимание на название НП, но если Caravan живет в Иваново, он всегда знает, находится ли его точка в Иваново или нет. Керг>Помнится было обещано помочь бестолковым с Яхой кто из нас троих бестолковый еще предстоит разобраться :) я тебя в members list уже вижу и вижу. что у тебя нет Yahoo ID. Это значит, что письма ты получать будешь, но к архиву, файлам и т.д. у тебя с доступом будут проблемы. Иди на http://groups.yahoo.com/<br> регистрируйся и прописывай свой email.
![Smiley :-)](./images/smilies/jsmiley.gif)
Re: начнем
: Лично мне в голову может и придет поискать г.Львов как что-то типа Львiв, но, признаюсь, я не уверен какие буквы правильно набирать. Аналогично - с Киевом (Кiев? Кiiв? - вроде там была какая-то буква с двумя точками...).
Ки╖в. :)
: Это я все к тому, что по-русски название набрать сможет каждый, а в локальном виде - далеко не все. Тем не менее, локальные названия хранить нужно. Поэтому я и предлагаю хранить лишний вариант, учитывая то, что ресурс предполагается русскоязычный. По мере появления пользователей, не владеющих русским языком можно будет добавлять поля с приемлимыми для них языками.
Уговорил, согласен. :)
: >Нужна таблица, в которой была бы ссылка на класс, ссылка на язык (локалию), и собственно название этого класса для этого языка.
: не нужна. Количество языков ограниченно, поэтому нужны дополнительные поля. Пока речь идет об английском, русском и, может быть, украинском.
Тоже согласен.
: >Но я считаю, что не стоит в принципе напрягать пользователя указанием информации, к какому региону относится точка, а вычислять это по имеющимся границам регионов. А с границами населённых пунктов могут возникнуть трудности, да и не нужно это, по-моему.
:
: см. выше. Принадлежность точки области или даже району, возможно, будет можно рассчитывать автоматом (по украине такая инфа есть, где взять по россии я не знаю). Но дать возможность пользователю "ручками" пришивать ее к НП вполне оправдано. Это не есть напряг, потому как поле необязательно для заполнения (стоит подумать о таком аттрибуте полей). Если я еду в Крым по трассе Москва-Сиферополь, я могу не обращать внимание на название НП, но если Caravan живет в Иваново, он всегда знает, находится ли его точка в Иваново или нет
Хорошо, только я не совсем понимаю, зачем это нужно.
Ки╖в. :)
: Это я все к тому, что по-русски название набрать сможет каждый, а в локальном виде - далеко не все. Тем не менее, локальные названия хранить нужно. Поэтому я и предлагаю хранить лишний вариант, учитывая то, что ресурс предполагается русскоязычный. По мере появления пользователей, не владеющих русским языком можно будет добавлять поля с приемлимыми для них языками.
Уговорил, согласен. :)
: >Нужна таблица, в которой была бы ссылка на класс, ссылка на язык (локалию), и собственно название этого класса для этого языка.
: не нужна. Количество языков ограниченно, поэтому нужны дополнительные поля. Пока речь идет об английском, русском и, может быть, украинском.
Тоже согласен.
: >Но я считаю, что не стоит в принципе напрягать пользователя указанием информации, к какому региону относится точка, а вычислять это по имеющимся границам регионов. А с границами населённых пунктов могут возникнуть трудности, да и не нужно это, по-моему.
:
: см. выше. Принадлежность точки области или даже району, возможно, будет можно рассчитывать автоматом (по украине такая инфа есть, где взять по россии я не знаю). Но дать возможность пользователю "ручками" пришивать ее к НП вполне оправдано. Это не есть напряг, потому как поле необязательно для заполнения (стоит подумать о таком аттрибуте полей). Если я еду в Крым по трассе Москва-Сиферополь, я могу не обращать внимание на название НП, но если Caravan живет в Иваново, он всегда знает, находится ли его точка в Иваново или нет
Хорошо, только я не совсем понимаю, зачем это нужно.
Re: начнем
Керг>Помнится было обещано помочь бестолковым с Яхой кто из нас троих бестолковый еще предстоит разобраться :) >я тебя в members list уже вижу и вижу. что у тебя нет Yahoo ID. Это значит, >что письма ты получать будешь, но к архиву, файлам и т.д. у тебя с доступом >будут проблемы. Иди на http://groups.yahoo.com/ >регистрируйся и прописывай свой email. Вижу на http://groups.yahoo.com/group/poi2002/ сообщение Welcome, kerg_v poi2002 ╥ POI v - это пятая попытка
) Но попрежнему не вижу единственное сообщение в за Aug 2002.
(( Сергей.
![Laugh :-))](./images/smilies/jlaugh.gif)
![Sad :-(](./images/smilies/jsad.gif)
Re: начнем
>Пока речь идет об английском, русском и, может быть, украинском.
и венгерском. они тоже хотят.
Alecs
и венгерском. они тоже хотят.
Alecs
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 43 гостя