Hi Well, as a humble community member, IMHO most of the "tag problems" listed at <https://wiki.openstreetmap.org/wiki/Birmingham_City_Council_trees_data#Problems_with_initial_import> are indeed problems. (I have no comment on species/genus tagging though.) Easy fixes: - change "usrn" to "ref:usrn" as requested, and document its meaning on the wiki; - format "height" values in the common format as requested, or perhaps "est_height" if only a range and not an exact value is known. Both of those easy fixes will make it easier for people who weren't involved in this import to make sense of the data.
A question: if "site_name" is indeed always a street, would it make sense perhaps to import it as "addr:street"? I realise some people might find this weird. I suggest it since it might make the semantics a bit more obvious to people in future years trying to make sense of the data, perhaps this as well as other imports from other datasets. Best Dan 2017-05-07 14:31 GMT+01:00 Andy Townsend <ajt1...@gmail.com>: > Anyone got any more comments about this import and the points raised below? > > We (the DWG) got a complaint about it at the time (and there were a lot of > "not in my name" comments on this list and on IRC), but there don't seem to > have been any further comments since 27th April. > > Best Regards, > > Andy > > > > On 27/04/2017 20:26, Brian Prangle wrote: > > 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 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 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 > > Tag problems : > > Example imported tree > > http://www.openstreetmap.org/node/4721553869 > > natural=tree source=bcc_dec_2016 form=Natural age=New Planting height=2 to > 2.99m species=Liquidambar styraciflua 'Worpl usrn=2701986 plot_number=110007 > site_name=LUDGATE HILL ward=Ladywood constituency=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). 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) 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, ajt1...@gmail.com <ajt1...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-gb > > > > > _______________________________________________ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > > > _______________________________________________ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
