<div dir="ltr"><div>If it's unknown, it's better to omit the tag alltogether. If one of the importers does happen to know, it's easy to add it again on an individual basis.<br><br></div>Jo<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014/1/9 Rafael Avila Coya <span dir="ltr"><<a href="mailto:ravilacoya@gmail.com" target="_blank">ravilacoya@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. 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>
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>
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>
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>
Rafael.<br>
<div class="im"><br>
On 09/01/14 02:07, Jo wrote:<br>
> If there is data in your source that you want to pass on to the people<br>
> who are going to import/integrate it into Openstreetmap, you can use<br>
> tags like<br>
><br>
> odbl<br>
> created_by<br>
><br>
> and such. These are tags which JOSM will silently remove before<br>
> uploading the data. So they will not end up in the OSM DB, but your crew<br>
> has them available to do cross checks.<br>
><br>
> You can use MAPCSS to make them visible more prominently during your<br>
> edit session.<br>
><br>
> I hope this helps. (Maybe JOSM could be expanded to have tags dedicated<br>
> for this purpose, say an import: namespace and maybe it would be a good<br>
> idea to be able to tag objects with upload=no, so JOSM refuses to upload<br>
> them when they have not been verified. But that's for another mailing<br>
> list...)<br>
><br>
> Jo<br>
><br>
><br>
</div>> 2014/1/9 Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a> <mailto:<a href="mailto:frederik@remote.org">frederik@remote.org</a>>><br>
<div><div class="h5">><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,<br>
>     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>
>     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><br>
</div></div>>     <mailto:<a href="mailto:frederik@remote.org">frederik@remote.org</a>>  ##  N49°00'09" E008°23'33"<br>
><br>
>     _______________________________________________<br>
>     Imports mailing list<br>
>     <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a> <mailto:<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>
<div class="im HOEnZb">><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>
</div><span class="HOEnZb"><font color="#888888">--<br>
Twitter: <a href="http://twitter.com/ravilacoya" target="_blank">http://twitter.com/ravilacoya</a><br>
<br>
--------------------------------<br>
<br>
Por favor, non me envíe documentos con extensións .doc, .docx, .xls,<br>
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.<br>
<br>
Atendendo á lexislación vixente, empregue formatos estándares e abertos.<br>
<br>
<a href="http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros" target="_blank">http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros</a><br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>