[Imports] Birmingham City Council tree import
Denis Carriere
carriere.denis at gmail.com
Fri May 12 14:21:22 UTC 2017
That's amazing! Keep up the great work Brian, the sample Example imported
tree looks great, it's an overwhelming amount of information for a standard
tree feature.
Big +1 from me!
*~~~~~~*
*Denis Carriere*
*GIS Software & Systems Specialist*
On Fri, May 12, 2017 at 8:29 AM, 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)*
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20170512/b6569cc5/attachment-0001.html>
More information about the Imports
mailing list