will_p has commented on the following diary entries
|Fixing common & possible Tagging Mistakes||7 months ago||
I disagree with combining craft=photographer and shop=photo_studio. Both can be used together where appropriate, but they are not always the same. craft=photographer implies the studio of a photographer, but it does not say which types of photography are offered. Some photographers specialise in particular things: weddings, glamour photography, photographing merchandise to appear in catalogues, etc. This tag does not suggest anybody can walk in off the street and have their photograph taken, while shop=photo_studio implies exactly that.
Please be careful about encouraging mass edits. Many mappers (myself included) have spent a lot of time mapping these things and really do care about these subtle distinctions. I have no objection to merging things that really are the same, but this must be done with care, and this almost always means by local mappers. It is very easy to remove worthwhile distinctions between tags without realising you are doing so and that can be demotivating to the people who added them
I agree people sometimes use shop=photo_studio where shop=photo would be correct. I don't disagree with changing them, but it must be verified on the ground or with local knowledge.
Where I live in Nottingham (England) we have a website showing services and amenities mapped locally. There is a separate layer for photo studio shops: http://osm-nottingham.org.uk/?z=12&lon=-1.19768&lat=52.95009&bgl=OSM,1,17&l=services&lh=Auctionhouses;Launderettes;Drycleaners;Printingcopyshops;Taxioffices;Drivingschools This will be no way to create such a layer if these tags are carelessly merged together.
|Mapped UK addresses by postcode area||over 1 year ago||
Tom: Looking at the Westbury addresses, they all appear to have been added in 2009, so I suspect the mapper didn't have access to good enough aerial imagery to add buildings. And StreetView wasn't available then either.
Regarding postcode 'stubs', I have never bothered with them, but I suppose they might be of some use, particularly on the borders of postcode districts, where trying to determine the postcode from centroids or other inexact sources is going to be unreliable.
A quick query on the address data I've extracted indicates there are 20,934 addresses with just a postcode stub, and of these, 11,980 are in Birmingham and 3,951 in Coventry. So it's obviously favoured by West Midlands mappers.
chillly: My lists certainly aren't a good indicator of completeness. I did unsuccessfully search for data about the total number of addresses in each postcode district, so I could show the level of completeness, but possibly this isn't available without access to the PAF database.
I suppose I could just use the total number of postcodes in each area as a rough indicator of the number of addresses. But it would require filtering out the inactive postcodes usually located at sorting offices first, and then, I'm not sure it would be accurate enough to be worthwhile.
I make regular use of your postcode overlay. It's much appreciated.
RobJN: I'm aware of the Postcode Finder tool. It is very useful, although it's a shame it doesn't support the 'street' relations that I have used a lot. I mostly use it to easily look at the Land Registry data.
Regarding the "Wrong Postcode" lists, it is necessary to be careful that it is matching the correct street, because most of the mismatches it's highlighted in my area have turned out to be a different street with the same name, sometimes several miles away. I appreciate that matching the correct street is quite difficult to do. Perhaps it could use the postcode centroids to pin down the location.
|Adding addresses: NG9||over 1 year ago||
Pgd81, a late reply to your comments:
I have sometimes used the approach you suggested for retail units. While not widely used it is one method that can be used. I have also sometimes used the addr:place tag for large retail parks, where the address doesn't really have a street just an area.
As for using addr:housename and addr:unit for residential sub-streets, I don't think there is anything particularly wrong with doing it that way, but I suppose I think there should be a more generic solution. This is partly because it won't work well in all circumstances: for example if the sub-street itself contains both house names and numbers. Consider this example (the names are made-up, but it's based on a real example): Dairy Barn, 2 Glebe Farm Court, Church Lane This is a courtyard called Glebe Farm Court, located off Church Lane, which containing a series of dwellings with housenames and numbers. It's not impossible to represent this using existing tags, but it would involve using 2 or 3 tags for things they aren't really intended for, so would be rather ugly/hackish.
|Adding addresses: NG9||almost 2 years ago||
In reply to Tom's comments:
Regarding using addr:interpolation on individual buildings, I think it is correct. It's really the only way to avoid ambiguity. I must have done this hundreds of times and would be most unhappy if somebody removed them. Here's an example: http://www.openstreetmap.org/browse/way/224033525. This usage of addr:interpolation has been documented on the wiki now (not that I think the wiki should be used as the sole source in deciding whether tagging is correct).
For addr:flats, I think it's acceptable to use a semi-colon to separate multiple numbers, so if I were tagging the example you gave, I would use addr:flats=23;23a;23b. (Some people prefer commas instead of semi-colons.)
Regarding the school I referred to, this is the link: http://www.openstreetmap.org/browse/relation/409896. It is split in two by a trunk road but joined by a foot bridge. To tag this, I decided to draw two separate polygons for the separate parts and then combined them together using a multipolygon relation with two 'outer' roles. I then included the amenity=school tag and the address details inside the multipolygon relation.
I like to group all the addresses on a street together using a street relation (in this case: http://www.openstreetmap.org/browse/relation/1917127). I was making a technical point that strictly (according to the wiki) 'address' roles in street relations are not allowed to themselves be relations (only nodes or ways). Personally I don't see any reason for this limitation and ignore it.