Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 16:43, Lester Caine wrote: > That it is not now a 'preferred route' is a problem, which in practice > was screwed up by giving it the A5191 designation in the first place, This does make me wonder how other sat-nav providers handle this road. In any case, I wonder if this section of A5191 has been recently reclassified by council but not in Ordnance Survey yet. Also the old sign at Meole Brace Roundabout - https://www.mapillary.com/app/?lat=52.6423=-2.7554437=17=photo=qx_aDiQRrdkhs4bDuv7tQw=0.48639059127464496=0.624061029625061=0 has now been changed and 'B4380' (left turn) is no longer in brackets, which says to me at least the bridge over Rea Brook is now part of the B4380. Jez C ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On 19/07/2019 20:29, Mark Goodge wrote: ONS postcode products are also OGL, so can be reused in OSM and similar. They're also more useful than Code-Point Open in that they also include lookups to a number of other government codes (such as local authority GSS codes). It also differentiates between "large user" and normal postcodes, and includes an introduction date and, where applicable, a termination date for every valid postcode. That would be very useful indeed but what is the license of these extra features? OGL alone doesn't mean anything if they qualify it with "data may contain third party IP" or similar. Their website says: "Our postcode products (derived from Code-Point® Open) are subject to the Open Government Licence." and then: "If you also use the Northern Ireland data (postcodes starting with “BT”), you need a separate licence for commercial use direct from Land and Property Services." I understand it as only the part that already exists in Code-Point Open is free, extra information may or may not be free, depending if it comes from ONS own data or other sources. Best regards, ndrw6 ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
19 Jul 2019, 13:55 by for...@david-woolley.me.uk:
> I think mapping it in conflict with a published official designation will
> devalue OSM.
>
Not sure is it happening in UK but Poland has some private driveways that
are officially assigned status of major road ("droga krajowa").
There is also officially existing major road route, crossing river by bridge
that
was destroyed in WW II and not rebuild. As result there is highway=track
that is officially a major road.
Japan has steps that have assigned rank of major road (for some historic
reasons).
In some cases deviating from official designations makes sense (
not sure is it actually happening here).
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 18:05, David Woolley wrote: On 19/07/2019 15:37, Mark Goodge wrote: There are, though, two potentially useful open data coordinate mapping systems that can be used by the likes of OSM. One is Mapcode, the other is Google's Open Location Code (aka Plus Codes). Both have the advantage of not only being entirely free and open to use, but can also be generated programmatically from a published algorithm - no need to hook into an API, just run some code locally. There is also the extended form of the venerable Maidenhead Locator System. Ah, that's a new one on me. Looks a pretty simple algorithm, too. Thanks. Mark ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On 19/07/2019 15:15, Andrzej wrote: Indeed, Code-Point Open is less than ideal, the issues are almost always caused by lack of differentiation between residential and "large user" postcodes. On the other hand, it is the only legal source of postcodes we have, other than local knowledge, but the latter is realistically limited to a dozen or so postcodes per mapper. Businesses website could also be OK but they are usually copyrighted. Derived databases, like FHRS, are generally not OK, a unless also permitted by Royal Mail. ONS postcode products are also OGL, so can be reused in OSM and similar. They're also more useful than Code-Point Open in that they also include lookups to a number of other government codes (such as local authority GSS codes). It also differentiates between "large user" and normal postcodes, and includes an introduction date and, where applicable, a termination date for every valid postcode. And, unlike Code-Point Open, the ONSPD has a persistent URL that can be used to automate updates. https://hub.arcgis.com/datasets/ons::ons-postcode-directory-latest-centroids More generally, the ONS open data geography datasets are a goldmine. Another useful one is the Index of Place Names; that has obvious utility for OSM as a means of verifying the official spelling of names entered by mappers. Mark ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On Fri, 2019-07-19 at 07:06 -0700, Richard Fairhurst wrote: > Tom Hughes wrote: > > That doesn't follow - in the UK we have always (with very rare > > exceptions like Oxford High Street) mapped secondary, primary > > and trunk to the official status of the road. > > It's slightly more nuanced than that - we have always mapped > secondary, > primary and trunk to the _observable_ official status of the road. > > Where a road isn't signposted with that status, we don't have a > strong > precedent. There is at least one such road which has been > highway=tertiary > since 2009. It is not signposted as the A*** on the ground - indeed, > traffic > for the A*** is expressly signed another way - but legally it is the > A***. > And no I'm not going to say where it is or some Sabristo[1] will come > along > and "fix" it. > > Philip's example is the same: I know the road he's talking about and > it > isn't signposted as the A, it's signposted only for the little > suburb > along it. There is a very definite decision there on the part of the > highways authority to not treat it as an A road. > > I don't have a simple answer, but I am tempted by the logic that > where the > highways authority has clearly made a decision not to signpost a road > as (in > OSM terms) secondary, primary or trunk, we should follow suit and tag > something like highway=tertiary, designation=primary, ref=A***. > Thank you for your comments Richard. Using a designation tag in these cases would make a lot of sense. We should certainly not be undermining hard pressed local authorities who are doing their best to improve the quality of life of their residents. Phil (trigpoint) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 15:37, Mark Goodge wrote: There are, though, two potentially useful open data coordinate mapping systems that can be used by the likes of OSM. One is Mapcode, the other is Google's Open Location Code (aka Plus Codes). Both have the advantage of not only being entirely free and open to use, but can also be generated programmatically from a published algorithm - no need to hook into an API, just run some code locally. There is also the extended form of the venerable Maidenhead Locator System. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On Fri, 2019-07-19 at 16:43 +0100, Lester Caine wrote: > On 19/07/2019 16:04, Philip Barnes wrote: > > As the sabristi have already discovered this one, and the OSM edits > > appear linked to Sabre Wiki edits, I will identify it. > > > > In this case I am concentrating on A5191 (Coleham Head, Belle Vue > > Road, > > Hereford Road) > > https://www.openstreetmap.org/#map=18/52.70122/-2.74811 > > > > Not a primary on the ground as can be seen on mapillary. > > https://www.sabre-roads.org.uk/wiki/index.php?title=A5191 > As some say, sabre is not an official source but it does use OSM as > it's > mapping tool! > > Essentially this seems like the opposite of my own problem. Around > here > the A46 moved over closer to Evesham, and the old road became the > B4632. > Traffic is then pushed towards the A46 and what can be a 10 mile+ > detour > over the other more direct routes linked with the B4632 and even the > secondary B4632 is 'avoided' by the routers! In your case the > preferred > route would seem to be the A49 and rather than downgrading the old > route > to a B road it's been left with an A designation? Bottom line is if > the > A5191 is used on traffic reports it should be identified. That it is > not > now a 'preferred route' is a problem, which in practice was screwed > up > by giving it the A5191 designation in the first place, and tagging > it > 'tertiary' IS breaking the rule don't tag for the router :( In the > absence of something to override the 'primary' rule set then we are > a > bit stuck, but that should be something additional to what is the > documented designation. That the road classifications provide a > crude > rule set for routing has always been a problem but in the case of > the > A5191 what is the speed limit? I think I would expect 30MPH if it is > essentially 'residential' which should push routing to faster > alternatives, but we are now seeing 20MPH zones even on primary roads > to > calm traffic and provide direct rules for routing? > Looking through the history this road has been mapped as tertiary since 2008, several local mappers have touched it but until one remote mapper, nobody had considered it to be primary. Phil (trigpoint) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On Fri, Jul 19, 2019, at 3:21 PM, Andrzej wrote: > > Thank you for your opinion, Robert. I will suspend adding postcodes from > Code-point Open. > > Do others agree with it or would you rather have more postcodes in database > first and work on accuracy and completeness afterwards? > > Indeed, Code-Point Open is less than ideal, the issues are almost always > caused by lack of differentiation between residential and "large user" > postcodes. On the other hand, it is the only legal source of postcodes we > have, other than local knowledge, but the latter is realistically limited to > a dozen or so postcodes per mapper. Businesses website could also be OK but > they are usually copyrighted. Derived databases, like FHRS, are generally not > OK, a unless also permitted by Royal Mail. > > It's not that I don't care about complete addresses either. But my spare time > is limited, and I feel I can contribute more by adding missing postcodes in a > town vs adding complete addresses in a few streets. Others may have different > priorities. > > I disagree that having data from Code-Point Open outside OSM is sufficient. > Excluding surveyed information, everything in OSM is already publicly > available (or should be). Yet, we all keep using and working on OSM. Besides, > how to extend or combine information without adding it first? > Hi, I would love to see a comparison done between the accuracy of manually added postcodes vs. those added from the OS or ONS datasets. Someone manually added a bunch of postcodes near me and I am pretty certain quite a few of them are wrong but without going around knocking on people's doors they are probably going to stay wrong forever. I usually use the ONS Postcode dataset (https://geoportal.statistics.gov.uk/datasets/ons-postcode-directory-may-2019) rather than CodePoint Open. The datasets do have differences and which is more accurate I have no idea. The ONS centroids are mostly "snapped" to the nearest building within the postcode so are pretty easy to match up. I know that Robert is sincere in his views but the classic "don't add data to OSM because it will spoil someone else's enjoyment" always makes me chuckle. In most parts of the country the idea that the current cohort of mappers can add accurate address data by hand is pie in the sky. There are certainly issues with adding these postcodes to buildings in dense town centres but in those areas you can often find postcodes by other means anyway. I think adding postcodes to residential or rural areas from these datasets is fine but I personally wouldn't add them unless I had some on-the-ground knowledge of the area. Kevin ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 16:04, Philip Barnes wrote: As the sabristi have already discovered this one, and the OSM edits appear linked to Sabre Wiki edits, I will identify it. In this case I am concentrating on A5191 (Coleham Head, Belle Vue Road, Hereford Road)https://www.openstreetmap.org/#map=18/52.70122/-2.74811 Not a primary on the ground as can be seen on mapillary. https://www.sabre-roads.org.uk/wiki/index.php?title=A5191 As some say, sabre is not an official source but it does use OSM as it's mapping tool! Essentially this seems like the opposite of my own problem. Around here the A46 moved over closer to Evesham, and the old road became the B4632. Traffic is then pushed towards the A46 and what can be a 10 mile+ detour over the other more direct routes linked with the B4632 and even the secondary B4632 is 'avoided' by the routers! In your case the preferred route would seem to be the A49 and rather than downgrading the old route to a B road it's been left with an A designation? Bottom line is if the A5191 is used on traffic reports it should be identified. That it is not now a 'preferred route' is a problem, which in practice was screwed up by giving it the A5191 designation in the first place, and tagging it 'tertiary' IS breaking the rule don't tag for the router :( In the absence of something to override the 'primary' rule set then we are a bit stuck, but that should be something additional to what is the documented designation. That the road classifications provide a crude rule set for routing has always been a problem but in the case of the A5191 what is the speed limit? I think I would expect 30MPH if it is essentially 'residential' which should push routing to faster alternatives, but we are now seeing 20MPH zones even on primary roads to calm traffic and provide direct rules for routing? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On Fri, 2019-07-19 at 15:06 +0100, Tom Hughes wrote: > On 19/07/2019 14:17, David Woolley wrote: > > On 19/07/2019 13:37, Tom Hughes wrote: > > > > I would say the logical consequence of that argument is that no > > > > road > > > > should be mapped as tertiary, as, unless taken from OS, it is > > > > a > > > > subjective judgement and can't be consistently verified. > > > > > > That doesn't follow - in the UK we have always (with very rare > > > exceptions like Oxford High Street) mapped secondary, primary and > > > trunk to the official status of the road. > > > > You seem to be rejecting the original proposal. I was analysing > > the > > case where the original proposal is accepted, and therefore the > > official > > status must be ignored if it is not signposted. > > Well I'm not entirely sure what the true status is since the road > hasn't been identified and OS OpenData seems to be being used as > the source of truth which wouldn't be my first choice. > > Philip seemed to be saying that this was genuinely a white > signed A road (or at least that OpenData says it is) and hence > that it is a primary although he apparently prefers it to be > tertiary. > > You then followed up by saying that the logical consequence > of it being a primary (which I was assuming was correct) was > that nothing was tertiary, which didn't seem to make much > sense to me > > Perhaps if the road was identified it would be a more productive > discussion... > As the sabristi have already discovered this one, and the OSM edits appear linked to Sabre Wiki edits, I will identify it. In this case I am concentrating on A5191 (Coleham Head, Belle Vue Road, Hereford Road) https://www.openstreetmap.org/#map=18/52.70122/-2.74811 Not a primary on the ground as can be seen on mapillary. As Richard says this is legally a primary route, but the Highway Authority have chosen not to promote it as a primary route, it is signed at both ends as Belle Vue. The Meole Brace end sign is http://trigpoint.myzen.co.uk/photodump/HerefordRoadSign.png The signed primary route is via Hazledine Way, Pritchard Way and Old Potts Way. Phil (trigpoint) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On 19/07/2019 15:15, Andrzej wrote: Do others agree with it or would you rather have more postcodes in database first and work on accuracy and completeness afterwards? Andrez ... while the code-point table does provide a list against which missing post codes can be identified, the key piece of information that is needed is to add a road name to the post code, and that is not something that is easy to establish currently. If we all simply add address data to places we visit the gaps would fill up quite quickly but I'm guilty of not doing that. I've a list of postcode I have been looking up on OASAnd and not finding which I need to actually put in! -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 13:50, Andy G Wood wrote: On Friday, 19 July 2019 13:30:48 BST Martin Wynne wrote: On 19/07/2019 12:55, David Woolley wrote: ... (As a variation on the last point, one of my pet hates, these days, is how few houses now have house numbers in the UK. It make it difficult to give accurate locations for fly tips Have you seen: https://what3words.com/ [...] "3. Rights in what3words Materials and your licence to use them Yes, unfortunately W3W is useless for any open data application as it exists primarily as a commercial service aimed at the likes of satnav manufacturers rather than being available for anyone to use. (It also doesn't work globally as the words are language specific). There are, though, two potentially useful open data coordinate mapping systems that can be used by the likes of OSM. One is Mapcode, the other is Google's Open Location Code (aka Plus Codes). Both have the advantage of not only being entirely free and open to use, but can also be generated programmatically from a published algorithm - no need to hook into an API, just run some code locally. Personally, I prefer Mapcode, its codes are more memorable (and, if you take the country for granted, can be very short). But I suspect that OLC is more likely to gain widespread use simply because it's backed by Google. https://www.mapcode.com/ https://plus.codes/ Mark ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 15:14, David Woolley wrote: The logical consequence of ignoring the official classification if it is not signposted, is that you cannot map tertiary, because with, very rare exceptions, they are not signposted and you can only distinguish them from residential by using the official sources, or by personal judgements. Certainly the key tertiary roads around this area ARE easy to identify on the ground and while small sections could be tagged residential or service the majority of the roads are clear 60MPH routes in open countryside and are essential 'primary' routes to get from A to B without long diversions through M,A & B roads many of which have a 40MPH speed limit! As I said ... this is not a case of tagging for the routers, but simply identifying the facts on the ground which often are clear. These roads to not have primary route reference numbers ... but they are a key part of vehicle routing. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On 19 July 2019 09:58:52 BST, "Robert Whittaker (OSM lists)" wrote: > >I thus have to object not just to the new proposal but also any >continuation of the previous work to add single postcodes to buildings >under the centroid. Thank you for your opinion, Robert. I will suspend adding postcodes from Code-point Open. Do others agree with it or would you rather have more postcodes in database first and work on accuracy and completeness afterwards? Indeed, Code-Point Open is less than ideal, the issues are almost always caused by lack of differentiation between residential and "large user" postcodes. On the other hand, it is the only legal source of postcodes we have, other than local knowledge, but the latter is realistically limited to a dozen or so postcodes per mapper. Businesses website could also be OK but they are usually copyrighted. Derived databases, like FHRS, are generally not OK, a unless also permitted by Royal Mail. It's not that I don't care about complete addresses either. But my spare time is limited, and I feel I can contribute more by adding missing postcodes in a town vs adding complete addresses in a few streets. Others may have different priorities. I disagree that having data from Code-Point Open outside OSM is sufficient. Excluding surveyed information, everything in OSM is already publicly available (or should be). Yet, we all keep using and working on OSM. Besides, how to extend or combine information without adding it first? Best regards, ndrw6 ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 15:06, Tom Hughes wrote: You then followed up by saying that the logical consequence of it being a primary (which I was assuming was correct) was that nothing was tertiary, which didn't seem to make much sense to me The logical consequence of ignoring the official classification if it is not signposted, is that you cannot map tertiary, because with, very rare exceptions, they are not signposted and you can only distinguish them from residential by using the official sources, or by personal judgements. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 14:17, David Woolley wrote: On 19/07/2019 13:37, Tom Hughes wrote: I would say the logical consequence of that argument is that no road should be mapped as tertiary, as, unless taken from OS, it is a subjective judgement and can't be consistently verified. That doesn't follow - in the UK we have always (with very rare exceptions like Oxford High Street) mapped secondary, primary and trunk to the official status of the road. You seem to be rejecting the original proposal. I was analysing the case where the original proposal is accepted, and therefore the official status must be ignored if it is not signposted. Well I'm not entirely sure what the true status is since the road hasn't been identified and OS OpenData seems to be being used as the source of truth which wouldn't be my first choice. Philip seemed to be saying that this was genuinely a white signed A road (or at least that OpenData says it is) and hence that it is a primary although he apparently prefers it to be tertiary. You then followed up by saying that the logical consequence of it being a primary (which I was assuming was correct) was that nothing was tertiary, which didn't seem to make much sense to me Perhaps if the road was identified it would be a more productive discussion... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
Tom Hughes wrote: > That doesn't follow - in the UK we have always (with very rare > exceptions like Oxford High Street) mapped secondary, primary > and trunk to the official status of the road. It's slightly more nuanced than that - we have always mapped secondary, primary and trunk to the _observable_ official status of the road. Where a road isn't signposted with that status, we don't have a strong precedent. There is at least one such road which has been highway=tertiary since 2009. It is not signposted as the A*** on the ground - indeed, traffic for the A*** is expressly signed another way - but legally it is the A***. And no I'm not going to say where it is or some Sabristo[1] will come along and "fix" it. Philip's example is the same: I know the road he's talking about and it isn't signposted as the A, it's signposted only for the little suburb along it. There is a very definite decision there on the part of the highways authority to not treat it as an A road. I don't have a simple answer, but I am tempted by the logic that where the highways authority has clearly made a decision not to signpost a road as (in OSM terms) secondary, primary or trunk, we should follow suit and tag something like highway=tertiary, designation=primary, ref=A***. cheers Richard [1] https://www.sabre-roads.org.uk/forum/ -- Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 13:37, Tom Hughes wrote: I would say the logical consequence of that argument is that no road should be mapped as tertiary, as, unless taken from OS, it is a subjective judgement and can't be consistently verified. That doesn't follow - in the UK we have always (with very rare exceptions like Oxford High Street) mapped secondary, primary and trunk to the official status of the road. You seem to be rejecting the original proposal. I was analysing the case where the original proposal is accepted, and therefore the official status must be ignored if it is not signposted. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 13:37, Tom Hughes wrote: On 19/07/2019 12:55, David Woolley wrote: On 19/07/2019 12:36, Philip Barnes wrote: I cannot dispute this is legally a primary, OS Opendata shows it. I would say the logical consequence of that argument is that no road should be mapped as tertiary, as, unless taken from OS, it is a subjective judgement and can't be consistently verified. That doesn't follow - in the UK we have always (with very rare exceptions like Oxford High Street) mapped secondary, primary and trunk to the official status of the road. Roads with no official status as A or B roads are then divided between tertiary, unclassified and residential on a more subjective basis. Agreed ... if a UK road has an official reference it's classified. If not then it's tertiary if it does form part of the main road system and unclassified if it's not suitable for normal vehicle use. MANY of the roads around here are 'class c' and while it IS tempting to re-tag them as a higher level in order to get the routers to actually work, it's the routers treating them as lower speed routes which is the problem. At least around here and that is when 'service' as opposed to 'tertiary' should apply where a route IS more access route than primary link between to 'higher classification' routes. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On Friday, 19 July 2019 13:30:48 BST Martin Wynne wrote: > On 19/07/2019 12:55, David Woolley wrote: > ... > > > (As a variation on the last point, one of my pet hates, these days, is > > how few houses now have house numbers in the UK. It make it difficult > > to give accurate locations for fly tips > > Have you seen: https://what3words.com/ [...] "3. Rights in what3words Materials and your licence to use them 3.1 We are the owner or licensee of all of the what3words Materials and all Intellectual Property Rights in the what3words Materials. You acknowledge that in being permitted to use the Site and the what3words Materials as set out in these Terms the Intellectual Property Rights are licensed (not sold) to you, and that you have no other rights in, or to, the Intellectual Property Rights and nothing in these Terms shall be deemed to grant you any right, title or interest in the what3words Materials or any of the Intellectual Property Rights in the what3words Materials. etc, etc." I think you can guess the rest! Andy. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 12:55, David Woolley wrote: On 19/07/2019 12:36, Philip Barnes wrote: I cannot dispute this is legally a primary, OS Opendata shows it. I would say the logical consequence of that argument is that no road should be mapped as tertiary, as, unless taken from OS, it is a subjective judgement and can't be consistently verified. That doesn't follow - in the UK we have always (with very rare exceptions like Oxford High Street) mapped secondary, primary and trunk to the official status of the road. Roads with no official status as A or B roads are then divided between tertiary, unclassified and residential on a more subjective basis. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 12:55, David Woolley wrote: ... (As a variation on the last point, one of my pet hates, these days, is how few houses now have house numbers in the UK. It make it difficult to give accurate locations for fly tips Have you seen: https://what3words.com/ Every 3m (10ft) square on the planet is given a location name consisting of 3 random words from the dictionary. Their app shows you the 3 words for your current location. Many emergency services are using it -- much easier than asking callers to give postcodes, grid refs, lat/lon, road numbers, etc. Just read out the 3 words from your screen. Even if the local authority don't already use it, they can easily download it when given the 3 words, or go to the web site to find the location. Anyone can scribble down 3 words without making a mistake. And often remember them. cheers, Martin. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Ground truth v legal truth
On 19/07/2019 12:36, Philip Barnes wrote: I cannot dispute this is legally a primary, OS Opendata shows it. I would say the logical consequence of that argument is that no road should be mapped as tertiary, as, unless taken from OS, it is a subjective judgement and can't be consistently verified. I think mapping it in conflict with a published official designation will devalue OSM. As you hint, the correct thing to do, in mapping, is to map verifiable attributes that would make a rational router want to avoid it. Beyond that, like any tagging for the renderer issue, it is up to routers to use more than the primary classification in deciding whether to route. This is going to get more important, with the continuing trend is to reduce signage, on the basis that it distracts drivers, and they have access to GPS maps so don't need it. (As a variation on the last point, one of my pet hates, these days, is how few houses now have house numbers in the UK. It make it difficult to give accurate locations for fly tips - many of the apps use sources like Bing, which use address interpolation, and can be a long way out in some cases. I believe some US cities have bye-laws requiring them to be displayed.) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Ground truth v legal truth
I have always held the view that the great strength of OSM is boots on the ground and mapping what we see is always better than other sources. I currently have a dispute with a remote mapper who is upgrading tertiary roads to primary. In the case of one I see a quiet tertiary road, with no signs indicating other than the local area it serves. It is narrow, has narrow pavements and has lots of parked cars. There is slightly longer bypass route, which was until this change routing on the bypass roads. Now OSM is routing through a residential area. I cannot dispute this is legally a primary, OS Opendata shows it. I can certainly change the ref to unsigned:ref and ensure any weight restrictions are mapped but is the view of others? Phil (trigpoint) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Automated Code-Point Open postcode editing (simple cases only)
On Tue, 16 Jul 2019 at 22:20, ndrw6 wrote: > Over past several months I've been adding postcodes from Code-Point > Open. I've streamlined the procedure a bit, so I can now add the tags > without spelling out every single one of them, but it is still a manual > and labour intensive process: > > https://github.com/ndrw6/import_postcodes/ > > While working on that, I've noticed there are a lot of simple cases > where automatic collation would have produced very similar results. For > example, in case of existing OSM buildings without an addr:postcode tag > located at or very near to a Code-Point Open centroid. > > Therefore I'm requesting permission to use the following automated edit > procedure: I'm afraid I think this new suggestion will be too prone to errors to outweigh the benefits, so I have to oppose it, unless there's significant manual curation. In which case though, you might as well not bother with the 15m limit and instead look to find the true extents of the postcode unit. I'm also not convinced that the previous work on adding postcodes to single buildings in isolation is that beneficial. In particular, the new proposal has the following issues: * Not all buildings are addressable properties, and so some (e.g. garages, outbuildings) shouldn't have a postcode. How would you avoid accidentally adding postcodes to these? * Large-user postcodes only belong to a single building, and shouldn't be added to any nearby buildings, however close. It's not clear how you would avoid these with the proposed method. (For example it's common for a bank to have its own postcode, but the buildings either side along the high street will all share a different postcode.) * Often the two sides of a street will have different postcodes. So in the case of terraced houses, you may have an opposite property within 15m belonging to a different postcode unit. There are also some problems with the existing method: * Sometimes OSM building polygons encompass several joined properties (e.g. a terrace or a row of shops). Adding a single postcode to such a building polygon might be incorrect, as the properties may not all share the same postcode. * Adding postcodes in this way removes a convenient way for other mappers to work on adding more detail, by looking for postcodes that are not yet in OSM. I would argue that the benefits of adding just a postcode to a building corresponding to the centroid are pretty small -- any users can already use code-point open to obtain this information. The real value in adding postcodes to OSM is when they combined with other address information (e.g. street names and house numbers to give a full address) and when human extrapolation is used to infer the full set of properties that have the same postcode. I thus have to object not just to the new proposal but also any continuation of the previous work to add single postcodes to buildings under the centroid. Instead I would suggest it would be better to proceed more slowly and take the time to add addr:street (and other addr tags) tags when adding postcodes, and also try to add the postcode to the full set of properties for each unit where this can be deduced. See the discussion at http://sk53-osm.blogspot.com/2013/12/british-postcodes-on-openstreetmap.html . For instance at http://overpass-turbo.eu/s/KRf only the highlighted buildings have postcodes and none have streets. It should be possible to infer the postcodes of most of the houses from the centroid locations, and also add the addr:street tags in that area. A tool that finds postcode units whose centroid lies on top of an existing OSM building would still be a good way of finding instances to apply this procedure to though. Better still if it could prioritise areas with a high density of small buildings (i.e. a systematic import/ tracing of buildings) that also lack postcodes. Best wishes, Robert. > 1. Open an osm file containing missing postcodes (from the above > website) in jOSM > > 1a. Select all points from the above dataset > > 2. Download OSM data in the area of interest > > 2a. Select all ways with a "building" tag of typical residential house > size and without an "addr:postcode" tag (search phrase: 'building > -"addr:postcode" type:way areasize:50-1000') > > 3. Use a collation plugin to collate both datasets with "centroid > distance" set to "< 15m". The condition is there to apply postcodes only > to small buildings in direct vicinity of the codepoint centroid. > > There are some caveats I've noticed, often not different from manual > editing: > > a) Some buildings have addresses added as separate points rather than > tags (automated edit will add addr:postcode tags directly to the > building, this is what I chose to do manually as well) > > b) Collation plugin doesn't support relations (these postcodes will get > ignored and can be added later manually) > > c) Often OSM buildings contain multiple addresses or postcodes and > should be split into several
