<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-05-15 13:11 GMT+02:00 Brian Prangle <span dir="ltr"><<a href="mailto:brianboruimport@gmail.com" target="_blank">brianboruimport@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>You have introduced a lot of new tags with this import and used others in a way that could be questioned:</div><div><br></div><div>- source tags usually should go on the changeset <br></div></span><div><b><i>This is news to me - there are currently over 5 million instances of this tag in the UK</i></b></div></div></blockquote><div><br><br></div><div>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><span class=""><div>-
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.<br></div></span><div>Is this a problem? <i><b>Not aware that using a tag requires all this. If it's a problem then I can substitute tree_form which is more explicit</b></i></div></div></blockquote><div><br><br></div><div>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>-
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. <i><b>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.</b></i><b><i> 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?<br></i></b></div></div></blockquote><div><br><br></div><div>yes. "min_age" relates to the min_age of the people attending the feature. It is defined like this.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b><i></i></b></div><div>Are you going to update these age tags frequently? <b><i> Already addressed in the original post - we can only update as frequently as the data owner refreshes the published data. </i></b><br>Otherwise I'd suggest a date based system. <span style="background-color:rgba(255,255,255,0)">An established tag for this is start_date. <i><b>Good idea but we don't have this data</b></i><br></span></div></div></blockquote><div><br><br></div><div>it is the same from another perspective, you do not need a precise date for start_date, it can also be a time range.<br><br></div><div dir="ltr"> <br><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>- what is usrn? Usually we don't use abbreviations in tags. <b><i>Already explained in the original post: Unique Street Reference Number. Suggestions have been to use ref:usrn</i></b></div></blockquote><div><br><br></div><div>IMHO there shouldn't be an abbreviation in the tag name, generally, there shouldn't even be a foreign key at all.<br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>-
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?<i><b> see reply from Colin Smale</b></i></div></blockquote><div><br><br></div><div>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.<br></div><div> <br></div><div>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.<br><br></div><div>Cheers,<br></div><div>Martin<br></div></div></div>
</div></div>