Re: [Talk-GB] UK street addressing
On 21/12/2020 11:14, Richard Fairhurst wrote: More philosophically, post towns violate the “on the ground” principle. No one here writes their address as Chipping Norton unless PAF autocompletes it for them. No one has Chipping Norton on their letterhead. Trusting some remote third-party database in preference to local knowledge is not what OSM does, and particularly not OSM in the UK. By all means namespace it (royal_mail:addr:city) or use a bespoke tag for what is a bespoke concept (addr:post_town). But let’s not remove useful information (the actual town/city) in favour of it, and let’s not tag as if post towns are an intrinsic part of UK addresses, because they’re not. I have a similar problem with 'PAF autocomplete' ... my business address does not actually exist at all and the post code covers a large area of the business park, so even that is of little help to any delivery driver. Adding a phone number to the delivery details helps some of the time and with temporary drivers being used in the run up to Christmas I've had to talk a couple in this last week. Full address is L.S.Caine Electronic Service Willersey Suite De Montfort House Enterprise Way Vale Park Evesham WR11 1GS The number of websites that do not allow for that in terms of numbers of lines or limiting lime length preventing two elements per line ... at least some of the delivery services are using OSM these days ... De Montfort House, Enterprise Way takes them straight to the door :) -- 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] UPRN wiki page
On 18/11/2020 11:10, Robert Whittaker (OSM lists) wrote: It's definitely possible for UPRNs to be assigned to streets. I think you can tell this by searching for such a UPRN at https://www.findmyaddress.co.uk/ (I don't look at that now since they added a new T forbidding any use of the information for competing purposes.) IIRC, that site will tell you if a UPRN you enter is a street reference, and then refuse to provide the usual address information. It is worth pointing out that UPRN references identify parcels of land and in theory the whole of the United Kingdom is now covered by a continuous grid of land parcels with unique identifiers. Where a parcel is developed into multiple new smaller parcels then a new block of UPRN's will be generated by the local authority as defined by the planning documentation. So roads and amenity land which do not involve postal addresses will be defined along with other land registry parcels. I am not sure what happens with the original UPRN, but I would expect it to be tagged as 'ended' when the new contained parcels are 'started'. It should not be used as a part of the new batch for consistency but I can't find the 'rules' applied here. The new roads on the developments will then have new USRN references and Royal Mail will assign postcodes to these new roads. Many UPRN packets will never have a postal address listed in the PAF file ( and many businesses today are not properly listed either ) even if a postcode is used with that object as if it is. -- 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] Lorries can't limbo
On 12/11/2020 23:54, Neil Matthews wrote: And maybe network rail have a longer list / more info? https://www.eveshamjournal.co.uk/news/18863187.lorry-blocking-badsey-road-getting-stuck/ Relevance for this the fact that the lorry has turned towards a disused railway line with a low bridge which prevented any recovery vehicle accessing from that end and any chance of pulling it out that way anyway. It had to be pulled back and exit the way it came in. Whether lorries of this size should even be on these roads is another matter :) -- 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] Solar tagging app
On 04/10/2020 15:41, Russ Garrett wrote: Once we have panel counts that multiple people have agreed on, I'll batch insert the data into OSM using a new account - I will update this list once that is happening. I've just spent a couple of days working on Vale Park, Evesham and many of the units have panels on the roofs, so I think that is next on my list to do ... problem is I've not mapped these before, so what is my best starting point re adding them. -- 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] UPRN Locations Map
On 26/09/2020 13:46, David Woolley wrote: OS are in a funny position, in that they are in the public sector, but are expected to be self funding. To the extent that they succeed in the latter, they don't owe a duty to the taxpayer. But since the vast majority of the UPRN data is actually collected and managed by the relevant councils, the question is do they have the right to restrict access when it is council taxes that pay for the management of that data and not OS! SHOULD we perhaps be asking the various councils for direct access to the raw data under the open data umbrella? -- 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] How closely do we map lamp posts?
On 02/09/2020 19:00, Dave F via Talk-GB wrote: I don't know the area. but they look like the existing posts to me. Has the cycle path been realigned around them to provide better vision splays/ stopping room to motorists? https://www.google.co.uk/maps/@51.7730673,-1.2396435,3a,56.4y,188.18h,85.12t/data=!3m6!1e1!3m4!1sCSZk4LPVkVJecufviv4kzw!2e0!7i13312!8i6656 I believe it's something to do with building regs. Existing posts have to be one of the last items to be decommissioned, usually by newly installed ones. Similar happened on one of the London CS ways, where everyone got their knickers in a twist over it. The fact that a neatly finished cycleway surface now has to be dug up so that the electric supply can be moved to a new location and the lamp pole moved is just another example of the complete waste of money many of these 'improvements' result in? Actually another question is just why the kerb to the footpath and the cycleway had to be moved at all? It no longer lines up with the next section anyway. -- 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
[Talk-GB] How closely do we map lamp posts?
https://www.bbc.co.uk/news/uk-england-oxfordshire-53999106 One does wonder about the competence of builders at times? -- 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] Street-name toids
On 13/08/2020 10:55, SK53 wrote: That was me too, I would have added the USRN if I'd had it immediately accessible. My understanding is that UPRNs do apply to roads, but have much to learn about them. I've added them to a couple of others at Cinderhill which is housing built on open fields so no historical properties there. This is a case of establishing what the UPRN actually relates to in terms of the parcel of land covered by it. There WILL be a UPRN for either the parcel of land, or even for the individual fields, but those will be superseded by the new UPRN's for each of the subdivided parcels in the new development. It is MY take on things that publically adopted roads only have a USRN and the historic UPRN is simply that - an historic record. But I believe ( and stand to be corrected ) that private roads do require a UPRN covering the ownership of the land? The UPRN is in essence the reference to the land registration showing ownership, and it may be today that councils are registering the publically adopted roads as has been seen recently with their claiming ownership of land people thought was part of their gardens but which the council want to sell them ... even where land registry records show a different situation? -- 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] UPRN tag proposal page
On 21/07/2020 12:42, Nick wrote: Hi Lester Rob has suggested a matching USRN tag You make a good point regarding upper and lower case. Perhaps the tag should be ref:GB:UPRN in line with normal convention of referring to UPRN in upper case? I was only thinking about the country code as I've seen both cases used on a number of different countries and I'm used to 'tags are lower case', but in reality these days, USRN and UPRN are the correct case as is GB so yes - if there is no rule on tags being lower case - then ref:GB:UPRN IS the correct format! Nick On 21/07/2020 10:34, Lester Caine wrote: On 20/07/2020 22:11, Rob Nickerson wrote: If there are no red flags I will move for a vote. Looks sensible to me but will there be a matching usrn tag? I see the occasional use of :gb: on other tags and any 'convention' on upper or lower case is possibly an international one, but I'm not sure anything actually says the country code being upper case trumps the convention of tags being lower case? I'm a long time PHP user where the case is agnostic anyway in many cases but again that is not specified here either ... -- 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] UPRN tag proposal page
On 20/07/2020 22:11, Rob Nickerson wrote: If there are no red flags I will move for a vote. Looks sensible to me but will there be a matching usrn tag? I see the occasional use of :gb: on other tags and any 'convention' on upper or lower case is possibly an international one, but I'm not sure anything actually says the country code being upper case trumps the convention of tags being lower case? I'm a long time PHP user where the case is agnostic anyway in many cases but again that is not specified here either ... -- 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] The curious case of USRN 20602512
On 10/07/2020 22:27, Nick wrote: Hi Lester I think there needs to be some thought as to the "proper channel to feed corrections to the 'data officer' responsible". It took me months to get a 'data officer' to correct the location of a single UPRN, so my thought is that this needs to be a 'public' (open) channel that shows a) the number of issues identified (the rationale for making data open) and b) how long it takes for these to be investigated and resolved (if appropriate). TOTALLY AGREE ... local authorities MAY be required by law to provide the data, but they get no funding, and no support to manage that data yet third parties have been making money from it! SO the next step is to document all the mistakes. There should be no assumption that the current data set IS correct, which is why it should be used as a parallel layer and not simply imported over what may well be more accurate data. On 10/07/2020 14:21, Lester Caine wrote: On 10/07/2020 11:27, Mark Goodge wrote: This is, of course, one of the problems with proprietary data. It can be difficult to spot errors, because the people who are most likely to spot errors - members of the general public with local knowledge - tend not to have easy access to the data. Spot on ... The 'proprietary data' is however the input from the relevant officer at the council covering the area. Probably originally tacked on to another job description and someone who probably had no training is this 'new' function? I was receiving NLPG updates for many years and the vast majority of 'updates' were corrections to data rather than additions. The problem has always been not allowing public access to what has always been public data and now we do have access there needs to be a proper channel to feed corrections to the 'data officer' responsible for the relevant slice of raw data. I don't think THAT has changed since the requirements for councils to provided the raw NPLG data passed into law? I'm fairly sure the street data is part of the same legal framework ... ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb -- 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] The curious case of USRN 20602512
On 10/07/2020 11:27, Mark Goodge wrote: This is, of course, one of the problems with proprietary data. It can be difficult to spot errors, because the people who are most likely to spot errors - members of the general public with local knowledge - tend not to have easy access to the data. Spot on ... The 'proprietary data' is however the input from the relevant officer at the council covering the area. Probably originally tacked on to another job description and someone who probably had no training is this 'new' function? I was receiving NLPG updates for many years and the vast majority of 'updates' were corrections to data rather than additions. The problem has always been not allowing public access to what has always been public data and now we do have access there needs to be a proper channel to feed corrections to the 'data officer' responsible for the relevant slice of raw data. I don't think THAT has changed since the requirements for councils to provided the raw NPLG data passed into law? I'm fairly sure the street data is part of the same legal framework ... -- 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] UPRN Locations Map
On 04/07/2020 23:14, Cj Malone wrote: On Sat, 2020-07-04 at 22:24 +0100, Lester Caine wrote: What is needed is a means of adding LAYERS of data which can be managed either via third party data sets, or manual edited using existing tools to add data that is missing from the narrow view confined to 'current' objects ... If I understand you right, I like the idea of this, for example a layer of bus stops in the UK would be sourced from NapTAN. That layer would be kept up to date with NapTAN (most bus stops in OSM are a decade old, unmodified, not validated) and OSM mappers could add corrections/modifications. Potentially we could have a line of communication to NapTAN to inform them of errors in there dataset. It'll be hard to change some peoples minds, but it's worth discussing. That is one example and if editing the data can be carried out using existing tools then new data sets can be created in a similar way. My own tools for handling NLPG data was targeted to allow councils to automatically create update data sets as they create new uprn's or correct existing ones. But my own interest is not so much the independent layers like NapTAN but being able to update current records with historic details such as start_dates which apply to CURRENT objects, but also maintain data that has expired due to end_date. -- 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] UPRN Locations Map
On 04/07/2020 20:33, David Woolley wrote: On 04/07/2020 18:24, Lester Caine wrote: The current 'OHM' is not a layer that can be easily combined with the current 'OSM' layer. Large sections of the current data are simply cloned into OHM I'm not referring to OHM; I'm referring to the main OSM map. At least since September 2012, OSM has the complete back history, and, as far as I can see, you can use overpass API to retrieve the map as of any date and time since then. BUT you can't upgrade the data in that history, only access previous data without any reference to if it is correct or not. OHM is not a solution to add the missing history, or correcting that history which was removed because of mistakes. It is simply a record of what was done with all it's mistakes ... What is needed is a means of adding LAYERS of data which can be managed either via third party data sets, or manual edited using existing tools to add data that is missing from the narrow view confined to 'current' objects ... -- 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] UPRN Locations Map
On 04/07/2020 12:54, David Woolley wrote: At the very least data currently live in on a 'current' view should be automatically filed to an historic layer when it is replaced How does this differ from how OSM already works? You can already create versions of the map at any point in its history, except where data has been redacted for legal reasons. The current 'OHM' is not a layer that can be easily combined with the current 'OSM' layer. Large sections of the current data are simply cloned into OHM anyway. Providing an historic layer which only holds the data that has changed over time AND using the same tools to expand on that historic data as are used to map current data removes another hurdle to maintenance. If third party data such as NLPG can be processed to provide it's data as another layer which can then be combined in the one view then it removes the need to simply import large data sets. One simply uses which set of layers you want ... Of cause the other approach is simply merge all available data ... past, present and future ... into the one humungus database and navigate the problems of maintaining potentially thousands of data sets in sync with the 'master' copy. -- 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] UPRN Locations Map
On 04/07/2020 08:51, Stephen Colebourne wrote: I'm not convinced this data should be pulled into OSM. It would add a lot of clutter that users would be tempted to move around or delete. In areas like mine where I've added thousands of buildings and addresses from surveys, it would be making matters worse not better. It would be a disincentive to adding more buildings with addresses as the additional nodes would get in the way of editing, and because they represent a semi random set of things. Because the dataset is fixed I would think it should be a layer used alongside OSM by those tools that think it adds value. Ideally, OSM itself should support layers, but AFAIK it doesn't. That about sums it up. The plans themselves may be a starting point where there is nothing, but ALL that needs importing are the references being added to existing objects in OSM. As you say, the data in the NLPG data set is 'read only' and so anybody 'editing mistakes' may not understand that it is displaying what is the 'legal' situation on the ground. Any mistakes need to be reported to the right authority. That OSM does not support layers is now a major stumbling block. At the very least data currently live in on a 'current' view should be automatically filed to an historic layer when it is replaced, but with the growing volume of other data sources with detailed graphical content, being able to combine layers of data should be a high priority. There should then be no need to import snapshots of those managed data sets and have to maintain mechanisms to keep the two in sync. Just use the raw data direct in parallel with the unique OSM data. It is worth pointing out that unless something has changed drastically in the last few years, then the range of fine detail contained in the NLPG varies vastly between the various council sources. I think I have seen comments about 'only having a node' and not providing enough detail to identify different references. Certainly 10 years ago only a small number of councils actually had plans of the extent of each council tax parcel and other fine detail. Most just had a node somewhere in the right area. Many were reliant on paid services from OS for map data and so did not have a licence to copy that data over. HOPEFULLY today that particular problem has been resolved. I've not had time yet to look at just what is available against the now somewhat out of data local extracts I have from the original NLPG dataset. -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 10/04/2020 17:37, Brian Prangle wrote: Can I ask two basic daft questions? Perfectly reasonable questions ... What use are these in OSM if we only pick at them instead of importing the lot ( which is highly unlikely)? I'll repeat that we do need to wait and see exactly what will be released, and how comprehensive the data is, but in theory it should be quite possible to cross check a vast range of 'objects' in the database, and more important pick up additions and subtractions of those objects automatically. The comparison is probably with the French property database which I understand has been imported, but I would still prefer to be able to merge third party sources like this with the existing outline in OSM rather than simply importing everything into OSM ... Is it possible to derive street names from USRN in a way that is licence compatible? Exactly the same answer as above, but we know exactly what objects are being handled, and if populated, the exact status of a 'way' can be confirmed. The accuracy is only that of the data sources, but there is a legal requirement for councils to provide updates in timely manor. My feed was 3 monthly, but I think faster updates are now happening at least as new road names are created. -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 10/04/2020 08:04, Jez Nicholson wrote: I don't think they meant 'replace an address with addr:uprn', just enhance it. I was not being as clear as I should have been. A UPRN parcel of land or object includes those for which an address is not appropriate and which 'Royal Mail' would never deliver to so I don't think it is appropriate to merge with the addr: set. I've already indicated that we need to wait and see just what quality of data will be provided, but I ecpevt that some council areas will not actually have postcode in the data. Certainly 15 years ago when I started receiving datasets this was a secondary piece of data yet at that time we were looking to manage the postcode tables for the councils that were providing the UPRN feed! They were not prepared to pay Royal Mail for data that they were legally required to create themselves ... -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 09/04/2020 20:58, nd...@redhazel.co.uk wrote: If uprn is supposed to denote an address, why not simply use addr:uprn? There is no intention that UPRN will replace an address. It will be able to return a unique address but there will be no move to remove that duplicate data from OSM. What the UPRN allows is the addition of external information which is also managed by public services. -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 09/04/2020 15:32, Mark Goodge wrote: So I'd propose that we use either ref:uprn and ref:usrn, or ref:UK:uprn and ref:UK:usrn. What does everyone else think? I'd be happy with either, so long as it's consistent. That is ideal from my point of view ... yes you can get the country by processing the location information, but being able to simply list all of them WITHOUT the overhead of other processing has to be the right way forward? -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 09/04/2020 10:46, Peter Neale via Talk-GB wrote: Hi Lester, Sorry if my post was a bit of a rant. I have a history of having to fight to get IT systems that do the hard work and preventing them demanding that people do the translation into "machine-speak". My rant has always been that postcodes are proprietary data and even in the NLPG data there is a question on if one can use it! The whole thing has always been a mess. Postal Address File I have no problem on being proprietary, just not the postcode on it's own ... Thanks for the explanation. I've had to change most of the references but https://rainbowdigitalmedia.uk/wiki/view/NLPG+Data is now up to date, just again, BS7666 is another chargeable element and my copy is no longer available on-line :( OH and it should be UPRN/USRN nowadays ... my 2006 databases still have the USN field name. -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 03/04/2020 10:15, Peter Neale via Talk-GB wrote: So, will I have to quote a 20-digit alpha-numeric code, if I want to order something from Amazon? ..or get my grandchildren to send me a birthday card? (I do not know what these UPRN's look like, but I bet they are not as easy to remember as "Rose Cottage, 3 Church Lane, XX3 4ZZ") We have to think about human readability and memorability, versus machine computability and we need to be careful not to make the humans do all the work, just to make it easier for the machines. Making me use a PostCode is already making me do some of the work, but at least they are only 6 or 7 characters. The NLPG is intended to provide a single database of all the land in the United Kingdom. Councils have been building this for many years now, and it allows parcels of land that the Post Office do not have any reference to in their Postal Address File to be uniquely identified. Looking up data using Postcodes can be fun but often due to people having the wrong postcode anyway. We can identify the vast majority of residential and business locations using 'building Number'/'Postcode', but additional data is useful to identify that this short form is actually correct, but your council tax or business rates will be charged against the UPRN reference on the council systems. It is not intended to be anything other than a 'machine readable' unique refference ... -- 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] Geospatial Commission to release UPRN/ UPSN identifiers under Open Government Licence
On 09/04/2020 09:19, Tony OSM wrote: Thanks to Andy for highlighting this. If the data is to be in the public domain the next step has to be tagging. As someone who has been using this data internally for clients who are the councils who have been providing it TO the charged for services I'm pleased that now I will not have to worry about linking that data to OSM data. Do we need country specific tags for these two pieces of data? https://wiki.openstreetmap.org/wiki/Key:ref:NPLG:UPRN:1 has existed for a while, but the matching Key:ref:NPLG:UPSN:1 doesn't as yet. Personally I think this style is messy and a GB/UK element would make sense ... and actually identifying that this is United Kingdom related in the wiki page would be helpful! What should they be? Do we need a wiki for them , where? I'll summarise the answers and create a wiki page if someone tells me where to place it - a UK specific page or section? Any traction in creating tools to help populating any new tags? It will be nice to see just what level if data is provided on the public feed when it becomes available. The level and accuracy of the data IS very much dependent on the level of effort that each council puts in, with some providing the full details of the land area described while others only provide a location reference. So there will be some problems producing a 'generic' tool to add UPRN tags to buildings and land plots. USN references should be a lot easier to automatically merge since the street name provided via OS data sets is the same one as used in USPN ... or should be ... Could this be a subject for a discussion as the probably virtual OSM AGM? This is just a United Kingdom discussion currently although as I understand it a few other countries do have something similar so a common country based tag for 'Property Reference' and 'Street Reference' may be a valid subject. But UPRN and USN seem right anyway. -- 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] Adding missing roads using Facebook detections
On 27/03/2020 13:04, Brian Prangle wrote: I echo Richard's comments - best to confine yourselves to new roads in recently constructed residential developments - and even here you need to be careful as on the ground some roads will be service roads and some will be living streets and there will also be gated communities (can you detect gates?). So definitely do not add access tags as these require a ground survey. I would also add that having been FIGHTING the Facebook Places naming process, I do not conciser Facebook as anything like a reliable source of data. I've along with others have given up trying to get the correct CURRENT place names properly referenced and in recent years even when we had got links fixed they have now been rolled back to long out of date references. See the UK Places list on facebook ... https://www.facebook.com/groups/ukplaceseditors/ ... for examples of the problem, although the wiki site which carried all of the reported errors has now been taken down by Facebook :( -- 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 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] 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 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] 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] Is metric or imperial units system used for max weight signs in UK?
On 20/06/2019 16:49, Mateusz Konieczny wrote: According to information that I found UK switched to metric system, at least as far as max weight signs go - with exception of Guernsey that use hundredweight as a unit. Is this correct? Are there still traffic signs using pounds as an unit? I'm fairly sure that weight limit signs are always in tonnes and have a 't' after the weight figure. The regulations certainly refer to 7.5 tonnes as a base for weight restriction for structural reasons and vehicle plated limits are in tonnes. -- 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] How to map new housing?
On 08/03/2019 15:15, Brian Prangle wrote: Whilst being immensely useful, Planning Applications are usually heavily annotated as Copyright, both Crown Copyright and Developer Copyright- so even if the developer gives you permission you're still lumbered with OS encumbrance The site plans may use OS material, but the developers drawings don't and in most cases even OS don't have the new roads and other details so permission to use is all that IS needed. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging post towns and other addressing issues in the UK
On 28/01/2019 18:24, Will Phillips wrote: On 28/01/2019 17:28, Lester Caine wrote: The reality is that for the UK ALL we need is the Postcode to supply a reference to the Royal Mail 'postal address' as that is purely a Royal Mail invention anyway. I personally don't see the need to add 'addr:street' everywhere but that is what people seem to prefer. Adding several more addr: fields to EVERY building is just taking things too far? There are certainly occasions when the street name is needed. For example, I recently surveyed a single postcode (DE72 2HP) containing two houses with the same house name, but different street names. Postcodes do sometimes cover two streets in rural areas. In these cases one might technically be a subsidiary street, but it's often not obvious which one. One could say that DE72 2HP is breaking Royal Mail's own rules, but it is a rare exception to the rule, and often you find the street is actually the secondary build reference rather than the street in the raw data. More generally, if we only included the postcode surely there would often be no way to discover the correct street without referring to closed proprietary data, and a key motivation for adding addresses to OSM is to avoid that. I'm still of a camp that prefers a proper relational dataset rather than 'flat file'. There is no reason we can't have tables of open source data that we reference and a single copy of the details. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging post towns and other addressing issues in the UK
On 28/01/2019 15:31, Tom Hughes wrote: The notion that I should tag addresses in Charlbury with "addr:city=Chipping Norton", a town 6 miles away, just because one private delivery operator[1] uses Chipping Norton as an optional part of their addressing is... one of the more outlandish ideas I've heard in OSM tagging circles, and that's saying a lot. To be fair "addr:city=Chipping Norton" would be outlandish even for an address *in* Chipping Norton... 'city' has always been the wrong title for the field across every system, but it is consistent and as far as I am concerned it is the name of the primary location, be it 'Birmingham', 'Chipping Norton' or 'Saintbury'. It does away with the need to make any decision on the 'size' of the place. That additional places can be added to location to more accurately identify it depends on the application, so addr: may consist of a lot more elements than we currently cater for anyway. The reality is that for the UK ALL we need is the Postcode to supply a reference to the Royal Mail 'postal address' as that is purely a Royal Mail invention anyway. I personally don't see the need to add 'addr:street' everywhere but that is what people seem to prefer. Adding several more addr: fields to EVERY building is just taking things too far? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] How to map houses
On 27/11/2018 11:40, John Aldridge wrote: It would be useful if there was a means of splitting buildings in the editor(s). I'm probably in a minority here, but since the mapper usually can't tell how the building is divided internally, it's more honest to leave the building undivided and put the housenumber etc. tags on nodes on the building boundary which represent the front doors. I also think this is more useful to someone using the map, as it shows where to find the doorbell! My source material has all the house divisions and we could even include the internal floorplans, but where we have a block of houses being able to quickly draw an outline and then create several objects with the same set of tags is easier than trying to manually create each linked element of the building. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] How to map houses
On 27/11/2018 08:47, Ed Loach wrote: 'We expect this "interpolation way" to be a temporary construct. In the long run, OSM will have every single house mapped as a building outline, and every single house will be tagged with its house number, so that interpolation ways will gradually vanish. However they are good to make a quick start with house numbers, and reportedly there's existing data waiting to be imported that will also require interpolation.' It would be useful if there was a means of splitting buildings in the editor(s). Even for semi-detached houses, being able to create two objects from the one original outline would be helpful. A terrace of houses just needs to identify how many new objects to create. Where I have been adding buildings this has been the irritation. Mirror would also be useful although architects seem to like making changes between the two halves of a semi these days. But draw one half with all it's tags then mirror to create the other half, and just edit the house number. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Network tag on railway stations
On 17/11/2018 17:26, Colin Smale wrote: Surely the infrastructure network is a different concept to the train network? The UK overland railway network is managed and owned by network rail. How about this for a thought: For the trains, a network might be linked to a brand; An operator may have distinct branding for commuter services, intercity services and freight operations giving three different "networks." All the services within a network will be integrated in terms of scheduling and other planning, whereas coordination with other networks is a whole different can of worms. If there is just one big team doing the planning, then it's one network. If the planning is done reasonably autonomously, then they are different networks. All investment in the overland rail structure is via Network Rail Is "London Overground" a separate "network" to the Underground? Is the DLR a separate network? Instinctively I would say yes to both of these, from both a train service point of view and from an infrastructure point of view. Pleased to hear arguments to the contrary though. There are other networks such as the such as Midland Metro, Dockland Light Railway and London Underground as well as other metro/tram networks. These tend to be owned and run by local transport authorities. Transport for West Midlands for Midlands Metro and TFL Transport for London for DLR and London Underground. These manage both the rolling stock and the tracks while Network Rail does not actually own any rolling stock - as far as I am aware - except perhaps for maintenance vehicles, although I would not be surprised if the maintenance companies owned them! So DLT has a network=Transport for London and an operator=Transport for London ... in my book. The other metro lines are similarly owned and operated. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Network tag on railway stations
On 17/11/2018 14:46, David Woolley wrote: On 17/11/18 14:36, Lester Caine wrote: Who operates the station, and who operates on each line accessing that station. The various ID's would help keep this data up to date. You need to distinguish between operating the line and operating services over that line. On the lines ... network='operating the line' operator='operating services over that line' Stations will also have operator='station services' I think 'National Rail' does not fit either of those definitions? So network=Network Rail ... or one of the Metro services? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Network tag on railway stations
On 17/11/2018 10:02, Tony Shield wrote: Ormskirk is a good case where Merseyrail manage the station - essentially the operator in OSM parlance. I picked Ormskirk is it is the terminus for both Merseyrail and Northern services on that line. They terminate here as the Merseyrail line is electric and the Northern line is still served by diesel trains. I'm not sure today, but certainly originally the break was simply a buffer placed on the line ( must be 45 years sinse I was there last ;) ) which could be removed at some point to restore through running. Hence the suggestion that the line north be tagged with the operator=Northern, but as Michael suggested there may well be a case for multiple operator tags on the lines. There is a good catalogue of data on the rail system, but I'm not sure it's all suitable to be used. It would be nice to see a 'UK' guide to tagging which covers all the options. Who operates the station, and who operates on each line accessing that station. The various ID's would help keep this data up to date. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Network tag on railway stations
On 17/11/2018 07:12, SK53 wrote: I've just come across a large number of instances of network=Nation Rail on stations. Clearly this is a mistake, presumably National Rail is intended. As the station concerned is heavily branded with Merseyrail my first instinct was to change the tag to this, but then I wondered if National Rail is more useful. Today a network=Merseyrail would be more useful to me because I have a day rover for that network. I wonder what others think, and can we clean up the erroneous name? Merseyrail is the operator rather than the network. The network is owned and managed by Network Rail. National Rail is simply a club of operating companies and includes both Network Rail and Merseyrail. So every station should have an operator=xxx and network=Network Rail, but they should also have some tag to the other train operators using the network through the station if more than 'National Railway' member is using it. So Ormskirk Station (https://www.openstreetmap.org/way/86878104#map=19/53.56928/-2.88114) for example needs an operator=merseyrail and *I* would prefer network=Network Rail. The line north should be tagged operator=Northern which would at least associate that fact with the station, but other stations may have more than one train operator using the track. Network Rail and National Rail is probably interchangable in the public mind, but freight services use the track and is not covered by National Rail, but it's unlike that stations like Ormskirk would have that problem ;) -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 20/09/2018 19:44, Mark Goodge wrote: Then get involved and put it in OHM. I was involved, but the current OHM development is not going in a way that works well with OSM so I gave up. I'd rather mirror OSM directly and add my historic material to that local copy! Which is what I'm doing currently ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 20/09/2018 17:50, Mark Goodge wrote: In fact, putting them in OSM isn't just damaging to OSM, it's damaging to OHM. At the moment, OHM is a bit sparse, there are some well-mapped areas but there are some pretty big blank areas. What it really needs is a group of enthusiastic contributors, who are knowledgeable about history and want to see it mapped. Putting the historic counties into OHM would be a huge boost for it, it would make OHM much more useful for genealogists, fans of listed buildings, ancient monuments, old railways, etc. And there are plenty of those. That in turn would drive more users of OHM, and more contributors, thus helping to make it even more useful. Until OHM has all of the current history available in parallel with 'extra' data it's not worth spending any time on. I want to see where historic changes fit around the current state on the ground so I work off OSM ... and will until all that data is available in OHM ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 20/09/2018 07:24, Frederik Ramm wrote: Surely your argument which seems to be based on the romantic "Rutland that people feel in their hearts" could not be applied as a reason to store "Rutland County Council District Council in the borders of 1997", plus "Rutland County Council District Council in the borders of 1999", and also "Rutland County Council District Council in the borders of 2003"...? That people have a desire to view this data is a simple fact. Had the 1997 boundary been drawn at that time, and then update to '1999' and subsequently to '2003' means that this data would have been in the database and as others keep pointing out would be accessible by looking at the change logs. The next changes will also be logged the same way, but ACCESSING the historic views is not an easy process? The current 'process' dictates that OHM should take over the job of displaying the older versions but there is currently no easy way to carry out that process, and these 'special cases' then have to exist in parallel across both databases. So is there not a good reason to start processing 'start_date' and 'end_date' properly so that an object CAN exist in different configurations over time. Material which has an 'end_date' is ignored by any 'current map' processes in which case a 'special case' historic element would be named as such and not have an end_date ... Current data will become superseded, and one is then adding the new version, but the old version is still valid data and needs to be handled better than it is currently. If the process is managed properly then adding additional historic data should not be a problem since the vast majority of that data will simply be a 'start_date' for objects that ARE current in the database! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] un-named roads in UK
On 29/08/18 21:21, Jubal Harpster wrote: Stadium Mews https://www.openstreetmap.org/way/260127900 https://goo.gl/maps/JJNxamCgLy12 _https://binged.it/2C0LAw1_ PAF file ... N5 1FP -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 16/08/18 14:24, Dave F wrote: A contributor has been reverting my changesets over the past few days: https://www.openstreetmap.org/user/tms13/history#map=7/56.741/-4.252 https://www.openstreetmap.org/changeset/61655207 https://www.openstreetmap.org/changeset/61623830#map=11/56.4828/-3.2425 As I don't wish to get into an edit war & believe blocking is a last resort, would it be possible if a couple of others attempt to help him understand the reasons. On what basis is 'highway_authority_ref' being put forward since I don't think the councils who allocate the references for C and U roads are actually the 'highway_authority' but are responsible for those roads NOT designated as the responsibility of the 'highway_authority' ... at least that is my reading of the situation. These references are 'local_authority_ref' and are not unique from one part of the country to another while 'highway_authority_ref' suggests a more central management? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 08/08/18 17:03, Nick Whitelegg wrote: I think these things are at least partly a product of what generation you belong to. I think one can include 'Middlesex' in that package? Just when will it cease to exist ;) -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 08/08/18 13:54, Colin Smale wrote: There are plenty of examples of "former" objects in OSM - closed pubs, railway alignments etc. They are only still there because they are perceived to have some kind of relevance in the present day. Can a case be made that these historic counties are still "relevant" today? I'm listening to the steam trains pulling in and out of Broadway station at the moment. This was a 'disused' line and there was talk about removing that sort of data from OSM. The line out of Broadway goes on north and still has a designated use of 'disused railway'. I don't know if the line will ever be extended, but in some peoples minds it's on the cards as it could eventually link to Stratford Upon Avon. That end of the line has now been built on so a new terminus would have to stop short, but knowing where the line used to run through that house estate is interesting to some. Even a pub has a place in the tracking of genealogical data and if one has some means of showing a current map with the location of previous events it's a useful tool. OHM is trying to do that, but since every change in OSM has to be mirrored to OHM I find this very counter productive ... YES there is a need for separate layers of data such as the battles of the second world war, but all should have a single base in OSM and where key parts of the two combine, the current OSM map continues to display them. Purely using OSM data to show the development of a town over time potentially needs very little 'historic' data other then 'start_date' ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 08/08/18 12:59, Dave F wrote: How often do you believe people will actually want historic data? Organizations archive for a reason. Consider your house, how things you don't use will get shoved to the back of the cupboard/shed. I live in a Roman city, the editors struggle to display current data. Imagine what it would be like if *everything* was shown back to the days of Emperor Nero. We have the same problem all over the place in keeping historic data accessible. The argument is always 'How many people will use it' or 'Does it matter if we ignore that' :( Even providing verifiable timestamps for historic events is a gamble since the timezone database hides verified data prior to 1970 'because it's outside the remit'! In which case one needs a reliable source for time offsets even as recently as the 2nd world war because those provided by TZ are known to be wrong ... but nobody provides it :( The fact that there was Roman settlement in an area is very useful data for a planning department to know if a full archaeological report is needed. My own genealogical research would be helped if CURRENT data had a start_date and then one could see if a street being referenced actually existed at the time ... that is one for OSM rather than OHM except the street may have been 'moved' or renamed, at which time the historic element may become important. And knowing if the street on the current map was in a different county is also important data. But where do you go to find out. There is no clear distinction as to what is current and what is historic data. They intertwine and a single documented view of all the data including that which is becoming history on a daily basis should be the target, rather than saying 'It's too difficult so lets ignore it'. It's not difficult for a computer to manage and if people have the desire to start filling in all the gaps then they should be supported, not told to go away? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 08/08/18 11:49, David Woolley wrote: I think people are overlooking the original use case for suppressing C references, which was that they confused satellite navigator users. As I pointed out before, this is really an attribute of the particular turn onto the road, not the road itself. The fact that a road (A, B, or C) may have its reference displayed somewhere along it is not going to help if someone approaching the turn cannot easily see that reference. That is little different to being told to 'turn right into "this" road' where most of the time one can't see a road name. It is perhaps a matter of identifying just which turns have a visible sign and which do not, and that can often apply even to A roads? But even if there is no signage, giving some road details is better than a simple 'turn right'? Many of main link roads around here don't have names or numbers displayed, but one still use them to avoid several miles of 'detour' via primary roads because the sat nav does no accept them as a 'fast route'. OSMAnd is a sod for that problem :( -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 08/08/18 10:56, Dave F wrote: On 08/08/2018 09:54, Lester Caine wrote: we are now in a situation where much accurately mapped material is simply dumped when there is a change to the current situation. 1. it's not dumped, it's still in the database as a historic version. 2. Changes almost always increase the accuracy & detail of the database. Going back through the change logs is not the easiest process? Isolating deletions that are due to historic changes rather than simple factual corrections also muddies the water. But making the link to OHM more organised would allow current valid data to be archived properly? The 'delete' process should be handled in a manor more sensitive to the hard work that has gone before! the vast majority of the material making up the historic data such as boundaries IS the same as the current 'live' data. I'm unsure that's true, but if it were, why duplicate? That was always my argument AGAINST OHM ... since much of the data making up boundaries has not changed, having to duplicate that information over to OHM, and then decide where material is current or historic means that IDEALLY OHM is a complete copy of the OSM database, but with the historic material easier to find than via change sets ... why not just manage a single database? People who don't want access to historic material simply ignore data which has 'expired' via end_date. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'historic' county boundaries added to the database
On 07/08/18 20:48, Dave F wrote: User smb1001 is currently adding county boundary relations with boundary=historic through out the UK: http://overpass-turbo.eu/s/ASf (May take a while to run) Changeset discussion: https://www.openstreetmap.org/changeset/61410203 From the historic wiki page "historic objects should not be mapped as it is outside of scope of OSM" Frankly I don't buy his comments. The problem is where to stop? Do we have ever iteration of every boundary change since time immemorial? Then what about buildings, roads, or coastline changes etc? The database would become unmanageable for editors (it already is if zoomed out too far). I think these edits should be revoked. They should be moved to OHM but then ANY information that is superseded should be automatically archived to SOMETHING since we are now in a situation where much accurately mapped material is simply dumped when there is a change to the current situation. The 'delete' process should be handled in a manor more sensitive to the hard work that has gone before! I have always disagreed that 'historic changes have no place in the database', since the vast majority of the material making up the historic data such as boundaries IS the same as the current 'live' data. Simply not downloading data that has a prior end date does not make anything 'unmanageable', in fact it makes life a hell of a lot easier since one can simply tag a section of the boundary as 'end_date=xxx' and add a new section with the boundary change as 'start_date=xxx'. The ONLY question is what happens to the data once it has an end date ... which may be some time in the future ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 08/08/18 08:30, Andy Townsend wrote: There are combinations that aren't handled perfectly (especially where roads have a mixture of different refs) and I'll look at some of these edge cases later. Hopefully though as things stand it's useful to people who really want to see these "official" refs. I think this is part of the 'UK' problem. While some reference numbers are not displayed 'on the ground', increasingly they ARE being used in official announcements such as accident reports, road closures, planning applications and the like so that the relevant authorities know they are talking about the same stretch of road, but that does not help us 'mere mortals' unless someone actually publishes a map to show the situation on the ground. That OSM IS in a position to fill this hole where often even the official maps do not because OS does not provide a rendering using them is just another plus for OSM. But I have no problem accepting that this should be on a UK specific map rather than something dumbed down for the whole world ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'D' class roads references.
On 06/08/18 08:37, Robert Whittaker (OSM lists) wrote: On 5 August 2018 at 19:50, David Woolley wrote: The only place for which I am aware of national legislation making certain government publications automatically free to use is the USA. Thanks to the EU, we do however have the "Re-Use of Public Sector Information Regulations 2015" http://www.legislation.gov.uk/uksi/2015/1415/contents/made . You have to ask for permission, but if the copyright is owned by a UK public body, they need a very good reason not to allow re-use under an open licence, and the options for charging are very limited for most bodies. That I think is the one that restricting access to both the NSG and NLPG falls fowl off, especially when councils are required by law to provide it but not paid to do so. Once we can freely use at least the National Street Gazetteer many of the 'problems' go away and we just need to add the USRN reference to each way in the UK -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'D' class roads references.
On 05/08/18 14:44, Richard Fairhurst wrote: Rob Nickerson wrote: Dave can you do the D class roads too. Someone has added these - e.g:https://www.openstreetmap.org/#map=18/52.21554/-1.87663 And D designations will be reused in other areas ... I have seen a couple more D5383 such as D5383, Johns Road, Bugbrooke but possibly not in OSM ... these designations ARE used in publicly published reports. That reminds me - there's some weird ones in Hillingdon too: https://www.openstreetmap.org/#map=15/51.5603/-0.3943 https://www.hillingdon.gov.uk/media/28177/List-of-classified-roads/pdf/JW-LIST_OF_CLASSIFIED_ROADS.pdf is probably the source of those designations ... Can anyone think of a location in mainland GB where tertiary/unclassified/residential roads_should_ have a (non-A/B[1]) ref? Milton Keynes has its (signposted) H and V numbers for Horizontal/Vertical, but other than that I can't remember any. Interestingly, from the guidelines ... C road – another term for a classified unnumbered road. Any numbering system around C roads is peculiar to the authority and is not coordinated on a national basis; as a result, we advise that it is not displayed. D road – another term for an unclassified road. Any numbering system around D roads is peculiar to the authority and is not coordinated on a national basis; as a result, we advise that it is not displayed. So we end up with data that should not be displayed ... but is still valid data in terms of the database! -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 04/08/18 10:07, Philip Barnes wrote: It seems to me that, in the UK, class C roads should be exactly the set of roads with highway=tertiary, so there is no need for a new tag. Even if that is not true, the correct solution would be to test the reference in the renderer and suppress it if within the UK. That really is not a pratical solution, OSM is an Internaional project and the standatrd renderer is International. It is unreasonable to expect the hard working rendering team to support country specific rendering. As I said previously, if you want to see C road references rendered, make your own renderer. Not many countries seem to have 'highway=tertiary' but those that do expect them to be rendered, and any reference they use should be rendered with them? This is not simply a 'UK' question, but one on how generic 'ref' tags are handled, and as I said ... 'highway=secondary' references can suffer from the same problem of not actually being displayed on the ground. So how the renderers handle this element is a world wide problem, and perhaps 'display_ref=no' would be appropriate in some areas of the world? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 04/08/18 10:02, David Woolley wrote: On 04/08/18 07:01, Philip Barnes wrote: The renderer cannot know not to render refs on C roads in the UK, remember osm is an international database. Telling a driver to turn left onto the C666 is confusing if there is no sign to back up that instruction. Routing type renderers need to know that a road is in the UK and handle it accordingly, because a lot of tagging has to be interpreted in the context of national legislation. And it would be nice if they also respected the national speed limits! Osmand needs every 'max speed' to get it to display 60 or 70 as appropriate :( And I WILL get around to adding a UK rendering of road colours sometime ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 'C' class roads references.
On 04/08/18 07:01, Philip Barnes wrote: If you want to produce a render to display these admin references then you are welcome to do so. We ideally need a proper UK rendering of data and this is another area where information IDEALLY needs to be selectable. Trying to make a single world wide rendering of the data is always going to fail given the volume of material that is now country specific. The 'C' and other paper references need to be attached to relevant way and it's somewhat academic how as I can give you many examples where the 'B' references are similarly not actually displayed on the ground! Should they be tagged using some 'hide' tag? 'ref' is the correct tag for the way's reference number ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Toys R Us
On 05/05/18 23:41, Rob Nickerson wrote: If an old sign still exists then this should be mapped *as a sign* not as a shop. With a number of other closures around here, premisses are remaining empty for a LONG time, and with no one taking over the buildings remain as they were, just not open. If I am using the map to navigate, and the place I want is 'around the back of X' then the building X is what I am looking for. UNTIL the building identity changes to some new use it should be mapped as it appears. If the signage is taken down then rather than 'shop-closed-ToyRUs' it should change to 'shop-closed' but I don't see much movement on signage being taken down on other closed businesses? So we maintain the accurate mapping ... and map what is seen. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Quarterly Project: Post Offices
On 04/05/18 14:41, Steve Doerr wrote: On 04/05/2018 12:52, Lester Caine wrote: it's not helped when postoffice.co.uk don't list the independent post offices in there search results! According to them Broadway does not have a post office ;) It comes up for me at Russell Square, Back Lane, Broadway, Worcestershire, WR12 7AP. I searched on that postcode. Or is there another Broadway? OK is google that gets it wrong ;) https://www.google.com/search?q=post+office+near+me only shows the post office owned ones. But the information on the branch search - when you find it (needs the worcs) - is at odds with the times on the Budgen's website which I know are correct but the magic time one needs to know is 5:15 as the latest time for collection today is not shown anywhere :) Only https://www.warnersbudgens.co.uk/post-offices/broadway.php shows the out of hours services ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Quarterly Project: Post Offices
On 04/05/18 12:28, Robert Whittaker (OSM lists) wrote: Or do people think we should use amenity=post_office for them with some other tagging used to differentiate things? If we did want to use other tagging to differentiate, then operator=* wouldn't work, as most Post Office branches are run by third parties. network=* or brand=* could do, but it would be complicated to use either on objects which are tagged with both amenity=post_office and e.g. shop=convenience, since we wouldn't know which part the tags were referring to. Our local post office is now situated in a local supermarket while the main postbox is still located outside it's previous home. Post Office hours are shorter than the opening for the shop although some services are available full time which adds to the fun tagging it. In addition two other local shops are drop-off points for other other carriers with one also a collection point for held deliveries. The published details for some of these service points is already wrong but trying to add a comprehensive set of tags covering everything is I think wishfull thinking? Especially when the shop handles several courier services? This is an area where secondary databases should be linked to provide the fine detail and just a generic tag with an ID to access that data. Trying to map all the secondary data is silly, but it's not helped when postoffice.co.uk don't list the independent post offices in there search results! According to them Broadway does not have a post office ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Petrol stations again
On 09/03/18 20:19, Philip Barnes wrote: Leicester Forest East looks a bit confused, it is down to both modify a Shell node and to add a BP node. It can't be both. I will try to check what brand it really is. It's a Welcome Break, so Shell ... at least it was last time I passed. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 01/02/18 08:58, Robert Whittaker (OSM lists) wrote: On 31 January 2018 at 11:13, Will Phillips<wp4...@gmail.com> wrote: I favour using addr:parentstreet rather than addr:substreet for the following reasons: +1 Which also then needs addr:street ON the addr:parentstreet as using postal_code has the same problem of matching ... OR is that only to be used on the buildings ON the substreet ? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 31/01/18 09:07, Mark Goodge wrote: On 27/01/2018 20:09, Robert Whittaker (OSM lists) wrote: Secondly, some addresses contain two street names, a main street and a so-called "dependent street". Apart from the historic anomalies, a single postcode should only cover one main street, but can include more than one dependent street. These are actually quite common, and having had a look at the error list for my local area nearly all of them are due to this - the address is on secondary street accessed from the main street with which it shares a postcode. Here's one, for example: https://www.openstreetmap.org/way/304095650 (The tool will not see the dependent streets as different if both streets are tagged, either as addr:substreet and addr:street or as addr:street and addr:parentstreet.) Which is the more correct usage here? Do we a) tag the dependent street as the addr:street, and the main street as addr:parentstreet, or should we b) (following Royal Mail practice as found in the PAF), tag the dependent street as a addr:substreet and the main street as addr:street? My personal preference would be the latter, it's not only consistent with official addressing practice but it's also how most people perceive these kind of addresses as well. But, on the other hand, most map editors are likely to use addr:street for the dependent street, simply because the editor UI doesn't make it obvious that addr:substreet is a possibility. So it might be simpler to fix these by adding addr:parentstreet as necessary rather than trying to get everything pedantically correct. I've the same problem on a number of cases and certainly addr:parentstreet is just wrong ... the sub street is actually part of the house detail rather than the street, so similar to 'Flat 1 Block of Flats' ' Street' but this still leaves the 'addr:street' or 'postal_code' question for the tag on the primary street. Having SOME of these tagged 'addr:parentstreet' is simply wrong ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 30/01/18 15:04, Robert Whittaker (OSM lists) wrote: Sorry about that -- it was a bug in my code -- which I think I've fixed now. Have another look at http://robert.mathmos.net/osm/addresses/street-warnings/WR.html -- there's a lot more moved to the highways section now. That is looking a lot more sensible. On my todo list, only the entries on the highways section with different names need work. I am going to leave postcode on addr:postcode and I'll start working through the WR stuff with missing street names, but the other 'errors' look a lot easier to handle as they are just spelling and secondary street names. We just need to agree how to tag all the highway stuff to wipe them from the list? I do appreciate the work you are doing ... I've been wasting more and more time on simply keeping machines working, with all the crap on windows machines being chased hard on the tail by similar ones on my main Linux machines. Having rolled back to SUSE LEAP42.3 on the main machine I've got a browser that works again with potlatch2 and a JOSM setup that is working, along with the main development platforms for the day job. PERHAPS now I can actually get some new work done in several areas ... I've even got all 4 screens running cleanly for the first time in years so I can keep multiple views open while cross checking things. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 30/01/18 10:14, Robert Whittaker (OSM lists) wrote: (There weren't nearly as many objects in case 2 as I thought there would be here based on people's comments, so it's possible I've messed up the programming logic somewhere. If there are still any objects with a highway=* tag listed in other sections, then please let me know, and I'll see if I can fix the bug.) http://www.openstreetmap.org/way/4298681 is now listed in 'highways with postcodes' for WR12 7EP, but my next road which is tagged the same way https://www.openstreetmap.org/way/4299405 is under 'Street Name Mismatches in Postcode Unit' but has the same name in both columns, so I don't see what the problem is ... A large number of WR12 7** postcodes are correct as far as MY checks show. WR12 7JJ, WR12 7PH, WR12 7PP ... WR12 7PJ has snagged a bus stop node ... One source of questions is the addition of addr:postcode to bus stops. https://www.openstreetmap.org/node/799223204 for example seems just wrong as it's now where near the WR12 7HP road and a quick check on local bus routes shows none stopping there anyway ... AH looks like the bus stop is now in the wrong place ... buses go down WR12 7HP now. But you can see the problem that adding postcodes to objects that don't have postal addresses seems strange except if one is tagging for routing :( Other nodes are also throwing up questions such as http://www.openstreetmap.org/node/3383359238 ...OK - WR14 3LT and WR14 3LY are getting confused by the ' which is not on the PAF file or on the Worcestershire Hub listing ... but is on google maps :) But I would repeat that while 'Code-Point Open' provides a list of valid postcodes, it can't be used to check the street names, so adding the postcode to the street seems to be the right thing to do. The only question is if t should be addr:postcode and combined with other addr: elements for 'place' or simply 'postal_code' ... I can accept the second if the guide is also to omit other addr: elements from the street tagging ... use of addr:place, addr:location and the like cries out for addr:postcode ... 'postal_code' pairs up with 'is_in' which is something else that does not work well? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Help remembering how to ...
On 29/01/18 21:22, Lester Caine wrote: It has been a while and my notes and crib sheets seem to be messed up. Have JOSM running with ImportImagePlugin and I have a tif file with a 28 pixel per meter scale, and the lat and long for the top left corner, but I'm obviously not putting the right numbers in the world file which I have done in the past and fine tuned position once loaded so has something changed, or have I just got the wrong data. I'm fairly sure I also had a Linux program that helped me play with the values but having brain freeze at the moment ... First problem solved ... it's PicLayer plugin ... and then I can tweak the config files ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Help remembering how to ...
It has been a while and my notes and crib sheets seem to be messed up. Have JOSM running with ImportImagePlugin and I have a tif file with a 28 pixel per meter scale, and the lat and long for the top left corner, but I'm obviously not putting the right numbers in the world file which I have done in the past and fine tuned position once loaded so has something changed, or have I just got the wrong data. I'm fairly sure I also had a Linux program that helped me play with the values but having brain freeze at the moment ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 29/01/18 13:27, Ed Loach wrote: All that is left to be sorted out is should all the current addr:postcode entries logged against the street ways be replaced with postal_code My suggestion is don't worry about it. Data consumers can easily check for both, and as soon as the actual addresses be mapped the tag (whichever) should be removed from the road anyway. In fact most data consumers are more likely to use CodePoint Open as a more complete dataset anyway. Certainly most of the 'mistakes' I've looked at to reduce the totals on 'WR' have not thrown up things that actually want changing! Personally however my own list of UK postcodes is based on the street elements of OSM so as NOT to be reliant on codepoint which does not supply freely usable street names? So being able to simply list 'highway' with 'addr:postcode' is an unrestricted data source. If that now has to be changed to or mixed with 'postal_code' then so be it, but 'don't worry' is not the right answer when one IS trying to tidy well defined data sets. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
(Send to pigging list ...) On 29/01/18 11:58, David Woolley wrote: On 29/01/18 11:36, Robert Whittaker (OSM lists) wrote: My understanding is that addr:postcode should be used only as part of an address. So if you want to put a postcode on a street (or part of a As I understand it, postal_code, in a UK context is for the outbound code, only, and is most useful in certain cities, where street name have the outbound code appended, on the name sign. On the other hand, sticking the full post code on a road is wrong, because it implies that everything on that road has that post code, which is not necessarily true, even for short roads, if there is a big user. For bigger roads, odd and even numbers may have different codes, and you cannot normally split the road at the right place without doing a house to house survey of the codes. UK post codes are based on the postmans walk, so follow the footpaths that a postman can follow to deliver mail. Yes a street may have a different postcode on each side, and long roads are broken down into smaller blocks each with it's own postcode. One rule for postcodes is that each will only cover one primary street name and so ignoring the 'postal address file', postcodes ARE essentially a list of streets. Two new estates are going up either side of here and both currently have plot numbers for selling the houses, but they will be replaced with new road names and house numbers which the council will allocate, and then the post office will add new postcodes to those new road names. All that is left to be sorted out is should all the current addr:postcode entries logged against the street ways be replaced with postal_code ... that should probably have been used originally, bu this material is ONLY relevant to the addr: group of tags ... except most sat nav's these days understand a postcode better than a street name. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 29/01/18 09:27, Robert Whittaker (OSM lists) wrote: So it ignores a simple 'name' ? which is why a lot of my streets are getting tagged as wrong? I don't see any reason to have to add addr:street= when the road already has name= ... The adjacent building use addr:street= ... You're right that it doesn't look at the name=* key (except on associatedStreet relations). But that shouldn't be a problem, as the tool is only checking objects with an addr:postcode=* tag -- which should be houses and other addressable premises, not the roads/streets themselves. Sorry if that wasn't clear in my original post. (There's currently no check that the values in addr:street=* on premises match the name=* any mapped highway=* nearby.) If you're not sure what's causing anything that's flagged by the tool, let me know know the postcode(s) and I'll take a look. So you are saying that the postcode should be removed from the street to fix your listings? I would prefer things the other way around and always have. The street and associated data does not need duplicating on every house if there is a matching street with the same addr:postcode ... but I think that boat has sailed ... However I see no reason to remove the addr:postcode from the street especially where routing to the property can take you to the wrong street where the building is closer to another road but has no access from it. So I'm not going to remove valid tagging ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Errors in Street Names in Addresses
On 27/01/18 20:09, Robert Whittaker (OSM lists) wrote: [1] Due to the way addresses are recorded in OSM, and the formatting of UK addresses by Royal Mail (see also [3] below), the "Street Name" for an object is picked up by the tool from a variety of tags. Currently it uses the following, in order of precedence: the addr:place tag, the addr:parentstreet tag, the addr:street tag, the name tag on associatedStreet relation if present, and the addr:locality tag So it ignores a simple 'name' ? which is why a lot of my streets are getting tagged as wrong? I don't see any reason to have to add addr:street= when the road already has name= ... The adjacent building use addr:street= ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing Shell fuel stations
Get the return address right ... On 28/12/17 16:12, Colin Spiller wrote: > I've been adding postcodes in the Bradford BD area using Robert & gregrs > useful tools. I've just noticed that the Shell station at the Rooley > Lane / Rooley Avenue junction BD5 8JR is now reported as having an > incorrect postal unit (the final two letters of the postcode). This > postcode appears widely on the internet for this site, but the RM > postcode finder thinks it should be Rooley Avenue, BD6 1DA. PAF file has ... Shell Filling Station Rooley Avenue BRADFORD BD6 1DA and BD5 8JR is not listed having been deleted in 2009 http://checkmypostcode.uk/bd58jr so the real problem is does one leave the faulty postcode in place because we can't use the PAF data or do we validate postcodes against the codepoint database and remove those that are not listed > The node Fuel #5210358416 <http://www.openstreetmap.org/node/5210358416> > has these tags: > > > Tags > > addr:postcode > <http://wiki.openstreetmap.org/wiki/Key:addr:postcode?uselang=en-GB> > BD5 8JR > amenity <http://wiki.openstreetmap.org/wiki/Key:amenity?uselang=en-GB> > fuel <http://wiki.openstreetmap.org/wiki/Tag:amenity=fuel?uselang=en-GB> > brand <http://wiki.openstreetmap.org/wiki/Key:brand?uselang=en-GB>Shell > opening_hours > <http://wiki.openstreetmap.org/wiki/Key:opening%20hours?uselang=en-GB> > 24/7 > phone <http://wiki.openstreetmap.org/wiki/Key:phone?uselang=en-GB>+44 > 1274 306188 <tel:+441274306188> > ref:navads_shell NVDS353-12038573 > > > but no street or city. The whole thing seems odd to me. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing Shell fuel stations
On 16/11/17 12:48, Robert Whittaker (OSM lists) wrote: >> Here's a strawman to start the discussion: >> >> Use Harry Wood's improved visualisation as a progress checker, with a colour >> change for missing filling stations to red >> Get active mappers to add/amend data around their localities or journeys >> Change marker colour for filling stations that are "complete" with Shell >> data where it is correct to green >> Watch the map turn green as we make progress > That sounds good to me. The one issue I have with the import though is > the reference numbers being proposed. As I think someone already noted > in the previous discussion, these seem to belong to the third-party > rather than being an official branch number assigned by Shell. Anybody asked Spar if we can use THEIR list of 1054 forecourts to add even more detail to this. Certainly many Shell and BP forecourts are owned and run by Spar and not Shell or BP ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The OSM UK map
On 15/11/17 07:48, Adam Snape wrote: > Most map users don't understand the distinction between primary (green) > and non-primary (red) A-roads so I understand why not all maps use it. > Since OSM makes this distinction anyway it makes sense to use the > standard uk green/red colour scheme in the UK map. I keep looking at OSMAND and thinking ... I must look at what is needed for a UK road theme there we have American and German! Vector display really is the way forward then one can select the right default for any area. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing Shell fuel stations
On 03/11/17 11:20, Richard Fairhurst wrote: > Ashton-under-Hill (postcode WR11 7QP, near Lester ;) ) is weird too - the > addr:street is proposed to be changed to 'A46', which isn't a street name, > it's a ref. Actually Spar list it as Vale Service Station , A46 Ashton Under Hill but it is really Cheltenham Road. All needs a bit of an update as the Transport Cafe has been closed for a while and the lorry park is closed off. But like many 'Shell' stations, it is operated by a third party, not by Shell. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The OSM UK map
On 30/10/17 11:32, David Woolley wrote: > On 30/10/17 10:37, Lester Caine wrote: >> What >> I'm looking at here is reports of fly tipping, dog mess, and so on;) > > <https://osm.fixmystreet.com/around?latitude=52.949211;longitude=-1.14391=1> > > However, note that some councils are insisting that only their own web > site be used to report problems, and no longer accept email (unless > there is a partnership with FMS, email is how the reports are presented > - one of the reasons is that councils want very structured reports, but > FMS is designed for free format reports). Yep ... fixmystreet is not working with the right authorities and is a pain to find the right location anyway. Looking to overlay the website location map with the sort of facilities a parish council looks after. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] The OSM UK map
On 30/10/17 08:58, Nick Whitelegg wrote: > As you may know, the plan is to produce a UK specific OSM mapping site. > A start on this has been made here: > > http://www.free-map.org.uk/osmuk/ > The test site covers Hampshire only due to server constraints. It would perhaps be useful to have a 'cloud' of servers which can provide high resolution layers around the country with a secondary facility for specialist layers. > - website_real - the coding behind the website (JavaScript; plan is to > use PHP server side) That is where I am currently 'stuck' ;) I'm looking to provide secondary layers specific to my client websites and all of that code is in PHP with Javascript browser side. > Would also be good to see a few suggestions for features. A few of mine; > on the cartography side: > - add contours (I have done this on Freemap so I should be able to > figure out this) A secondary layer of contours should just be an implementation exercise? The info is already available ... > - Landranger-style rendering? Any other preferences? One of the problems I've been fighting is the 'standard' UK road colours. Need the green truck roads back as this helps identify who is responsible for maintenance. ( or at least it used to ;) ) > - permissive paths need showing; Andy's cartography does not yet do this > but again this is something I have experience with. Providing UK councils with a generic tool with cross boarder display of right of way may help bring them on board. > On the features side (walking oriented most of mine): > - click on POIs to get information about them, e.g. links to Wikipedia > articles and websites, real ale status for pubs, opening times, values > of the "description" tag, etc With secondary data like the edubase and now fhrs which can be accessed easily and SHOULD be up to date. Wikipedia/wikidata should perhaps be a secondary source if a primary source is available. > - click on footpaths to get information about them e.g. if a particular > footpath has nice views described in the 'description' tag, this should > be shown > - ability to re-tag footpaths (e.g. add PROW ref, description tag) by > clicking on them (users can already authenticate with OSM via OAuth) Turning that around ... encouraging smaller council sources to make OSM their primary tool and feed the results back to other data? > - link with Mapillary to show photos along a given route? Looking to secondary sources ... if the browser side tools can allow a links layer accessing private data, one can add your own pictures. What I'm looking at here is reports of fly tipping, dog mess, and so on ;) > In terms of server space, we did have a server available to us for > development purposes (provided by Birmingham in Real Time) however this > will be unavailable for a month or two; however our contact there is > going to recommend some cheap hosting options. I've space and bandwidth which WAS running a UK mirror, but the software had not been updated in some years and OSRM was no longer working, so I need to reinstate that. I will have a look at the github setup ... I'm only looking to mirror the UK but include Ireland in that until the great wall of brexit appears ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging Schools with fhrs:id
On 21/10/17 10:17, Warin wrote: >> At one level we only need an icon for >> 'Rugby School' and all the secondary tags appear against that, but with >> all the fine detail now contained inside the likes of 'Rugby School', >> some consistent way of combining that at the higher level is what is >> missing? > > Would a site relation help? The way relations currently work ... no it's still not the right answer. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging Schools with fhrs:id
On 21/10/17 08:55, Gregrs wrote: >> Bottom line ... there should be separate objects where that is necessary >> and it would be nice if the larger operations such as Rugby School >> helped with detailed campus maps as many of the collage and university >> sites have been doing? > > I agree that in the case of more complex campuses each separate FHRS ID > should be attached to the relevant building if possible, and I think > that the associated postcode should also be attached to that building > rather than to the school boundary in these cases. This is what I have > done in the case of Rugby School (with the added bonus of local > knowledge) and it seems to work well e.g. Stanley House within Rugby > School: http://www.openstreetmap.org/way/259571188. This does keep showing the holes in the whole process :( While I appreciate that one camp seem to think that scanning the whole database for other objects with enclosing boundaries that MAY relate to the contained object, information such as the edubase ref and even the fact that Stanley House is part of Rugby School and not simply a house in Rugby seems to get lost. I think that this still goes back to the macro/micro mapping problem. At one level we only need an icon for 'Rugby School' and all the secondary tags appear against that, but with all the fine detail now contained inside the likes of 'Rugby School', some consistent way of combining that at the higher level is what is missing? I STILL think there is a 'place' for 'place=Rugby School' much as Nominatim adds and that the place elements hold the macro view with links to the micro elements ... Other thought on this is ref:edubase defines the edubase link, so why are we not using ref:fhrs for the food hygiene link. We then define lookups from ref:xxx to the secondary dama on each of those database ... I don't think we need to add fhrs:authority everywhere. It's inherited from the ref:fhrs ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging Schools with fhrs:id
On 20/10/17 18:51, Gregrs wrote: > I think it makes sense for both fhrs:id and addr:postcode to be on the same > entity, whether that's the boundary or a building. In some cases schools > might have more than one building with an fhrs:id, but it's possible that > these would have a different postcode e.g. the different houses at Rugby > School (http://www.openstreetmap.org/way/363617437). The majority of UK schools will only have the one catering facility and it's unlikely that this will not be the same place as school premises and involve a single postcode although with the unstable ownership of schools these days, we may well see private food outlets inside 'academies'? Although central catering facilities feeding several schools also messes up the picture. Bigger collage complexes may well have additional catering outlets across multiple campuses which need separate objects for each campus, building and potentially each identifiable outlet. It should not be a problem identifying each outlet and since the FHRS data is open licence http://ratings.food.gov.uk/enhanced-search/en-GB/Rugby%20School/Rugby/Relevance/0/%5E/%5E/1/1/20 provides every inspection point and the raw data can be download from http://ratings.food.gov.uk/OpenDataFiles/FHRS319en-GB.xml and a couple of the 8 entries for Rugby School are at the same postcode. So one needs separate objects to hold these fhrs:id records rather than the campus boundary. Bottom line ... there should be separate objects where that is necessary and it would be nice if the larger operations such as Rugby School helped with detailed campus maps as many of the collage and university sites have been doing? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 20/10/17 06:05, Marc Gemis wrote: > The full information that Nominatim knows for "WR12 7EP, United > Kingdom" is shown on : > http://nominatim.openstreetmap.org/details.php?place_id=180306705 > It does list a collection of streets. What you see on osm.org is just > a small set, which does not include the list of streets. The number of > streets in a postal code really depends on the country, it might be a > small number in the UK, but is large in e.g. Germany. Actually http://nominatim.openstreetmap.org/details.php?place_id=65620674 is of more interest in this discussion. Should I have added a postcode to the highway object? Also should each house have a name tag in addition to the house number? The information on houses is complete in my book, but do we need to create additional tags so that Nominatim lists the equivalent of the PAF file addresses? If I add the names then the rendering becomes messy which is why I only added the house number. And I must update the postbox collection times ... that change some time back :( ... but if those details were pulled from a secondary source ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 15:37, Colin Smale wrote: > Which boundaries are your referring to, which have yet to be mapped? > There are big holes in Civil Parish + Community mapping in the north of > England/Wales/Scotland, but most of England is OK. AFAIK all other admin > boundaries are in there. Parish boundaries are the one that normally catch me out ... And often it's difficult to sort ward boundaries from one another. > "Place" boundaries are a whole other can of worms, because they have no > defined boundaries in most cases and most of the UK will be in the ether > between places. They will usually differ from Royal Mail´s perspective > anyway. Hospital grounds and university campus boundaries are another area that are improving, along with industrial estates, but one I look after does not fair well with Nominatim as its WR11 post codes inside Gloucestershire. > If the use case is to get decent results out of nominatim, we need to > have a discussion about how best to approach that. I think we will not > get there with OSM data alone - changes to nominatim's logic will be > required. But it all depends on your expectations I suppose. 'Places' like Wychavon being used for directions are simply wrong, and more of a problem often is finding places on OSMAND that are currently not showing up properly. I had a run up to Haydock .. Wedge Avenue ... but it does not appear. Adding postcodes around there will probably help, but having selected 'Haydock' one would expect all the roads to be listed? Not sure how OSMAND is holding data, but a search on http://www.openstreetmap.org/search?query=Wedge%20Avenue%20Haydock#map=13/53.4778/-2.4421=H fails ... this is not really even a 'post' problem, just finding directions. > On 2017-10-19 16:27, Lester Caine wrote: > >> On 19/10/17 14:31, Dave F wrote: >>> On 19/10/2017 12:04, Lester Caine wrote: >>>> On 19/10/17 11:35, Adam Snape wrote: >>>>> Doesn't its location within the UK make an explicit UK tag unnecessary? >>>> But when reading a single object tags do you know just where it is? Some >>>> other mechanism has to return the 'inside boundary' data which takes >>>> processing power. >>> >>> OSM is geospatially aware. Nominatim have stated that it's not intensive >>> processing & prefer it over is_in*. If unwilling to use 'inside >>> boundary' coding it requires *every* object to have multiple location >>> tags for *every* search boundary. Expecting mappers to add this enormous >>> amount of data is selfish. >> >> The reverse of that is that there are a large number of boundaries that >> have yet to be mapped and in some instances may be difficult to map at >> all. I'm not suggesting that mappers add any more tags than useful and >> easy to add. What I AM suggesting is that 'Expecting mappers to add this >> enormous amount of data is ...' unnecessary when some key tags will >> cross reference the rest of the data! And where linked data changes then >> one does not have to address every object, just the top record. >> >> Yes automation can manage and change multiple records in parallel and >> fill multiple tags from the one entry, but does all that information >> have to be stored raw in OSM WHEN the processing can just as easily >> provide it? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 15:30, Colin Smale wrote: > It appears they don't even know/understand their own address... The post > town is not Ebbsfleet but Swanscombe. Not according to Royal Mail ;) But then that is no proof either, except that is where post will be delivered by them. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 14:31, Dave F wrote: > On 19/10/2017 12:04, Lester Caine wrote: >> On 19/10/17 11:35, Adam Snape wrote: >>> Doesn't its location within the UK make an explicit UK tag unnecessary? >> But when reading a single object tags do you know just where it is? Some >> other mechanism has to return the 'inside boundary' data which takes >> processing power. > > OSM is geospatially aware. Nominatim have stated that it's not intensive > processing & prefer it over is_in*. If unwilling to use 'inside > boundary' coding it requires *every* object to have multiple location > tags for *every* search boundary. Expecting mappers to add this enormous > amount of data is selfish. The reverse of that is that there are a large number of boundaries that have yet to be mapped and in some instances may be difficult to map at all. I'm not suggesting that mappers add any more tags than useful and easy to add. What I AM suggesting is that 'Expecting mappers to add this enormous amount of data is ...' unnecessary when some key tags will cross reference the rest of the data! And where linked data changes then one does not have to address every object, just the top record. Yes automation can manage and change multiple records in parallel and fill multiple tags from the one entry, but does all that information have to be stored raw in OSM WHEN the processing can just as easily provide it? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 13:15, Adam Snape wrote: > But Ebbsfleet is not a Post Town. The address will include Swanscombe. I > should have said before that my experience (as an eBay seller) is lots > of people are unaware of their correct postal address. Each postcode > section eg. DA1, DA2, DA3... will have a particular post town, so I > correct this which I know to be wrong for the postcode. Because several > of the editors don't include a box for suburb or hamlet it is aslo > common to see names of villages or suburbs in the tagged as addr:city. From a postal point of view, the result of a lookup on the Royal Mail website is the best way of checking a postcode and the return from DA10 1AZ is longer than some results and is what Steve listed originally. If we can actually use that view of the data is a little grey, but one can at least check where one is shipping something is correct. I'm sure manually top level sorting post, the post person will be looking at the postal town rather than the postcode, but on automated machines then only the name and postcode are relevant. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 12:37, Marc Gemis wrote: > Then at least people know that they should not check with Nominatim. > > AFAIK, Nominatim does not try to generate an address you can put an a > letter. It tries to show the address as part of the administrative > hierarchy defined by the other objects in OSM. Some of those > administrative levels are not used for letters or navigation where I > live. Nominatim produces something of a overloaded location string Residential Road Smallbrook Road, Broadway, Wychavon, Worcestershire, West Midlands, England, WR12 7EP, United Kingdom but then fails to return the street if you do a postcode lookup. Postcode Broadway, WR12 7EP, United Kingdom But the main point here is that there are a large number of other useful boundaries that can be identified via postcodes. It would be nice though if we could simply use the NLPG reference for every property since it SHOULD be a freely available database that council tax payers have financed and councils are required to keep up to date. But it's a chargeable resource to use :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 11:35, Adam Snape wrote: > Doesn't its location within the UK make an explicit UK tag unnecessary? But when reading a single object tags do you know just where it is? Some other mechanism has to return the 'inside boundary' data which takes processing power. > The postcode, where present does usually indicate the other address > details (though very occasionally postcodes can include more than one > street). However we have no way of tagging attributes to a postcode > rather than an OSM object. The original UK postcode rules were one (or more) postcodes per street. The rules have been bent a little but this is achieved by making the 'extra' street data part of the building details rather than the postcode. Accessing secondary data without having to store ALL of it in every tag is the problem, and one that should be solvable? > Using associated street relations > http://wiki.openstreetmap.org/wiki/Relation:associatedStreet might be an > option but seems a bit overly complicated. Relations have never worked well in my view. Comes full circle here. How do you identify the boundaries that objects are inside when it is described by a complex relation. Properly handled 'relations' could allow all higher level data to be accessed in a simple data read ... something relational databases are good at. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Quarterly Project: Addresses and Postcodes
On 19/10/17 09:35, Adam Snape wrote: > So I'd tag Steve's example: name=The Spring River, addr:street=Talbot > Lane, addr:hamlet=Weldon, addr:suburb=Ebbsfleet Valley, > addr:city=Swanscombe, addr:postcode=DA10 1AZ One of those itches to be scratched that have been discussed elsewhere ... Do we really need to add 'addr:street=Talbot Lane, addr:hamlet=Weldon, addr:suburb=Ebbsfleet Valley, addr:city=Swanscombe,' to every object on the street? addr:postcode=DA10 1AZ provides that data and more besides and only needs augmenting with a house name/number for an address. With all the other data manipulation tools being discussed, one which provides common data for an object is long overdue. Looking at the long format, should it not also include addr:country=United Kingdom so that one knows just how to validate the postcode anyway ... although I am tending towards addr:postcode:UK=DA10 1AZ so that one can pick up the correct secondary data easily ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?
On 22/08/17 12:23, Colin Smale wrote: > If you ask people where they live, they will probably talk about the > county level and the settlement/town/city, but the informal boundaries > of these settlements will likely not follow the administrative > boundaries. In fact, it may not be possible to agree a polygon with a > sharp boundary of what constitutes a settlement with a given name. Most > place=* polygons in OSM just follow the boundary of the built-up area. > > So I see a possible role for is_in - to help out geocoding where > geometrical methods lead to an undesirable (though accurate) result. Middlesex ceased to exist in 1965 yet many people still use it in their postal address ... there is certainly no boundary for it on OSM :) To add to the fun, facebook's allowed list of places miss-identifies this area of London in the same way as the other areas that became London Boroughs back then and this is creating a mess in Facebook's use as a business platform. Starting with a list of the current official designations from the ONS database has to be the correct currently accurate information, but while there should be a boundary associated with each entry, a simple list of elements does not need to be overloaded with all of the way information providing that boundary. It is a secondary relation to the base 'name'. http://geoportal.statistics.gov.uk/datasets/0e7bbf9926584a57a2818c64f01d0bfe_0/data provides a list of the official COUNTRIES in the United Kingdom but even that is probably inaccurate in relation to is Northern Ireland part of the United Kingdom? ( At some time will Scottish translations also be added? ) The Open Geography Portal provides a list of data and the basis for checking that within OSM, but it will be easier to complete a complete mirror of is_in: hierarchy which can be updated as changes appear in the ONS dataset and THEN associate boundaries as appropriate. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Are Northern Ireland, Wales & England 'states'?
On 12/08/17 13:12, Dave F wrote: > I also think the 'is_in:country_code' along with all 'is-_in' tags are > redundant if there's a boundary tag.. In the past I thought that the is_in element was something of a problem, but it does have a place when one remembers that OSM is all about the data. "if there's a boundary tag" is the problem here if one is extracting a set of data? Processing a number of boundaries around a set of objects takes time, while cleanly managed is_in:admin_area with a proper hierarchy allows a much quicker lookup of information such as - in the case of the the UK - parliamentary boundaries, wards, historic county, NHS admin area and so on without having to physically draw every fine detail of these ever changing boundaries. BUT it only works well if there is a well defined hierarchy so tagging is_in:gb-ward http://geoportal.statistics.gov.uk/datasets/417e93f21c5c419283ac23abc8eedcce_0 gives all this data in a format we can freely use as with the other 'boundary' data. It is just a pity that 'postcode' is so badly organised that it quite regularly straddles these other boundaries, but is_in:gb-postcode would remove the need to add all of the associated address data to every object on a particular street, and for the vast majority of postcodes it WOULD also identify all of the other is_in: data at a higher level. It just needs an object defining is:gb-postcode and is:gb-ward to provide all the hierarchy ... without overloading the server with searches for all of the boundaries intersecting the original dataset? Of cause I am also still looking to maintain access to historic data, and this model makes it easy to check start and end dates of is:gb-postcode and is:gb-ward without having to maintain all of those boundaries actually in the base dataset - something which the majority of users seems to have decided against :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Edits in Wales
On 11/08/17 11:44, Chris Jones wrote: > For OSM that would mean translating the website/interface, providing a > localised render (like cyosm did), and improving the name:cy coverage. > It does not mean shoving both English and Welsh version in the same name > tag to everybody's detriment. As always others have put it better them me :) My own 'view' on the translation side is that one should be able to populate a table with :cy values for everything including the interface, but defaulting to 'name' is not the optimal, so a :en value cleanly identified is important. The interface is essentially :en and requires each word translated to the alternate language, so a clean set of :en values makes that consistent world wide, while the 'name' element lacks any identification as to the languages used :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Edits in Wales
On 10/08/17 11:15, Miguel Sevilla-Callejo wrote: > Hi Lester, God I hate replying to top posters :( > Have you read the Wiki [1]? Have you see street sing pictures [2][3]? That wiki page does not ACTUALLY say 'only map what is visible' The tag covering the sign for Queen's Square should have ... name=MAES Y FRENHINES QUEEN'S SQ. > I'm improving the DATA adding a neutral and appropriate "name" tag as > well as the "name:en" and "name:cy" tags. And I would tag those as name:cy=Maes Y Frenhines name:en=Queen's Square Other translations would probably be based off the English version as I don't think there are many other Welsh to xxx dictionaries? So expanding the 'SQ.' element is important. The problem is that while I search for Queen's Sq Aberystwyth it is being found as Queens' Road http://www.openstreetmap.org/search?query=Queen%27s%20Sq%20Aberystwyth#map=18/52.41657/-4.08115 so local knowledge is needed to explain the signage ... > I guess that the wiki says is the way to do it, right? The wiki does not ACTUALLY say that is right - or wrong - which is the problem? Should the case used on the signs be followed, should shorthand be expanded to make searching easier. > Here we are to argue if it is wrong of not but from my point of view > it's the right approach because it is the same as in other bilingual > places around the World: some places in Spain, Belgium, etc. Since it is widely accepted that the wiki is simply guidelines then as I said "This is still a bit of a woolly area". What is still accepted is that the key structure is English and so the default when nothing is defined should be 'English' so putting the english element first can be argued as the 'correct' approach, and I would prefer that I can find 'Queen's Square' easily which is more difficult when 'name' element is randomly ordered. Added to which other countries have their own wars on who's language is more important. So we ended up with all the extra keys under 'name' http://wiki.openstreetmap.org/wiki/Key:name with the comment against 'name' being what I would consider a rule and the one I described ... except it misses the problem of case. < trim out of place stuff and sig should never be quoted! > -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Edits in Wales
On 09/08/17 23:40, Miguel Sevilla-Callejo wrote: > So I would like to translate here why I'm using a neutral approach for > the bilingual tagging in Wales: mainly because I'm following the wiki. This is still a bit of a woolly area, but name= should only contain the information that is actually DISPLAYED locally. So if the street sign has only welsh or only english that is what appears in 'name'. This may also result in different tags on the same object where signage has different spellings or ordering, but someone looking for 'Fford-y-Mor Terrace Road' will have a good chance of seeing that on a sign. If the signs only have 'Fford-y-Mor' then one knows not to look for 'Terrace Road' ... In countries where different alphabets are used reading the signs can be challenging ;) This is then supported by name:en and name:cy along with additional name:* translations where people feel the need to generate them. Rendering a 'translated' map is then a matter of selecting the available name elements in the right order with 'name' being the final fallback, but 'Terrace Road' may be preferable for some translations even when the displayed name is only 'Fford-y-Mor' ... It depends just what the DATA is actually being used for? Making the DATA easy to use is the key element here not any particular rendering approach, but this has been messed up somewhat with there not being a consistent way to handle the evolution of the data. Many parts of Wales have been 'improving' the prominence of Welsh so what was only displayed in English now has the official Welsh signage as well. Using 'old_name' may be a way to record some of the changes, but we do need a much better defined way of handling the large amount of historic name changes that are currently 'lost' in the change logs! OHM needs to be feed automatically with data that the general consensus deems not appropriate to retain in OSM and the evolution of things like names are simply part of that. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] [Talk-gb-london] New OSM London Meetup - Invite
On 09/05/17 08:27, Stuart Reynolds wrote: > > For info, stations are regarded as “national” and so have their own 910 > prefix. So 9100LHONSEA is Leigh-on-sea (OK, it’s not in London but > that’s the one I know). The alpha code on the end is a match to the rail > industry TIPLOC codes, which throws up some oddities (such as London > Victoria and London Bridge having two TIPLOCs each, and Clapham Junction > having four). Been a while since I worked with TIPLOC codes ... it stands for 'Timing point locations' rather than the station itself. So complex stations like Clapham Junction having several routes through have different timing points. Not sure how up to date http://trains.barrycarlyon.co.uk/data/locations/ is and the link to the source is dead (along with other links to Phil Deave), but then I found http://nrodwiki.rockshore.net/index.php/AddingJunctionsAndSidingsToOsm. Not sure that there has been much progress with that. The open rail data is probably a source that we can use today, http://wiki.openraildata.com/index.php/File:TIPLOC_Eastings_and_Northings.xlsx.gz for example. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] [OSM-talk] Coordinates in OSM. Really annoying
Looks like I fell fowl of another annoying 'standard' ... just how replies to an email list are handled! If only people would use the same standard everywhere ;) On 22/04/17 16:23, Dave F wrote: > In this context I'm unsure what you mean by "interface standards" Working from the bottom ... nik2img is a python application, so expects the list of parameters to be listed with spaces ... https://code.google.com/archive/p/mapnik-utils/wikis/Nik2Img.wiki it IS actually using the box parameter, but in python scripts this is --bbox mapnik supports several interfaces, and url style links prefer not to use the space character, preferring the comma to break up strings. Overpass actually comes with a number of interface standards and the comma string can be used in OverpassQL (but the wrong pigging way around ;) ), but the XML standard requires each element has it's own name. Osmosis is a java application and that brings another layer of 'flexibility' which requires every element of --bounding-box to be named ... and as with python each element is flagged by a space ... essentially similar to the XML rules but with different element titles. Each programming language has it's own well defined standards and there is little chance we will be able to change those, so we end up with wrappers which pass a coordinate set in the right format. http://osm.duschmarke.de makes a number of those formats available in parallel for those times when you may need to swap between languages ... > On 22/04/2017 15:45, Lester Caine wrote: >> On 22/04/17 15:28, Dave F wrote: >>> As they're parameters, the format can be standardised for the end user & >>> any programme should be able to sort out syntax behind the scenes. >> Totally agree except passing box="w,s,e,n" is STILL a matter of the >> passing mechanism the target application is built around. There would be >> no problem with the box selector simply providing the right input via a >> link to the target application, and a graphic interface providing a >> suitable 'box' into which to put the coordinate string into for GUI >> interfaces, but as I said ... the problem is the vast number of >> interface standards currently in use and not a simple one to solve for >> one piece of data. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Reversing the flow of a one-way street
On 13/01/17 22:36, Mark Goodge wrote: > There is a one-way street (to be more precise, a service road) in my > town centre which has the wrong direction of flow on OSM. I can't see > any obvious way of changing that - the "oneway" tag merely has a value > of "yes", and there's no direction attribute anywhere that I can see. > > Is it simply a case of deleting the way and re-adding it in the right > direction, or is there a better solution? You simply reverse the direction the way is drawn. What editor are you using as it's fairly obvious on all of them which direction a way has been input. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging a multilvel building
On 12/01/17 10:07, Mark Goodge wrote: > 1. The entire building is "Evesham Town Hall". Mark - I have the same problem showing access to the Shopmobility office on the top floor of the car park ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK suburbs
On 06/10/16 17:48, Jez Nicholson wrote: > Seems like a silly question, but which tag do we commonly use in the UK > for suburbs? addr:place? If you look at http://wiki.openstreetmap.org/wiki/Key:addr you will see there are a few 'ancillary' sub tags including suburb, but there is little consistency, and despite what the addr:place tag says about NOT using with addr:street it is the most consistent where a second or even third line of 'street' data is required. addr:flat(s) flat number(s) within 'housename' addr:housename ( addr:housenumber ) name or number addr:street From the postcode addr:place Within town area addr:city Consitent with Facebook - everywhere is a city :) addr:county Which may not match 'postcode' addr:postcode The reference doc I'd like to quote is not publically accessible, but http://www.bitboost.com/ref/international-address-formats/united-kingdom/ is a good summary. Just missing the primary and secondary Building Name where flats are located within one of a number of buildings on a single street. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] John Watson School, Oxford
On 06/10/16 18:56, Christian Ledermann wrote: > How to map this? The staring point is if you can identify separate buildings. I've mapped a couple of sites where the playgrounds are shared space, so the 'site' is an amenity=school, but the names go against each building. Closer surveying of a couple of the sites did establish a separation of some of the playing areas but a 'common' car park so it does need at least some local knowledge to include the finer detail. I've been lucky that each was on a separate area, while a know I number of inner city schools have separate floors of the same building for infants and junior with separate governance, but they time share the outside space. Not easy to map the third dimension on OSM, but each has to have it's own 'level' tag. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Autumn Quarterly Project
On 03/10/16 11:17, Jez Nicholson wrote: > I was about to say that the data has a good chance of fairly high > accuracy because it is generated from an active processthen I found > my first typo > :) http://ratings.food.gov.uk/business/en-GB/803334/ "Longhill Hight > School". We can of course perform a service by reporting typos back. There are a substantial number of mistakes in the schools data. In these cases the OSM data is more accurate, but it would be nice if there was a consistent way of notifying these errors back to the original source. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upper Booth camp site, Pennine Way near Edale
On 03/10/16 09:23, Nick Whitelegg wrote: > highway=footway or path should really mean "it's just a physical path", > we shouldn't really be assuming things about access. Then add explicit > access tags if we know it's permissive (or designation=public_footpath > if it's known to be a RoW). I'm with you on that Nick ... Farm tracks around here are very useful reference points on the ground so should be visible on a map as well but unless there are signs up restricting access it is often difficult to know. One well surfaced road has now 'grown' a 'private - no access' sign, but one would not remove it from the map, only add the restriction. The ramblers are probably the best for pushing the boundaries on just what are RoW and border line cases ;) But even on the ground, access rights are often not obvious. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK Postcodes
On 25/09/16 23:24, Chris Hill wrote: > Postcodes don't apply to a road, they apply to a collection of delivery > points. Many, many roads have multiple postcodes Reply on phone went to wrong place ;) If we have buildings on a road, then the postcode goes on every building, but I still think that is wrong. The alternative of putting on road does not work for the reason Chris gives, but grouping all the houses having a common street name and post code cuts down on the volume of duplication in the data. One thing that a postcode is SUPPOSED to avoid is having two different street name elements for the postcode, so at least the sections of a road can be consistent. So yes - 'Postcodes never apply to more than one street', but we may have a different postcode on either side of a street :( The main reason for searching for a postcode is for the routing software, and in those cases identifying the road is useful when the 'centroid' can be some distance of track. If the postcode is only on the buildings then the result can be even worse where roads are in close proximity, so we probably have to put up with duplication on building and the correct adjacent road, although 'postcode for GPS' is common in rural areas - and confuses things further. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
