Re: [Talk-GB] Thankful Villages
On 22/08/14 15:23, Brian Prangle wrote: I'll leave it to others to judge whether this is data they would want on the map, but: Thankful_Village= yes_WWI Thankful_Village= double_WWIII I believe that Thankful_Village=WWI Thankful_Village=WWI;WWII would be more in the spirit of the tagging system. Alternatively, to avoid multiple values: Thankful_Village:WWI=yes Thankful_Village:WWII=yes wikipedia= en:Thankful_Villages I think this is a misuse of wikipedia tags. The tag should be to an entry for the specific village (regardless of its thankful status). I also think it is wrong for the Thankful_Village article to repeat the contents of the corresponding category. wikidata=Q3519572 Not sure how to interpret this, but I think that this should also follow the indirection chain via the wikipedia article for the village. NB Wikipedia should never be used as a primary source for OSM as: - it is supposed to be a secondary source, so you should always cite the corresponding primary source; - it has much less strict rules on database copyrights, so you may end up making an illegal database import. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Thankful Villages
On 22/08/14 15:50, David Woolley wrote: Thankful_Village=WWI Thankful_Village=WWI;WWII Other things I would want to investigate are whether this can be generalised to other countries: do the Americans have a similar category; does it include Korean and Vietnam wars? What about the Germans and Japanese? This may require changing the name to be more generic. Also, is there an existing de facto namespace for wars. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Imaginery footpaths added by user Gavaasuren
On 18/08/14 10:59, SomeoneElse wrote: Whilst the existance of a highway=pedestrian area that isn't connected is an indication of something, it's usually just an indication of that mapping in a particular area is not complete. Considering the longer term problems: 1) There needs to be better guidance to routing software developers on how to route when there are parallel features accessible on foot; 2) There needs to be a lot more mapping of barriers. Ideally, the routing rule for foot needs to be something like that, subject to access and surface quality considerations, if there is no barrier between adjacent features, you may cross at any point between them. In this case, there has probably been pressure to make life easier for the router. I think this also came up recently with regard to central reservations on non-motorways. The other difficult situation we have here is that pedestrian areas are mapped physically, as the actual area occupied, but most roads are mapped, abstractly, as an infinitely narrow line on the centre of the carriageway, so you will get a gap between the two and the router has to use some heuristics to decide whether that gap is bridgeable on foot. I have seen cases where the pedestrian area was mapped out to the centre of the road, but I considered that wrong. (In fact, mapping roads as areas will generally confuse routing software.) Another variation of this routing problem is that of where is it reasonable to cross a road. Ideally, physical barriers at the centre of the road should be mapped, and access restrictions put on any reservations that is not supposed to be used by the public, but the main consideration tends to be the level and speed of traffic and the visibility of that traffic, combined with whether or not there is a designated crossing point near enough to be used. There really isn't enough information mapped to make a decision as to whether it will be safe to cross. Also, a little old lady may not be safe crossing at an arbitrary point, whereas it will be no problem for a more able bodied person. Some people may want to avoid pedestrian subways, particularly after dark. Any mapping of crime levels in them is likely to be volatile and may even move the crime. Particularly for residential roads, you might get into the dangerous area of mapping actual maximum speeds on rat runs, as, there is a road near me with a 20mph limit, but, apart from speed bumps it is long and straight, so vehicles may get up to 40 mph between bumps, with visibility limited by parked cars. The council policy is to only use passive enforcement. Mapping that as 40 mph de facto, may encourage people to use it that way, but saying it is safe for little old ladies to cross at night, based on the 20 mph limit may also be wrong. Maybe there is a need for a verification tool that renders additional random interconnections and crossing points, so that one can see whether there is a need to add barriers, and other hints, to prevent such routings. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Imaginery footpaths added by user Gavaasuren
On 18/08/14 12:15, SK53 wrote: There are plenty of examples of people building routers for people with restricted mobility using OSM data (for instance wheelchair users, blind people etc). Most of us will map steps on footways simply because even one step acts as a barrier to wheelchair users or many older people. In the case that I'm thinking about, the limitation wasn't physical barriers, but a combination of very slow walking and short gaps between vehicles. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK addresses
On 12/08/14 23:08, Rob Nickerson wrote: 6, The Hollies, Birmingham Road, Town, Cases I've seen are maisonettes and parades of shops. I've used: housenumber: 5 street: The Hollies, Birmingham Road but that is more to ensure the data is captured than because it really seems right to me. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] UK addresses
On 13/08/14 11:36, Will Phillips wrote: 2. I don't agree that tagging only postcode and 'addressable object' is a good idea. To convert that into a full address requires access to a closed database. Surely the whole point about OSM is creating useful It's also a database which is incomplete; it doesn't include things like sub-stations, or garages at the back of, which are contained in the National Land and Property Gazetteer http://www.nlpg.org.uk/nlpg/welcome.htm. This is what defines the unique identifiers actually used by councils and the emergency services. This is another database that is being monetized. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Licences for Highways and PRoW data (Was: C roads again)
On 13/08/14 12:15, Robert Whittaker (OSM lists) wrote: They have to maintain a written List of Streets Maintainable at the Public Expense. Councils also allocate addresses for streets not maintained at public expense (and it is my impression that many new residential streets, including most social housing, come into that category!) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] A431 toll road (going a bit OT)
On 11/08/14 10:33, Dave F. wrote: On 05/08/2014 15:00, Curon Davies wrote: On 5 August 2014 14:25, Dave F. dave...@madasafish.com mailto:dave...@madasafish.com wrote: One reason I haven't added it is because it's illegal (AFAIK. The owners of the land local councillor failed to reply to my tweets) definitely has no planning permission. The development isn't illegal, there is no criminal offence (AFAIK), on the other hand it is unlawful. a) Semantics b) Isn't there a statute law which says 'you can't build or open a road without authorisation'? It seems to me that this is being driven by one particular application of the map, motor vehicle routing. The road exists. It is possible to get permission to use it if you are under 3.5T. Therefore I would say that something like this is valid: highway=unclassified; motor_vehicles=yes/permissive; hgv=no; fee=yes is necessary. If that results in routing applications using it in a way that voids insurance, maybe add something like mib_approved=no. Buildings certainly should still be mapped, even if they don't have planning permission (four years for construction and 10 for use are more permanent than most shop tenancies). Settlements should be mapped, even if some other country disputes their legality. More generally, though, it is dangerous for something like OSM to claim authority on the legal status of any object. Locally, you put yourself at risk of being sued when you turn out to be wrong. Internationally, it increases the pressure to ban it from countries involved with border disputes. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Tagging of British canals.
On 06/08/14 22:29, Dave F. wrote: Really sorry to say this, but some of your edits have been a bit off. In JOSM do you load all the data in the area you're editing? I've noticed you move whole entities, such as fences, but seem unaware that action affects any joined elements like other fences or footpaths. If these are the edits I think they are, my concern is that they are difficult to audit because they all have the same generic comment. If I remember correctly, they also tend to have large bounding boxes. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] City names translation
On 05/08/14 12:00, Pavlo Dudka wrote: There is also nice project Multilingual Map created as part of Multilingual maps wikipedia project(http://wiki.openstreetmap.org/wiki/Multilingual_maps_wikipedia_project). Unfortunately, the only realisation of this concept that I have found (not necessarily part of that project) is in an update freeze, pending the closure of the toolserver machine. There are apparently plans to re-host it. E.g. http://toolserver.org/~osm/locale/uk.html ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] City names translation
On 05/08/14 00:37, Lester Caine wrote: Simply writing a name in a different alphabet is something that the renderer can do if required. There is rarely a 1:1 mapping between different alphabets, except within a single country, and the mapping depends on both source and destination languages - and in fact dialect. If you are going to do it mechanically, you must have detailed transliteration rules between every pair of languages that don't share a script. Just consider the different transliterations needed for Paris in French and Paris (Texas?) in English. You could reduce the problem to O(n) rather than O(n**2) by having a phonetic transliteration, but note that, as normally used, IPA is an approximation, designed to distinguish phonemes within a single language, so you would need a more detailed IPA markup than most people are used to. In this particular case, I think there is almost certainly an element of Ukrainian nationalism, attempting to expunge all traces of Russian. If you started transliterating based just on Russian pronunciation of Cyrillic, even if you called it a pseudo-language called Cyrillic, it would probably never be acceptable to the Ukrainians in the current political climate. Especially with Chinese, there are large numbers of homophones with different meanings, and words are often composed from two characters. Approximate transliteration requires a lot of knowledge, to avoid unintended meanings in the transliteration. Also the script is used with widely different spoken languages, so a mechanical transliteration would have to choose one of those languages. I'm not suggesting that it is a good idea to translate every street name, although I would note that that will already have been done, outside OSM, for all the central London (tourist area) streets, into Chinese. I think place names are so fundamental to any geographical map that contains any text at all, that alternative names should be part of the core database (although one could have special structures for them. Any mechanical process needs to be predicated on having phonetic transcriptions available (probably two: the one used in the place itself, and the one in the country's equivalent of received pronunciation). English street names largely come from a small vocabulary, which strongly overlaps with place names. If you are afraid of a proliferation of ad hoc street name transliterations, maybe the map database should contain a list of names used for streets within a country. (In the USA, there is also a lot of re-use of place names (Roswell in New Mexico is not the only Roswell). ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] City names translation
On 05/08/14 08:05, Pavlo Dudka wrote: No, I don't want to add name:uk for cities or other objects that were never mentioned it ukrainian texts. This is redundant. Unfortunately, there are lots of cases where people add detailed data that, although possibly not mechanically derivable from other data, still doesn't add much to the map. Recently I've noticed that a snap shot of restaurant food safety ratings has been added in a certain area. These will never get maintained and the restaurant may have moved from perfect to being closed by the council by the time someone reads them (fortunately the one that had been closed by the council wasn't one that had a recorded rating!). (Street names are actually very stable compared with small office tenants or food safety ratings, so are relatively harmless except in terms of database bloat.) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] City names translation
On 04/08/14 16:15, Pavlo Dudka wrote: Hi! I would like to add ukrainian names for cities of UK, but found that SomeoneElse_Revert removed some of name:uk-tags in changeset 20757217 with a comment reverting undiscussed Ukrainian translations including There might be some need to check that: - the names really are those used in Ukraine; - they haven't been taken from a copyright source - a likely problem when importing in bulk; - the process will not override existing Ukrainian names. but... ones for which there's nothing on the ground. I certainly don't think that commonly used names should be rejected simply because the local signage doesn't include them. As I pointed out to SomeoneElse elsewhere, most or all UK Universities have a Chinese name, even though it probably doesn't appear at the entrance to the campus. That probably extends to all the cities and towns, as well. Taking the Chinese case, particularly, the names are often a mix of phonetic and semantic translations. E.g Cambridge has a phonetic for the Cam and a straight translation for the bridge, but Oxford is a translation of both parts. Westminster is a translation for West and a phonetic for Minster. The phonetic may only work for one dialect, or may even be Japanese. The red brick university in question, had more than 940,000 Google hits on its Chinese name (actually now 1.36 million), in spite of not being signed with that name. The reason that I don't normally add foreign language names, unless actually signed, is that most of the sources I would have for them would have effective database copyrights. This is the list of cities I plan to modify: http://overpass-turbo.eu/s/4rF Those look like the sort of major cities and towns that would have foreign language names. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] [OSM-talk] Tagging of private roads
On 03/08/14 17:02, Tom Hughes wrote: In reality such roads may, even though they are not adopted and are hence not maintained at public expense, be highways with an associated right of way for the public. That's more likely for long established, and probably rural roads. For recently established private roads (and councils seem to be more and more reluctant to adopt) they won't have the established usage, of 20 years, to make them public highways, by default, and one suspects title deeds are written with explicit, limited, rights of way (e.g. in one case very near me all purposes in connection with the use and enjoyment of the property that is accessed via a private road across land belonging to another property. Interestingly, social housing is now normally set up as unadopted roads, often with fences, although not closed gates, around the estate. I tend to assume that the intent is that you only use those roads if you actually want to go somewhere in the estate, so tend to code them as access=destination, and reserve private for those cases where there is a strong implication that you must seek explicit permission before entering by the default means of transport for the road. Generally, though, I don't think that OSM really captures all the subtleties of level of privateness of highways. There are probably several dimensions to properly encode all the details. Also, for many purposes, adoption status is important, even if the road is a highway. Already mentioned is that it can affect who enforces parking rules, but it also often implies a lower standard of maintenance. It's quite likely that the owners have the right to control parking but less likely that they have the right to control access and passing along the road. There are also a lot of roads that are not labelled as private, but where there is no general right of access, e.g. the roadways to the garages behind my flats only have a right of way to people authorised, directly or indirectly, by a leaseholder or the freeholder, but there is no sign to say that that is the case, and there are actually covenants forbidding signs. Another example is back alleys. Rarely these are adopted, but in the more usual case that they are unadopted, you will not generally find that there is a public right of way preventing the gating of the alley (even though they are in regular use by fly tippers, and drug addicts!). As I hinted above, there is a strong trend towards making all new residential roads private), although especially at the top and bottom ends. Most of the presumed private roads I see in an urban environment are less than 20 years old, so cannot have become dedicated to the public by default. In my estimation, urban private roads are are under-coded on OSM (and properly coding them would show a worrying trend towards privatisations of the road network). ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
On 31/07/14 17:01, Nick Allen wrote: actual stop was. As a result of this, it is quite possible that there are stops shown in the right place with the correct tags concerning shelters, benches, tactile paving, name of stop, timetables or bus route references displayed, etc, but added to a NaPTAN reference which new data would show to actually be elsewhere. I've certainly found a lot of misplaced NaPTAN nodes, and ones where the logical stop has moved. The only way of improving this would be a line by line comparison, with perhaps the transfer of a reference from new NaPTAN data, to the existing OSM data. If I appear in the history of the bus stop (Ctrl+h using JOSM), then there is a bus stop in that exact location. I suspect that this is true of many stops elsewhere, so some cautionary line by line merging is going to be needed. The OSM history mechanism is flawed in that it can only track one side of a merge (more generally, detaching a node from a way without creating a new node can be difficult, although not many NaPTAN nodes have been accidentally attached to ways). several stops which I have created, for which there is no NaPTAN data in the current database. A small proportion of NaPTAN data has gone missing either through personal mapping (people don't want the stops cluttering their map) or because people decided that the stop wasn't present, but never read the bit about leaving the node, marking physically_present=no and not a bus_stop. I've definitely seen the former and there are cases where the latter is the most obvious explanation. One of the things I find missing from the process is actually an audit against the original import, to recover those cases - or to detect deliberate damage to the imported information. Another issue with NaPTAN is stop area names. There is nothing on the ground to identify these, but the actual stop names change relatively frequently as landmarks come and go. Often stops within a stop area have different names. At the moment, this means that as you zoom out of the transport map, the name can change to one that is no longer/not used on the ground. I don't know if a re-merge would help with that, or whether there is a more fundamental problem with stop area names. On the more general issue of maintaining bulk data, I've found I've inherited several high streets where someone takes a photograph, maps it six months later, and never returns to check changes, something which really needs doing at least every three months. I have taken on maintaining those within a couple of kilometres, but I'm aware of other ones which I don't visit often enough to recognize changes, or detect errors in the original mapping. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] highway=trunk Roads and Cycle Navigation
On 27/07/14 22:26, ianmspen...@gmail.com wrote: So there should be a clear tagging that is distinct for the meaning of “trunk (UK sense)” vs “trunk (International sense) The logical conclusion of this would be that there would have to be a different tag for every jurisdiction. In this context a jurisdiction could be a city, not just a country, as they all have the potential to change the rules independently of each other, at any time. (Although I can't think of a good example for routing, at the moment, rules for highways differ from the rest of the county in London, e.g. there are more strict rules on pavement parking and blocking dropped kerbs.) That would actually make life more difficult for routing software developers, as they would need to have a table listing all of the variants, even if most where the the same. The current rules are set for the benefit of the many amateur mappers, not for the few professional software developers. Even in areas where the rules require the use of a single international standard, namely phone numbers, the British amateur mappers regularly break the rule by giving national format numbers or even +44(0) format numbers, because that is how they are used to representing them, and because it is more difficult for part time mappers to learn and remember the rules than it should be for a professional software developer. Of course commercial software development managers, when given something apparently free for cost, do tend not to budget for the cost of making it usable in their application. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] highway=trunk Roads and Cycle Navigation
On 25/07/14 17:15, Philip Barnes wrote: Are you proposing we tag for the renderer by not tagging trunk roads as trunk? No. He wants people to tag for the router, not the renderer. I think that is a bad idea, although not as bad when most trunk roads weren't already mapped, as it is doing something for the convenience of a small number or routing software developers rather than a large number of mappers. It could be argued that the current approach is actually tagging for the renderer, except that the details in question don't get rendered in the standard rendering. In practice, though, it is more likely that roads would have been mis-tagged if the most common case required extra permissions to be be explicitly added. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] os.openstreetmap.org down since at least Sunday
os.openstreetmap.org has been down every time I've tried since last Sunday. I've tried from two completely unrelated ISPs. I've googled for news, but found none, and the wiki still quotes it as the official tile server for OpenData StreetView. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Getting vandalism reverted without associating email address with location
Is there any mechanism for reporting and reverting vandalism that doesn't tend to associate the non-OSM internet identity of the reporter with their likely physical location. As far as possible I try to avoid my internet ID and my physical location being associated, but assume that the OSM ID is compromised in that respect. I don't even want to go into too much detail about the nature of the vandalism here. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Getting vandalism reverted without associating email address with location
On 05/08/13 11:22, SomeoneElse wrote: David Woolley wrote: I don't even want to go into too much detail about the nature of the vandalism here. If you did want to give an example without making any specific reference, perhaps you could perform similar vandalism (in a different place with different names / other identifying info) using the dev API: http://api06.dev.openstreetmap.org/#map=18/53.12037/-0.52980 The reason I'm uncomfortable about giving details is that they would allow the reversion to be identified. In this case, I don't think there is any issue that there was vandalism. If necessary, I'll do a piecemeal reconstruction of the bits that are blocking me, but that may prevent a proper reversion. I'll give you some more details off list. Please don't copy them back on list. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Getting vandalism reverted without associating email address with location
On 05/08/13 12:37, Craig Wallace wrote: You can revert it yourself, using the JOSM reverter plugin. OK Thanks. I suspected something like that must exist, but I'd got to http://wiki.openstreetmap.org/wiki/Vandalism, which led me to http://wiki.openstreetmap.org/wiki/GB_revert_request_log, which said I had to go to this mailing list. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb