[Imports] Nepal VDC's boundaries import

Rafael Avila Coya ravilacoya at gmail.com
Sun May 17 17:15:02 UTC 2015

Hash: SHA1

Hi, Paul:

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: 
>> https://lists.openstreetmap.org/pipermail/imports/2013-August/002054.html
. 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.

> https://docs.google.com/document/u/1/d/1X7vAOXg7O7SGiGgUV8_2C_1LtmNt7mgCmoh5YYm9IvY/pub
item 8 has the LWG minutes on the matter, and
> https://lists.openstreetmap.org/pipermail/talk-au/2015-April/010552.html
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 [1],
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 [2]. 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.



[1] http://creativecommons.org/staff
[2] http://wiki.openstreetmap.org/wiki/Import_Unocha_Pcode

> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/imports

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

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.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/


More information about the Imports mailing list