<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi,</div><div><br></div><div>Anyone interested to make this topic going forward?</div><div>For info, Central African Republic is rated Crisis Level 3, as only Syria and Philippines, and the situation there is now compared to the tragic crisis that occurred in Rwanda an Bosnia, read <a href="http://reliefweb.int/report/central-african-republic/ocha-operations-director-john-ging-opening-remarks-press-central">here</a>. </div>
<div><br></div><div>Sincerely,</div><div><br></div><div>Severin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Fri, 17 Jan 2014 11:22:16 +0100<br>
From: Severin MENARD <<a href="mailto:severin.menard@gmail.com">severin.menard@gmail.com</a>><br>
To: "<a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a>" <<a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a>><br>
Subject: Re: [Imports] Import UNICEF data in Central African Republic,<br>
act II<br>
Message-ID:<br>
<CA+y5pBLgWW5DK-MxUk=aXVRLP2u0x8j=<a href="mailto:cpDR%2BgGRF0C%2BbLJX%2BA@mail.gmail.com">cpDR+gGRF0C+bLJX+A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
Still hoping decision can be taken on this list on through the wiki to get<br>
through the blocking did on December 23.<br>
<br>
Sincerely,<br>
<br>
Severin<br>
<br>
On Tue, Jan 14, 2014 at 12:12 AM, Severin MENARD<br>
<<a href="mailto:severin.menard@gmail.com">severin.menard@gmail.com</a>>wrote:<br>
<br>
> Hi,<br>
><br>
> Seems my quick answer has been blocked because it exceeds a little bit 40<br>
> Kb. Would be good the admin allow messages in such cases. Here it is again<br>
> with deleted lines. Hope it will be less than 40 Kb this time.<br>
> Otherwise, i would like to know how decisions will be made based on the<br>
> discussion. Voting process in the wiki as for tag propositions? Something<br>
> else?<br>
><br>
> Sincerely,<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Severin MENARD <<a href="mailto:severin.menard@gmail.com">severin.menard@gmail.com</a>><br>
> Date: Thu, Jan 9, 2014 at 3:14 PM<br>
> Subject: Import UNICEF data in Central African Republic, act II<br>
> To: "<a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a>" <<a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a>><br>
><br>
><br>
> Hi,<br>
><br>
><br>
><br>
><br>
>> Thank you all for your quick answers, my comments inline<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: Import UNICEF data in Central African Republic, act II<br>
>> (Frederik Ramm)<br>
>> 2. Re: Import UNICEF data in Central African Republic, act II (Jo)<br>
>> 3. Re: Import UNICEF data in Central African Republic, act II<br>
>> (Rafael Avila Coya)<br>
>> 4. Re: Import UNICEF data in Central African Republic, act II (Jo)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Thu, 09 Jan 2014 00:24:02 +0100<br>
>> From: Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>><br>
>> To: <a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a><br>
>> Subject: Re: [Imports] Import UNICEF data in Central African Republic,<br>
>> act II<br>
>> Message-ID: <<a href="mailto:52CDDE12.9030903@remote.org">52CDDE12.9030903@remote.org</a>><br>
>> Content-Type: text/plain; charset=ISO-8859-1<br>
>><br>
>> Sev,<br>
>><br>
>> I don't see big issues with your proposed import. The page on schools<br>
>> has a tag value of "uncomplete" where I'd guess that "incomplete" would<br>
>> be a better term but I'm not a subject matter expert.<br>
>><br>
>> What strikes me that in your explanation, you seem to ask for special<br>
>> treatment because "this is for humanitarian purposes" - quotes:<br>
>><br>
>> On 08.01.2014 23:34, Severin MENARD wrote:<br>
>> > Please keep in mind it deals with humanitarian data in a big crisis<br>
>> > context, so it is important to have the possibility to cross checked<br>
>> > facilities incorrectly located<br>
>><br>
>> ...<br>
>><br>
>> > therefore it is a very light dataset and adding a few tags really<br>
>> > useful for data control, considering its humanitarian ground, would only<br>
>> > represent a few more Kb.<br>
>><br>
>> You seem to be of the opinion that because this is "humanitarian" we<br>
>> should be lenient - but I think the opposite is the case. As HOT - a<br>
>> group of people who have been doing various imports for a long time and<br>
>> will doubtlessly continue to do so - you have to be a shining example to<br>
>> everyone else. You, of all people, are expected to "do things right",<br>
>> and other people will look at your imports and say: If people who do so<br>
>> many imports do <X> then it must be the right thing to do. You've<br>
>> already done a very good job at documenting the import procedure on the<br>
>> Wiki (this is indeed a very good example to others).<br>
>><br>
><br>
> No, I never asked the import group to be lenient. I was mostly complaining<br>
> about the fact the import having been stopped in 24 hours while it took<br>
> quite more time to get an answer to the explanations I provided without a<br>
> real discussion to start. Happy this is the case now, but it could have<br>
> been quicker (not lenient), regarding the humanitarian purpose.<br>
><br>
> Regarding the sentence you quoted, I wanted to stress the importance to<br>
> have control check for humanitarian data, like an original source tag and<br>
> supposed admin level, so if ever someone doing the import makes a mistake,<br>
> the final user to have some metadata for each object. Therefore I would not<br>
> say lenient, but adapted and useful.<br>
><br>
>><br>
>> That's why I'm happy that you're starting this discussion just like we'd<br>
>> expect from anyone else making an import.<br>
>><br>
>> The two issues you mention in your email, source tag on every object and<br>
>> named admin units tagged with every object, are indeed unusual.<br>
>><br>
>> The problem with source tags is that they only tell part of the truth -<br>
>> if you import a hospital from UNICEF and someone later changes it then<br>
>> they will likely forget to remove or amend the source tag. A source tag<br>
>> on the changeset makes this more clear.<br>
>><br>
><br>
> Except it will not appear in any GIS format. What about a tag mentioning<br>
> the original source? Another point to have in mind: field data collection<br>
> in CAR are rare, and the country practicability becomes quite hard, so it<br>
> should not be updated on a very regular basis.<br>
><br>
>><br>
>> I understand your admin level explanation but I don't think it is<br>
>> sufficient reason for adding the highly unusual three "is-in" type of<br>
>> tags that you are proposing. I wonder how addresses in CAR are<br>
>> constructed - is it possible that the correct postal address for a<br>
>> location like that might be "XYZ Hospital, Adminarea 3, Adminarea 2,<br>
>> Adminarea 1, CAR" or so? In which case a potential compromise could be<br>
>> using the addr:full tag (Wiki: "Use this for a full-text, often<br>
>> multi-line, address if you find the structured address fields unsuitable<br>
>> for denoting the address of this particular location.").<br>
>><br>
> This is a good idea, if everyone agrees I change the wikipages to reflect<br>
> that<br>
><br>
>><br>
>> Lastly, I too think the "fixme" should be dropped, because doing an<br>
>> import with "fixme" tags gives the impression that it is ok to import<br>
>> half-baked data for others to fix - something we're doing everything to<br>
>> avoid, and your documented import procedure makes it clear enough that<br>
>> you expect importing users to curate the data as required.<br>
>><br>
> I already dropped it<br>
><br>
>><br>
>> Bye<br>
>> Frederik<br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Thu, 9 Jan 2014 02:07:31 +0100<br>
>> From: Jo <<a href="mailto:winfixit@gmail.com">winfixit@gmail.com</a>><br>
>> To: Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>><br>
>> Cc: "Imports OpenStreetMap.org" <<a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a>><br>
>> Subject: Re: [Imports] Import UNICEF data in Central African Republic,<br>
>> act II<br>
>> Message-ID:<br>
>> <CAJ6DwMAe62x_MfOxmhE302r79WQgMMq5QChwcK=<br>
>> <a href="mailto:DSsCxhz2atg@mail.gmail.com">DSsCxhz2atg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> If there is data in your source that you want to pass on to the people who<br>
>> are going to import/integrate it into Openstreetmap, you can use tags like<br>
>><br>
>> odbl<br>
>> created_by<br>
>><br>
>> and such. These are tags which JOSM will silently remove before uploading<br>
>> the data. So they will not end up in the OSM DB, but your crew has them<br>
>> available to do cross checks.<br>
>><br>
>> You can use MAPCSS to make them visible more prominently during your edit<br>
>> session.<br>
>><br>
>> I hope this helps. (Maybe JOSM could be expanded to have tags dedicated<br>
>> for<br>
>> this purpose, say an import: namespace and maybe it would be a good idea<br>
>> to<br>
>> be able to tag objects with upload=no, so JOSM refuses to upload them when<br>
>> they have not been verified. But that's for another mailing list...)<br>
>><br>
>> Jo<br>
>><br>
>><br>
>> 2014/1/9 Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>><br>
>><br>
>> > Sev,<br>
>> ><br>
>> > I don't see big issues with your proposed import. The page on schools<br>
>> > has a tag value of "uncomplete" where I'd guess that "incomplete" would<br>
>> > be a better term but I'm not a subject matter expert.<br>
>> ><br>
>> > What strikes me that in your explanation, you seem to ask for special<br>
>> > treatment because "this is for humanitarian purposes" - quotes:<br>
>> ><br>
>> > On 08.01.2014 23:34, Severin MENARD wrote:<br>
>> > > Please keep in mind it deals with humanitarian data in a big crisis<br>
>> > > context, so it is important to have the possibility to cross checked<br>
>> > > facilities incorrectly located<br>
>> ><br>
>> > ...<br>
>> ><br>
>> > > therefore it is a very light dataset and adding a few tags really<br>
>> > > useful for data control, considering its humanitarian ground, would<br>
>> only<br>
>> > > represent a few more Kb.<br>
>> ><br>
>> > You seem to be of the opinion that because this is "humanitarian" we<br>
>> > should be lenient - but I think the opposite is the case. As HOT - a<br>
>> > group of people who have been doing various imports for a long time and<br>
>> > will doubtlessly continue to do so - you have to be a shining example to<br>
>> > everyone else. You, of all people, are expected to "do things right",<br>
>> > and other people will look at your imports and say: If people who do so<br>
>> > many imports do <X> then it must be the right thing to do. You've<br>
>> > already done a very good job at documenting the import procedure on the<br>
>> > Wiki (this is indeed a very good example to others).<br>
>> ><br>
>> > That's why I'm happy that you're starting this discussion just like we'd<br>
>> > expect from anyone else making an import.<br>
>> ><br>
>> > The two issues you mention in your email, source tag on every object and<br>
>> > named admin units tagged with every object, are indeed unusual.<br>
>> ><br>
>> > The problem with source tags is that they only tell part of the truth -<br>
>> > if you import a hospital from UNICEF and someone later changes it then<br>
>> > they will likely forget to remove or amend the source tag. A source tag<br>
>> > on the changeset makes this more clear.<br>
>> ><br>
>> > I understand your admin level explanation but I don't think it is<br>
>> > sufficient reason for adding the highly unusual three "is-in" type of<br>
>> > tags that you are proposing. I wonder how addresses in CAR are<br>
>> > constructed - is it possible that the correct postal address for a<br>
>> > location like that might be "XYZ Hospital, Adminarea 3, Adminarea 2,<br>
>> > Adminarea 1, CAR" or so? In which case a potential compromise could be<br>
>> > using the addr:full tag (Wiki: "Use this for a full-text, often<br>
>> > multi-line, address if you find the structured address fields unsuitable<br>
>> > for denoting the address of this particular location.").<br>
>> ><br>
>> > Lastly, I too think the "fixme" should be dropped, because doing an<br>
>> > import with "fixme" tags gives the impression that it is ok to import<br>
>> > half-baked data for others to fix - something we're doing everything to<br>
>> > avoid, and your documented import procedure makes it clear enough that<br>
>> > you expect importing users to curate the data as required.<br>
>> ><br>
>> > Bye<br>
>> > Frederik<br>
>> ><br>
>> > --<br>
>> > Frederik Ramm ## eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a> ## N49?00'09"<br>
>> E008?23'33"<br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Thu, 09 Jan 2014 11:37:47 +0100<br>
>> From: Rafael Avila Coya <<a href="mailto:ravilacoya@gmail.com">ravilacoya@gmail.com</a>><br>
>> To: <a href="mailto:imports@openstreetmap.org">imports@openstreetmap.org</a><br>
>> Subject: Re: [Imports] Import UNICEF data in Central African Republic,<br>
>> act II<br>
>> Message-ID: <<a href="mailto:52CE7BFB.7000002@gmail.com">52CE7BFB.7000002@gmail.com</a>><br>
>> Content-Type: text/plain; charset=ISO-8859-1<br>
>><br>
>> Hi S?verin and all:<br>
>><br>
>> I agree with Frederik about the use of addr:full instead of the<br>
>> boundary_admin_levelX_name tags (I would change "CAR" at the end of the<br>
>> full address for "R?publique centrafricaine" or "Central African<br>
>> Republic"). I think it's a smarter solution: 1 tag instead of 3, and a<br>
>> tag that is fully accepted by all.<br>
>><br>
>> I wonder if the data available at this time through the HOT task manager<br>
>> will be changed or not to incorporate these changes to the import.<br>
>><br>
><br>
> Sure it will be changed to reflect all the decision made on this thread<br>
><br>
> In<br>
>> case you change the data for the rest of the import process, I would add<br>
>> some improvements that I already suggested in past emails, so we avoid<br>
>> having to correct them afterwards (in case we want):<br>
>><br>
>> 1) Some schools have the 'capacity:classrooms', 'capacity:pupils' and<br>
>> 'capacity:teachers' with value "0". I would set it better to "unknown"<br>
>> value, as it makes more sense (for the capacity:classrooms one at least,<br>
>> as there is surely no school without any classroom in it).<br>
>><br>
> Good idea, we will change this<br>
><br>
>><br>
>> 2) I find operator=yes/no not appropiate. As we read in the key:operator<br>
>> wiki ( <a href="http://wiki.openstreetmap.org/wiki/Key:operator" target="_blank">http://wiki.openstreetmap.org/wiki/Key:operator</a> ), "the operator<br>
>> tag is used to name a company, corporation, person or any other entity<br>
>> who is in charge of the operation of a certain map object". But "yes" or<br>
>> "no" aren't any entity themselves. I think it would be more appropiate<br>
>> to change it to operated=yes/no, maintained=yes/no, manned=yes/no or<br>
>> something similar. I would suggest the tagged "maintained". The only<br>
>> issue: these tags are not widely accepted tags, as it is the operator tag.<br>
>><br>
> the original field is COMITE_GES (= COMITE GESTION) that means management<br>
> committee, and the values are yes or no. What would fit the most?<br>
><br>
>><br>
>> 3) Again, in case the data is updated to incorporate the changes for<br>
>> this import, I would correct the following typos for the health<br>
>> facilities import:<br>
>><br>
>> operator:type instead of operator_type<br>
>> toilets:number instead of toilets_number<br>
>> capacity:beds instead of capacity_beds<br>
>> health_facility:type instead of health_facility_type<br>
>> addr:city instead of addr_city<br>
>><br>
> Has been done in the wiki (and will be implemented in the TM as well). DO<br>
> you see remaining ones?<br>
><br>
>><br>
>> I know we can correct that with a script or by hand afterwards, but what<br>
>> if, in the mean time, somebody makes and improvement like tracing the<br>
>> area of the hospital, copy/pasting the data from the hospital node to<br>
>> the new area or relation and deleting the node? The same would be true<br>
>> for schools (much less probable for water facilities).<br>
>><br>
><br>
> Hmm this is another discussion. Frankly I prefer to have the global<br>
> attributes on one node in the middle of the compound. Why not create also a<br>
> relation between it, the buildings, the landuse and other objects like<br>
> related water points but it is basically time consuming, it would be far<br>
> from being an world standard as many mappers are not skilled enough in OSM<br>
> techniques to do this, and it does not provide much extra value. Moreover<br>
> it would require to be in the field to know what are the facility extent<br>
> and involved buildings, what is not obvious at all from imagery in CAR<br>
> context.<br>
><br>
>><br>
>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstreetmap.org/pipermail/imports/attachments/20140117/5afa5987/attachment.html" target="_blank">http://lists.openstreetmap.org/pipermail/imports/attachments/20140117/5afa5987/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.org/listinfo/imports</a><br>
<br>
<br>
End of Imports Digest, Vol 55, Issue 19<br>
***************************************<br>
</blockquote></div><br></div></div>