[Imports] Birmingham City Council tree import

[Martin Koppenhoefer]

2017-05-15 13:11 GMT+02:00 Brian Prangle <brianboruimport at gmail.com>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170515/025f1bea/attachment.html>