Re: [OSM-talk] Rendering barangays for the Philippines
David Earl wrote: Here's an example of how I'm seeing it working: User T is Thai so sets JOSM to work in Thai (I'm not considering UIs here, just the data). JOSM tells the API that's what the language is when it uploads or downloads. So T's download automatically sees what I know as a village as thai-for-village. N, the Norwegian visitor to Bangkok entered that village the previous day in norwegian-for-village having told Potlatch she was working in Norwegian. T decides it is really a town, so changes it to town-in-thai and uploads it. N downloads it the following day and sees town-in-norwegian. Mapnik also sees it and renders town-as-a-symbol. You are ignoring the fact that human languages rarely produce interchangeable words which really mean the same. Each language is heavily influenced by it's peoples history. Just let's pick up your village-example. In German we name it Dorf. If you ask how to translate Dorf to English, you'll get village and cottage. cottage translates back either to Dorf (multiple houses), but also as Häuschen, Hütte, Landhaus (forms of a single house). Just think of someone inventing a Tag cottage, which should be translated? Which meaning does apply? The best example for such an untranslatable word is trunk as in highway=trunk. What is this? In the UK, it is a declaration that a street is part of the main road system, but it does in no way indicate any kind of traffic rules, number of lanes to expect etc. In fact, any trunk road could end up being anything from motorway down to unclassified if it hadn't been labelled trunk by the authorities. This trunk produces all kinds of strange conflicts because of its unclear meaning, which leads to having every country define which kind of road should be tagged as trunk. In Germany we chose to tag roads which are similar to Autobahn (dual carriageway or four lanes), but lack the blue road sign. But this is simply not what you'd expect in Great Britain. By simply translating the word trunk, you'll end up in a mess if you have Germans running around in the UK, retagging every trunk road as primary road because it is no Kraftfahrstrasse (or whatever the translation would be). Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Wed, Nov 26, 2008 at 12:51 PM, Lester Caine [EMAIL PROTECTED] wrote: [...] why should snow maps be any different to cycling or 'in-line skating' ;) well, you don't have a tag that shows whether a cycle route is opened or closed due to the weather -- Elena of Valhalla email: [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
Frederik Ramm wrote: Hi, Erik Johansson wrote: pat=patuqutaujuq == natural=snow pat=patuqun == natural=snow pat=patpat == natural=snow Ah, the old story about the various Inuit names for snow, isn't it. How about natural=snow snow=slush snow=sleet snow=blizzard snow=drift snow=white-out snow=flurry snow=powder snow=dusting snow=hardpack snow=crust if you're looking for diversity. - All these should, of course, ideally take the form of multiple tags, with one first saying there is snow and then, in a second or third tag, say something about where it came from, where it goes to, how much there is, how cold it is, and whether or not it has dog pee traces in it. I know this was a bit tongue in cheek, but with the ski season for the north with us, up to date maps showing the show conditions are probably of interest to a lot of people. I'm certainly not one of them, but why should snow maps be any different to cycling or 'in-line skating' ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
How about natural=snow snow=slush snow=sleet snow=blizzard snow=drift snow=white-out snow=flurry snow=powder snow=dusting snow=hardpack snow=crust I almost got to use natural=snow here the other day but it had melted before I could get the computer booted. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
Sounds like a classic need for another layer of indirection:
http://tools.ietf.org/html/rfc1925 section 6
Maning Sambale wrote:
Of course the correct way would be to tag them as place=barangay and we
will do so from now on. Can we request the renderers to render them the
same as place=village?
Erik Johansson wrote:
pat=patuqutaujuq == natural=snow
pat=patuqun == natural=snow
pat=patpat == natural=snow
This can be solved with an equivalence table at the renderer, eg:
{place,plaats,ilagay}={village,barangay,dorpje} : render(brown)
{natural,pat}={snow,patuquaujuq,patuqun,patpat} : render(white)
This lets us keep the richness and sublety of all the tags and values in the
database. As new tags or values are introduced it only requires updates to the
equivalence table, not the rendering engine or the editors.
The only (possible) constraint is the additional processing needed by the
lookups,
and the additional space required by the tables, but in another 18 months
processing
power will have doubled and the cost of disk space halved :-)
--Bob.
-- -- -- --
Bob Jonkman [EMAIL PROTECTED] http://sobac.com/sobac/
SOBAC Microcomputer Services Voice: +1-519-669-0388
6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413
Software --- Office Business Automation --- Consulting
On 26 Nov 2008 at 1:39, Erik Johansson wrote:
On Wed, Nov 26, 2008 at 1:01 AM, Frederik Ramm [EMAIL PROTECTED]
wrote: Erik Johansson wrote: pat=patuqutaujuq == natural=snow
pat=patuqun == natural=snow pat=patpat == natural=snow Ah,
the old story about the various Inuit names for snow, isn't it.
:-)
Sure it's a wonderful urban myth, but do you know how many different
words for snow the Australian newspapers uses. Even though people try
hard to dispell that myth I'm pretty sure there is at least one of
those words for snow that fit this example from Chinese
早上好，表姐！ which is Good morning, my
female-cousin-on-maternal-or-paternal-aunt's-side-elder-than-myself[1
].
You Loose Information by doing bad Translation.
[1]http://www.21jfs.com/xykw/ShowArticle.asp?ArticleID=600
http://news.bbc.co.uk/2/hi/africa/3830521.stm
How about
snow,slush,sleet, blizzard, drift, white-out, flurry, powder,
dusting, hardpack, crust
For me most snow would then have to be natural=snow, and I'm very
passionate about snow. But I didn't grow up thinking about snow in
English did I. This is about making maps not creating english tags for
maps.
/Erik
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On 26 Nov 2008 at 21:03, David Earl wrote:
On 26/11/2008 20:47, Bob Jonkman wrote:
This can be solved with an equivalence table at the renderer, eg:
{place,plaats,ilagay}={village,barangay,dorpje} : render(brown)
{natural,pat}={snow,patuquaujuq,patuqun,patpat} : render(white)
[...]
Yes, but *every* renderer - nay, *every* consumer everywhere -
editors, renderers, search engines, route finders, each of which must
all know about all the tag variants everyone uses.
[...]
Surely it must be better to centralise handling of this
Absolutely. The equivalence table is stored whereever the mapping database is
stored. As the database (or a portion) is downloaded, so is the relevant
portion of
the equivalence table.
The beauty is that the existing tags and values continue to exist as they are
now,
so existing applications continue to work as they always have. New
applications
that incorporate the equivalence table lookups can make use of the extra
information
as they see fit.
so that consumers only have to know either about one canonical form,
But there isn't one canonical form. That's the problem.
or can get the data out in their language (e.g. for editing it) rather
than necessarily the form in which it was input.
You can only get the data out in your own language if there is a translation
mechanism somewhere. Equivalence tables could provide the i18n portion
(another
use I hadn't anticipated); the renderer, search engine, route finder c. can
provide
the l10n part.
Why force re-invention of the wheel in every application that uses
OSM?
Because the needs of OSM users isn't being met by current data and
applications.
The issue is important enough to have sparked a 20+ message discussion over two
days.
One way to centralise it might be to provide a central table consumers
can work from. But so much better to have it happen transparently.
Agreed on both points, which aren't mutually exclusive.
David
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On 26/11/2008 22:04, Bob Jonkman wrote:
On 26 Nov 2008 at 21:03, David Earl wrote:
On 26/11/2008 20:47, Bob Jonkman wrote:
This can be solved with an equivalence table at the renderer, eg:
{place,plaats,ilagay}={village,barangay,dorpje} : render(brown)
{natural,pat}={snow,patuquaujuq,patuqun,patpat} : render(white)
[...]
Yes, but *every* renderer - nay, *every* consumer everywhere -
editors, renderers, search engines, route finders, each of which must
all know about all the tag variants everyone uses.
[...]
Surely it must be better to centralise handling of this
Absolutely. The equivalence table is stored whereever the mapping database
is
stored. As the database (or a portion) is downloaded, so is the relevant
portion of
the equivalence table.
The beauty is that the existing tags and values continue to exist as they are
now,
so existing applications continue to work as they always have. New
applications
that incorporate the equivalence table lookups can make use of the extra
information
as they see fit.
so that consumers only have to know either about one canonical form,
But there isn't one canonical form. That's the problem.
or can get the data out in their language (e.g. for editing it) rather
than necessarily the form in which it was input.
You can only get the data out in your own language if there is a translation
mechanism somewhere. Equivalence tables could provide the i18n portion
(another
use I hadn't anticipated); the renderer, search engine, route finder c. can
provide
the l10n part.
Why force re-invention of the wheel in every application that uses
OSM?
Because the needs of OSM users isn't being met by current data and
applications.
The issue is important enough to have sparked a 20+ message discussion over
two
days.
One way to centralise it might be to provide a central table consumers
can work from. But so much better to have it happen transparently.
Agreed on both points, which aren't mutually exclusive.
OK, so you are happy to have the translation table centrally, but not
the algorithm which applies it. I still don't really see why you want to
make each application implement its own version of the algorithm when it
could so simply be done as the data passes into and out of the database.
Applications need change hardly at all this way, whereas your way all
renderers have to understand (via a table and a homegrown algorithm)
what each of the equivalent tags mean, otherwise the maps don't render
correctly.
Here's an example of how I'm seeing it working: User T is Thai so sets
JOSM to work in Thai (I'm not considering UIs here, just the data). JOSM
tells the API that's what the language is when it uploads or downloads.
So T's download automatically sees what I know as a village as
thai-for-village. N, the Norwegian visitor to Bangkok entered that
village the previous day in norwegian-for-village having told Potlatch
she was working in Norwegian. T decides it is really a town, so changes
it to town-in-thai and uploads it. N downloads it the following day and
sees town-in-norwegian. Mapnik also sees it and renders town-as-a-symbol.
All that happens with the only change to the API being an indication of
what language you want to communicate in. You don't care how it is
stored (it could store the source data and language codes or translate
it on the fly - but that's all abstracted away, you don't care it is
hidden behind the API).
(Of course the API would need to include a protocol for changing the table.)
This reduces the impact across all the software, doesn't mean you have
to download every combination of every tag with each download, and can
be implemented more efficiently as the API only has to consider the one
language requested by the user, not all combinations.
I just don't understand why you want to distribute this common code (or
more likely subtly different code!) and data around all the applications
when it can be done just once. The effect is identical in the end - when
all applications implement the table handling in your case - whereas
doing it centrally all applications continue to work and if they make a
tiny change to allow users to specify which language automatically get
localised tags.
David
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On 25/11/2008 06:41, Elena of Valhalla wrote: On Tue, Nov 25, 2008 at 12:08 AM, Erik Johansson [EMAIL PROTECTED] wrote: On Mon, Nov 24, 2008 at 4:11 PM, David Earl [EMAIL PROTECTED] wrote: Better editor (or API) support for different languages is surely a better way to go. If everyone here are native english speakers or speaks relatively fluently, and they all take the pragmatic route of using UK centric tagging how is this ever going to happen? I am not a native english speaker, but the place for language support is the editor, not the API, and the editors are already being translated, so it is already happening The problem about putting it in the editor (and it isn't just editors - it's all the tools, producers and consumers) is that each tool has its own means of doing it. The fact that the database stores place=village is only coincidentally a pair of English words. It could equally well be 27:42. It's basically something that means this is a village or whatever that sentence reads in your own language. So what I had in mind was a means for the API to accept and retrieve data in a more human friendly form in whatever languages we support and translate to and from the internal canonical form (which the user need never see). That way we achieve consistency across many different tools. Of course there's other things to translate in the tools, in the UI and so on, but this is part of the fundamental data, so making is consistent across all our applications seems desirable to me. Doing it in the editors is better than nothing, but second best. The worst possible solution seems to me to be to store tags and values which have the same meaning but are expressed in hundreds of different ways. Every application then has to have huge tables of alternative representations of the same thing, and they all end up doing the same job, no doubt in dozens of myriad ways and different (computer) languages, and probably using different translation tables too. I think we're editing too close to the actual data that is stored, and a level of abstraction in between the tools and the internal database representation would support localized versions of tags and values better. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Tue, Nov 25, 2008 at 6:34 AM, Erik Johansson [EMAIL PROTECTED] wrote: Your and Elenas opinion seems to be that Openstreetmap should be consistent. That's not my fight; OSM isn't consistent, hasn't been since 2005. I'm actually only talking about translation, lets say I want to tag snow, natural=snow might seem perfect in english but cultures and languages that deal with snow will have a much bettter understanding of it and hence using natural=snow will be barbaric. To illustrate: pat=patuqutaujuq == natural=snow pat=patuqun == natural=snow pat=patpat == natural=snow natural=snow == (list of alternative meanings) There are more examples. even with simple things like highway=crossing. In civilized places there are more types than the barbaric Swedes has. I'm afraid I have to agree with David on this point. Ideally, there should be a single, consistent representation for any given abstract concept. The fact that for the most part, these values are in UK English is more an accident of history and we'd have tools to abstract that away from the end user. Even in the case you cite, if we found a need to tag three different kinds of snow, we could come up with a canonical representation for it, which for all I care could be represent in the database as: natural=patuqutaujuq natural=patuqun natural=patpat or natural=old_snow natural=powdery_snow natural=snow Then, in the UI, the canonical value could be translated into an appropriate local expression. -Scott -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
Hi, Erik Johansson wrote: pat=patuqutaujuq == natural=snow pat=patuqun == natural=snow pat=patpat == natural=snow Ah, the old story about the various Inuit names for snow, isn't it. How about natural=snow snow=slush snow=sleet snow=blizzard snow=drift snow=white-out snow=flurry snow=powder snow=dusting snow=hardpack snow=crust if you're looking for diversity. - All these should, of course, ideally take the form of multiple tags, with one first saying there is snow and then, in a second or third tag, say something about where it came from, where it goes to, how much there is, how cold it is, and whether or not it has dog pee traces in it. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Wed, Nov 26, 2008 at 1:01 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Erik Johansson wrote: pat=patuqutaujuq == natural=snow pat=patuqun == natural=snow pat=patpat == natural=snow Ah, the old story about the various Inuit names for snow, isn't it. :-) Sure it's a wonderful urban myth, but do you know how many different words for snow the Australian newspapers uses. Even though people try hard to dispell that myth I'm pretty sure there is at least one of those words for snow that fit this example from Chinese 早上好，表姐！ which is Good morning, my female-cousin-on-maternal-or-paternal-aunt's-side-elder-than-myself[1]. You Loose Information by doing bad Translation. [1]http://www.21jfs.com/xykw/ShowArticle.asp?ArticleID=600 http://news.bbc.co.uk/2/hi/africa/3830521.stm How about snow,slush,sleet, blizzard, drift, white-out, flurry, powder, dusting, hardpack, crust For me most snow would then have to be natural=snow, and I'm very passionate about snow. But I didn't grow up thinking about snow in English did I. This is about making maps not creating english tags for maps. /Erik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Tue, Nov 25, 2008 at 6:13 PM, Scott Atwood [EMAIL PROTECTED] wrote: [..] Ideally, there should be a single, consistent representation[...]in UK English [..] Then, in the UI, the canonical value could be translated into an appropriate local expression. Hi again! Since there is little consistency in English tags, I don't see why you first canonize a list of one-true-way tags then translate it to other languages. There are many things that aren't mentioned in our tags, even more isn't mentioned on the wiki, how will you supply translations for these things? And why is it important for foreign tags to be 1. documented in the wiki 2. translated in the editor interface 3. having a good English translation But you it's ok to use shitty english tags. Consistency is the stigma of OSM, that's what's sweet. /Erik PS. sorry for misquoting you, but I feel that is what you say.. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Tue, Nov 25, 2008 at 5:41 PM, Erik Johansson [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 6:13 PM, Scott Atwood [EMAIL PROTECTED] wrote: [..] Ideally, there should be a single, consistent representation[...]in UK English [..] Then, in the UI, the canonical value could be translated into an appropriate local expression. Hi again! Since there is little consistency in English tags, I don't see why you first canonize a list of one-true-way tags then translate it to other languages. There are many things that aren't mentioned in our tags, even more isn't mentioned on the wiki, how will you supply translations for these things? And why is it important for foreign tags to be 1. documented in the wiki 2. translated in the editor interface 3. having a good English translation But you it's ok to use shitty english tags. Consistency is the stigma of OSM, that's what's sweet. /Erik PS. sorry for misquoting you, but I feel that is what you say.. I'm coming at this as someone with a hobbyist interest in linguistics, and as a software engineer with both personal and professional interest and experience with internationalization and localization. FWIW, I do feel that you have misunderstood me and unfairly misquoted me. What I said, and what I mean, is that there should be a single consistent internal representation for any given abstract concept. That makes things much easier for editors, validators, renderers, and any other automated software that needs to work with the data in OSM. The fact that most tags today are in UK English is an accident of history. If you ever look at the details of an HTTP transaction, or an SMTP mail transaction, you will similarly see that the internal representations in these systems are in US English for similar historical reasons. But it isn't necessary to speak English to use a web browser or an email client, because these details are abstracted away from the end users. At least for common, standardized, and/or well-established tags, the OSM editing clients should abstract away the underlying representation (which happens to be UK English, but could just as easily have been French or Swedish, or even an abstract number), and allow the user to add tags in his or her preferred language. Since the tagging system is completely open-ended, things get a little fuzzier for new or ad-hoc tags. For what it is worth, I'm OK with a little fuzz around the edges. There is an inherent struggle between freedom and constraint here. Part of the power of OSM is that people are free to invent new tags on the fly to meet new needs and situations as they arise. But for OSM to be universally useful and to avoid balkanizing into mutually unintelligible sub-maps we need to strive towards a common representation. Over time, new tags that lost to an alternative representations should be re-normalized to the standard representation, something that could be aided by appropriate assistance from editors and validators. -Scott -- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
2008/11/26 Erik Johansson [EMAIL PROTECTED] On Tue, Nov 25, 2008 at 6:13 PM, Scott Atwood [EMAIL PROTECTED] wrote: [..] Ideally, there should be a single, consistent representation[...]in UK English [..] Then, in the UI, the canonical value could be translated into an appropriate local expression. Hi again! Since there is little consistency in English tags, I don't see why you first canonize a list of one-true-way tags then translate it to other languages. There are many things that aren't mentioned in our tags, even more isn't mentioned on the wiki, how will you supply translations for these things? And why is it important for foreign tags to be 1. documented in the wiki 2. translated in the editor interface 3. having a good English translation But you it's ok to use shitty english tags. Consistency is the stigma of OSM, that's what's sweet. The issue here is that where ever there is a need to express intent in a language other than English some software needs to be modified to allow it to work... One option, as mentioned before, is the editors, through the use of translated presets or a more indepth translation of tags users could work in whichever language they were most comfortable with for most things (tagging non-basic things, especially if they hadn't been translated, and how to deal with that regarding lack of translation could be tricky) but what would get sent to the API and stored in the database would be the 'standard' tags, be they english/pseudo english as now, numeric keys or something more exotic. This allows for all tools that use the data to work with a globally consistent(ish) set of tags for things that refer to the same concept. Another option would be in every application that uses the data, renderers etc, if every language can have it's own keys and values the users of the data would need to be modified to support the ability to detect every possible language in both the keys and values with no clues, if they don't then they couldn't use the data available in other languages... The key thing here though is that the keys and values that are in use are only English because a) that's where it started and, probably more importantly, b) because English thanks to it's pretty wide spread use is really more likely to be understood around the world than most other languages, whether or not this influenced the decision, I don't know, but I think it's a good point... I, personally, feel that keys and standard values, e.g. the standard values within place, should be ascii. I feel that there should be some form of standardness (real word?) to them so that people can express their intent in a way that data users are likely to understand. I feel it's important to document them as much as possible so that people adding data can use preexisting tags that might cover their needs rather than created unnecessary new tags. I don't care if all keys are stored as random 128bit values expressed as hex in the API or English or German or French or insert your own language here, as long as only standard ascii characters were used... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
Hey! This sounds sensible. Why not as place=village (or what happens to suit that place) and place:ph=barangay ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Rendering barangays for the Philippines
Hi, We are having a discussion in talk-ph on tagging barangays: http://lists.openstreetmap.org/pipermail/talk-ph/2008-November/000129.html The old practice was to tag barangay as place=village. By definition from the Map Features: http://wiki.openstreetmap.org/wiki/Map_Features#Places The tag place=village is almost the same with what we define as barangay in the Philippines: http://en.wikipedia.org/wiki/Barangay Of course the correct way would be to tag them as place=barangay and we will do so from now on. Can we request the renderers to render them the same as place=village? Or any other ideas? cheers, maning PS: I know others would say just render your own slippymap. We want to and we will, but not right now, maybe soon. -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
- Original Message - From: maning sambale [EMAIL PROTECTED] To: Talk Openstreetmap talk@openstreetmap.org Sent: Monday, November 24, 2008 9:10 AM Subject: [OSM-talk] Rendering barangays for the Philippines Hi, We are having a discussion in talk-ph on tagging barangays: http://lists.openstreetmap.org/pipermail/talk-ph/2008-November/000129.html The old practice was to tag barangay as place=village. By definition from the Map Features: http://wiki.openstreetmap.org/wiki/Map_Features#Places The tag place=village is almost the same with what we define as barangay in the Philippines: http://en.wikipedia.org/wiki/Barangay I agree. Of course the correct way would be to tag them as place=barangay and we will do so from now on. Can we request the renderers to render them the same as place=village? Or any other ideas? Yes, keep tagging them as place=village. This tag is used to denote any settlement of village size. It doesn't imply that in the local language such settlements are called villages. David cheers, maning PS: I know others would say just render your own slippymap. We want to and we will, but not right now, maybe soon. -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Mon, Nov 24, 2008 at 12:36 PM, David Groom [EMAIL PROTECTED] wrote: Of course the correct way would be to tag them as place=barangay and we will do so from now on. Can we request the renderers to render them the same as place=village? Or any other ideas? Yes, keep tagging them as place=village. This tag is used to denote any settlement of village size. It doesn't imply that in the local language such settlements are called villages. Please tag it is as place=Barangay. It isn't pragmatic but the current solution is only convenient. You loose a lot if you don't allow local languages. It almost works in anglofied countries, but it's not optimal, by longshot. It would be very easy to tag roads in Sweden if I could say: väg=riksväg. Instead of using an UK created system of tagging. Take things like place=Hamlet it is just a sea of troubles, really. And perhaps opposing it with tags like barangay, we would end them. But I can dream about it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On 24/11/2008 14:46, Erik Johansson wrote: On Mon, Nov 24, 2008 at 12:36 PM, David Groom [EMAIL PROTECTED] wrote: Of course the correct way would be to tag them as place=barangay and we will do so from now on. Can we request the renderers to render them the same as place=village? Or any other ideas? Yes, keep tagging them as place=village. This tag is used to denote any settlement of village size. It doesn't imply that in the local language such settlements are called villages. Please tag it is as place=Barangay. It isn't pragmatic but the current solution is only convenient. You loose a lot if you don't allow local languages. It almost works in anglofied countries, but it's not optimal, by longshot. It would be very easy to tag roads in Sweden if I could say: väg=riksväg. Instead of using an UK created system of tagging. Take things like place=Hamlet it is just a sea of troubles, really. And perhaps opposing it with tags like barangay, we would end them. But I can dream about it. I'm sure you ought to be able to use väg=riksväg, but there needs to be a canonical form, otherwise we have something that is completely unmanageable or degenerates into a set of national systems rather than a world map. There's a big difference between being able to manage the map contents in your own language (good) and proliferating synonyms (bad). There's no reason a canonical form should be in UK English (they could just be numbers, for example), except that was how it started. David Groom said barangay is essentially the same as village, so village is the tag to use for this. Going off down your own set of tags for things is allowed but very unhelpful, and I think it would be unwise for barangay to be rendered, as there will then be a flood of tens of thousands of tag synonyms needing to be rendered in every language there is. If it _is_ a fundamentally different thing, then fine, it should have its own tag, but settlements of varying sizes are pretty much worldwide. Better editor (or API) support for different languages is surely a better way to go. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Mon, Nov 24, 2008 at 4:11 PM, David Earl [EMAIL PROTECTED] wrote: Better editor (or API) support for different languages is surely a better way to go. If everyone here are native english speakers or speaks relatively fluently, and they all take the pragmatic route of using UK centric tagging how is this ever going to happen? So Please tag as place=barangay and create a wiki page with a template or some kind of link that says that this is more or less similar to place=village. This would help in making it render, on the main map. If this list of terms that are translated grow big enough there will be people (me) that will be motivated to work on solutions. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
On Tue, Nov 25, 2008 at 12:08 AM, Erik Johansson [EMAIL PROTECTED] wrote: On Mon, Nov 24, 2008 at 4:11 PM, David Earl [EMAIL PROTECTED] wrote: Better editor (or API) support for different languages is surely a better way to go. If everyone here are native english speakers or speaks relatively fluently, and they all take the pragmatic route of using UK centric tagging how is this ever going to happen? I am not a native english speaker, but the place for language support is the editor, not the API, and the editors are already being translated, so it is already happening The data however should remain as worldwide consistent as it can and to do so it must remain in one language only; maybe uk-en isn't the better choice, but there are plenty of worse one, and surely it is good enough So Please tag as place=barangay and create a wiki page with a template or some kind of link that says that this is more or less similar to place=village. if it is almost a village and needs to be rendered like a village, tag it place=village and write a translation for the main editors and the main routers that call the preset barangay This would help in making it render, on the main map. If this list of terms that are translated grow big enough there will be people (me) that will be motivated to work on solutions. if we go with the localized api way, the list of terms to be translated would grow exponentially: why translate village and not place? why keep highway and not the local name? or anything else? -- Elena of Valhalla email: [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering barangays for the Philippines
Just to summarise a bit: 2 major points: 1. If its a barangay then tag them as such, place=barangay 2. Well it is the same as a village, then tag them as place:village and, add a page in the wiki explaining that the village tag represents barangay in the Philippines There's also a suggestion in talk-ph to add admin_level tag: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00133.html cheers, maning On Tue, Nov 25, 2008 at 2:41 PM, Elena of Valhalla [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 12:08 AM, Erik Johansson [EMAIL PROTECTED] wrote: On Mon, Nov 24, 2008 at 4:11 PM, David Earl [EMAIL PROTECTED] wrote: Better editor (or API) support for different languages is surely a better way to go. If everyone here are native english speakers or speaks relatively fluently, and they all take the pragmatic route of using UK centric tagging how is this ever going to happen? I am not a native english speaker, but the place for language support is the editor, not the API, and the editors are already being translated, so it is already happening The data however should remain as worldwide consistent as it can and to do so it must remain in one language only; maybe uk-en isn't the better choice, but there are plenty of worse one, and surely it is good enough So Please tag as place=barangay and create a wiki page with a template or some kind of link that says that this is more or less similar to place=village. if it is almost a village and needs to be rendered like a village, tag it place=village and write a translation for the main editors and the main routers that call the preset barangay This would help in making it render, on the main map. If this list of terms that are translated grow big enough there will be people (me) that will be motivated to work on solutions. if we go with the localized api way, the list of terms to be translated would grow exponentially: why translate village and not place? why keep highway and not the local name? or anything else? -- Elena of Valhalla email: [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- |-|--| | __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda | | '-._7' |Freedom is still the most radical idea of all -N.Branden| | /'.-c |Linux registered user #402901, http://counter.li.org/ | | | /T |http://esambale.wikispaces.com/ | | _)_/L I http://epsg4253.wordpress.com/ | |-|--| ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
