[OSM-legal-talk] CouchDB: Software Licenses under ODbL
Hello! While writing my master-thesis, I stumbled upon an interesting problem: When I save a set of OSM data to a CouchDB, a database is created. Now, I add a couchapp ( http://couchapp.org/page/index) to this database. Since the used files are stored in the same database as database-content, I would have to check whether the Apache 2.0 license (couchapp), the FreeBDS license (OpenLayers) and the MIT-license (jQuery) are compatible with the ODbL. A bizarre situation. Am I right? Greetings, Markus ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CouchDB: Software Licenses under ODbL
Hello, again! According to 2.4 in the ODbL, there should not be any big problems. (The individual items of the Contents contained in this Database my be covered by other rights, [...] .) Am 2012-07-25 15:33, schrieb ScubbX: Hello! While writing my master-thesis, I stumbled upon an interesting problem: When I save a set of OSM data to a CouchDB, a database is created. Now, I add a couchapp ( http://couchapp.org/page/index) to this database. Since the used files are stored in the same database as database-content, I would have to check whether the Apache 2.0 license (couchapp), the FreeBDS license (OpenLayers) and the MIT-license (jQuery) are compatible with the ODbL. A bizarre situation. Am I right? Greetings, Markus ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CouchDB: Software Licenses under ODbL
On 25/07/12 14:33, ScubbX wrote: Hello! While writing my master-thesis, I stumbled upon an interesting problem: When I save a set of OSM data to a CouchDB, a database is created. Now, I add a couchapp ( http://couchapp.org/page/index) to this database. Since the used files are stored in the same database as database-content, I would have to check whether the Apache 2.0 license (couchapp), the FreeBDS license (OpenLayers) and the MIT-license (jQuery) are compatible with the ODbL. A bizarre situation. Am I right? Hi Markus - no. For legal purposes, a database is just a collection of data. What you mean by stored in the same database means stored in a given storage instance of some database software. In IT we call that a database but it's not the same meaning as the legal usage, and shouldn't be confused. In other words - storing some data in the same instance of a database as some OSM data doesn't automatically extend your ODbL responsibilities to that data. If there are no interdependencies, there's no problem. Jonathan. -- Dr Jonathan Harley :Managing Director: SpiffyMap Ltd m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Naming disputes in Ukraine
Hi, I'd like to hear the opinion of others in OpenStreetMap about the following situation that Data Working Group has been asked to mediate. The official language in Ukraine is Ukrainian. To the untrained eye there's not much of a difference to Russian but of course the devil is in the detail, here's a street name example: name:ru = Фурманова улица name:uk = Фурманова вулиця There are many areas in Ukraine where the language used by people who live there is mainly Russian. The clearest example is the Crimea peninsula (http://en.wikipedia.org/wiki/Crimea) where the official language is still Ukrainian, but Russians make up 60% of the population (against 25% Ukrainians) and therefore Russian is the language generally used locally. One Ukrainian mapper told me that if we there *were* mappers in the Crimea (which is an unknown to me), I'm 100% sure that any Crimean mapper would take the Russian-language side. We have photos from the Crimea that document street signs in Russian, but other Ukrainians say that technically signs must be in Ukrainian there and if they aren't then that's just because the government lacks the funds to change them. Predictably, edit wars have broken out in OSM about street names in the area; most streets were created with Russian names initially, sometimes they were there for years, until this year members of the Ukrainian community started renaming streets to Ukrainian (often, it seems, automatically). The Ukrainian community is hotly discussing these edits (http://forum.openstreetmap.org/viewtopic.php?id=12367) but cannot seem to come to a conclusion; our general naming rule (The default name (occupying the 'name' tag without suffix) should be the name in whatever language is used locally., from wiki.openstreetmap.org/wiki/Names) is interpreted by some to mean locally in the area and by some to mean locally in the country. Based on the facts It would be relatively easy for us to decree that the name tag should be Russian in the Crimea. The problem is that Ukraine has lots of communities where there is still a Russian majority but not as pronounced as in the Crimea. Of course the issue is highly political, with ethnic Russians fighting for their identity against a government that forces them to use Ukrainian in official business etc., so if someone now comes along in OSM and changes the name of the street they live in to Ukrainian then that means much more to them than just a name on a street. But where to stop? If we say to use Russian in the Crimea, then what about some city in Eastern Ukraine where people also use more Russian than Ukrainian? And what if the use is maybe even local to a city quarter? (What if residents of San Francisco's Chinatown demand that the name tag in their area be in Chinese?) The best solution to this conflict is, of course, a dual-language map where people can switch. Neighbouring Belarus has problems similar to Ukraine with regards to the Russian language, and they have created a dual-language map on openstreetmap.by. In the long run I hope we'll have a world-wide map that covers all languages of the world (Jochen is working on something like this, funded by Wikipedia, see recent http://blog.jochentopf.com/ entries). In the medium term, maybe OSMF could help people in the Ukraine set up a dual-language map. But in the short term, a solution needs to be found regarding the name tag. (Simply removing all name tags in the Crimea, as we once did with the Jerusalem name tag when there was a conflict, is probably not something that would go down well.) So, my questions to you are 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
(Skipping all this, because obviously you are not that well informed about how this situation with Ukraine came into being) So, my questions to you are 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute that. So, *in my opinion*, no. 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? I think it always have been local *official* language. As always, for other languages, including Russian, there is name:ru=* tag. Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On 07/25/2012 09:42 AM, Peteris Krisjanis wrote: Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute that. So,*in my opinion*, no. In my opinion, if there are multiple languages and there is a dispute, the language on the sign should be the guiding principle. If we look where I live (Norway), we have multiple official languages. Some municipalities have 4 official languages, in that case, the fist name on the sign should be in the name tag. You also have nat_name, and loc_name that can be used. eg. name= whats on the sign nat_name=the nations official name name:code=language name. So this sign: http://www.sprakrad.no/upload/11207/porsanger.jpg name=Porsanger kommune name:no=Porsanger kommune name:kvensk=Porsangin komuuni name:si=Porsanggu gielda PS: do not know how to get the non-ASCII char in the picture... And I do not know the langcode for kvensk. One reason for having the sign name as name=, is that the ones that really needs a map, aren't local people, but travelers, and they need to be able to look on the map and the signs. In other cases names can be more diffrent than ? ? and ? ??. So as a potential tourist to Ukraine Use the signed name... -- Mike Menk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
T , 2012-07-25 10:08 +0200, Michael Eric Menk rakstīja: On 07/25/2012 09:42 AM, Peteris Krisjanis wrote: Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute that. So, *in my opinion*, no. In my opinion, if there are multiple languages and there is a dispute, the language on the sign should be the guiding principle. If we look where I live (Norway), we have multiple official languages. But in Ukraine there is one :) Some municipalities have 4 official languages, in that case, the fist name on the sign should be in the name tag. I don't dispute that, but this is different case. There is one official language, then there is artificially created huge minority of Russians (and in some regions majority) during Soviet times, which is reason why we have this dispute here. However, I don't want to dictate what Ukrainian community should do. It's their own decision. I have other question though - maybe we should nuke name=* generic usage (or leave it for English) and stick with name:lang=*? It is very hard to detect what language is used in name=* as you should use outside prererences, etc. Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OT (was: Re: Naming disputes in Ukraine)
On Wed, 25 Jul 2012 10:08:25 +0200, Michael Eric Menk wrote: So this sign: http://www.sprakrad.no/upload/11207/porsanger.jpg name=Porsanger kommune name:no=Porsanger kommune name:kvensk=Porsangin komuuni name:si=Porsanggu gielda PS: do not know how to get the non-ASCII char in the picture... And I do not know the langcode for kvensk. Gosh, I've (mis)typed that character so many times, that I'm glad it's a real character used by real people somewhere in the world :D AltGr + G: ŋ (in fact, I always type that when I rapidly write @gmail.com) ..and the code for Kvensk is fkv. Kindly, David (and sorry for the OT) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Peteris Krisjanis wrote: (Skipping all this, because obviously you are not that well informed about how this situation with Ukraine came into being) Actually I don't think it is particularly relevant in any of these disputes, the thing is simply that OSM is fundamentally 'English' and this is the problem? Personally when I look at a map I prefer 'English' names, and so I would anticipate that someone would be helpful and provide an :en translation ... which would probably start another dispute ... but the point here is that what ever is done is wrong. The starting point is the tagging, and every name entered should have the :lang extension, even English ones, so that when raw data is accessed a number of options are available. The applications reading the data then display the preferred language of the user. Of cause what do we default to is the crux of the problem here, but having a CHOICE would get over many of the disputes? Rendering to a single map is never going to be ideal, and the 'map what is on the ground' rule should ALWAYS take priority. It's not use printing a map with welsh on it if the road signs only show English. So from my point of view if a print an 'untranslated' map I would expect to be able to find the roads if I could read the signs? Providing a translated map is exactly what the dual map approach was set up for but has to be done on a regional rather than world basis? So ... TAG every language (please ;) ) but keep the main osm map following the 'map what is on the ground' rule ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Peteris, On 07/25/2012 09:42 AM, Peteris Krisjanis wrote: (Skipping all this, because obviously you are not that well informed about how this situation with Ukraine came into being) I am trying to get a good picture of the situation, without being dragged into an ethnic conflict that seems to be the very reason why the Ukrainian community cannot solve this problem themselves. I have looked at the history of objects in OSM and if you believe that the key facts I mentioned (objects usually created in Russian, then renamed to Ukrainian a few months ago) are wrong then feel free to show us examples. 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute that. So, *in my opinion*, no. Russia, as a country, isn't involved. We are talking about Ukrainian citizens here who live in Ukraine and who prefer to use the Russian language. 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? I think it always have been local *official* language. This certainly is a valid line of argument; however even the Ukrainian government seems to see the problem and now allows regional governments to define additional official languages: http://www.nytimes.com/2012/07/04/world/europe/ukraine-parliament-adopts-russian-language-bill.html I don't know if whatever regional government is responsible for the Crimea has already made use of these powers but there's no doubt that they will, is there? Which will lead to the Russian language having official status in the Crimea, and certainly with two official languages, we'd choose that which is used on the ground for the name tag, right? This also demonstrates a weakness of the official language argument: It seems to be arbitrary. The law I quoted seems to have been passed with a slim majority, and it paves the way for Russian to be an official language in the Crimea. But the article says there are many Ukrainians who don't like that, so it is quite possible that the next government strikes down the law again, so Russian won't be an official language in the Crimea any more, and so on - do we really think it is good to change the name tags in the Crimea with every successive Ukrainian government just because the political whim of the day is for or against giving Russian official status? The people on the ground don't change, it's the same people in the same houses in the same streets, just a different government 800km away in Kiev... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
1. No, in this case Russian name should be in name:ru only. Since the official language is Ukrainian this should be used. 2. The area should not be limited by sq km but by independent administrative body (country or its autonomous part). If there is official language, this should be used, if there is not one the most common should be it. Generally only name:language keys should be used in my opinion. It does not cause editing wars - this issue is moved to rendering, which is far easier to control. Even in undisputed areas there is added information about the language... LM_1 2012/7/25 Peteris Krisjanis pec...@gmail.com: (Skipping all this, because obviously you are not that well informed about how this situation with Ukraine came into being) So, my questions to you are 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute that. So, *in my opinion*, no. 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? I think it always have been local *official* language. As always, for other languages, including Russian, there is name:ru=* tag. Cheers, Peter. ___ 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] Naming disputes in Ukraine
Hi, On 07/25/2012 10:25 AM, Lester Caine wrote: Personally when I look at a map I prefer 'English' names, and so I would anticipate that someone would be helpful and provide an :en translation ... Actually the Ukrainian community is providing a (automatically generated, I believe) English transliteration in the name:en tag for many objects so if you go to open.mapquest.com which prefers English names you should be fine ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On Wed, 2012-07-25 at 11:23 +0300, Peteris Krisjanis wrote: I have other question though - maybe we should nuke name=* generic usage (or leave it for English) and stick with name:lang=*? It is very hard to detect what language is used in name=* as you should use outside prererences, etc. +1 from me.. but, how would the renderer know what name:* to use then? Country level is not even enough as for example here (.fi) we have some regions that should use the swedish name. -- Kaj-Michael Lang mil...@tal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Peteris Krisjanis wrote: I have other question though - maybe we should nuke name=* generic usage (or leave it for English) and stick with name:lang=*? It is very hard to detect what language is used in name=* as you should use outside prererences, etc. That was the bit that was not quite so clear on my post ;) BUT we do still need some flag which indicate what language is used on the sign we are looking at!!! I would not be so blinkered to insist that the main map is 'English' - this should always be 'on the ground', but an 'English' layer would be nice :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Our principal product is a street map. A street map is used to navigate in unfamiliar places. The names on the map must correspond with names on a street signs, signposts, etc. so that strangers may verify their position. So it is nothing to do with 'official' languages. The map needs to correspond with the observed real world. If street signs in Ukraine are in Russian, then the tagged name should be in Russian. When the signs are changed to Ukrainian, then that is the time to re-tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Frederik Ramm wrote: Personally when I look at a map I prefer 'English' names, and so I would anticipate that someone would be helpful and provide an :en translation ... Actually the Ukrainian community is providing a (automatically generated, I believe) English transliteration in the name:en tag for many objects so if you go to open.mapquest.com which prefers English names you should be fine ;) But I would still need to know what was on the signs as well if I went there :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Our principal product is a street map. A street map is used to navigate in unfamiliar places. The names on the map must correspond with names on a street signs, signposts, etc. so that strangers may verify their position. So it is nothing to do with 'official' languages. The map needs to correspond with the observed real world. If street signs in Ukraine are in Russian, then the tagged name should be in Russian. When the signs are changed to Ukrainian, then that is the time to re-tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Malcolm Herring wrote: Our principal product is a street map. A street map is used to navigate in unfamiliar places. The names on the map must correspond with names on a street signs, signposts, etc. so that strangers may verify their position. So it is nothing to do with 'official' languages. The map needs to correspond with the observed real world. If street signs in Ukraine are in Russian, then the tagged name should be in Russian. When the signs are changed to Ukrainian, then that is the time to re-tag. Nicely put ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
WHAT OpenStreetMap is not mainly a database, the project produce a rendered map that should be used and usable for real ??? It's not only meant for contributors to show their edits ? ;-) On 25 juil. 2012, at 10:50, Malcolm Herring wrote: Our principal product is a street map. A street map is used to navigate in unfamiliar places. The names on the map must correspond with names on a street signs, signposts, etc. so that strangers may verify their position. So it is nothing to do with 'official' languages. The map needs to correspond with the observed real world. If street signs in Ukraine are in Russian, then the tagged name should be in Russian. When the signs are changed to Ukrainian, then that is the time to re-tag. ___ 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] Naming disputes in Ukraine
On 25/07/12 09:50, Malcolm Herring wrote: Our principal product is a street map. A street map is used to navigate in unfamiliar places. The names on the map must correspond with names on a street signs, signposts, etc. so that strangers may verify their position. Actually our principle product is open geodata, not a rendered map. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On 25/07/2012 10:21, Tom Hughes wrote: Actually our principle product is open geodata, not a rendered map. Point taken, but it does not alter my argument that the data in the database should correspond to the world as it is, not the world that we may prefer it to be. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 95, Issue 37
There has been recently a similar discussion in the Italian OSM talk list. Basically the outcome - I hope I am summing up correctly - is that the name tags in Italy should contain the official names, which in Italy's bi- or sometimes multi-lingual areas appear in several languages on the officio road signs. So the road sign says Bolzano-Bozen, hence the name tag is name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen name:it=Bolzano. In the discussion some contributors pointed to the different approach in Switzerland. In Switzerland there is only one official name and that is the name in the local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra The legal bases in Italy and in Switzerland are different but clear, and the road signs in both countries reflect the different legal approaches accurately. If the road signs in the Crimea reflect the legal situation correctly then the mappers should take what they see on the road signs, plus whatever name:xx tags are useful. If however the road signs (which are important for the users of the map) do not reflect the legal situation, than you have a conflict. (In that case I would tend to put in the name tag in OSM what is on the road signs, giving priority to the map users' interest, but this is my personal opinion) Volker Padova, Italy On 25 July 2012 09:35, talk-requ...@openstreetmap.org wrote: Send talk mailing list submissions to talk@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk or, via email, send a message with subject or body 'help' to talk-requ...@openstreetmap.org You can reach the person managing the list at talk-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of talk digest... Today's Topics: 1. Re: City routing grid for Australia and the US (Svavar Kjarrval) 2. Re: City routing grid for Australia and the US (Mike N) 3. Re: City routing grid for Australia and the US (Toby Murray) 4. Re: City routing grid for Australia and the US (Jaakko Helleranta.com) 5. Re: City routing grid for Australia and the US (Svavar Kjarrval) 6. Re: Coastline generation resumed (Paul Norman) 7. Naming disputes in Ukraine (Frederik Ramm) -- Message: 1 Date: Tue, 24 Jul 2012 18:59:49 + From: Svavar Kjarrval sva...@kjarrval.is To: talk@openstreetmap.org Subject: Re: [OSM-talk] City routing grid for Australia and the US Message-ID: 500ef0a5.2000...@kjarrval.is Content-Type: text/plain; charset=iso-8859-1 I checked the terms for the Google Maps API and noticed that the collection of data, as done by the tool, is forbidden. Does anyone know of any other services which could provide reference distances? - Svavar Kjarrval On 23/07/12 21:42, Pieren wrote: I've not checked the tool in details but if I understand correctly, the reference distance numbers are coming from Google API. Imo, massively extracting distance like this is a copyright infringement, even if it's just to compare, in the same way using GMaps to check the street names correctness in OSM. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: http://lists.openstreetmap.org/pipermail/talk/attachments/20120724/30cfc7f0/attachment-0001.pgp -- Message: 2 Date: Tue, 24 Jul 2012 15:04:33 -0400 From: Mike N nice...@att.net To: talk@openstreetmap.org Subject: Re: [OSM-talk] City routing grid for Australia and the US Message-ID: 500ef1c1.3000...@att.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 7/24/2012 2:59 PM, Svavar Kjarrval wrote: Does anyone know of any other services which could provide reference distances? Does anyone have a pre-redaction planet that could have an OSRM instance created? I would think that this would not violate the ODBL or CC-BY of either state if it is just used for route comparison. -- Message: 3 Date: Tue, 24 Jul 2012 14:50:43 -0500 From: Toby Murray toby.mur...@gmail.com To: talk@openstreetmap.org Subject: Re: [OSM-talk] City routing grid for Australia and the US Message-ID: cajeqkgsfmcg_xpusiszrqhjsnprxo6qmdldohop_qbsjnrq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 24, 2012 at 2:04 PM, Mike N nice...@att.net wrote: On 7/24/2012 2:59 PM, Svavar Kjarrval wrote: Does anyone know of any other services which could provide reference distances? Does anyone have a pre-redaction planet
Re: [OSM-talk] Naming disputes in Ukraine
There has been recently a similar discussion in the Italian OSM talk list. Basically the outcome - I hope I am summing up correctly - is that the name tags in Italy should contain the official names, which in Italy's bi- or sometimes multi-lingual areas appear in several languages on the official road signs. So the road sign says Bolzano-Bozen, hence the name tag is name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen name:it=Bolzano. In the discussion some contributors pointed to the different approach in Switzerland. In Switzerland there is only one official name and that is the name in the local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra The legal bases in Italy and in Switzerland are different but clear, and the road signs in both countries reflect the different legal approaches accurately. If the road signs in the Crimea reflect the legal situation correctly then the mappers should take what they see on the road signs, plus whatever name:xx tags are useful. If however the road signs (which are important for the users of the map) do not reflect the legal situation, than you have a conflict. (In that case I would tend to put in the name tag in OSM what is on the road signs, giving priority to the map users' interest, but this is my personal opinion) Volker Padova, Italy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline generation resumed
And thanks to you Paul for the data files in the first place. Also I wouldn't want the impression I'm the only one fixing coastline errors, so thanks to the rest of you as well. Just to be clear the error points layer is automatically updated from Paul's files. The other error layers require manual generation so may only get done once a day. Also due to the number of error points the map current won't display in some (maybe all) versions of IE, but is OK in Firefox Chrome. I can't be bothered to fix this, as the number of error points is falling daily, and so it won't be an issue in a while. David - Original Message - From: Paul Norman To: 'osm-talk' Cc: David Groom Sent: Wednesday, July 25, 2012 6:42 AM Subject: RE: [OSM-talk] Coastline generation resumed Minor update: I am now running three times a day. Exact upload times depend on runtime which is largely a factor of dev server speed. Errors points are definitely going down. Many thanks for David Groom for both hosting the visualization and for often fixing errors before I can get to them, even though I know when my runs finish. From: Paul Norman [mailto:penor...@mac.com] Sent: Sunday, July 22, 2012 11:55 PM To: 'osm-talk' Subject: [OSM-talk] Coastline generation resumed I have resumed my daily generation of coastline files. These are generated with the coastcheck program[1] from my jxapi database starting at 5 AM pacific time. They take 3-4 hours to generate and upload, depending on my internet speed at the time. The completed files are uploaded to http://pnorman.dev.openstreetmap.org/coastlines/ If opening these shapefiles in QGIS be sure to create a spatial index for tolerable performance. There is a visualization of errors at http://www.wightpaths.co.uk/coast/ Many of the errors appear to be short errors between ways that became disconnected. More complicated errors are often best fixed by deleting the bad coastline and retracing. [1]: http://svn.openstreetmap.org/applications/utils/coastcheck/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI - Automated edit: footway - sidewalk
I object based on the British/American language. I don't have an account on the forum. Why did people tag sidewalk=* ? Maybe they meant something different to the established tag of footway=*. Change footway in America if you have to, but don't go changing it in the UK or other countries. What's the point of having a preferred language for tags if we go against it because some Americans can't deal with another language. Many other non-British countries cope or use an editor with translations. This is also probably a discussion for tagging@ not the general talk list. On 23 July 2012 11:32, Mike N nice...@att.net wrote: FYI, please provide any feedback to the original author on the forum. http://forum.openstreetmap.**org/viewtopic.php?id=17526http://forum.openstreetmap.org/viewtopic.php?id=17526 __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Greetings
Greetings to you too Chanel, I don't think we've met before but I hope you have been well during your silence. Gregory. On 23 July 2012 22:29, Chanel Malenki cmale...@gmail.com wrote: Hello everyone. This is to advice you all that my absence from talk does not mean I am not available for talk. Pardon my absence from talk and let us resume conversation. Thank you. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Hi, We had similar discussions in Serbia as well, since we need to support two writing systems at the same time (Cyrillic and Latin), and any official ethnic minority languages in areas where they are used. On Wed, Jul 25, 2012 at 11:39 AM, Volker Schmidt vosc...@gmail.com wrote: Basically the outcome - I hope I am summing up correctly - is that the name tags in Italy should contain the official names, which in Italy's bi- or sometimes multi-lingual areas appear in several languages on the official road signs. So the road sign says Bolzano-Bozen, hence the name tag is name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen name:it=Bolzano. While this might reflect signs on the ground, it's bad from data structure point of view because there is no clue to what languages are stored in name= and how to process them if necessary (e.g. automatic transliteration). In the discussion some contributors pointed to the different approach in Switzerland. In Switzerland there is only one official name and that is the name in the local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra Again, you don't know what language is stored in name=, but at least in this case adding also a name:fr would improve the situation. Which brings us back to the point Peteris Krisjanis made: name= without the context of a language is somewhat useless from the database point of view, apart from quick and dirty rendering of what is on the ground. A much better approach would be to dispose of it, and force having name:lang everywhere. Then one would be able to define e.g. on the administrative level (country, district, municipality) what languages to use/render on objects inside that relation. For example: for the whole of Italy relation you would have lang=it, but for the South Tyrol you would have lang=de;it (or whatever order is appropriate) which would take precedence. For any exceptions, you would add lang= on the object itself which would have highest priority... M ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/07/12 12:39, Volker Schmidt wrote: There has been recently a similar discussion in the Italian OSM talk list. Basically the outcome - I hope I am summing up correctly - is that the name tags in Italy should contain the official names, which in Italy's bi- or sometimes multi-lingual areas appear in several languages on the official road signs. So the road sign says Bolzano-Bozen, hence the name tag is name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen name:it=Bolzano. In the discussion some contributors pointed to the different approach in Switzerland. In Switzerland there is only one official name and that is the name in the local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra The legal bases in Italy and in Switzerland are different but clear, and the road signs in both countries reflect the different legal approaches accurately. If the road signs in the Crimea reflect the legal situation correctly then the mappers should take what they see on the road signs, plus whatever name:xx tags are useful. If however the road signs (which are important for the users of the map) do not reflect the legal situation, than you have a conflict. (In that case I would tend to put in the name tag in OSM what is on the road signs, giving priority to the map users' interest, but this is my personal opinion) I also prefer the name that is on the sign, but we should think about always adding the name with its language tag, too, otherwise it is not clear which language is used and you have to get this information from some other source. I see your point in calling ukrainian the only official language but I have to say that for hundreds of years now politics might change borders and languages but as long as the citizen are not forced to leave, it does not change them. Regarding Switzerland, there is one language missing and I thought I have seen multi-lingual sign there, too, especially in the south-east with Rhaeto-Romance as one language. Just my 2ct Colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlAP7WEACgkQalWTFLzqsCvBGwCgxCN2zxFBbIoBTuJInGGD1DtI PIQAn1hc5pPd5OScyjE+pIL/IGXzrMti =IaSg -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
2012/7/25 Miloš Komarčević kmi...@gmail.com: Hi, We had similar discussions in Serbia as well, since we need to support two writing systems at the same time (Cyrillic and Latin), and any official ethnic minority languages in areas where they are used. On Wed, Jul 25, 2012 at 11:39 AM, Volker Schmidt vosc...@gmail.com wrote: Basically the outcome - I hope I am summing up correctly - is that the name tags in Italy should contain the official names, which in Italy's bi- or sometimes multi-lingual areas appear in several languages on the official road signs. So the road sign says Bolzano-Bozen, hence the name tag is name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen name:it=Bolzano. While this might reflect signs on the ground, it's bad from data structure point of view because there is no clue to what languages are stored in name= and how to process them if necessary (e.g. automatic transliteration). In the discussion some contributors pointed to the different approach in Switzerland. In Switzerland there is only one official name and that is the name in the local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra Again, you don't know what language is stored in name=, but at least in this case adding also a name:fr would improve the situation. Which brings us back to the point Peteris Krisjanis made: name= without the context of a language is somewhat useless from the database point of view, apart from quick and dirty rendering of what is on the ground. A much better approach would be to dispose of it, and force having name:lang everywhere. Then one would be able to define e.g. on the administrative level (country, district, municipality) what languages to use/render on objects inside that relation. For example: for the whole of Italy relation you would have lang=it, but for the South Tyrol you would have lang=de;it (or whatever order is appropriate) which would take precedence. For any exceptions, you would add lang= on the object itself which would have highest priority... M ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk I agree LM_1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI - Automated edit: footway - sidewalk
Gregory wrote: I don't have an account on the forum. Your standard OSM login should work there I think? Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Am 25.07.2012 14:54, schrieb Miloš Komarčević: Which brings us back to the point Peteris Krisjanis made: name= without the context of a language is somewhat useless from the database point of view, apart from quick and dirty rendering of what is on the ground. +1 But it is useful for quick and dirty usage like give me any name - and there it's much better than to use the first name-tag found (hooray, everywhere in the world we get Albanian names on the maps!) or something like that. A much better approach would be to dispose of it, and force having name:lang everywhere. I would not like to dispose name, but enforce (but not hardly require) to add name:de even in single-language parts of Germany and so on. Done completely that would lead to name=* everywhere in any language that seems to be useful for the user tagging it (doesn't prevent the disputes of course, but neither does a mapper-defined lang-attribute). name:*=* everywhere as much as needed, but enforced to be once for the language used in name. This can be used to determine the language of name by comparison, while some times more than one language might match. Therefore it's redundant, but matches the requirements fulfilled by the lang-tag implicitely. Then one would be able to define e.g. on the administrative level (country, district, municipality) what languages to use/render on objects inside that relation. For example: for the whole of Italy relation you would have lang=it, but for the South Tyrol you would have lang=de;it (or whatever order is appropriate) which would take precedence. For any exceptions, you would add lang= on the object itself which would have highest priority... -1 I oppose to have rendering rules in the data like suggested here, but again the implicit language definition as described above may be used here, too - even if probably not in the main maps renderer, but that's a completely different thing. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI - Automated edit: footway - sidewalk
On Wed, Jul 25, 2012 at 6:47 AM, SomeoneElse li...@mail.atownsend.org.ukwrote: Gregory wrote: I don't have an account on the forum. Your standard OSM login should work there I think? There's also the whole forums are a PITA factor that mailing lists lack entirely. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
colliar wrote: I also prefer the name that is on the sign, but we should think about always adding the name with its language tag, too, otherwise it is not clear which language is used and you have to get this information from some other source. I'm coming to a point where I might suggest that 'name' is ONLY populated with a language code or codes? Text is stored in name:xx and hopefully over time every language can be supported (or created via google), but the version as displayed on a sign is the current language of the sign, so what one will see on the ground. In the case of multi-lingual signs, xx/yy/zz in the order they appear on the sign ( is that welsh/english or english/welsh ) 'Known as' text can also obviously be added, but to be honest if it's not displayed on a sign SHOULD it be? We are then getting into the area that does not fullfill the 'on the ground rule' ... but may well be appropriate when changes have taken place over time. ( At what point does 'historic' information get removed from the main map rendering or database ) Rendering of the main OSM would use the name selection, while translated versions would simply follow their own rules for selection, but I could make a case for two overlays on the main map, one in english? With links to tile sets in other languages? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Jo wrote: Sorry, don't know anything in Wales... Neither do I - I just live near by ... The point I'm trying to make is that the separator might also be important. In Brussels the choice has been made for - . White space always gets a little tricky, but 'displaying' a list of names is a rendering problem, so mapping xx^yy ( or what ever ) to name:xx - name:yy would be conversion problem anyway, and may involve RTL conversion as well ... what does one do with a pair of names with reverse directions? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On 2012-07-25 at 13:54:28 +0100, Miloš Komarčević wrote: name= without the context of a language is somewhat useless from the database point of view, apart from quick and dirty rendering of what is on the ground. it is a single usecase, but it is one that is very useful, and in a significant number of cases it is probably enough. In the cases where there is only a name for a feature, and said name is in the official language for the country, using just name is simpler and unambigous. I wouldn't go below the country-level however: having e.g. different defaults in Italy except South Tyrol, South Tyrol except for a couple of municipalities, and said municipalities would just be a mess. In the areas where there are more than one language, instead of just disposing of it I believe it is better to use it for whatever name (or names) can be found on the signs on the ground, since that is probably what somebody who is doing a quick and dirty render/router needs, and then sort-of-mandatory name:lang tags can cover all of the other uses. -- Elena ``of Valhalla'' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Lester Caine wrote:
colliar wrote:
I also prefer the name that is on the sign, but we should think about
always
adding the name with its language tag, too, otherwise it is not clear
which
language is used and you have to get this information from some other
source.
I'm coming to a point where I might suggest that 'name' is ONLY
populated with a language code or codes?
This is actually pretty good idea, but...
If we start replacing the content of the name only by language
reference, we will most definitely break a lot of apps.
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang=de / it.)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name=Praha, name:en=Prague}
=name=Praha
{name:de=Bozen, name:it=Bolzano, lang=it - de}
=name=Bolzano - Bozen
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy on the ground rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
Best regards,
Petr Morávek aka Xificurk
signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Petr Morávek [Xificurk] wrote:
Lester Caine wrote:
colliar wrote:
I also prefer the name that is on the sign, but we should think about
always
adding the name with its language tag, too, otherwise it is not clear
which
language is used and you have to get this information from some other
source.
I'm coming to a point where I might suggest that 'name' is ONLY
populated with a language code or codes?
This is actually pretty good idea, but...
If we start replacing the content of the name only by language
reference, we will most definitely break a lot of apps.
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang=de / it.)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name=Praha, name:en=Prague}
=name=Praha
{name:de=Bozen, name:it=Bolzano, lang=it - de}
=name=Bolzano - Bozen
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy on the ground rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
Actually 'lang' could be populated from a higher level area setting initially?
This sidesteps a number of problems in implementation, my only comment would be
as I indicated. lang=it - de or de / it needs to be a single identifiable
character. Formatting should be language specific when building a 'text=
string, and that could be populated in a language specific way for the users
preference anyway?
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
I was thinking about roughly the same idea except the process is a bit
different. There could be an alternate usage through references.
Something like [de] in the name tag could indicate a reference to
name:de. A semicolon in the name tag could be used to indicate the order
of languages to display or backups in case the name:* in the front of
the line don't exist.
- Svavar Kjarrval
On 25/07/12 15:21, Petr Morávek [Xificurk] wrote:
Lester Caine wrote:
colliar wrote:
I also prefer the name that is on the sign, but we should think about
always
adding the name with its language tag, too, otherwise it is not clear
which
language is used and you have to get this information from some other
source.
I'm coming to a point where I might suggest that 'name' is ONLY
populated with a language code or codes?
This is actually pretty good idea, but...
If we start replacing the content of the name only by language
reference, we will most definitely break a lot of apps.
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang=de / it.)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name=Praha, name:en=Prague}
=name=Praha
{name:de=Bozen, name:it=Bolzano, lang=it - de}
=name=Bolzano - Bozen
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy on the ground rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
Best regards,
Petr Morávek aka Xificurk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
In my opinion sorting languages for rendering is the renderer's problem, one can assume that name= tags in countries with a single language is the national language, but for a renderer to understand this, poligons with lang=* or similar must exist (either within OSM or in a separate database) It will be much more logic to store every name in name:xx tags, and let renderers sort out how to deal with them. Renderers must thus have fallback rules in places where several language name tags exists, but again, this is the renderers problem. Now, to allow completely I18N compability in the maps, one would need every version of names to be available, either in name:xx tags within OSM, or in a separate database for name translation. This way, OSM could be completely neutral to naming disputes (as no 'default' name would exist in our database), leaving renderers resolving the various problems. I would love to see our 'default' map layer to show names based on browser language settings (i.e. Moscow would show as Moskva on my map, and my home town show up in Cyrlic in the browser of anyone from Moscov) I understand that it might be a long and complicated task cleaning this up, as 'the entire world' is tagged with name= and only a few regions and places have aditional name:xx Aun Y. Johnsen Sent from my iPad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On Wed, Jul 25, 2012 at 4:21 PM, Petr Morávek [Xificurk]
xific...@gmail.com wrote:
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang=de / it.)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name=Praha, name:en=Prague}
=name=Praha
{name:de=Bozen, name:it=Bolzano, lang=it - de}
=name=Bolzano - Bozen
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy on the ground rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
+1
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Fwd: Re: Naming disputes in Ukraine
Original Message
Subject: Re: [OSM-talk] Naming disputes in Ukraine
Date: Wed, 25 Jul 2012 18:06:56 +0200
From: LM_1 flukas.robot+...@gmail.com
To: Petr Morávek [Xificurk] xific...@gmail.com
I agree that name data itself should be exclusively in name:lang tags.
official names should be kept (especially for countries).
Alternatively multiple values for each name:lang should be supported.
I would not agree that name=* containing language codes be placed on
each and every object - that seems like a lot of duplicities and
mistakes.
There should however be some data in the map what language are to be
used. I would place them in administrative boundary relations for
italy it would be lang=it, for soth tirol (part of italy) it would be
lang=it;de or similar.
More specific would have precedence. If preferred language would not
be present, any other would be used (renderer!s discretion)
Lukáš Matějka
LM_1
2012/7/25 Petr Morávek [Xificurk] xific...@gmail.com:
Lester Caine wrote:
colliar wrote:
I also prefer the name that is on the sign, but we should think about
always
adding the name with its language tag, too, otherwise it is not clear
which
language is used and you have to get this information from some other
source.
I'm coming to a point where I might suggest that 'name' is ONLY
populated with a language code or codes?
This is actually pretty good idea, but...
If we start replacing the content of the name only by language
reference, we will most definitely break a lot of apps.
Taking the best of this and previous ideas, I would propose this:
*** Data producers ***
1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
suffix).
2) Embrace the usage of language specific tags like 'name:en',
'name:de', ...
3) Introduce new tag 'lang', which should contain a pointer to the
locally used language. (For multilingual areas, we could use something
like lang=de / it.)
*** Data consumers ***
How to get name, official_name, etc. in default local format?
- Is there lang tag?
YES: Take its value and replace lang codes by the values of language
specific tags.
NO: Fallback to the tag value withou language suffix.
Examples:
{name=Praha, name:en=Prague}
=name=Praha
{name:de=Bozen, name:it=Bolzano, lang=it - de}
=name=Bolzano - Bozen
---
There are few things I really like about this solution:
1) You can apply the same logic to all language specific tags, not only
'name'.
2) There is no BC break.
3) No data duplication in the main database.
4) You are free to specify locally used multilingual format, so the
result of the algorithm above would satisfy on the ground rule.
5) I could imagine this algorithm implemented in osm2pgsql, it could
automatically expand this to the appropriate general tags on import
time, thus all its users would not have to change a thing in their code.
So, what do you think?
Best regards,
Petr Morávek aka Xificurk
___
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] Naming disputes in Ukraine
Svavar Kjarrval wrote: I was thinking about roughly the same idea except the process is a bit different. There could be an alternate usage through references. Something like [de] in the name tag could indicate a reference to name:de. A semicolon in the name tag could be used to indicate the order of languages to display or backups in case the name:* in the front of the line don't exist. The use of ':' in a key is well establish as flagging a language specific version, so one would not touch that. The 'name=' defaulting to a specific 'lang=' setting makes sense, and can be over-ridden when downloading tag data by a client specific setting. The only addition that needs handling is to sort out just what goes into 'lang=' when more than one language is required by the on the ground situation. In my opinion, we just select a suitable single character separator and add the tag with an appropriate list if required. I don't think you want to start messing with 'name=' itself in this case? But the tools should be able to override the 'name=' tag with a more suitable local option based on a local 'lang=' setting. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
I meant a semicomma, sorry. That is, ; - Svavar On 25/07/12 16:24, Lester Caine wrote: Svavar Kjarrval wrote: I was thinking about roughly the same idea except the process is a bit different. There could be an alternate usage through references. Something like [de] in the name tag could indicate a reference to name:de. A semicolon in the name tag could be used to indicate the order of languages to display or backups in case the name:* in the front of the line don't exist. The use of ':' in a key is well establish as flagging a language specific version, so one would not touch that. The 'name=' defaulting to a specific 'lang=' setting makes sense, and can be over-ridden when downloading tag data by a client specific setting. The only addition that needs handling is to sort out just what goes into 'lang=' when more than one language is required by the on the ground situation. In my opinion, we just select a suitable single character separator and add the tag with an appropriate list if required. I don't think you want to start messing with 'name=' itself in this case? But the tools should be able to override the 'name=' tag with a more suitable local option based on a local 'lang=' setting. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
It does fall under OSM's jurisdiction to indicate what the official names are and which are translations. If I'm a tourist in a country, I need to know the names on the signs, not a renderer's guess or my native language's name. If the renderers have to guess, they have to create additional data for each area and research which languages they should use in each of them, instead of focusing on the rendering process itself. - Svavar Kjarrval On 25/07/12 16:10, Aun Yngve Johnsen wrote: In my opinion sorting languages for rendering is the renderer's problem, one can assume that name= tags in countries with a single language is the national language, but for a renderer to understand this, poligons with lang=* or similar must exist (either within OSM or in a separate database) It will be much more logic to store every name in name:xx tags, and let renderers sort out how to deal with them. Renderers must thus have fallback rules in places where several language name tags exists, but again, this is the renderers problem. Now, to allow completely I18N compability in the maps, one would need every version of names to be available, either in name:xx tags within OSM, or in a separate database for name translation. This way, OSM could be completely neutral to naming disputes (as no 'default' name would exist in our database), leaving renderers resolving the various problems. I would love to see our 'default' map layer to show names based on browser language settings (i.e. Moscow would show as Moskva on my map, and my home town show up in Cyrlic in the browser of anyone from Moscov) I understand that it might be a long and complicated task cleaning this up, as 'the entire world' is tagged with name= and only a few regions and places have aditional name:xx Aun Y. Johnsen Sent from my iPad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Petr Morávek [Xificurk] wrote: Actually 'lang' could be populated from a higher level area setting initially? Well, it could be... but I'm not really a fan of this idea, because... You would need to do a spatial query to get the setting from the higher level. And this complicates everything, because... - Things (multipolygons boundaries especially) get broken pretty frequently, so a single bug in one relation or way could do a lot of damage. - It means that you have to check a whole hierarchy to decide if you need to regenerate the value, which means this would order of magnitude harder to implement in data consumers SW. - Not all data consumers use whole planet data and if they cut out only a small region, they don't have the higher level in their data. - You would need to define how to resolve conflicts, e.g. a way spanning multiple areas with defined lang format. I'm just talking about an initial setup to get things started. This sidesteps a number of problems in implementation, my only comment would be as I indicated. lang=it - de or de / it needs to be a single identifiable character. Formatting should be language specific when building a 'text= string, and that could be populated in a language specific way for the users preference anyway? I don't really understand this. To clarify, my suggestion was basically this: let the lang format be arbitrary, just replace any string matching [a-z_]+ by key:[a-z_]+. E.g. lang=it - de = name=Bolzano - Bozen lang=it (de) = name=Bolzano (Bozen) lang=it / de = name=Bolzano / Bozen While I can understand why you propose this, it makes 'decoding' the languages by tools a little more difficult, and 'hard codes' a format, which alternative uses may need to replace? Does hard coding the display format here make sense in general terms? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Aun Yngve Johnsen wrote: I understand that it might be a long and complicated task cleaning this up, as 'the entire world' is tagged with name= and only a few regions and places have aditional name:xx It would not take that long to clean this up, but it is something that needs to be done anyway if only to identify the languages that appear in 'name=' so that we can then translate them correctly? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
2012/7/25 Lester Caine les...@lsces.co.uk Petr Morávek [Xificurk] wrote: Actually 'lang' could be populated from a higher level area setting initially? Well, it could be... but I'm not really a fan of this idea, because... You would need to do a spatial query to get the setting from the higher level. And this complicates everything, because... - Things (multipolygons boundaries especially) get broken pretty frequently, so a single bug in one relation or way could do a lot of damage. - It means that you have to check a whole hierarchy to decide if you need to regenerate the value, which means this would order of magnitude harder to implement in data consumers SW. - Not all data consumers use whole planet data and if they cut out only a small region, they don't have the higher level in their data. - You would need to define how to resolve conflicts, e.g. a way spanning multiple areas with defined lang format. I'm just talking about an initial setup to get things started. This sidesteps a number of problems in implementation, my only comment would be as I indicated. lang=it - de or de / it needs to be a single identifiable character. Formatting should be language specific when building a 'text= string, and that could be populated in a language specific way for the users preference anyway? I don't really understand this. To clarify, my suggestion was basically this: let the lang format be arbitrary, just replace any string matching [a-z_]+ by key:[a-z_]+. E.g. lang=it - de = name=Bolzano - Bozen lang=it (de) = name=Bolzano (Bozen) lang=it / de = name=Bolzano / Bozen While I can understand why you propose this, it makes 'decoding' the languages by tools a little more difficult, and 'hard codes' a format, which alternative uses may need to replace? Does hard coding the display format here make sense in general terms? Mapnik needs a default that it can work with, so I think hard coding it does indeed make sense. Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On Wed, Jul 25, 2012 at 5:32 PM, Lester Caine les...@lsces.co.uk wrote: Petr Morávek [Xificurk] wrote: lang=it - de = name=Bolzano - Bozen lang=it (de) = name=Bolzano (Bozen) lang=it / de = name=Bolzano / Bozen While I can understand why you propose this, it makes 'decoding' the languages by tools a little more difficult, and 'hard codes' a format, which alternative uses may need to replace? Does hard coding the display format here make sense in general terms? Totally agree, this formatting is not the databases problem, and should be left to the render to decide how to format e.g. the desired list of languages lang=it;de. M ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On Thu, 26 Jul 2012 01:35:21 Lester Caine wrote: Aun Yngve Johnsen wrote: I understand that it might be a long and complicated task cleaning this up, as 'the entire world' is tagged with name= and only a few regions and places have aditional name:xx It would not take that long to clean this up, but it is something that needs to be done anyway if only to identify the languages that appear in 'name=' so that we can then translate them correctly? This was discussed in April in the thread: Transcription and 'internationalization' in place names My suggestion at the time was to always include name:xx=* for the local language xx, even if it is redundant with the name=* tag. The definition of name=* then becomes subtly altered to mean The label we use if no language is specified. Then we can argue what goes into that label, but it could be 'whatever is printed on the sign, including multiple languages'. It is an issue for me as I am mapping in Korea. In Korea we have Korean and English on most signs, but in OSM we are trying to include name:ko and name:en as the two parts separated out. Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
I do not agree with you on this, besides, the language polygon I mentioned can solve your desire here. If the renderer knows what is the official language in an area, than you can in theory tuggle freely between that/those official languages and any other language you would desire. For instance if I am in a country not using latin alphabet street signs, I still would like to see the names in latin script. IMO all of this is not up to OSM, but to renderers. A tag in border relations should be enough to indicate official languages. After that it is up to the renderer how to solve it. Doing it this way relieves OSM from any naming disputes (we are thus handling all names equally), and renderers choose how much effort they want to put in name rendering. Your tourist rendering can easily be done inside an app where official language have been set in a boundary relation. This might also allow municipal relations to overide national standards, as I believe not all parts of Belgium have the same order between the three official languages rendered on street signs. The same can apply for countries that have more official languages only in certain regions, such as northern Norway also have Samii names, the southern part of Finland use a lot of Swedish names, various regions of Switzerland have different settings, etc. Your approach I feel is exposing OSM to a lot of politics and possible edit wars, while the option I try to suggest might limit this type impact for OSM. Same also, for all those countries where tthere are only one official language, the language tag in the boundary relation can allow the renderers to assume that name= is the same as name:xx even if name:xx isn't tagged. That way it will not be confused with name:yy and name:zz Aun Y. Johnsen Sent from my iPad On 25. juli 2012, at 13:37, talk-requ...@openstreetmap.org wrote: Message: 3 Date: Wed, 25 Jul 2012 16:30:47 + From: Svavar Kjarrval sva...@kjarrval.is To: talk@openstreetmap.org Subject: Re: [OSM-talk] Naming disputes in Ukraine Message-ID: 50101f37@kjarrval.is Content-Type: text/plain; charset=iso-8859-1 It does fall under OSM's jurisdiction to indicate what the official names are and which are translations. If I'm a tourist in a country, I need to know the names on the signs, not a renderer's guess or my native language's name. If the renderers have to guess, they have to create additional data for each area and research which languages they should use in each of them, instead of focusing on the rendering process itself. - Svavar Kjarrval On 25/07/12 16:10, Aun Yngve Johnsen wrote: In my opinion sorting languages for rendering is the renderer's problem, one can assume that name= tags in countries with a single language is the national language, but for a renderer to understand this, poligons with lang=* or similar must exist (either within OSM or in a separate database) It will be much more logic to store every name in name:xx tags, and let renderers sort out how to deal with them. Renderers must thus have fallback rules in places where several language name tags exists, but again, this is the renderers problem. Now, to allow completely I18N compability in the maps, one would need every version of names to be available, either in name:xx tags within OSM, or in a separate database for name translation. This way, OSM could be completely neutral to naming disputes (as no 'default' name would exist in our database), leaving renderers resolving the various problems. I would love to see our 'default' map layer to show names based on browser language settings (i.e. Moscow would show as Moskva on my map, and my home town show up in Cyrlic in the browser of anyone from Moscov) I understand that it might be a long and complicated task cleaning this up, as 'the entire world' is tagged with name= and only a few regions and places have aditional name:xx Aun Y. Johnsen Sent from my iPad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
Petr Morávek [Xificurk] wrote: While I can understand why you propose this, it makes 'decoding' the languages by tools a little more difficult, Not really, it's a matter of simple regular expression. and 'hard codes' a format, which alternative uses may need to replace? What? That was the point of my proposal, NO hard-coded format (hard coded in the sense of specifying_one-true-format_ in the algorithm itself). If you stick with my proposal: - you can easily satisfy on the ground rule for the local default value of tag generated from 'lang' template - if you don't want/need the default local template, just ignore the lang value, and generate your own value from key:lang values - if you only want a list of locally used languages, but don't care about the locally used format of multilingual signs, it's again a matter of one simple regular expression (i.e. you can always go in the direction format string=list of langs, but you can never go in the opposite direction) Actually when you put it that way it does make sense ... I was thinking more on displaying two or more names while rendering, but of cause the 'on the ground' format is just as important. I'm just used to keeping data and format separate ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Redaction finished already?
Can not see anything left here: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Will officials confirm this? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Redaction finished already?
On Wed, Jul 25, 2012 at 3:38 PM, Jan Kučera kozuc...@gmail.com wrote: Can not see anything left here: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Will officials confirm this? Mostly. As announced moments ago on rebuild@ by Andy Allan: Hi All, Another step along the way: The redaction bot has completed. All 101,859,280 entities needing examined have now been processed, with the final pass completing at 18:16 UTC I know that there is other work that needs doing before the license changeover itself happens, but the redaction bot has done its job now. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Redaction finished already?
Ok so are imports allowed again? 2012/7/25 Richard Weait rich...@weait.com: On Wed, Jul 25, 2012 at 3:38 PM, Jan Kučera kozuc...@gmail.com wrote: Can not see anything left here: http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php Will officials confirm this? Mostly. As announced moments ago on rebuild@ by Andy Allan: Hi All, Another step along the way: The redaction bot has completed. All 101,859,280 entities needing examined have now been processed, with the final pass completing at 18:16 UTC I know that there is other work that needs doing before the license changeover itself happens, but the redaction bot has done its job now. Cheers, Andy ___ 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] Naming disputes in Ukraine
Hi, On Wed, Jul 25, 2012 at 09:33:43AM +0200, Frederik Ramm wrote: Hi, I'd like to hear the opinion of others in OpenStreetMap about the following situation that Data Working Group has been asked to mediate. The official language in Ukraine is Ukrainian. To the untrained eye there's not much of a difference to Russian but of course the devil is in the detail, here's a street name example: name:ru = Фурманова улица name:uk = Фурманова вулиця How has this been solved in Finland? They have a Swedish minority which is a majority in some places in which case (i heard) the Swedish signs are at the top, otherwise Finnish ist at the top. Its a little bit different as both languages are official languages as i remember. I stick with a very simple rule - Whats on the road sign - that should be in the database. If there is both - the one at the top should be in name and the other in the appropriate secondary language tag. You want to be able to identify the road sign by your map. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Redaction finished already?
Jan Kučera wrote: Ok so are imports allowed again? Back in April I made this request: http://www.mail-archive.com/talk@openstreetmap.org/msg42372.html and I'd suggest that it would help mappers if imports stayed off for a while too. In some areas there's a fair bit of tidying up still to be done, and it isn't always obvious whether an import would partially duplicate something that got partially redacted. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
On 25 jul 2012, at 21:59, Florian Lohoff f...@zz.de wrote: Hi, On Wed, Jul 25, 2012 at 09:33:43AM +0200, Frederik Ramm wrote: Hi, I'd like to hear the opinion of others in OpenStreetMap about the following situation that Data Working Group has been asked to mediate. The official language in Ukraine is Ukrainian. To the untrained eye there's not much of a difference to Russian but of course the devil is in the detail, here's a street name example: name:ru = Фурманова улица name:uk = Фурманова вулиця How has this been solved in Finland? They have a Swedish minority which is a majority in some places in which case (i heard) the Swedish signs are at the top, otherwise Finnish ist at the top. If the area is swedish (i.e. swedish name only or on top) then name=sv-name name:sv=sv-name name:fi=fi-name In finnish areas it is reversed name=fi-name name:sv=sv-name name:fi=fi-name Its a little bit different as both languages are official languages as i remember. I stick with a very simple rule - Whats on the road sign - that should be in the database. If there is both - the one at the top should be in name and the other in the appropriate secondary language tag. You want to be able to identify the road sign by your map. Flo -- Florian Lohoff f...@zz.de ___ 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] Redaction finished already?
Am 25.07.2012 21:50, schrieb Jan Kučera: Ok so are imports allowed again? Imports are by their intrinsic nature never urgent (it is not as if the 3rd party data is going to vanish if you don't import it today). I would strongly suggest doing something more useful, like helping with remapping Australia or Poland, than wasting time on something that can easily wait. Simon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
At 2012-07-25 00:33, Frederik Ramm wrote: Hi, I'd like to hear the opinion of others in OpenStreetMap about the following situation that Data Working Group has been asked to mediate. The official language in Ukraine is Ukrainian. ...So, my questions to you are 1. The concrete question: Should all name tag in the Crimea be in Russian (with appropriate name:uk tags of course), even though the official language in Ukraine is Ukrainian? 2. The general question: What exactly is the local language in an area - can we come up with some rule of thumb that says if X% of people in an area of at least Y sq km use the language... or so? I would say the definition of area should be as local as is reasonable/possible. For many countries, this is certainly sub-national. In a given area, if the vast majority uses a given language, that language should be used/assumed for the name value. It would be good if we had some meta-data somewhere to define this, as well as other defaults/assumptions for an area (e.g. oneway=no except for junction=roundabout and highway=*_link, lanes, sidewalks, maxspeed). If there is no vast majority (say, less than 80%), I would suggest no name tag - only name:xx tags. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[talk-au] Question about relations
attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20120725/4a4432d9/attachment-0001.html -- Message: 2 Date: Wed, 25 Jul 2012 08:55:24 +1000 From: Michael Hampson mhamp...@fastmail.com.au To: Ian Sergeant inas66+...@gmail.com Cc: talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] LTUAE Message-ID: 500f27dc.2050...@fastmail.com.au Content-Type: text/plain; charset=iso-8859-1; Format=flowed Ian, I did see some relations on the M4 that were broken, I'll go back and check them. Must learn more about relations too. Glad to hear you a sticking around John. :) Regards, Michael On 25/07/2012 8:18 AM, Ian Sergeant wrote: But for metroad 10 for example, there were 2 x relations for metroad ten. I expected they were for north and south bound routes as that is the way they appeared to be listed in some other areas I checked so that is what I have done. Put one relation for north and the other for south. If that's not right let me know and I will fix. Not sure how a routing relation works anyway. For the Sydney metroads I have added directional route relations, that use two directional relations for each metroad. This allows the connectivity of the route to be checked quickly during the reconstruction phase, and otherwise does no harm. When we have reached the next stage of maturity we can decide if we want to merge them back into a single route relation with directional elements. So, yes, what you have done is correct. 2. for the road naming where the ref tag for metroad 10 was MR10 I have changed those to network=MR and ref=10. Same for the other roads I have worked on. Not *certain* that is correct though either so if someone could enlighten me would be good thanks That is correct. See the Australian tagging guidelines in the wiki. 3. state highway 29 continues from boundary street along pacific highway and then along delhi road, which makes that small section of the pacific highway sh29 *and* mr1. what should I use to reflect that? It can be part of both route relations. Just my own view on the redaction process. No issue with people who declined the licence agreement. However it was annoying for me to see one of the very first things I used for practice vanish in a puff of smoke. It was just a building outline, a coles supermarket. I named it, put in the opening hours, telephone number, full address details eg addr: city: etc etc. I turned it into a thing of beauty by entering approx 10 odd pieces of information, just for practice and learning. I thought it a bit harsh just because someone traced a building roof everything I added went as well. Tracing the building would have taken less than a minute. I spent 40 minutes researching and entering that extra detail on that single item. Your change sets are still available. You should be able to at least refer to the info you have added. And yes, the loss of data in this way is the hardest. One person just traces from an aerial and then does not agree. Others survey, add cycle facilities, names etc that are lost to OSM. I don't know if it still possible to better use some of this unattached data in the database down the track. Ian ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20120725/5d8e2198/attachment-0001.html -- Message: 3 Date: Wed, 25 Jul 2012 08:58:42 +1000 From: Michael Hampson mhamp...@fastmail.com.au To: Paul HAYDON cadmana...@live.com.au Cc: Talk-AU OSM talk-au@openstreetmap.org Subject: Re: [talk-au] Establishing Priorities on the Central Coast Message-ID: 500f28a2.3090...@fastmail.com.au Content-Type: text/plain; charset=iso-8859-1; Format=flowed Paul, I'll do a little bit around Woy Woy when I visit in a few weeks. Let me know if there is anything specific you need looked at. Regards, Michael On 25/07/2012 3:49 AM, Paul HAYDON wrote: SO, any takers interested in getting organised on the N.S.W. Central Coast? (For arguement's sake, let's call it Woy Woy to Swansea - unless someone has a preferred recommendation). -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20120725/ff00d903/attachment-0001.html -- Message: 4 Date: Wed, 25 Jul 2012 15:04:31 +1000 From: Ian Sergeant inas66+...@gmail.com To: Michael Hampson mhamp...@fastmail.com.au Cc: talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] LTUAE Message-ID
Re: [talk-au] Question about relations
Adrian Plaskitt wrote: My specific question is, when the route passes down only part of a way, say just a few blocks of a longer street, how do you assign the relation to just a few internodes. Is it necessary to split the ways at the nodes and then just assign the relation to the segments between, or is it necessary to create a new way over the top which is just the walking route, or is there some method that is simpler that I have failed to appreciate. I'd split the way, like this: http://www.openstreetmap.org/browse/way/141369518 Here the end of Mandalay Beach Road has been split and the part of the road that belongs to the walking route has been added to the walking route relation ( http://www.openstreetmap.org/browse/relation/400098 in this case). The result looks like this on a map designed to show long distance hiking routes: http://hiking.lonvia.de/en/?zoom=17lat=-35.00144lon=116.53484 Cheers, Andy ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction recovery
Don't worry too much about the Hume, it's almost fixed as far as i can tell. I think I fixed the last issue affecting routing between Melbourne and Sydney tonight. (hopefully) South west sydney is full of broken roads. I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. If you need a change, Adelaide is also a huge mess. On 24/07/2012, at 8:34 PM, Michael Hampson wrote: Hi Brian, Good have you on board Brian. Take a look at the Hume Hwy and M5 motorway if you get a chance. Both head south west out of Sydney. Regards, Michael On 24/07/2012 8:23 PM, Brian Prangle wrote: Hi All I can give assistance retracing roads from bing concentrating on motorways and primary roads - I've made a start in South Sydney. Let me know if there's anywhere more urgent. I map mostly in Birmingham UK wher we're now pretty complete and are mostly tracing buildings from bing and addressing which is slow tedious work - so this provides a bit of welcome relief. It also reminds me of my visit to Oz 4 years ago - might even revisit some favourite places virtually! Regards Brian ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Question about relations
On 25/07/12 16:07, Adrian Plaskitt wrote: Greetings all. I usually confine my mapping to bush tracks and cycle paths as this is what I am most interested in and is often not available from other sources. With the recent devastation of the base map I am remapping some of my local area, and rapidly realising how little I really understand, so forgive this basic question. I also find the wiki very hard to practically understand as it assumes a level of knowledge that is beyond me. I am interested in mapping/remapping the walking route the great north walk, which is an established relation. My specific question is, when the route passes down only part of a way, say just a few blocks of a longer street, how do you assign the relation to just a few internodes. Is it necessary to split the ways at the nodes and then just assign the relation to the segments between, or is it necessary to create a new way over the top which is just the walking route, or is there some method that is simpler that I have failed to appreciate. I am only able to use the potlach editor. Yes, split the way as required, and add only the relevant sections to the relation. John ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] relations
Thanks, fellas, I had worried that splitting ways would cause trouble with route finding etc as one street would become 2 adjoining streets with the same name. Regards, adrian From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 61, Issue 34 To: talk-au@openstreetmap.org Date: Wed, 25 Jul 2012 12:00:07 +0100 Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Question about relations (SomeoneElse) 2. Re: Redaction recovery (Leon Kernan) 3. Re: Question about relations (John Henderson) -- Message: 1 Date: Wed, 25 Jul 2012 07:38:47 +0100 From: SomeoneElse li...@mail.atownsend.org.uk To: talk-au@openstreetmap.org Subject: Re: [talk-au] Question about relations Message-ID: 500f9477.6050...@mail.atownsend.org.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Adrian Plaskitt wrote: My specific question is, when the route passes down only part of a way, say just a few blocks of a longer street, how do you assign the relation to just a few internodes. Is it necessary to split the ways at the nodes and then just assign the relation to the segments between, or is it necessary to create a new way over the top which is just the walking route, or is there some method that is simpler that I have failed to appreciate. I'd split the way, like this: http://www.openstreetmap.org/browse/way/141369518 Here the end of Mandalay Beach Road has been split and the part of the road that belongs to the walking route has been added to the walking route relation ( http://www.openstreetmap.org/browse/relation/400098 in this case). The result looks like this on a map designed to show long distance hiking routes: http://hiking.lonvia.de/en/?zoom=17lat=-35.00144lon=116.53484 Cheers, Andy -- Message: 2 Date: Tue, 24 Jul 2012 21:35:34 +1000 From: Leon Kernan lker...@gmail.com To: talk-au@openstreetmap.org Subject: Re: [talk-au] Redaction recovery Message-ID: 18353cab-6f82-4d09-a7f4-5031dfbc3...@gmail.com Content-Type: text/plain; charset=iso-8859-1 Don't worry too much about the Hume, it's almost fixed as far as i can tell. I think I fixed the last issue affecting routing between Melbourne and Sydney tonight. (hopefully) South west sydney is full of broken roads. I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. If you need a change, Adelaide is also a huge mess. On 24/07/2012, at 8:34 PM, Michael Hampson wrote: Hi Brian, Good have you on board Brian. Take a look at the Hume Hwy and M5 motorway if you get a chance. Both head south west out of Sydney. Regards, Michael On 24/07/2012 8:23 PM, Brian Prangle wrote: Hi All I can give assistance retracing roads from bing concentrating on motorways and primary roads - I've made a start in South Sydney. Let me know if there's anywhere more urgent. I map mostly in Birmingham UK wher we're now pretty complete and are mostly tracing buildings from bing and addressing which is slow tedious work - so this provides a bit of welcome relief. It also reminds me of my visit to Oz 4 years ago - might even revisit some favourite places virtually! Regards Brian ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20120724/5b340688/attachment-0001.html -- Message: 3 Date: Wed, 25 Jul 2012 16:16:01 +1000 From: John Henderson snow...@gmx.com To: Adrian Plaskitt adrianplask...@hotmail.com Cc: talk-au@openstreetmap.org Subject: Re: [talk-au] Question about relations Message-ID: 500f8f21.2090...@gmx.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 25/07/12 16:07, Adrian Plaskitt wrote: Greetings all. I usually confine my mapping to bush tracks and cycle paths as this is what I am most interested in and is often not available from other sources. With the recent devastation of the base map I am remapping some of my
Re: [Talk-br] Imobiliaria
Boa pergunta. Não tenho mapeado esses dois por não saber que tags colocar. []s 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? Em 6 de junho de 2012 21:31, vitor vitor.geo...@gmail.com escreveu: Oi Eduardo, Segundo o Taginfo, as pessoas estão utilizando as tags * 'shop=estate_agent'* e *'office=estate_agent'*: http://taginfo.openstreetmap.org/search?q=estate#values No wiki ainda não existe um consenso sobre qual é a correta, mas está pendendo mais para *'shop=estate_agent'*. Eu usaria esta. Vitor George mapaslivres.org twitter.com/mapaslivres On Wed, Jun 6, 2012 at 2:45 PM, Eduardo Medeiros eduardoamedei...@gmail.com wrote: Alguém já registrou uma imobiliária? Utilizou o office=estate_agent? []s, Eduardo Medeiros ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imobiliaria
2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? Na única vez que mapeei um quiosque da polícia eu usei amenity=police. Acredito que garagens de ônibus devem ser mapeadas como amenity=parking. Provavelmente vc deve ter interesse em usar também a tag access=private para indicar que a garagem não é aberta ao público em geral. Abraços, -- Tulio Magno ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imobiliaria
Tambem em Planemetria de Vitoria, qiusque de policia for identicada igual de delegacia, e outros paredes de policia, eu marquei eles com amenity=police Aun Y. Johnsen Sent from my iPad +55 (27) 9736-3919 (vivo) On 25. juli 2012, at 09:00, Tulio Magno Quites Machado Filho tul...@quites.com.br wrote: 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? Na única vez que mapeei um quiosque da polícia eu usei amenity=police. Acredito que garagens de ônibus devem ser mapeadas como amenity=parking. Provavelmente vc deve ter interesse em usar também a tag access=private para indicar que a garagem não é aberta ao público em geral. Abraços, -- Tulio Magno ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imobiliaria
2012/7/25 Tulio Magno Quites Machado Filho tul...@quites.com.br: 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? [...] Acredito que garagens de ônibus devem ser mapeadas como amenity=parking. Provavelmente vc deve ter interesse em usar também a tag access=private para indicar que a garagem não é aberta ao público em geral. A wiki ( http://wiki.openstreetmap.org/wiki/Key:building ) sugere usar building=garage em prédios usados como garagem. Em http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking chegam dizer para usar building=garage *ao invés* de amenity=parking nestes casos. LMB ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imobiliaria
Não sei se entendi. Eu só lembro de ter visto estacionamentos/garagens de ônibus de dois tipos: 1) Os ônibus ficam numa área mais aberta; alguns até tem cobertura, mas não são um prédio propriamente dito (só cobertura, sem paredes, portas e etc). Esses eu mapearia como foi sugerido antes: amenity=parking e access=private (e talvez algum daqueles tags de tipo de veículo identificando que é para ônibus. 2) Os ônibus ficam num prédio de verdade. Neste caso, eu acho que cada prédio, seja lá quantos forem, merece ser marcado como building=garage (mesmo que a área em que eles se encontram seja tageada como landuse=garages). Mas sei lá, talvez eu nunca tenha visto uma garagem de cooperativa de ônibus como as que vocês estão querendo mapear! LMB 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Mas nesse caso (key:building) seria para um edifício só, como anexos de condomínios, edifícios-garagem e casos parecidos. O mais próximo da garagens de cooperativas de ônibus acho que seria a tag landuse=garages (http://wiki.openstreetmap.org/wiki/Tag:landuse=garages), que foi criada para um tipo de uso de solo para estacionamento de uso diverso aos estacionamentos tradicionais (públicos). Nesse caso, acho que está sendo utilizada apenas nos países da antiga URSS para garagens comunitárias (são privadas, não confundir com públicas). Acho que seria interessante nós brasileiros agregarmos esse valor de garagens privadas à tag, que está bem específica para esse uso de países da antiga URSS até agora. Podemos até conversar com o pessoal de lá e editar a wiki, o que acham? Em 25 de julho de 2012 10:44, Leandro Motta Barros l...@stackedboxes.org escreveu: 2012/7/25 Tulio Magno Quites Machado Filho tul...@quites.com.br: 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? [...] Acredito que garagens de ônibus devem ser mapeadas como amenity=parking. Provavelmente vc deve ter interesse em usar também a tag access=private para indicar que a garagem não é aberta ao público em geral. A wiki ( http://wiki.openstreetmap.org/wiki/Key:building ) sugere usar building=garage em prédios usados como garagem. Em http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking chegam dizer para usar building=garage *ao invés* de amenity=parking nestes casos. LMB ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imobiliaria
O tag amenity=parking tambem tem informação sobre vagas, ou tipo de vagas. Acho nao e traducido completamente, leia o pagina wiki em ingles para descrição completo Talvez parking=* poder ajuda em mostrar areas cobertas, ou cover=yes. Aun Y. Johnsen Sent from my iPad +55 (27) 9736-3919 (vivo) On 25. juli 2012, at 12:43, Leandro Motta Barros l...@stackedboxes.org wrote: Não sei se entendi. Eu só lembro de ter visto estacionamentos/garagens de ônibus de dois tipos: 1) Os ônibus ficam numa área mais aberta; alguns até tem cobertura, mas não são um prédio propriamente dito (só cobertura, sem paredes, portas e etc). Esses eu mapearia como foi sugerido antes: amenity=parking e access=private (e talvez algum daqueles tags de tipo de veículo identificando que é para ônibus. 2) Os ônibus ficam num prédio de verdade. Neste caso, eu acho que cada prédio, seja lá quantos forem, merece ser marcado como building=garage (mesmo que a área em que eles se encontram seja tageada como landuse=garages). Mas sei lá, talvez eu nunca tenha visto uma garagem de cooperativa de ônibus como as que vocês estão querendo mapear! LMB 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Mas nesse caso (key:building) seria para um edifício só, como anexos de condomínios, edifícios-garagem e casos parecidos. O mais próximo da garagens de cooperativas de ônibus acho que seria a tag landuse=garages (http://wiki.openstreetmap.org/wiki/Tag:landuse=garages), que foi criada para um tipo de uso de solo para estacionamento de uso diverso aos estacionamentos tradicionais (públicos). Nesse caso, acho que está sendo utilizada apenas nos países da antiga URSS para garagens comunitárias (são privadas, não confundir com públicas). Acho que seria interessante nós brasileiros agregarmos esse valor de garagens privadas à tag, que está bem específica para esse uso de países da antiga URSS até agora. Podemos até conversar com o pessoal de lá e editar a wiki, o que acham? Em 25 de julho de 2012 10:44, Leandro Motta Barros l...@stackedboxes.org escreveu: 2012/7/25 Tulio Magno Quites Machado Filho tul...@quites.com.br: 2012/7/25 Pedro Geaquinto pedrodi...@gmail.com: Também surgiram umas dúvidas aqui. Qual tag utilizar para guaritas/quiosques policiais e para garagens de ônibus? [...] Acredito que garagens de ônibus devem ser mapeadas como amenity=parking. Provavelmente vc deve ter interesse em usar também a tag access=private para indicar que a garagem não é aberta ao público em geral. A wiki ( http://wiki.openstreetmap.org/wiki/Key:building ) sugere usar building=garage em prédios usados como garagem. Em http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking chegam dizer para usar building=garage *ao invés* de amenity=parking nestes casos. LMB ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] dúvidas sobre tags
Aproveitando a dúvida sobre garagens e postos policiais, resolvi abrir uma thread para dúvidas sobre tags. Aqui vai a primeira: qual tag vocês têm utilizado para identificar Casas Lotéricas? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Alguém mestre em usar Ushahidi?
Amigos, Alguem por aqui é expert em usar Ushahidi? Por favor me escreva um email, me adiciona no skype, porque preciso solicitar umas ajudas, sem perturbar todo mundo aqui... Skype: venturamaputo -- ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Alguém mestre em usar Ushahidi?
Acho bacana a conversa rolar por aqui (não precisa tirar as dúvidas pela lista, talvez mandar o log da conversa do skype pra cá) para termos um histórico; as próximas pessoas que tiverem dúvidas como as suas poderiam consultar o log. ;) []s 2012/7/25 Boaventura Monjane boa.monj...@gmail.com Amigos, Alguem por aqui é expert em usar Ushahidi? Por favor me escreva um email, me adiciona no skype, porque preciso solicitar umas ajudas, sem perturbar todo mundo aqui... Skype: venturamaputo -- ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Alguém mestre em usar Ushahidi?
OOla Arlindo! Então começamos aqui mesmo... Como faço, passo a passo (sou novato em sistemas de mapeamento) para usar o google map ou openstreetmap no Ushahidi e colocar icons e relaciona-los a informação (texto, links, etc)? Quero algo como isto: http://viacampesina.org/map/members/map.html Obrigado! 2012/7/25 Arlindo Pereira openstreet...@arlindopereira.com Acho bacana a conversa rolar por aqui (não precisa tirar as dúvidas pela lista, talvez mandar o log da conversa do skype pra cá) para termos um histórico; as próximas pessoas que tiverem dúvidas como as suas poderiam consultar o log. ;) []s 2012/7/25 Boaventura Monjane boa.monj...@gmail.com Amigos, Alguem por aqui é expert em usar Ushahidi? Por favor me escreva um email, me adiciona no skype, porque preciso solicitar umas ajudas, sem perturbar todo mundo aqui... Skype: venturamaputo -- ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] dúvidas sobre tags
Olá! 2012/7/25 Wille wi...@wille.blog.br: Aproveitando a dúvida sobre garagens e postos policiais, resolvi abrir uma thread para dúvidas sobre tags. Aqui vai a primeira: qual tag vocês têm utilizado para identificar Casas Lotéricas? Acho que não existe consenso (na wiki tem uma proposta abandonada). Em algumas que eu mapeei há um tempo atrás, eu usei shop=lottery. Parece que gambling=lottery também é usado. LMB ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] dúvidas sobre tags
Eu tenho tagueado como amenity=bank, uma vez que elas são muito usadas pela população para pagar contas. Mas concordo que é tagging for the renderer. []s 2012/7/25 Leandro Motta Barros l...@stackedboxes.org Olá! 2012/7/25 Wille wi...@wille.blog.br: Aproveitando a dúvida sobre garagens e postos policiais, resolvi abrir uma thread para dúvidas sobre tags. Aqui vai a primeira: qual tag vocês têm utilizado para identificar Casas Lotéricas? Acho que não existe consenso (na wiki tem uma proposta abandonada). Em algumas que eu mapeei há um tempo atrás, eu usei shop=lottery. Parece que gambling=lottery também é usado. LMB ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hoi Stefan, fuzzy links bzw. semantische ID name=Matterhorn weltweit wohl eindeutig Berühmte Namen finden immer Abbildungen in anderen Objekten. Beispielsweise gibt es das legendäre Restaurant Matterhorn in NZ :-) http://www.matterhorn.co.nz Und bei unserem Matterhorn gibt es mehrere Gipfel, die dieses bezeichnen... Neben name braucht man also noch restaurant bzw. gipfel etc? plus land (oder Adresse?) oder eine (fuzzi?)-Koordinate? Wie machen das eigentlich andere Projekte mit der ID? Beispielsweise Wikipedia oder Commons? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hi, On 07/24/2012 11:55 PM, Frederik Ramm wrote: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank s/kein/ein/ ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 25.07.2012 01:20, schrieb Stefan Keller: Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast noch grösseren Kummer als die OSM-ID. Das klingt für mich etwas komisch. Du willst nicht mit einer festen Koordinate/BBox arbeiten, aber dir dann über mehr oder weniger Raten eine Koordinate aus der OSM-DB holen? Mal ganz praktisch gefragt: Was verspricht sich ein Projekt egtl. aus so einer Verlinkung? Die meisten Eigenschaften wird das Projekt sowieso selber erheben müssen. Bei OSM gibt es neben der Koordinate in der Regel maximal noch die Adresse. Ist es da nicht allgemein deutlich einfacher, diese Daten selber zu speichern? Das hindert ja kein Projekt daran, die Daten nicht aus OSM zu holen. Aber wenn ich mir so überlege, welcher Aufwand getrieben werden soll, um das ganze zu verknüpfen, frage ich mich ob das überhaupt einen nennenswerten Vorteil bringt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 24.07.2012 10:32, schrieb Georg Feddern: Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli 2012 13:34 an Georg. Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine Herausforderung zu sein, so einen Node zu verschieben und die ID beizubehalten. JOSM - utilsplugin2 - Punkt extrahieren Wenn man sich denn überhaupt der Problemstellung bewusst ist, dass die ID unbedingt mitverschoben werden muss. Das ist der Knackpunkt. ProblemSTELLUNG trifft es ganz gut - denn bisher sehe ich dieses Problem immer noch nicht, bzw. nur konstruiert aus der Idee, die osm-id als permanente ID verwenden zu wollen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 24.07.2012 12:05, schrieb Manuel Reimer: Stefan Keller wrote: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Eben. Die Tendenz geht dahin, dass ein Mapper ggf. alle Tags übernimmt. Erst recht auch die, die er nicht kennt. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Nicht nur das. Ich müsste für alle Bildstöcke (ca. 30 Stück) eine BBox ermitteln und speichern. Zudem gibt es Stellen, an denen Bildstöcke relativ nah beieinander stehen. Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen. Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes Ersetzen sein; nur, wenn beide IDs auf einmal weg sind, dafür aber andere Bildstöcke in der BBox stehen, wird es problematisch. Die BBoxen zu ermitteln ist auch nicht weiter schwierig: Abhängig von der Dichte würde ich da einfach eine Standardgröße, z.B. 50 Meter rundrum oder so benutzen - für Städte und Dörfer aber z.B. einige Kilometer, für Bushaltestellen 100m und so weiter. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Peter Wendorff wrote: Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen. Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes Ersetzen sein; nur, wenn beide IDs auf einmal weg sind, dafür aber andere Bildstöcke in der BBox stehen, wird es problematisch. Teilweise stehen mehrere Bildstöcke relativ nahe. Ich möchte aber jedem sein korrektes Bild zuordnen. Ich finde nach wie vor die Idee mit den UUIDs am ehesten attraktiv. Im Idealfall übernimmt der Mapper, der etwas an dem Objekt macht, einfach alle Tags. Wenn er das UUID-Tag nicht kennt, dann wird er im Wiki fündig. Wenn er es dennoch killt, dann kann ich, als Nutzer dieses Tags, dieses dann ggf. immer noch wieder reparieren. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Markus wrote: Wie machen das eigentlich andere Projekte mit der ID? Beispielsweise Wikipedia oder Commons? Wenn ich das recht verstanden habe, dann wird in der Wikipedia eine Koordinate hinterlegt für das Objekt, das beschrieben wird. Am Objekt in der OSM muss dann ein wikipedia-Tag sein, welches auf den Artikel zurückverweist. Im groben haben wir hier also die Project-ID-Lösung. Wenn jemand das wikipedia-Tag killt, dann bleibt nur noch die Koordinate stehen. In der Wikipedia wird also nicht mehr das Objekt visualisiert (z.B. eine Straße) sondern ein Pointer zeigt irgendwo in die Mitte der selbigen. Bei einem solch großen Projekt wie die Wikipedia wird das wohl nicht hinterfragt und keiner kritisiert diese Lösung. Wie sieht es aber mit kleineren Projekten aus. Also eben der kleinen Vereinskarte. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 25.07.2012 01:20, schrieb Stefan Keller: Diese Relevanz-These scheint mir etwas gewagt: Wieso sollte ich als für die Erhaltung der Parkbänke verantwortliche Parkverwaltung zwei nebeneinander stehende knallrote Parkbänke (ohne Plakette) nicht verlinken wollen? Als Verwalter der Parkbänke halte ich aber sowieso meine master-table als referenz - und zwar als Kopie, die definitiv nur von mir angetastet werden kann. Darin kann ich eindeutig referenzieren, und anhand dessen auch entdecken, wenn in osm neues auftaucht oder etwas, das meiner Datenbank nach existieren sollte, plötzlich fehlt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hi, On 07/25/2012 10:44 AM, Manuel Reimer wrote: Bei einem solch großen Projekt wie die Wikipedia wird das wohl nicht hinterfragt und keiner kritisiert diese Lösung. Wie sieht es aber mit kleineren Projekten aus. Also eben der kleinen Vereinskarte. Bei der Wikipedia kommen neben die sind gross auch noch zwei andere Punkte ins Spiel - erstens das Tag ist schon etabliert und zweitens deren Relevanzkriterien, durch die wir sicher sein koennen, dass wir eben *nicht* irgendwann an jedem Gullideckel und jeder Strassenlaterne ein Wikipedia-Tag haben. Ansonsten gilt wie ueberall bei OSM in gewissen Grenzen die Narrenfreiheit des einzelnen Mappers - wenn ich hier schreibe, dass ich Projekt-IDs nicht gut finde, dann rede ich vom allgemeinen Fall. Das heisst nicht, dass ich einem einzelnen Mapper seine 30 Bildstock-IDs loeschen wuerde. Ich will bloss nicht, dass wir das als allgemein akzeptiertes Vorgehen fuer jede Art von Links zwischen der Aussenwelt und OSM propagieren, dass man in OSM seine privaten IDs platziert, weil ich die Sorge habe, dass das dann ueberhand nimmt (erstmal eine permanente ID an alles, was place=* hat, denn sowas kann man bestimmt gut brauchen, und danach dann an alle POIs, und...). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
aighes wrote: Mal ganz praktisch gefragt: Was verspricht sich ein Projekt egtl. aus so einer Verlinkung? - Nutzung der OSM-Tools um Geodaten zu pflegen - Halten der Geodaten in der OSM-DB erlaubt auch anderen Projekten die Nutzung Die meisten Eigenschaften wird das Projekt sowieso selber erheben müssen. ... kann diese dann aber komfortabel mit den OSM-Editoren eintragen und pflegen. Ich bekomme für unsere Bildstock-Karte alle Daten (Koordinate, Beschreibung, Errichtungsdatum) aus der OSM. Lediglich die Bilder steuere ich selber zu, weil ich sicherstellen will, dass ich auf *unserer* Karte nur *unsere* Bilder habe. Das Problem hier ist nun, dass ich irgendwie die Verlinkung zwischen den aus OSM abgeholten Daten und den Bildern hinbekommen muss. Bei OSM gibt es neben der Koordinate in der Regel maximal noch die Adresse. Für so einen typischen Bildstock kann man alle Daten, die relevant sind, mit dokumentierten Tags anbringen. Es gibt alles was man braucht und vermutlich auch noch wesentlich mehr: name - Für den Namen des Bildstocks, wenn bekannt/vorhanden start_date - Wann wurde der Bildstock errichtet? description - Kurzbeschreibung Ist es da nicht allgemein deutlich einfacher, diese Daten selber zu speichern? Das hindert ja kein Projekt daran, die Daten nicht aus OSM zu holen. Aber wenn ich mir so überlege, welcher Aufwand getrieben werden soll, um das ganze zu verknüpfen, frage ich mich ob das überhaupt einen nennenswerten Vorteil bringt. Warum gibt es dann WIWOSM? http://wiki.openstreetmap.org/wiki/DE:WIWOSM Faktisch ist das die Project-ID-Lösung für Wikipedia. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 25.07.2012 10:41, schrieb Manuel Reimer: Peter Wendorff wrote: Du kannst ja die ID als zusätzliches Kriterium problemlos mitziehen. Wenn sich nur eine ID ändert, wird es dann wohl ein entsprechendes Ersetzen sein; nur, wenn beide IDs auf einmal weg sind, dafür aber andere Bildstöcke in der BBox stehen, wird es problematisch. Teilweise stehen mehrere Bildstöcke relativ nahe. Ich möchte aber jedem sein korrektes Bild zuordnen. Liest du eigentlich, was andere Leute schreiben, oder bist du von deiner Idee einfach zu überzeugt? Ein Ausschnitt von 15x15 Metern hat 5 Bildstöcke, eingetragen als osm nodes mit den IDs 123, 124, 125, 126, 127. Du speicherst als Link für den ersten Bildstock sowas wie n123[bildstock-tag]@ausschnitt' (wobei ausschnitt' ein Ausschnitt von 10x10 Metern mit der dir bekannten letzten korrekten Koordinate des Bildstocks im Zentrum ist). Für den zweiten speicherst du n124[bildstock-tag]@ausschnitt'' - und so weiter. In diesem Moment kannst du eindeutig zuordnen. Was kann jetzt passieren? - Ein Bildstock wird hinzugefügt: Kein Problem, du benutzt die IDs zur Zuordnung deiner Bildstöcke - stellst aber evtl. zusätzlich fest, dass deiner Datenbank eventuell noch ein neuer Bildstock fehlt. - Ein Bildstock wird gelöscht: Kein Problem - die anderen werden aufgrund der ID weiterhin korrekt zugeordnet, der gelöschte wird korrekt als identifiziert und nachgucken musst du sowieso, ob das jetzt ein Fehler in OSM ist oder der Bildstock tatsächlich nicht mehr existiert. - Ein Bildstock wird verschoben: Du erkennst das, weil die ID auf einmal an anderer Stelle steht. - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu): Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig relativ leicht verifizieren, ob der neu erstellte node vielleicht der adäquate Ersatz ist. - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag verloren: Du erkennst das, hast aber immer noch die ID und den Ausschnitt, die passen - aber prüfen musst du sowieso. Gelöst ist also: - Das Verlinken genau eines Objekts, selbst wenn dazu keine ID existiert. - Das Tracken von Änderungen und das Nachvollziehen derselben. - Es werden keine aus Sicht von OSM unsinnigen FremdIDs gebraucht, die kein Mensch außer dir kontrollieren kann. Wo ist jetzt deine Lücke in dem Konzept? Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID auch nicht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Frederik Ramm wrote: Ich will bloss nicht, dass wir das als allgemein akzeptiertes Vorgehen fuer jede Art von Links zwischen der Aussenwelt und OSM propagieren, dass man in OSM seine privaten IDs platziert, weil ich die Sorge habe, dass das dann ueberhand nimmt (erstmal eine permanente ID an alles, was place=* hat, denn sowas kann man bestimmt gut brauchen, und danach dann an alle POIs, und...). Bleibt nur die Frage, ob nun eine eigene ID besser ist, als eine UUID als Allgemein eindeutige ID. Ich finde die Idee mit der UUID durchaus nicht verkehrt, wenn klare Regeln dafür geschaffen werden. Zum Beispiel sollte eine UUID wirklich eindeutig sein. Darf also nicht mehrfach verwendet werden. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Peter Wendorff wrote: Wo ist jetzt deine Lücke in dem Konzept? Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID auch nicht. Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern nicht verändert/angefasst wird. Wenn der Fall doch eintritt, dann packe ich die UUID wieder rein und fertig. Es geht mir ja darum, ein bestimmtes Objekt zu referenzieren. Auch dann, wenn das Objekt heute noch ein Node, morgen aber eine Fläche ist. Bei Bildstöcken wird kaum jemand eine Fläche draus machen, aber bei Gebäuden ist das nicht unüblich einen erst nur hilfsweise eingesetzten Node später durch den Gebäudeumriss zu ersetzen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachfrage OSMF Redaction Account - was tut der?
On Thu 2012-07-19 (22:36), Peter Wendorff wrote: Vielleicht redet hier Simon als Techniker am eher nicht-techniker vorbei. Der Bot holt das maximale an Information von Zustimmern heraus, ABER er kann dabei nicht semantisch vorgehen. Also: Ein Tag ist ein Tag ist ein Tag - und zwei Tags sind voneinander unabhängig (aus Sicht des Bots). Was Stefan vermutlich meint ist, dass ein hinzufügen von voltage=* eigentlich automatisch auch power=line verifizieren müsste, so wie name=Bussardweg highway=* verifiziert - wenn auch eventuell nicht die Klasse, dann hätte ein menschlicher Bot daraus durchaus schlussfolgern können, dass man highway=road als allgemeineren Wert hätte stehenlassen können. Da das Kind nun mal im Brunnen ist (ich war mir über die Reichweite auch nicht im Klaren, und einen Sandkasten, an dem man das hätte abschätzen können, gab es m.W. nichts): könnten wir ein Tool (osmi oder keepright) haben, das solche Dinge sukzessive markieren kann? Ich denke hier auch besonders an Dinge wie xyz:abc=def gesetzt, aber kein zugehöriges xyz=ghi (addr ausgenommen). Bis es soweit ist, ist auch mit dem Verbinden noch existierender vagabundierender Nodes und dem Rekonstruieren teilweise gelöschter Ways noch genügend zu tun (und der OSMI zeigt ja zumindest, was noch übrig ist), bevor es einzeln in den OSB landet (geht schon los). S ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 25.07.2012 12:32, Manuel Reimer wrote: Peter Wendorff wrote: Wo ist jetzt deine Lücke in dem Konzept? Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID auch nicht. Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern nicht verändert/angefasst wird. Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme* aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage war, was fehlt dir noch, wenn du diese *Lösungen* anwendest. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Polen bitte nocht nicht remappen!
Hi, Am 19.07.12 schrieb SteMo: wie ist der Stand für die Daten in Polen? der Bot knabbert gerade an der letzten Region (Szczecin). Danach bleiben nur noch Relationen offen. Gruß, Fabian. schrieb Fabian Schmidt, am 17.07.12 18:21: Hi, es gab ein Problem des Lizenzumstellungsbots, durch den eine Liste von Objekten, die ODBL-sauber sind, ignoriert wurde. Dadurch wurden zu viele Objekte versteckt. Es wird gerade an der Lösung gearbeitet, bitte mappt noch nichts in Polen neu, um Konflikte beim Revert zu vermeiden und weil ein Teil der Objekte sowieso wieder auftauchen werden. Für Datenkonsumenten: es wird versucht, die Reparatur so durchzuführen, dass sich aus den Diffs wieder der richtige Datenbestand ergibt.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] visualizzare una o più tracce GPX su una mappa utilizzando le librerie OpenLayers
Ciao a tutti, è da qualche giorno che quanto il codice descritto in questa pagina ( http://wiki.openstreetmap.org/wiki/IT:Openlayers_Track_example) non funziona più. Suggerimenti? Gian Mario Navillod. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] visualizzare una o più tracce GPX su una mappa utilizzando le librerie OpenLayers
Il giorno 25 luglio 2012 12:05, Gian Mario Navillod gian.mario.navil...@gmail.com ha scritto: Ciao a tutti, è da qualche giorno che quanto il codice descritto in questa pagina ( http://wiki.openstreetmap.org/wiki/IT:Openlayers_Track_example) non funziona più. Suggerimenti? http://openlayers.org/dev/examples/gml-layer.html http://openlayers.org/dev/examples/vector-formats.html Uno di questi dovrebbe andare bene :) Gian Mario Navillod. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Come taggereste questo cartello di divieto?
Questo qui: http://www.autoscuolafutura.com/069.gif maxweight=6.5 non va bene, perché il divieto è solo per i mezzi per il trasporto di cose. hgv=no nemmeno, perché proibisce il transito ai mezzi con peso superiore a 3.5 tonnellate; ovvero corrisponde a questo divieto http://www.autoscuolafutura.com/068.gif -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Come taggereste questo cartello di divieto?
On Wed, 25 Jul 2012 12:13:58 +0200, Giacomo Boschi wrote: Questo qui: http://www.autoscuolafutura.com/069.gif maxweight=6.5 non va bene, perché il divieto è solo per i mezzi per il trasporto di cose. hgv=no nemmeno, perché proibisce il transito ai mezzi con peso superiore a 3.5 tonnellate; ovvero corrisponde a questo divieto http://www.autoscuolafutura.com/068.gif hgv indica generalmente i veicoli per trasporto di cose, e 3.5t è solo un default, e come tutti i default non deve essere considerato se si specifica un valore diverso. Con queste considerazioni, direi maxweight:hgv=6.5 . Gli hgv possono passarci, ma il peso massimo dev'essere 6.5t (forse sarebbe meglio specificare anche t nel valore del tag, non ho idea di quale sia l'unità di misura standard per il peso in OSM) Ciao, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Boundaries
On 24/07/2012 21:35, Matteo Gottardi wrote: Nel caso il fiume cambiasse il suo corso, non ho idea di cosa succederebbe ai confini :) Sono piuttosto sicuro che il confine si sposti assieme al fiume: ricordo benissimo che questo concetto era stato spiegato durante una lezione di economia agraria. Non ho però sotto mano i riferimenti normativi: se qualcuno li trovasse, sarebbe utile. Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Come taggereste questo cartello di divieto?
David Paleino, on 25/07/2012 12.24, wrote: Con queste considerazioni, direi maxweight:hgv=6.5 . Gli hgv possono passarci, ma il peso massimo dev'essere 6.5t (forse sarebbe meglio specificare anche t nel valore del tag, non ho idea di quale sia l'unità di misura standard per il peso in OSM) Si, concordo. Anche se maxweight:hgv è ancora in votazione [0] direi di usarlo comunque. L'unità di misura per il maxweight è t, quindi si può lasciare senza la t. Damjan [0] http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Boundaries
Carlo Stemberger, on 25/07/2012 12.36, wrote: On 24/07/2012 21:35, Matteo Gottardi wrote: Nel caso il fiume cambiasse il suo corso, non ho idea di cosa succederebbe ai confini :) Sono piuttosto sicuro che il confine si sposti assieme al fiume: ricordo benissimo che questo concetto era stato spiegato durante una lezione di economia agraria. Non ho però sotto mano i riferimenti normativi: se qualcuno li trovasse, sarebbe utile. Ciao! Carlo Io non lo so, ma mi ricordo di aver visto da qualche parte in Europa che il confine (tra stati) era rimasto uno, mentre il fiume aveva cambiato corso. Forse era qui, ma non saprei se sia questo il caso...: http://www.openstreetmap.org/?lat=46.4902lon=16.5308zoom=13layers=M Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] mappare un autovelox
Ciao a tutti Come si mappa esattamente un autovelox fisso lungo la strada o ad un semaforo con telecamera? E le torrette che invitano a rallentare? Si inseriscono speed_camera e poi si fa la relazione con maxspeed? Qualcuno mi sa dire la giusta sequenza? Thanks:) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
