2017-05-15 13:11 GMT+02:00 Brian Prangle <[email protected]>:
> You have introduced a lot of new tags with this import and used others in > a way that could be questioned: > > - source tags usually should go on the changeset > *This is news to me - there are currently over 5 million instances of this > tag in the UK* > yes, it is used a lot, but it is recommended to put source tags on the changeset. Many of those source tags on objects actually come from imports like yours, which generally distort tag usage statistics. > > - form is not an established key, it seems there is no docu about it, not > even a proposal. Capitalized values are not common for formal values. > Is this a problem? *Not aware that using a tag requires all this. If > it's a problem then I can substitute tree_form which is more explicit* > the point is, while a mapper can use any tags he wants, an import shouldn't introduce any new tags but rather use established tags in a way they are already defined. Capitalization: generally we agreed on all-lowercase tags for formal values, because it makes a difference for computers and will lead to tag fragmentation if we don't have clear rules. > > - age is only used for kindergartens so far, and the established tags are > min_age and max_age. Again there is no proposal for it, there is a > capitalized formal value, and it remains unclear when "new" was. *Not > aware that in order to use a tag there has to be a proposal. The use and > content of age as data seems pretty self-explanatory.* > * The source tag contains the date of the data so the age can be related > to that, so "new" and all other values are current at the source of the > data: dec 2016. Could I also suggest that the age tag for kindergartens as > you describe it doesn't relate to the object tagged but to the children > attending?* > yes. "min_age" relates to the min_age of the people attending the feature. It is defined like this. > Are you going to update these age tags frequently? * Already addressed in > the original post - we can only update as frequently as the data owner > refreshes the published data. * > Otherwise I'd suggest a date based system. An established tag for this is > start_date. *Good idea but we don't have this data* > it is the same from another perspective, you do not need a precise date for start_date, it can also be a time range. - what is usrn? Usually we don't use abbreviations in tags. *Already > explained in the original post: Unique Street Reference Number. Suggestions > have been to use ref:usrn* > IMHO there shouldn't be an abbreviation in the tag name, generally, there shouldn't even be a foreign key at all. - the address tags are not the established kind with addr:* or is_in. > Generally I'm not sure whether you should add them, your local community > even decided to not import administrative boundaries, why would they want > to import derivative point data?* see reply from Colin Smale* > Colin made me aware of the different meaning of "political" and "administrative" boundaries, but in general the comment stands: if you don't want political boundaries in OSM, why would you want to query trees by political-boundary queries? Even more, if those are codified like the is_in tags that went away for good reason years ago. I appreciate you are discussing your import here in detail, but I think the stuff you already entered in the way your example showed should be modified to make it fit better with the rest of our data. Cheers, Martin
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
