Names in addresses

Pedja · 2012-06-10T21:34:07.000Z

Svejedno, treba i pretraga da bude moguća na raznim pismima i jezicima.

U suštini, za ulice se može automatski prepisati sadržaj iz name tagova, jer mora biti identičan.

mpele · 2012-06-11T06:58:51.000Z

Pedja:

U suštini, za ulice se može automatski prepisati sadržaj iz name tagova, jer mora biti identičan.

Пеђа, буди конкретнији - мешаш једнине и множине па се последња реченица може схватити на више начина.

Него, да поставим, по мени, суштинско питање. Ко користи тагове addr:street? Тагови name:* имају очигледног смисла јер се простим подешавањима може подесити да се приказују на мапи. Још је и реално да неко ради рендер мапе али да неко прави свој систем за претрагу адреса мало ми је вероватно.

Дакле, треба видети како функционишу системи типа Nominatum, Garmin, Osmand и слични и шта би њима одговарало па одлучити шта да се ради и да ли има смила попуњавати тагове типа addr:street:sr-Latn. Можда је бесмислено да таг addr:street буде у ћирилици.

Drazha · 2012-06-11T07:46:27.000Z

Ako smo vec poceli da enkodiramo razlicite jezike u name tag-u onda ne vidim zasto se nebi taj obrazac i princip koristio svuda gde treba. Jeste da je to visak posla, ali to ne znaci da ne treba da se stvar uradi ispravno.

Pedja · 2012-06-11T10:10:08.000Z

mpele:

Pedja:

U suštini, za ulice se može automatski prepisati sadržaj iz name tagova, jer mora biti identičan.

Пеђа, буди конкретнији - мешаш једнине и множине па се последња реченица може схватити на више начина.

По логици тај addr:street није ни потребан јер потребна информација већ пише у name тагу. Но ако већ постоји тај таг онда у нјега треба пресликати исто што стоји и у наме тагу, укључујући и вишејезичне варијанте.

Него, да поставим, по мени, суштинско питање. Ко користи тагове addr:street? Тагови name:* имају очигледног смисла јер се простим подешавањима може подесити да се приказују на мапи. Још је и реално да неко ради рендер мапе али да неко прави свој систем за претрагу адреса мало ми је вероватно.

Зашто не би важио исти принцип као и за све остало на мапи: у базу треба уписати потребне податке, а ко извлачи податке нек бира шта ће и како ће?

Дакле, треба видети како функционишу системи типа Nominatum, Garmin, Osmand и слични и шта би њима одговарало па одлучити шта да се ради и да ли има смила попуњавати тагове типа addr:street:sr-Latn. Можда је бесмислено да таг addr:street буде у ћирилици.

Не знам за друге али Гармин мапе сигурно нису вишејезичне, па ко извлачи податке да би изгенерисао мапу за Гармин он свакако мора да се одлучи за један језик.

Оно што би евентуално могло да се уради, то је да се у addr:street уписује специјално пресловљен формат који се може добити неком трансформацијом из било ког језика, тако да се омогући јединствена претрага. Обично се то ради тако што се врши пресловљавање у облик ојиј садржи само латинску абецеду без наих слова. Када корсиник укуца претрагу било ћирилицом, било латиницом, његов упит се прво преслови у тај облик па се онда врши претрага. То омогућава да се добиеј универзална претрага без обзира на писмо.

Ипак, ми не можемо знати ко ће радити претагу те врсте па и нема неког смисла да ми припремамо те податке. То ће он учинити када податке буде преузимао из базе. Наше је да му обезбедимо све потребне податке да то може да направи.

Drazha:

Ako smo vec poceli da enkodiramo razlicite jezike u name tag-u onda ne vidim zasto se nebi taj obrazac i princip koristio svuda gde treba. Jeste da je to visak posla, ali to ne znaci da ne treba da se stvar uradi ispravno.

Да, то је суштина. Где год се уписује текстуални податак у базу, треба се држати истих принципа вишејезичности.

misabrzi · 2012-06-11T11:08:40.000Z

Дакле биће потребно направи одређене измене у ‘preslovljavač’ plugin-u, jer koliko sam primetio sada ne prepoznaje address tagove.

Drazha · 2012-06-11T11:30:18.000Z

Preslovljavac ima imalo nesretno ime, i nemora obavezno da se bavi i address tagom…

mpele · 2012-06-11T14:17:07.000Z

Идеално би било да постоји addr:street тагова колико и тагова name и да све претраге раде са свим језичким варијантама. Што је до нас ми можемо само да “убацујемо податке”

