[Talk-GB] Birmingham Tree Import

Brian Prangle bprangle at gmail.com
Thu Apr 27 19:26:48 UTC 2017


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 Harry's 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)*

Regards


Brian

On 14 April 2017 at 17:24, ajt1047 at gmail.com <ajt1047 at gmail.com> wrote:

> On 13/04/2017 20:26, ael wrote:
>
>> ....And none of the 3 suggested causes applies in my case.
>>
>
> What was the problem in your case?
>
> Best Regards,
>
> Andy
>
>
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20170427/86dc0f0e/attachment.html>


More information about the Talk-GB mailing list