Hi Frederik,

Thank you for your valuable response.  Am writing from the official mail ID.

Here is the Clarification on the Local Knowledge: We have planned to create the 
Maproulette challenge for the non coordinated government data with respect to 
the regions and for taking this challenge to repositioning the coordinates 
needs the “Local Knowledge”.
These are the region wise sample MR challenges for the Hospital directory.
https://maproulette.org/browse/challenges/8023
https://maproulette.org/browse/challenges/8020
https://maproulette.org/browse/challenges/8000


For the First: The attributes which we can see in the wiki with uppercases are 
the unchanged Government attributes.
By the way while tagging these attributes, we have used the lower case letters 
which is also updated the in tagging plans.

For the second: As per your suggestion we updated the wiki page with the detail 
explanation of data transformation of the data for both the health related tags 
and general tags.

For the Third: Thanks for your suggestion we will add import to changesets 
instead of “import=yes” in elements and Of course, we will make sure to include 
readable description in changesets comment, then have hash tag as additional 
information to assist tracking all submitted changesets. It will be something 
like this “Import of health facilities in India, see 
https://wiki.openstreetmap.org/wiki/India_Health_Facilities_Import 
#OpenGovernmentData”.

For the Fourth: Indian government has shared its license about the  
“Permissible use of data” stating that this data can be used globally or adapt 
or publish or translate or add value for all lawful commercial and 
non-commercial purposes etc...  Here is the link for the license which is 
already shared in the OSM wiki page: 
https://data.gov.in/government-open-data-license-india.

For the Fifth:
While working on the import, we first will apply JOSM for validation to ensure 
errors are all cleared. After the import, we will come back and check all 
changesets we submitted to guarantee the data satisfy OSM standard. And this is 
also why it's important for us to include hash tag in changesets comment to 
allow the QA process to be easier.

Thanks
Aruna Valli


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

Date: Wed, 10 Jul 2019 16:00:13 +0200
From: Frederik Ramm <[email protected]>
To: [email protected]
Subject: Re: [Imports] Open Government Data- India Health Facilities
        Import
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Hi,

thank you for writing.

I applaud your mention of "local knowledge" under the "data merge workflow"; 
how are you going to ensure that participants actually do have local knowledge?

I have a few comments on your documentation but I haven't been looking at the 
data yet.

First, there are almost no tags in OSM that begin with an upper-case letter. 
Your documentation mentions several tags with captial letters.
Double-check them.

Second, you write that "General attributes (Addresses details, Contact 
Information, Operator etc.. ) in the directories will be tagged with the 
reference to Global OSM keys.". It would be good to have an exact plan of how 
you intend to convert this information. Among the values you wish to retain are 
things like "Pincode", "Hospital_Primary_Email_Id", "Taluka_Name" and I would 
very much like to know how these will be mapped to OSM in a way that is 
compatible with existing data in India.

Third, you suggest to tag every object with "Import=yes". Don't do that, tag 
the changeset with import=yes instead. Also, don't use hashtags in your 
changeset comment ("#IndiaHealthFacilitiesImport #OpenGovernmentData)", they 
are an insult to the human reader - use a proper description ("Import of health 
facilities in India, see <wiki
link>" or so).

Fourth, has the Indian Government Open Data License been approved for import 
data sources? I am worried that OSM is not compliant with the attribution 
requirements.

Fifth, I am concerned that you write "QA: post-import". What problems do you 
expect and can they be avoided during the import, rather than fix them after? 
"We'll do QA after the import" is, sadly, a good intention of many organised 
projects which then often fail to do this step.

Bye
Frederik

--
Frederik Ramm  ##  eMail [email protected]  ##  N49°00'09" E008°23'33"


"Disclaimer: This communication contains information which is confidential and 
the copyright of RMSI Private Limited, its subsidiaries or a third party 
(“RMSI”). This email may also contain legally privileged information. 
Confidentiality and legal privilege attached to this communication are not 
waived or lost by reason of mistaken delivery to you.This email is intended to 
be read or used by the addressee only. If you are not the intended recipient, 
any use, distribution, disclosure or copying of this email is strictly 
prohibited without the express written approval of RMSI. Please delete and 
destroy all copies and email RMSI at [email protected] immediately. Any views 
expressed in this communication are those of the individual sender, except 
where the sender specifically states them to be the views of RMSI. Except as 
required by law, RMSI does not represent, warrant and/or guarantee that the 
integrity of this communication has been maintained nor that the communication 
is free of errors, virus, interception or interference. If you do not wish to 
receive such communications, please forward this communication to [email protected] 
and express your wish not to receive such communications henceforth." 
http://www.rmsi.com
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports

Reply via email to