Pedja:

Drazha wrote:Ako smo vec poceli da enkodiramo razlicite jezike u name tag-u onda ne vidim zasto se nebi taj obrazac i princip koristio svuda gde treba. Jeste da je to visak posla, ali to ne znaci da ne treba da se stvar uradi ispravno.Да, то је суштина. Где год се уписује текстуални податак у базу, треба се држати истих принципа вишејезичности.

Да ли је таг:

addr:street:sr-Latn

коректан? Ово питам из чисто практичних разлога јер овакав формат неодољиво личи на стварање проблема.

Може ли то неко да провери са “вишим инстанцама”?

kmilos · 2012-06-11T16:00:19.000Z

mpele:

Идеално би било да постоји addr:street тагова колико и тагова name и да све претраге раде са свим језичким варијантама. Што је до нас ми можемо само да “убацујемо податке”

Ovo je sve samo ne idealno. Duplikacija podataka samo vodi glovobolji u sinhronizaciji i održavanju, a nikako povećavanju upotrebljivosti.

Primere već imamo gde ljudi promene ‘name’ (novi naziv ulice ili koji god već razlog), a ‘name:sr’ i ‘name:sr-Latn’ ostanu po starom.

Ovo treba stvarno rešiti pri višoj instanci. Po meni, dovoljno bi bilo da ‘addr:street’ sadrži jedan od jezika/pisama sačuvanih u svim name=* oznakama, a algoritam za pretragu bi trebalo da je dovoljno pametan da nađe podudaranje i ponudi ispis na drugom jeziku/pismu ako je potrebno…

SunCobalt · 2012-06-11T19:17:27.000Z

kmilos:

mpele:

Идеално би било да постоји addr:street тагова колико и тагова name и да све претраге раде са свим језичким варијантама. Што је до нас ми можемо само да “убацујемо податке”

Ovo je sve samo ne idealno. Duplikacija podataka samo vodi glovobolji u sinhronizaciji i održavanju, a nikako povećavanju upotrebljivosti.

Primere već imamo gde ljudi promene ‘name’ (novi naziv ulice ili koji god već razlog), a ‘name:sr’ i ‘name:sr-Latn’ ostanu po starom.

Ovo treba stvarno rešiti pri višoj instanci. Po meni, dovoljno bi bilo da ‘addr:street’ sadrži jedan od jezika/pisama sačuvanih u svim name=* oznakama, a algoritam za pretragu bi trebalo da je dovoljno pametan da nađe podudaranje i ponudi ispis na drugom jeziku/pismu ako je potrebno…

I think you are right. I have thought a bit about this. I don’t think it makes much sense to add addr:*-Latn because you would need to add it not only to addr:street but also to addr:city and …funny…addr:housenumber
http://osm.org/go/0KoMP0Yrr–
(The letters are really in that order.)

I hope I can explain the reason. First it blow up the database. If you have a street with 100 housenumbers you would store the translation information (addr:street-Latn) 100 times which is already available at the highway-way (highway=, name(:sr)= → name:sr-Latn translation can be made with the street).
The second thing is how I think OSM based routers work. Due to the lack of housenumbers in the most areas in OSM, they look for highway names not addr: names. Chances are much higher to find the highway+name= because there are not so much housenumbers available. When they have the street, they probably look for a housenumber around where addr:street= is equal to name= on a highway=. Second reason is that Serbia would be the only country which has a 2-script addr: tag. Even if someone writes a routing engine trying to support that, then it is not a big deal to translate the addr:*=cyrillic name to a latin name based on the street to which the housenumber belongs… where hopefully name=, name:sr= and name:sr-Latn is added.

There is only reason I can find for adding addr:*-Latn…
http://www.openlinkmap.org/?lat=45.1199562&lon=21.305999&zoom=17&id=927156725&type=node

Such applications parse the address data directly from addr:* tags, so when no addr:*-Latn exist, you would need a workaround.

Pedja · 2012-06-13T06:57:59.000Z

kmilos:

mpele:

Идеално би било да постоји addr:street тагова колико и тагова name и да све претраге раде са свим језичким варијантама. Што је до нас ми можемо само да “убацујемо податке”

Ovo je sve samo ne idealno. Duplikacija podataka samo vodi glovobolji u sinhronizaciji i održavanju, a nikako povećavanju upotrebljivosti.

Primere već imamo gde ljudi promene ‘name’ (novi naziv ulice ili koji god već razlog), a ‘name:sr’ i ‘name:sr-Latn’ ostanu po starom.

