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 <[email protected]> > 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 <[email protected] <mailto:[email protected] > >> > > > > 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 [email protected] > > <mailto:[email protected]> ## N49°00'09" E008°23'33" > > > > _______________________________________________ > > Imports mailing list > > [email protected] <mailto:[email protected]> > > https://lists.openstreetmap.org/listinfo/imports > > > > > > > > > > _______________________________________________ > > Imports mailing list > > [email protected] > > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/imports >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
