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: [OSM-talk] Roadmap for deprecation of name tags in OSM
On 09/08/2020 09:42, Mateusz Konieczny via talk wrote: Aug 9, 2020, 10:25 by pang...@riseup.net <mailto:pang...@riseup.net>: I suggest we create a roadmap for deprecating of storing and updating names in OSM for objects with a Wikidata tag. Absolutely no. tagging name tag is a fundamental part of OSM tag, offloading it to a third party service is a mistake that will not happen https://josm.openstreetmap.de/ticket/19655 contains several misleading, wrong, mistaken and problematic claims, statements and implications but I have no time to process in detail as the entire idea is fundamentally bad, mistaken, problematic, broken, not workable, not acceptable, not going to happen and wrong. Seconded ... However sensible LINKING to third party services does make sense such as with geonames which already has services linking back to OSM ... geonames is a useful source of local time data for example. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On 24/05/2020 23:45, Mateusz Konieczny via talk wrote: There are also many roads signed as "No HGVs except for access." It is tempting to tag them as "hgv=destination" but that doesn't cover the case where you are allowed to follow that route for many miles and make several turnoffs IF you "need access". The current definition of "access=destination" doesn't allow routers to distinguish between truly "first/last segment only" and "its fine if you are going to/from this general area". AFAIK this awaits solution, at least I am not aware about even a tag proposal. A delivery driver following a drop list may have a drop on that road, and then go on to their next drop out of the other end of the road. In fact it may be that the road is impractical for the vehicle to turn around. The 'legal' restriction is to prevent lorries using it as a short cut through a residential or similar area and physically it is perfectly practical for the biggest legal vehicle. The router can simple avoid that road if there is no stop on it, but the tagging should ADDITIONALLY indicate if it is physically possible to get the vehicle to the destination so obstructions such as tight corner, overhanging buildings, weight restrictions and the like will prevent some of the examples of lorries blindly following their sat nav without their brains in gear? It is the routers problem to pick the best route, which may be to approach the destination from the other end and perhaps even indicate 'back up to destination' ... now that WOULD be an intelligent router ... but if there is no information on which to base that decision even the driver has to guess. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] our Q site help.openstreetmap.org is dying
On 20/05/2020 20:32, Frederik Ramm wrote: Not copying past answers, at least the last two years or so, would mean we'd have to write all these answers again because the questions will inevitably be asked. I'm with you on that ... I've seen far too much material simply ditched because it been to difficult to 'recover' it after systems stopped working. So where would I head to get my hands on an XML dump of the current data to see if I can push it into the copy of Q2A I've just set up ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] our Q site help.openstreetmap.org is dying
On 20/05/2020 08:28, Tobias Wrede wrote: The site is based on OSQA, a software which has not been maintained in some time. Some application errors have surface in the past but had to be ignored since no fixes are coming from OSQA any more. Until now we could live with that. They were annoying but not critical. There are open tickets on OSM github to move the help site to some other framework (https://github.com/openstreetmap/operations/issues/149, https://github.com/openstreetmap/operations/issues/377) but there isn't exactly an abundance of volunteers to take care of that. Question2Answer looks like it's being well supported. At least it has a release that works on the latest PHP and while it's a little long in the tooth, https://github.com/jamesspittal/osqa-q2a offers a hope that there is potential to pump existing material across? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On 25/02/2020 23:39, Alan Mackie wrote: Vector tiles that prefer either the browser's requested languages or something selectable would be ideal, but we aren't there yet technically for the main 'editors map'. When we are it might be worthwhile revisiting this discussion. There are complaints about what language to use everywhere. Even such a fundamental part of the infrastructure as 'timezones' has an ongoing debate about just how to spell the ENGLISH name of some identifiers and there has been a growing push to simply drop the 'names' and use abstract references so close the discussion once and for all. The argument here HAS been a problem since day one, and I remember discussions on converting tagging to use ID numbers rather than names ... what ever language they are written in. Just as with timezone identifiers, many of the text strings used can be 'translated' into any language one likes to DISPLAY them, and what has always been missing is a part of the API that simply allows one to select the language one would like to see ... and something which vector tiles could easily support ... but just as browsers still have problems with the simple stuff like returning a clients ACTUAL timezone (time offset as ALWAYS been the wrong information), the basic simple steps have never been defined in any standard? That the current 'map' is missing names for many graphic objects is just a matter of who controls the style sheets. Personally I prefer the French tile sets over the main version and have to accept that road colours are wrong. None of that affects the flexibility that the raw data provides, although a nice 'United Kingdom' colour set on OSMAND is still on my own todo list, and the vector maps THAT produces have potential to solve many of the 'complaints' ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] handling street names in speech
On 17/07/2019 08:29, Jo wrote: Unfortunately TTS is not perfect and it never will be, for one thing because it's often difficult to decide with TTS (which language) to use for each word in a name string. For many years I used a TTS engine called Rhetorical on a caller management system we supplied. It was used to allow calling people by name rather than ticket number ... we will ignore the privacy debate ... there was a general consensus that at that time the personal style was better. The nice thing about Rhetorical was that even without any help it did a better job pronouncing foreign surnames and some of the staff did ;) It also had a very good mechanism for adding improvements to words when there was any particularly obvious mispronunciation. In addition selection of a different 'output language' worked well, possibly because the company involved was based in Scotland, and the clarity of Scottish pronunciation worked well. We had already had to re-work the older 'English' segmented announcements using a Scottish voice because of complaints ... but perhaps the main point here is that this was providing THE SAME English text! Rhetorical was bought up by an American company and essentially dropped, but I think CereProc is using the same engine and a large range of 'voices' are available on Android ... if only OSMAnd could access them :( Text to Speech rendering is exactly the same problem as tile rendering and adding tagging for particular processes will always be wrong. The real problem is that there is no mechanism to add corrections in a secondary system in much the same way as there is no translation system for the key English elements of the data. Even IPA strings depend on the context and accent that is being vocalised! -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ways divided by paint?
On 04/07/2019 15:24, Mike N wrote: What if strictly following the rule of "no split ways unless physical divider" results in wildly incorrect turn-by-turn instructions? I have the same problem with the right turn lane being removed from https://www.openstreetmap.org/#map=19/52.11366/-1.94141 ... one can transition from the A46 to the A44 heading north WITHOUT having to stop for the roundabout. Because the only separation IS a crosshatch area the slip road has been removed but there is NOTHING to indicate that this slip road even exists by any other tagging! Unless someone has an 'approved' way of adding it back? Personally I think that micro-mapping complex junctions does require multiple ways even if the planned routes through a junction can be abused by taking the wrong path ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] We're erasing our history in wiki
On 22/04/2019 11:45, Ilya Zverev wrote: It’s history. Ilya ... it's the same problem we have with with a lot of the historic material. Personally I'd prefer to see the history accessible in some way, be it the history of the development of a area of mapping data, or the history of how we got to a particular style of recording that data. The data is in reality not totally lost, all that is missing is some general consensus on making it visible when appropriate. There has been a request for 'namespaces' in the wiki to help manage such things as the historic discussions on how tags have evolved and why some have been rejected. I'm not sure that it is the appropriate way to manage it, but an historic time line view of wiki pages is something that would not require 'manual management' and with a switch to display or not deleted pages would fill the gap? People investigating a particular tagging development could then see the past history of related pages. Doing the same with the map data is somewhat more difficult, but I still think it's a development that would replace the need to marry OSM with OHM for material that is substantially linked to current live data? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] OSMF makes a political decision where should be a technical solution?
On 22/11/2018 18:53, Victor Shcherb wrote: In that case I would actually support idea of deleting all country boundaries to avoid this question completely. There are numerous sets of data within OSM that are disputed and one 'controlling body' or another would prefer was not published at all. The best that can be done is for local displays of that data to provide local filters. Simply deleting data is never going to be the right solution, but allowing tools that censor the data is equally controversial. For the point of view of OSMAND, the display needs to know where one can drive and where one will be stopped and need paperwork to proceed. THAT in my book is the simple ToTG because it is flagged by something physical. That some areas don't actually have 'border posts' does create a problem, but as an 'outside visitor' to the Ukraine or Cyprus, where can I drive and where could I run into difficulty if I do drive into a disputed area. It's the grey areas that are something that will cause problems and may require projects like OSMAND to censor data based on the user view? I doubt that OSM services are really able to manage this area in a generic way? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Plus code grid service
On 19/11/2018 17:16, Rasťo Šrámek wrote: A plus code is not intended to have the same function as latitude and longitude. It is intended as a replacement for "street name, house number" address parts where those don't exist and cannot be reasonably created. If you write Firstname Lastname WF8R+H6 Praia Cabo Verde on an envelope and drop it off at your local post office, wherever you live, it will be delivered. As long as they know just which code system you are using. This is just another in a long list of 'postcode for no postcode' areas. Have any of them actually gained traction on the ground? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] Really heavy browser load with Overpass-turbo map display
On 24/09/2018 20:36, Dave F wrote: Switching to an older version of a browser isn't neutral and raise security considerations as always. Usability is the same & 61.0 works OK & is only 2 months old. Personally I wouldn't rely on browser security. There are a number of problems resulting from the major surgery Firefox recently went through which are only slowly getting fixed. It would have been much more sensible to maintain the original build in parallel until more of the core functions and disabled extensions were made functional and compatible. I'm still struggling with the lack of Firebug as the replacement has problems with font sizes at least on linux and does not provide some of the nice features Firebug STILL provides on my development machine. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] Representing places with no housenumber
On 23/08/18 10:16, Mark Wagner wrote: As a rather extreme first-world example, the address of https://www.openstreetmap.org/way/132723167 is: name=Grand Canyon North Rim Lodge addr:city=North Rim addr:state=AZ Not only does the building not have a house number, house name, or other house identifier, the road it's on isn't named either. When there's only one road in town, and that road only has one building that receives mail, you don't need much in the way of identifiers. But I see nothing wrong with that. MANY places the name is also the building name ... I don't think anybody is saying there HAS to be a building number and if they are then THAT is the error. Many rural buildings simply have a name which in the case of the UK gets listed in the PAF file and I would simply expect 'Grand Canyon North Rim Lodge' to be the address if USPS had a similar postal address listing? I find the practice of adding ANY tag that does not enhance the data as pointless. There is no need to TAG that there is no number ... you just don't add the tag ... just as the example here ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] highway=* + area=yes vs area:highway=*
On 11/08/18 07:02, Andrew Harvey wrote: > No, all highways are areas :) Mapping them as a line is a manual generalization ;) Yes, but you're mapping the road centerline, which isn't a generalization but a real world feature. Mapping the path of a highway as a 'way' is a generalization. This can be extended by adding additional tags to describe all the fine detail such as width, number of lanes, associated cycle and footpaths, and so on, but this is a simplification to the actual fine detail. I'll repeat what I said, 'highway' SHOULD only be attached to a way and not to areas so that we have the simplification for lower resolutions of the data. ADDING areas to map the fine detail that is associated with the information also contained in the additional tags should be tagged by association and not by adding additional 'highway' tags to the areas. IN THAT CASE area=yes could be used to identify that there are associated area objects that can be used on higher resolution mapping. I don't think 'area:highway=' has place especially where the 'centerline' way is used to combine several highway=xxx types such as road,cycleway and footpath ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] building=grandstand vs leisure=bleachers
On 14/07/18 07:23, Tomasz Wójcik wrote: Building=grandstand is not perfect for me, beacuse building=* tag suggest that is some kind of typical building (with walls, roof, etc.) and most of the OSM styles render building=grandstand like every other buildings, where you can go inside, which may be confusing with grandstands areas. On the other hand we have leisure=bleachers , when the "bleachers" word is propably used only in USA. What do you think about it? Many of these are a compromise, but I would expect more tags not less. The problem with these two are they span different 'domains' as a number of others do. A built structure is a 'building', and there are a range of structures covering seating, so grandstand, covered_seating, open_seating ... move the leisure tag to a more appropriate tag? In addition, many of these can well be temporary structures for a particular event but present for some time perhaps every year. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*
On 03/07/18 13:21, Dave F wrote: Removes duplicated, reduces confusion, easier to search. A good Spring clean improves the database. I really think this fear of bulk edits has gone too far. I would probably ask just how many of the tags you think are duplicated? The point here is that there is no NEED for this edit, and it basically does nothing to improve the database. It simply hides this block of tags within the later larger bulk of 'fixme', when as has been said, if these have been around for so long they should be addressed. Miss-spelt tags being bulk edited is one thing, but 'FIXME' is clean and changing them just because you can adds nothing to the data. Get on an deal with them to remove them all together is the right tack ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*
On 03/07/18 09:28, Frederik Ramm wrote: On 02.07.2018 19:42, Mateusz Konieczny wrote: It would make development of QA tools easier as authors would not need to discover and implement support for this duplicated key. I think the downsides of such a large mechanical edit far outweigh the advantages. Don't forget that new FIXMEs will continue to appear all the time. Software should be able to deal with both. I'm with you on this Frederik. The correct fix for a 'FIXME' tag is to deal with it or remove it completely if no longer valid, and adding extra change events to 'fixme' only gets in the way of that. IF there is a general consensus that some tags are no longer acceptable, then the first step is to fix the API to prevent their use? Once the source of the problem is eliminated THEN address the historic data. Is there any case for not enforcing lowercase only tags? The fact that 'FIXME' and 'fixme' can exist on the same node just seems wrong in ANY case? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] About OSM social implications and what can/should be displayed on the map (or not)
On 29/06/18 16:27, Carlos Cámara wrote: Second: The very foundations of OSM as a project are techno-political in terms that it was created to overcome the lack of certain geographical information about certain areas or topics. This is even more obvious in HOSM or the not-at-all-accidental use of open licenses from its very beginning. Yes and No ... 'the map' is NOT the project ... the raw data is. I find it difficult to use the current style of the SAMPLE map provided simply because it gets the road colours wrong now. So I'm using a source of map tiles that use a more UK friendly colour set. The bottom line is that what is displayed on the map is already in conflict with many uses ignoring adding any additional censoring. What SHOULD be done is provide our own versions of the map for our own applications, as wikipedia is doing with names (although I can't see how to access them). Whether something has it's own icon is not a political decision - everything should have an icon - but the PRIORITY of displaying should be a non-political decision - not censorship! Moving to a more interactive map would be a positive step, rather than the continual churn of 'views of what is important' on a single static map and I know the technology is there, just not the resources to generate 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] Please do not re-use old node IDs
On 06/03/18 10:26, Frederik Ramm wrote: Long story short, please don't do it - let the API assign you new node IDs to your stuff instead of building ingenious contraptions to recycle old nodes. The reality is they are not 'old nodes' simply nodes which are not currently visible. I think I know the answer, but should the API be able to accept these ID's anyway? In an ideal world, the previous now hidden data should perhaps be flagged when the ID is 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On 24/02/18 20:49, Martin Koppenhoefer wrote: Every country may have different peculiarities, but the general concept is the same: a road usually restricted to motorized traffic, typically grade separated and distinct carriageways. We’re normally using British English in tagging but this doesn’t mean we couldn’t map things that don’t occur in the UK or for what they don’t have a word. I think the main problem is that there are well established guidelines for various areas on mapping data at both country and region level but in may cases even those rules do not harmonize. We need the several levels of highway that are currently accurately mapping UK roads, but other areas of the world do not need that degree of classifications ... so they just don't use the ones that are not appropriate ... ( And I am battling getting my computer working again as it was such as getting email replies properly handled on different lists :( ) -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On 24/02/18 09:30, djakk djakk wrote: There is 2 « independant » things in the debate : 1) trunk definition - what is a trunk, a motorway-like road - based on physical characteristics- or a super-primary road - based on the importance ? Since the classification initiated from the UK, that is still the base and a motorway has restrictions that do not apply to a trunk route such as 'no learners'. In addition they were maintained 'nationally' while primary roads are a local responsibility. That was been muddied much as the idea that trunk routes are faster. For the UK the road structure is well defined and it would be nice to get back a rendering with the proper colours ( and a selection for that on OSMAND ) ... 2) wordwilde trunk definition ? - should we have the same definition all over the world of what is highway= trunk ? (value that are country-dependant are not that common, aren’t they ?) Since there are no distinctions in many countries there is no need to include truck if there are no such roads in a country, and perhaps for 'world wide' trunk gets rendered the same as motorway or primary? Only local rendering actually benefits from the distinction? Do any countries not have motorways at all? Certainly the current default rendering is useless for many of us anyway so we have to ue an alternate anyway ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] iD news - v2.6.0 lots of new features...
On 23/01/18 09:37, Martin Koppenhoefer wrote: 2018-01-23 10:06 GMT+01:00 Lester Caine <les...@lsces.co.uk <mailto:les...@lsces.co.uk>>: Actually it's more likely to be the estate name so for my near by estate it is messy since I've ended up using 'housenumber' so that it renders better and the street is 'Weston Industrial Estate' as it appears with the postcode. https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250 <https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250> from my understanding, you should not use "addr:street" for the estate, I'd suggest "addr:place". NO ... the postal element "addr:street" is 'Weston Industrial Estate' so building a postal address from addr: elements needs that element. The adjacent road does not form part of the address. However larger estates with multiple roads will have the name of the estate separate. Using "addr:place" if it is displayed before "addr:street", but other uses of "addr:place" need it AFTER street. Construction of an address from addr: elements should be consistent but *IS* something that will have a different template for each country, and adding more addr: fields just complicates that template? This is what is currently not documented? I don't like the idea that addr:number could be a housename, there is addr:housename for this. My point here is to loose the confusing mess and just have "addr:number" and then -> addr:property might be an option, if you deem addr:place inappropriate "addr:property" is the expanded format of the number. "addr:place" is an area with multiple premises and "addr:property" is an individually identified unit of accommodation/workspace/storage ... for a UK address template addr:place comes after addr:street and before addr:town while the estate name would normally come before addr:street ... but a UK addr:postcode would provide all the addr:street and later elements, just needing a tidy property reference ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD news - v2.6.0 lots of new features...
On 22/01/18 22:27, Tom Hughes wrote: I wouldn't say unit is common at all in the UK to be honest. It's only really used for commercial units on industrial estates and things - you wouldn't normally see it in residential addresses like you do in many countries. For the UK all that is required is 'property' and 'postcode' and for an industrial estate property may be 'Unit X' and postcode provides the rest of the street details. Adding 'street' is a little belt and braces, although people asking for your details will ask for 'first line of your address and postcode' in which case the 'Unit X' may or may not include the street. Actually it's more likely to be the estate name so for my near by estate it is messy since I've ended up using 'housenumber' so that it renders better and the street is 'Weston Industrial Estate' as it appears with the postcode. https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250 does not want 'Unit' in front of the numbers, so should the 'addr:housenumber' now be changed to 'addr:unit' ... on one hand yes that would seem better, but I still think 'addr:housenumber' is wrong, and we should have 'addr:number' and 'addr:property' where 'number' would be the shorthand style of property reference ( and may even be a house name where not numbered ) and 'property' would be the expanded for. For 'unit' ... 'X' and 'Unit X' ... for office 'blocks' this may be something like 'B4A' for 'Block B, Floor 4, Office A' or something similar. Units on a storage site may well be more complex than just number. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Automatically generated changeset discussion comments by OSMCha
On 17/01/18 09:46, Frederik Ramm wrote: It's like clapping your hands to the supermarket cashier every time he/she prints you the receipt. I had to smile at that one. Reminds me off the developers lists where there is more traffic of the 'I like that' than actual constructive contributions. I think users should either be able to opt out of automatically generated changeset comments, or perhaps such changeset comments should only ever be generated to users who have actively opted in (the "review requested" could be interpreted as an opt-in even though it doesn't exactly mean that). Requesting the review of an edit should always be optional, but for new editors it should be a part of the process anyway. TAGGING a changeset for review should not simply be a comment. OSMCha should perhaps be pushing feedback to the contributor and ONLY to the database when there is a problem. Can we keep that hand clapping to a separate channel to the live data in the database please? 2) I've always been using the "changesets w/comments" line of the HDYC page to double check suspicious mappers. Usually a mapper with a ton of commented changesets was to consider suspicious, from now on this osmcha feature is going to add a crazy amount of positive/useless comments Could auto-generated changeset comments be marked as such, so that HDYC could ignore them or at least treat them as less relevant? We live in a world where much of the traffic on social media is automatically generated by a bot of some sort. Adding that 'feature' to OSM to improve quality should be part of the edit process so it informs a contributor at the time, not generating feedback later. And certainly as with any contribution, it should be tagged in a way that you KNOW just how it was generated, and can filter the 'social media' contributions from the 'constructive' ones. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] What would make MapRoulette better?
On 21/11/17 04:02, Marc Gemis wrote: > I'll agree with Yuri that is has to be the choice of the mapper to > work in a specific region and not the challenge creator. I stopped using MapRoulette simply because it was taking me well out of my comfort zone ... -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
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: [OSM-talk] Woods vs Forests
On 02/11/17 10:34, Warin wrote: > On 02-Nov-17 09:21 PM, Lester Caine wrote: >> On 02/11/17 09:40, Martin Koppenhoefer wrote: >>> ONE tag to say what? You are still owing an answer to this. >> I think the problem is similar to the multiple areas problem. There are >> several layers of complexity so should landuse=residential enclose the >> whole area including the grass and wooded areas or should they all be >> isolated areas? Adding leisure=park within landuse=residential area just >> makes things even more difficult? Just what is a small area of trees? >> within the leisure=park or landuse=forest because it's not a >> natural=wood 'creation' ... it's something the planning authorities have >> requested as perhaps a barrier or simply as an amenity ... or has been >> preserved as it has been there for hundreds of years ... >> >> We need to build a proper hierarchy of LANDUSE into which more detail >> can be added if required? >> > If you want to tag the presence of trees then it is a land cover you > want, not a land use. Rather than natural= ? ... My point was that there should be an agreed non-overlaping set of landuse=tags ... landuse=agricultural for areas between landuse=residential or landuse=industrial where appropriate with the farm builds, yards, orchards, coppices, and other detail secondary tags to the landuse one ... rather than having to define every field with it's own landuse tag. Actually ... how difficult would it be to identify areas that don't have a boundary around them? I have always though it would be useful if one could fill in the gaps between things like landuse= areas. > The difference between a large group of trees compared to a smaller group? Size of the area is not relevant ... But adding landcover=trees inside landuse=residential is perhaps a better solution? But should a large park outside a residential area still be tagged leisure=park? To fill in the landuse coverage it should perhaps be landuse=park ... with wooded areas tagged within it. > What next - the difference between a large group of houses and a smaller > group? We can accurately every building cleanly that is not a problem! It's adding the other details of the development which is ... somewhat hit and miss? > landuse=forest does not mean there are trees there all the time, they > could be logged and later replanted. > > With landuse=residential there are no sub tags to indicate the kind of > houses there or apartment blocks, colours, height etc. > > If you want that kind of detail then map the physical houses with that > detail. > > You could do the same with trees .. map each one with its height, > species and genus .. I'll leave that to others... Actually the plans for the current local developments HAVE all of that detail. Not that I expect them to actually follow the signed off plans on the ground ;) But it does define the areas of the developments that are not covered with buildings, highway elements, private gardens and fencing. But again for consistency should the whole area be re-tagged residential from farmland, or the preserved wooded areas inside the development be tagged differently? One of the developments south of here has individual trees that have to be protected but they are less of a problem since they are individual objects. -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Woods vs Forests
On 02/11/17 10:17, Warin wrote: > A botanic Garden contains lots of different plants, including grass for > the ones I have been to. > Mapping each individual plant with its species and genus ... no thanks. > I did map one tree though, just to be inconsistent. :) But there is nothing stopping the staff of that Botanic Garden adding all the footpaths, private areas, beds, features and so on if they are working to produce their own map of the site? In much the same way that universities and collages are mapping campuses in more and more detail. Some areas have considerably more detail than others depending on who is generating the data. It's Tomas's interpretation of landuse=forest and natural=wood which is a little at odds with others who would tag large 'unmanaged' forests as natural=wood ... we need perhaps two levels of tagging for macro and micro, rather than implying different interpretations on existing tags depending on where they are 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Woods vs Forests
On 02/11/17 09:40, Martin Koppenhoefer wrote: > ONE tag to say what? You are still owing an answer to this. I think the problem is similar to the multiple areas problem. There are several layers of complexity so should landuse=residential enclose the whole area including the grass and wooded areas or should they all be isolated areas? Adding leisure=park within landuse=residential area just makes things even more difficult? Just what is a small area of trees? within the leisure=park or landuse=forest because it's not a natural=wood 'creation' ... it's something the planning authorities have requested as perhaps a barrier or simply as an amenity ... or has been preserved as it has been there for hundreds of years ... We need to build a proper hierarchy of LANDUSE into which more detail can be added if required? -- 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 mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