Ovo treba stvarno rešiti pri višoj instanci. Po meni, dovoljno bi bilo da ‘addr:street’ sadrži jedan od jezika/pisama sačuvanih u svim name=* oznakama, a algoritam za pretragu bi trebalo da je dovoljno pametan da nađe podudaranje i ponudi ispis na drugom jeziku/pismu ako je potrebno…

Onda postojanje addr:street postaje besmisleno. Ako već renderer mora da se oslanja na name:*, addr:street mu uopšte nije ni potreban. Radi se o tipičnoj redundansi podataka koja upravo i pravi probleme kao što je ovaj. Ovakvi problemi se rešavaju uklanjanjem redundanse, a ne daljim frankenštajnskim komplikovanjem baze.

Sama ideja da se ovako reši problem pokazuje da postoji ozbiljan problem u dizajnu same baze (a kada je višejezičnost u pitanju OSM baza ima ozbiljne nedostatke).

Pedja · 2012-06-13T07:33:09.000Z

SunCobalt:

I think you are right. I have thought a bit about this. I don’t think it makes much sense to add addr:*-Latn because you would need to add it not only to addr:street but also to addr:city and …funny…addr:housenumber
http://osm.org/go/0KoMP0Yrr–
(The letters are really in that order.)

Order is correct. Script used is Cyril but actual order is an Latin alphabet. If Cyril alphabet is used, that would be real nightmare.

About other namespaces of addr tag: there is again serious database design flawz. There are addr:street, addr:city and addr:country keys which are all redundant. street, city and country are already defined. Those keys should not contain redundant data but point to objects that are already defined in a map. those objects already have name tags that are set properly and in multilanguage manner.

SunCobalt:

I hope I can explain the reason. First it blow up the database. If you have a street with 100 housenumbers you would store the translation information (addr:street-Latn) 100 times which is already available at the highway-way (highway=*, name(:sr)= → name:sr-Latn translation can be made with the street).

No, it is not a problem. House numbers can be easily transliterated to Latin or Cyril script for search purpose, as there are used only those letters that are common for Latin and Cyril script.

The only problem are addr:street, addr:city and addr:country which contain originaly Cyril contents and which is not easy to transliterate to Latin for search functionality.

SunCobalt:

The second thing is how I think OSM based routers work. Due to the lack of housenumbers in the most areas in OSM, they look for highway names not addr:* names. Chances are much higher to find the highway+name= because there are not so much housenumbers available. When they have the street, they probably look for a housenumber around where addr:street= is equal to name= on a highway=. Second reason is that Serbia would be the only country which has a 2-script addr: tag. Even if someone writes a routing engine trying to support that, then it is not a big deal to translate the addr:*=cyrillic name to a latin name based on the street to which the housenumber belongs… where hopefully name=, name:sr= and name:sr-Latn is added.

This is, actually, database design flaw. Tag addr:street is redundant as there is already name:* which contain necessary data. All problems are raised from that redundancy. Redundancy has to be solved. The best solution is to remove addr:street tag as unnecessary or make ot point to exact object that represents street. It’s contents as it is defined now is just an unnecessary duplicate of already existing information.

You are suggesting that OSM database should be fixed in manner that suits some rendering needs. This is wrong. Main principle of OSM database is to contain data not fixed for rendering needs. What you see as rendering need is not unique and someone else has different needs.

And rendering need you see is actually wrong as transliterating Cyril to Latin contents for search purpose is not as simple as you think. I dealt with that issue for years. Search will not work good if you just transliterate. Check www.vokabular.org. There, we dealt with this problem and achieved search on Cyril contents of a database to work regardless user uses Cyril or Latin search keys. We did use transliterated form of database contents but it was not simple Cyril to Latin transliteration.

This is not problem just with Serbian language and Cyrillic. This is problem with any language that uses letter other than plain English Latin script. Map user does not necessarily have to know language used for addresses, and especially does not have to be able to use keyboard that offers entering characters specific for given language.

To make things worse. OSM designers decided to allow primary usage of languages of minority, so we do not even have consistency in naming scheme, and, as things are now, we all have to know all languages and have keyboards for all their alphabets used to be able to use map of Serbia, including searching. And that is all for map of our own country! What about foreigners? What if we go abroad, in some exotic country. This is all ridiculous per se.

The only solution for this problem is to allow full multilanguage use of database. That means addr:street has to allow multilanguage contents in the same manner as it is done for name tag. That means any tag that allows custom entered text has to be multilingual.

Unfortunaltely for OSM database designer, multilinguality is not just allowing unicode in name tag. It means that all functions have to work as multilingual.

