[Imports] Birmingham City Council tree import

[Brian Prangle]

Hi everyone

I've been editing the already imported data to take on board some of the
comments made

1.height is now a numeral and the original data is now tagged as
height:range
2.usrn is now tagged as ref:usrn and documented in the wiki page
<https://wiki.openstreetmap.org/wiki/Key:ref>
3.capital letters removed  from values for age tag

I'm proposing for the avioidance of doubt to change the tag form to
tree_form.

Regards

Brian

On Fri, May 12, 2017 at 1:29 PM, Brian Prangle <brianboruimport at gmail.com>
wrote:

> Cross-post from Talk GB
>  (please be aware there have been some comments to this post so your POV
> may already have been articulated)
> Apart from some posts  about the problems with email notifications of
> changeset discussions, there has been nothing to indicate where I take this
> import. I guess that's because the initative is really down to me.
>
> I've annotated the Import wiki page
> <https://wiki.openstreetmap.org/wiki/Birmingham_City_Council_trees_data>
> with some comments and ideas. I've copied below what I think are the
> relevant bits from the wiki page and I look forward to resolving the issues
> as I'm keen to complete the import.
>
> Extract from wiki page:
>
> So update approach is to be planned. *This is not a requirement currently
> listed in the wiki imports guidelines. However it is good practice and the
> issue was raised with Amey and Birmingham City Council as soon as the data
> was released. Don't expect quick results!*
>
> *Import user problems*: The import so far has been entirely uploaded by
> the brianboru <http://www.openstreetmap.org/user/brianboru> user account.
> The size of the import was such that it should have been carried out by
> specially created OpenStreetMap user account. This guideline is in order to
> create another mechanism of separating/disentangling these edits from
> normal mapping
>
> *Solution: dedicated import account created: brianboruimport
> <https://www.openstreetmap.org/user/brianboruimport>*
>
> *Tag problems* :
> Example imported tree
>
> http://www.openstreetmap.org/node/4721553869
> natural <https://wiki.openstreetmap.org/wiki/Key:natural>=tree
> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree>source
> <https://wiki.openstreetmap.org/wiki/Key:source>=bcc_dec_2016form
> <https://wiki.openstreetmap.org/w/index.php?title=Key:form&action=edit&redlink=1>
> =Naturalage
> <https://wiki.openstreetmap.org/w/index.php?title=Key:age&action=edit&redlink=1>=New
> Plantingheight <https://wiki.openstreetmap.org/wiki/Key:height>=2 to 2.99m
> species <https://wiki.openstreetmap.org/wiki/Key:species>=Liquidambar
> styraciflua 'Worplusrn
> <https://wiki.openstreetmap.org/w/index.php?title=Key:usrn&action=edit&redlink=1>
> =2701986plot_number
> <https://wiki.openstreetmap.org/w/index.php?title=Key:plot_number&action=edit&redlink=1>
> =110007site_name
> <https://wiki.openstreetmap.org/w/index.php?title=Key:site_name&action=edit&redlink=1>=LUDGATE
> HILLward
> <https://wiki.openstreetmap.org/w/index.php?title=Key:ward&action=edit&redlink=1>
> =Ladywoodconstituency
> <https://wiki.openstreetmap.org/w/index.php?title=Key:constituency&action=edit&redlink=1>=City
> Centre
>
>    - Areas: ward, and constituency tags describe the *area* a tree is in.
>    That is not a normal thing to do with tags on many nodes. A lot of data
>    which ordinarily should be determined by a data user (if they require it)
>    by geo-querying boundaries information. These tags will have a data update
>    problems when the political boundaries change *The local community
>    decided some years ago not to add political boundaries, so there is
>    currenty no other way of querying the tree data by this attribute. This
>    will need revisiting once the boundary changes are in effect*
>    - 'site_name' key which contains the street name written in all
>    capitals. Did this need importing, and if so, did it have to be in
>    capitals? *Enables the average joe/jane to query data by street name.
>    Is the use of capitals a problem apart from being ugly? Maybe searches are
>    case-sensitive? The downoaded dateset used for import has been edited so
>    that this field is "Properly Cased" so any new imports won't be affected.
>    Can also bulk edit existing imported data*
>    - 'usrn' appears to be an identifier (Unique Street Reference Number
>    <https://data.gov.uk/dataset/national-address-gazetteer>). The purpose
>    for this should be documented. Perhaps local_ref or ref:usrn should have
>    been used. *usrn is indeed Unique Street Reference No. Its purpose is
>    documented in the link and is a national standard for referencing streets.*
>    - 'height' values are formatted in a non-standard way (See Key:height
>    <https://wiki.openstreetmap.org/wiki/Key:height>) *Is this a problem?
>    Not everything is recorded to a standard. If there is insistence on a
>    standard then it can be fixed e.g by tagging the existing data as
>    height:range and tagging with height =x where x= the nearest whole number
>    at the upper end of the range*
>    - species but no genus *????? See example above which uses normal
>    binomial name of genus and species (and includes in this case a cultivar)*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170531/2c1b946c/attachment.html>