[Imports] Import UNICEF data in Central African Republic, act II

Jo winfixit at gmail.com
Thu Jan 9 10:47:40 UTC 2014


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.

Jo


2014/1/9 Rafael Avila Coya <ravilacoya at gmail.com>

> Hi Séverin and all:
>
> I agree with Frederik about the use of addr:full instead of the
> boundary_admin_levelX_name tags  (I would change "CAR" at the end of the
> full address for "République centrafricaine" or "Central African
> Republic"). I think it's a smarter solution: 1 tag instead of 3, and a
> tag that is fully accepted by all.
>
> I wonder if the data available at this time through the HOT task manager
> will be changed or not to incorporate these changes to the import. In
> case you change the data for the rest of the import process, I would add
> some improvements that I already suggested in past emails, so we avoid
> having to correct them afterwards (in case we want):
>
> 1) Some schools have the 'capacity:classrooms', 'capacity:pupils' and
> 'capacity:teachers' with value "0". I would set it better to "unknown"
> value, as it makes more sense (for the capacity:classrooms one at least,
> as there is surely no school without any classroom in it).
>
> 2) I find operator=yes/no not appropiate. As we read in the key:operator
> wiki ( http://wiki.openstreetmap.org/wiki/Key:operator ), "the operator
> tag is used to name a company, corporation, person or any other entity
> who is in charge of the operation of a certain map object". But "yes" or
> "no" aren't any entity themselves. I think it would be more appropiate
> to change it to operated=yes/no, maintained=yes/no, manned=yes/no or
> something similar. I would suggest the tagged "maintained". The only
> issue: these tags are not widely accepted tags, as it is the operator tag.
>
> 3) Again, in case the data is updated to incorporate the changes for
> this import, I would correct the following typos for the health
> facilities import:
>
> operator:type instead of operator_type
> toilets:number instead of toilets_number
> capacity:beds instead of capacity_beds
> health_facility:type instead of health_facility_type
> addr:city instead of addr_city
>
> I know we can correct that with a script or by hand afterwards, but what
> if, in the mean time, somebody makes and improvement like tracing the
> area of the hospital, copy/pasting the data from the hospital node to
> the new area or relation and deleting the node? The same would be true
> for schools (much less probable for water facilities).
>
> Rafael.
>
> On 09/01/14 02:07, Jo wrote:
> > If there is data in your source that you want to pass on to the people
> > who are going to import/integrate it into Openstreetmap, you can use
> > tags like
> >
> > odbl
> > created_by
> >
> > and such. These are tags which JOSM will silently remove before
> > uploading the data. So they will not end up in the OSM DB, but your crew
> > has them available to do cross checks.
> >
> > You can use MAPCSS to make them visible more prominently during your
> > edit session.
> >
> > I hope this helps. (Maybe JOSM could be expanded to have tags dedicated
> > for this purpose, say an import: namespace and maybe it would be a good
> > idea to be able to tag objects with upload=no, so JOSM refuses to upload
> > them when they have not been verified. But that's for another mailing
> > list...)
> >
> > Jo
> >
> >
> > 2014/1/9 Frederik Ramm <frederik at remote.org <mailto:frederik at remote.org
> >>
> >
> >     Sev,
> >
> >        I don't see big issues with your proposed import. The page on
> schools
> >     has a tag value of "uncomplete" where I'd guess that "incomplete"
> would
> >     be a better term but I'm not a subject matter expert.
> >
> >     What strikes me that in your explanation, you seem to ask for special
> >     treatment because "this is for humanitarian purposes" - quotes:
> >
> >     On 08.01.2014 23:34, Severin MENARD wrote:
> >     > Please keep in mind it deals with humanitarian data in a big crisis
> >     > context, so it is important to have the possibility to cross
> checked
> >     > facilities incorrectly located
> >
> >     ...
> >
> >     > therefore it is a very light dataset and adding a few tags really
> >     > useful for data control, considering its humanitarian ground,
> >     would only
> >     > represent a few more Kb.
> >
> >     You seem to be of the opinion that because this is "humanitarian" we
> >     should be lenient - but I think the opposite is the case. As HOT - a
> >     group of people who have been doing various imports for a long time
> and
> >     will doubtlessly continue to do so - you have to be a shining
> example to
> >     everyone else. You, of all people, are expected to "do things right",
> >     and other people will look at your imports and say: If people who do
> so
> >     many imports do <X> then it must be the right thing to do. You've
> >     already done a very good job at documenting the import procedure on
> the
> >     Wiki (this is indeed a very good example to others).
> >
> >     That's why I'm happy that you're starting this discussion just like
> we'd
> >     expect from anyone else making an import.
> >
> >     The two issues you mention in your email, source tag on every object
> and
> >     named admin units tagged with every object, are indeed unusual.
> >
> >     The problem with source tags is that they only tell part of the
> truth -
> >     if you import a hospital from UNICEF and someone later changes it
> then
> >     they will likely forget to remove or amend the source tag. A source
> tag
> >     on the changeset makes this more clear.
> >
> >     I understand your admin level explanation but I don't think it is
> >     sufficient reason for adding the highly unusual three "is-in" type of
> >     tags that you are proposing. I wonder how addresses in CAR are
> >     constructed - is it possible that the correct postal address for a
> >     location like that might be "XYZ Hospital, Adminarea 3, Adminarea 2,
> >     Adminarea 1, CAR" or so? In which case a potential compromise could
> be
> >     using the addr:full tag (Wiki: "Use this for a full-text, often
> >     multi-line, address if you find the structured address fields
> unsuitable
> >     for denoting the address of this particular location.").
> >
> >     Lastly, I too think the "fixme" should be dropped, because doing an
> >     import with "fixme" tags gives the impression that it is ok to import
> >     half-baked data for others to fix - something we're doing everything
> to
> >     avoid, and your documented import procedure makes it clear enough
> that
> >     you expect importing users to curate the data as required.
> >
> >     Bye
> >     Frederik
> >
> >     --
> >     Frederik Ramm  ##  eMail frederik at remote.org
> >     <mailto:frederik at remote.org>  ##  N49°00'09" E008°23'33"
> >
> >     _______________________________________________
> >     Imports mailing list
> >     Imports at openstreetmap.org <mailto:Imports at openstreetmap.org>
> >     https://lists.openstreetmap.org/listinfo/imports
> >
> >
> >
> >
> > _______________________________________________
> > 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.
>
> http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140109/cc3d8bff/attachment-0001.html>


More information about the Imports mailing list