Pedja · 2012-06-13T08:01:51.000Z

mpele:

Него, да поставим, по мени, суштинско питање. Ко користи тагове addr:street? Тагови name:* имају очигледног смисла јер се простим подешавањима може подесити да се приказују на мапи. Још је и реално да неко ради рендер мапе али да неко прави свој систем за претрагу адреса мало ми је вероватно.

Сваки систем који озбиљније приказује мапе има и могућност претраге мапе по називима улица. Ако се не варам, проблем са ознакама адреса је у томе што се те ознаке додељују тачкама које не припадају самој улици (нисам то радио па не знам тачно), те не постоји друга веза са улицом него по имену.

Пројектанти ОСМ базе су као брзо решење увели да се у адреси понови име улице али сада се то показује као лоше решење, не само због вишејезичности (јер се сада морају дупло уносити и сви вишејезични облици назива улице) него и иначе: да би се могла направити веза између тачке која означава адресу и објекта који представља улицу, имена им се морају потпуно поклапати. Шта ако неко различито укуца име улице на објекту улице или у адреси? Шта ако постоји више улица истог назива?

Исправно би било да се у адреси уместо назива улице у ствари постави веза као објекту који представља улицу, јер он већ садржи све потребне информације укључујући и тачне и вишејезичне називе. Исто важи и за addr:city и addr:country. За ову везу не треба користити имена него ИД објекта, јер је то кључни и непроменљив податак који дефинише објекат.

SunCobalt · 2012-06-20T18:47:01.000Z

strange question: Is A (latin) = А (serbian cyrillic)? I am adding housenumbers with interpolations. But if a road segments begins with АБЦД I start the interpolation and the first “clean” number (without abcd) and make an extra adress node for the АБЦД.
here for example http://osm.org/go/0KoMY9Aex–
90% it is a A (BCD is not very often used) and I am wondering if I need to switch to cyrillic keybord settings only for the A and then back or if I can add a german/latin A…in case it makes no difference. So far I have switched the keyboard language to cyrillic.

misabrzi · 2012-06-20T19:19:22.000Z

SunCobalt:

strange question: Is A (latin) = А (serbian cyrillic)? I am adding housenumbers with interpolations. But if a road segments begins with АБЦД I start the interpolation and the first “clean” number (without abcd) and make an extra adress node for the АБЦД.
here for example http://osm.org/go/0KoMY9Aex–
90% it is a A (BCD is not very often used) and I am wondering if I need to switch to cyrillic keybord settings only for the A and then back or if I can add a german/latin A…in case it makes no difference. So far I have switched the keyboard language to cyrillic.

This is good question, I was asking my self same thing, and i guess it depends on what type of encoding are they using in main DB, because in Unicode it looks like it’s not the same, U+0061 a Latin Small Letter A and U+0430 а Cyrillic Small Letter A, obviously not the same value.
src. http://en.wikipedia.org/wiki/List_of_Unicode_characters

And here are few other resources just in case
http://www.tamasoft.co.jp/en/general-info/unicode.html
http://www.utf8-chartable.de/unicode-utf8-table.pl

Pedja · 2012-06-20T19:48:25.000Z

SunCobalt:

strange question: Is A (latin) = А (serbian cyrillic)?

No it is not. They look the same but they are totally different characters.

misabrzi · 2012-06-20T20:01:47.000Z

True, every encoding table I look it’s different. And it looks like they use Unicode http://wiki.openstreetmap.org/wiki/Data_Primitives#Tag.

Drazha · 2012-06-21T06:32:07.000Z

Ok, any reason NOT to repeat the same solution that we used for the “name” tag?

Pedja · 2012-06-21T06:45:46.000Z

The only problem my be if “addr:street:sr-Latn” is correct syntax.

kmilos · 2012-06-21T07:21:36.000Z

Drazha:

Ok, any reason NOT to repeat the same solution that we used for the “name” tag?

Yes, see above.

a) Data redundancy is a bad idea on many levels

b) We really don’t know how search works and if it’s really neccessary

This should be shifted to the main project list, nothing will be resolved here. See e.g. others suffering from multilingual issuses:

http://gis.19327.n5.nabble.com/Re-Talk-hr-Names-of-towns-in-Istria-td5713372.html

Drazha · 2012-06-21T07:33:38.000Z

The way I see it, the name tag is used for a street, house, object, mountain, river, rubbish bin… It does not necessarily conform to the address search requirements. Whereas each and every object can have an address, no matter if it is on a street or not, in an urban area or not. Therefore, although the data might seem redundant, I feel that it just happens to be on two completely separate layers.