Re: [OSM-talk] [OSM-newbies] avoid repeating the name tag twice
On Sun, Mar 15, 2009 at 7:51 PM, Pierre-André Jacquod
wrote:
> Hi
>> 1) This proposal will not help the Brussels map, where a similar need exists.
>> In Brussels they want the default map to show street names in France and
>> Dutch.
>> see
>> http://www.openstreetmap.org/?lat=50.77218&lon=4.38126&zoom=15&layers=B000FTTT
>> for
>> a road with these tags:
>> name="Avenue de la Sapinière - Denneboslaan" <--- could be
>> "{name:fr} - {name:nl}"
>> name:fr="Avenue de la Sapinière"
>> name:nl="Denneboslaan"
> A possibility would be to tag the language like: name:local_lang=fr - nl
> where the separator is the one that has to be used for the
> representation. (iso-codes are known, the rest is spearator)
name:local_lang="fr - nl" is indeed an interesting idea, that I
haven't thought of.
However, I ask myself if it's flexible enough.
It seems that for just a little more coding you get the much more
flexible "{name:fr} - {name:nl}" (with special escape combinations \\,
\{, \} ).
I think that mappers from Brussels and also other parts of the word
with strings comprised from two languages should add there insights.
Do they care about this problem? Are they willing to use such a
solution?
If they don't show interest, we can just forget about it, and go with
the less general solution you offered below.
>> 2) Sometime an object (node/way/relation) contains more then one
>> translatable tag.
>> For example, a house address is a node with
>> addr:housenumber="12Alef" <- translatable
>> addr:street="Herzel" <- translatable
>> addr:city="Tel-Aviv" <- translatable
>> addr:country="IL"
>> addr:full="" <- translatable
>> building=yes
>> name="Azrieli Shopping Mall" <- translatable
>>
>> Do we want to add a single a tag for each translatable tag:
>> addr:housenumber:lang=de
>> addr:street:lang=de
>> addr:citylang=de
>> addr:full:lang=de
>> name:lang=de
>> or do we want a single tag to indicate the text labels for the entire
>> node/way/relation?
>
> Aaargh
:)
> Ok I think the local language(s) is (are) the same for all description
> of a node/way/relation. Then I think we should introduce a new tag, like
> local_lang=xx and then tag name:xx=Germany addr:city:en="Tel-Aviv" and
> so on...
> what do you think about it??
I support the idea of a new local_lang=xx tag, exactly as you described it.
A possible problem could be if, for example, the default map should
show Arabic house addresses (addr:housenumber:ar tag) but french
building names (name:fr tag). This situation seems pretty ridiculous
to me, but it might be wiser to request just a little more feedback
from people who actually face these kind of problems.
This solution is good enough for the map of Israel. As far as I
understood from an earlier post of Michel Barakat, it's also good
enough for Lebanon (please correct me if I'm wrong!).
Can we please have some more ok / not-ok for this idea from some
mappers who map in several languages?
Tal
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-legal-talk] Possible datasources: Corine Land Cover 2000dataset
Hi Andy, Jukka, I have created a new entry on the Potential Datasources wiki page: http://wiki.openstreetmap.org/index.php?title=Potential_Datasources&action=submit#Corine_Land_Cover_2000_datasets. I am also posting this to OSM-talk so more people can review the possibility of using this dataset. Because Jukka pointed out that on another page http://dataservice.eea.europa.eu/dataservice/metadetails.asp?id=950 the copyright notice is different: Rights: >EEA grants free access to all its data/applications provided that the > user agrees: >· to acknowledge the source as follows: Copyright EEA, Copenhagen, 2007 >· to display a link to the EEA web site http://www.eea.europa.eu >· not to use the data/applications for commercial purposes unless the > Agency has expressly granted the right to do so > I will try to contact the Agency and obtain an official answer about the usage. In the meantime feel free to give any feedback on the matter. Thanks, Ciprian On Thu, Mar 12, 2009 at 12:21 PM, Andy Robinson (blackadder-lists) < ajrli...@googlemail.com> wrote: > Ciprian Talaba: > >Sent: 12 March 2009 9:28 AM > >To: legal-t...@openstreetmap.org > >Subject: [OSM-legal-talk] Possible datasources: Corine Land Cover > >2000dataset > > > >Hi all, > > > >I know the discussion lately have been towards agreeing about an OSM > >license, and probably this is not the best time to ask this question. > >But I came across Corine Land Cover 2000 datasets and I want to make sure > >that they can be use in OSM. The organization behind CLC 2000 is European > >Environment Agency (EEA) and the website where the dataset is available > >have some legal information like: > >1. on the page http://www.eea.europa.eu/legal/copyright > >"Unless otherwise indicated, the information available from this site is > >within the public domain. Public domain information on the EEA web pages > >may be downloaded free of charge, and reproduced provided the source is > >acknowledged*. > >. > >* Citing this website" > > > >2. on the page http://www.eea.europa.eu/themes/landuse/clc-download from > >where you can download the datasets, in the tab "My details" where is the > >following notice: > >"The information available in this application is under copyright of EEA > >and within the public domain. Public domain information in this > application > >may > >be used free of charge, provided the source is acknowledged. The > >acknowledgment should read (c) EEA, Copenhagen, 2007" > > > >So my opinion is that we can use data from CLC 2000 as long as we add the > >source as a tag to each imported element. So you see any problems in using > >this dataset? > > > >Thanks, > >Ciprian > > Ciprian, > > I would suggest you drop this information on a wiki page and ask for > comments there as well. At face value on what you have put in your email it > looks similar to other data sets that require attribution. We normally deal > with that as you say by adding the correct source tag and also placing the > attribution on the wiki page at > http://wiki.openstreetmap.org/wiki/Contributors and or > http://wiki.openstreetmap.org/wiki/Attribution (looks like those two pages > should be combined or redirect to just one.) > > As a final confirmation its worth writing to the data provider explaining > the intention and how attribution is dealt with. That at least shows a > paper > trail if anyone asks a question at a later date. > > Finally its worth doing any imports under a specifically set up username, > that way its easy to identify the original upload of data. > > Hope these pointers help. > > Cheers > > Andy > > > > > ___ > legal-talk mailing list > legal-t...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/legal-talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
2009/3/15 Russ Nelson : > > On Mar 15, 2009, at 1:27 PM, Donald Allwright wrote: >> Maybe we could get round this by keeping it all in one database, but >> adding a separate tag to denote where the data come from? Anyone >> could use this tag to filter only the data they want, or to remove >> data from a particular source. >> >> I'd suggest something like source= > > I'd suggest instead that all bulk imports should each have their own > userid. Even mass imports are most of the time not a fully automated process and the data is reviewed before upload. That means that 1. it's possible to screw up the job, 2. it can't be done by one person if there's a lot of data. Then, it's a good thing that the users doing the upload can be contacted and use different ids. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Which entry level budget garmin
Ulf Lamping wrote: > Well, the zumo 550 (which is very certainly a somewhat roughetized nuvi) > has no "snap to road" setting (it has not a lot of options in that > regard at all). > > I did made experiments with the track log. Some of the tracks did > *suspiciously* looked like a snap to road while others did not. So if > its useable for OSM or not - I don't know and care (I'm still using my > WBT201 for tracking which has no maps :-). The nüvi series does not snap to road nor has the option to. The 200 (no longer available) can be downgraded to capture GPX tracks. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-newbies] avoid repeating the name tag twice
Hi
> 1) This proposal will not help the Brussels map, where a similar need exists.
> In Brussels they want the default map to show street names in France and
> Dutch.
> see
> http://www.openstreetmap.org/?lat=50.77218&lon=4.38126&zoom=15&layers=B000FTTT
> for
> a road with these tags:
>name="Avenue de la Sapinière - Denneboslaan" <--- could be
> "{name:fr} - {name:nl}"
>name:fr="Avenue de la Sapinière"
>name:nl="Denneboslaan"
A possibility would be to tag the language like: name:local_lang=fr - nl
where the separator is the one that has to be used for the
representation. (iso-codes are known, the rest is spearator)
> 2) Sometime an object (node/way/relation) contains more then one
> translatable tag.
> For example, a house address is a node with
> addr:housenumber="12Alef"<- translatable
> addr:street="Herzel" <- translatable
> addr:city="Tel-Aviv" <- translatable
> addr:country="IL"
> addr:full=""<- translatable
> building=yes
> name="Azrieli Shopping Mall" <- translatable
>
> Do we want to add a single a tag for each translatable tag:
> addr:housenumber:lang=de
> addr:street:lang=de
> addr:citylang=de
> addr:full:lang=de
> name:lang=de
> or do we want a single tag to indicate the text labels for the entire
> node/way/relation?
Aaargh
Ok I think the local language(s) is (are) the same for all description
of a node/way/relation. Then I think we should introduce a new tag, like
local_lang=xx and then tag name:xx=Germany addr:city:en="Tel-Aviv" and
so on...
what do you think about it??
best regards
paj
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Mar 15, 2009, at 1:27 PM, Donald Allwright wrote: > Maybe we could get round this by keeping it all in one database, but > adding a separate tag to denote where the data come from? Anyone > could use this tag to filter only the data they want, or to remove > data from a particular source. > > I'd suggest something like source= I'd suggest instead that all bulk imports should each have their own userid. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Mar 15, 2009, at 1:02 PM, Cartinus wrote: > On Sunday 15 March 2009 17:42:26 Russ Nelson wrote: >> Every editor should show this data to a >> user when they go to edit. Otherwise, if there are things that are >> available to a map renderer but not to an editor, how will the editor >> know that the things are in the map already? > > Of course the editor should show everything available, but that > doesn't mean > it couldn't be stored in separate databases or displayed in separate > layers. > It just needs "smarter" software. Well, that's fair enough. We might want to be able to do more than our tools will let us do. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
>Of course the editor should show everything available, but that doesn't mean >it couldn't be stored in separate databases or displayed in separate layers. >It just needs "smarter" software. Maybe we could get round this by keeping it all in one database, but adding a separate tag to denote where the data come from? Anyone could use this tag to filter only the data they want, or to remove data from a particular source. I'd suggest something like source=? :-) Donald ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
On Sunday 15 March 2009 17:42:26 Russ Nelson wrote: > Every editor should show this data to a > user when they go to edit. Otherwise, if there are things that are > available to a map renderer but not to an editor, how will the editor > know that the things are in the map already? Of course the editor should show everything available, but that doesn't mean it couldn't be stored in separate databases or displayed in separate layers. It just needs "smarter" software. -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
I'm not sure I wrote clearly enough, because it seems like you didn't understand what I said. Everything that someone might want to add to the map should, if imported, actually BE in the map, not in a separate database or separate layer. Every editor should show this data to a user when they go to edit. Otherwise, if there are things that are available to a map renderer but not to an editor, how will the editor know that the things are in the map already? Perhaps they could use the existing map renders as a backdrop? Then you'd end up with editors as second-class citizens to renderers, and put (BACK) in the position of needing to beg for changes. That's precisely what we want to avoid by having an editable map database. On Mar 15, 2009, at 9:37 AM, MP wrote: > Well, I thought we would have one layer per each mass import (so you > can look at what was imported) - one layer for TIGER import, one layer > for AND import, etc ... and the data would ge trimported both in that > special layer and in ordinary layer, where everybody can edit it. > > In future, we can have layers even at different servers not operated > by OSM (for things that are not exactly within scope of OSM map), like > layers with wifi hotspots, etc ... > > Technically, these layers will merely redirect to another server. > > Martin > >> Er, no. Anything that someone might ADD to the map should be, if >> imported, in the same place. Otherwise, someone will fire up their >> editor, not see the data that already been imported, and start to add >> it. No better way to piss off a volunteer than to waste their time. >> >> Yes, there are problems with this approach. We need to solve them, >> not run away from them. We'll just create worse problems if we try >> to >> avoid solving this problem. We ALREADY have to deal with it with the >> TIGER import. Neither that data, nor the edits made to it, are going >> to be exiled from the database into this proposed "bulk import data >> layer". >> >> -- >> Russ Nelson - http://community.cloudmade.com/blog - >> http://wiki.openstreetmap.org/wiki/User:RussNelson >> r...@cloudmade.com - Twitter: Russ_OSM - >> http://openstreetmap.org/user/RussNelson >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk >> > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bulk import as a data layer (like gpx currently is)
Well, I thought we would have one layer per each mass import (so you can look at what was imported) - one layer for TIGER import, one layer for AND import, etc ... and the data would ge trimported both in that special layer and in ordinary layer, where everybody can edit it. In future, we can have layers even at different servers not operated by OSM (for things that are not exactly within scope of OSM map), like layers with wifi hotspots, etc ... Technically, these layers will merely redirect to another server. Martin > Er, no. Anything that someone might ADD to the map should be, if > imported, in the same place. Otherwise, someone will fire up their > editor, not see the data that already been imported, and start to add > it. No better way to piss off a volunteer than to waste their time. > > Yes, there are problems with this approach. We need to solve them, > not run away from them. We'll just create worse problems if we try to > avoid solving this problem. We ALREADY have to deal with it with the > TIGER import. Neither that data, nor the edits made to it, are going > to be exiled from the database into this proposed "bulk import data > layer". > > -- > Russ Nelson - http://community.cloudmade.com/blog - > http://wiki.openstreetmap.org/wiki/User:RussNelson > r...@cloudmade.com - Twitter: Russ_OSM - > http://openstreetmap.org/user/RussNelson > > > ___ > 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] Bulk import as a data layer (like gpx currently is)
On Mar 14, 2009, at 11:31 AM, Sam Vekemans wrote: > +1 for that!!! Er, no. Anything that someone might ADD to the map should be, if imported, in the same place. Otherwise, someone will fire up their editor, not see the data that already been imported, and start to add it. No better way to piss off a volunteer than to waste their time. Yes, there are problems with this approach. We need to solve them, not run away from them. We'll just create worse problems if we try to avoid solving this problem. We ALREADY have to deal with it with the TIGER import. Neither that data, nor the edits made to it, are going to be exiled from the database into this proposed "bulk import data layer". -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
