[Imports] Nepal VDC's boundaries import
Rafael Avila Coya
ravilacoya at gmail.com
Sun May 17 17:15:02 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
Thank you for your input. My comments inline:
On 16/05/15 19:06, Paul Norman wrote:
> On 5/15/2015 4:08 PM, Rafael Avila Coya wrote:
>> The license is CC-by 3.0 (I forgot to put the 3.0). It's not only
>> me that I think that we comply with the attribution, as we
>> mention the source of the data as Fortius One Inc. in each single
>> segment, each boundary relation and each changeset (now Fortius
>> One Inc. is GeoIQ, part of ESRI), with the source=* tag.
>> Back in 2013 you already mention that what the folks from Nepal
>> were proposing as attribution was good enough, pointing that some
>> people disagree on that:
. Is this the Legal Working Group opinion too? Apart from all of that,
>> I don't give even one on one million that GeoIQ will complain
>> about this in any way whatsoever.
item 8 has the LWG minutes on the matter, and
is a higher level summary.
You still didn't answer to:
1) The clearly different views on the compatibility/incompatibility of
CC-by among ourselves (members of the OSM community). For my
understanding, we should have a consensus in this matter, but we haven't.
2) You only refer to statements made by yourself in the past. Note
that Sarah Hinchliff Pearson, Senior counsel of Creative Commons ,
says that CC-by is compatible with ODbL, refering in fact to OSM. Is
she not authoritative enough? If not, why? Do you have any legal
advice to refer to, that contradicts Sarah's? If she is not good
enough, why and whom did we consult that contradicted that reasoning
of hers? Can you please answer to these questions?
3) Both of the links you mention on the LWG minutes are your own
opinion, isn't it?
>> I documented the pcodes already. The pcodes are United Nation
>> codes, very important to facilitate identification of places (as
>> you know, in many countries names have many spelling
>> alternatives, and no one is the most "official", so having a
>> unique code for each place is vital). The pcodes solve this
>> problem. We add also the old OCHA codes, as they are still used
>> by some organizations.
> As you can see with the tags you're proposing adding, they are red
> links, indicating the page doesn't exist. The wiki pages
> Key:ocha:old_code and Key:ocha:pcode should be created and have
> appropriate documentation.
> I am puzzled by the ocha prefix for pcode, as it sounds like they
> are not OCHA specific?
You asked me to document the ocha:pcode and ocha:old_code tags, and I
did. For the sake of consistency, we will use the same unocha:pcode
key already described in the wiki page for the West Africa Ebola
crisis pcodes import last year . Consecuently, we also changed the
second to unocha:old_code. As you can see, the unocha:pcode tag is in
red colour in the refered Ebola wiki, as it is in ours.
> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org
Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer, non os abro.
Atendendo á lexislación vixente, empregue formatos estándares e abertos.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Imports