Re: [Talk-GB] NaPTAN (stop) import
On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] NaPTAN (stop) import
Right - I was just trying to understand which was the canonical source. One of the things I've been wanting to try (but never have the time) is repair the OSM bus route relations based on the TNDS schedule info - which sounds very much like your track-finding system. But that gets dangerous if TNDS is indirectly pulling data from OSM itself.. Oliver On 1 August 2014 14:20, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: Oliver, TNDS data (Traveline National Data Set, for other’s benefit - national set of bus coach timetables) does not currently have the route detail - known in TransXChange as tracks. This is because up to now there have been issues of IPR with OSGR coordinates derived from OS and/or Navteq data. Certainly from our point of view - and by “us” I mean the traveline regions of South East, London, East Anglia, South West, East Midlands and (shortly) West Midlands - we are all now on a merged system using OSM data so those problems have gone away. But I still won’t be exporting Tracks until TNDS asks me to. Even then, it still has the issues of “is this right”. Most of the time it is, but we do get some routes which find a shorter path along a back street rather than down the main road. Cheers Stuart *From:* Oliver Jowett [mailto:oliver.jow...@gmail.com] *Sent:* 01 August 2014 1:51 PM *To:* Stuart Reynolds *Cc:* Talk GB *Subject:* Re: [Talk-GB] NaPTAN (stop) import On 1 August 2014 11:17, Stuart Reynolds stu...@travelinesoutheast.org.uk wrote: In terms of bus routes, we also compute the most likely route between stops, and could use that to update the services on each link. But that is a whole different ball game - we have to make sure our data is good quality, and I will need to think what to do when a bus turns off halfway along a road that is mapped as one line, for example, - and I’m not about to get into that for now! Although I would like to, eventually! Where does TNDS fit into this? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 1 December 2013 19:03, Rob Nickerson rob.j.nicker...@gmail.com wrote: For most users, you just need to log-in and tick the always stay logged in button and the welcome box will go. As an often requested feature I am sure that someone will write the required code to add a close button (or my preference - an up/down arrow to roll it up/down as required), but there will also need to be a way to bring it back. What's the workaround for users that do not wish to retain cookies? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 1 December 2013 20:19, Frederik Ramm frede...@remote.org wrote: Hi, On 01.12.2013 21:00, Oliver Jowett wrote: What's the workaround for users that do not wish to retain cookies? GreaseMonkey could be an option. The barrier to entry in setting that up is a bit high for me unfortunately (unless you have a script already prepared?) Richard's pull request sounds like it'll work for me (I don't mind clicking a close box each time), so +1 for that. Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 1 December 2013 20:46, Frederik Ramm frede...@remote.org wrote: Hi, On 01.12.2013 21:32, Oliver Jowett wrote: The barrier to entry in setting that up is a bit high for me unfortunately (unless you have a script already prepared?) This'll do: Works like a charm! Thanks :) Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 17 November 2013 00:10, Tom Hughes t...@compton.nu wrote: The point is that just using the map is not our target audience. As has been said many times, we are not trying to be an end user mapping site that offers a Google Maps alternative for the masses. Our target audience is people that want to signup and contribute. I contribute when I see problems with the map in areas I am familiar with. To see the problems, I have to be using the map in the first place. To use the map I'd prefer not to have that signup box floating around all the time (I am only logged in when I am about to edit). Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 17 November 2013 15:06, Rob Nickerson rob.j.nicker...@gmail.com wrote: To use the map I'd prefer not to have that signup box floating around all the time (I am only logged in when I am about to edit). Oliver You could tick the stay logged in button, I don't retain cookies between browser sessions. or alternatively if you want a full screen map there are plenty of sites that provide alternate views of OSM data. One such full screen example is at: http://faffy.openstreetmap.org/?zoom=4lat=47.63024lon=1.75347layers=B Is the response to Here's a usability issue with the proposed changes really use something else then? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Upcoming changes to OpenStreetMap.org website
On 17 November 2013 21:42, Rob Nickerson rob.j.nicker...@gmail.com wrote: p.s. This redesign is a proposal from John of the MapBox team. It will ultimately be accepted or rejected by the OSM Foundation/working groups. Anyone can propose changes, so if you have the coding skills to make this change then feel free to do it and add a pull request on github. Oof, web development is really not my favorite activity :( I don't have much more to say here and I don't really want to get into a big discussion about the pros and cons of what osm.org should show - I'll just limit myself to reiterating that a close button on that bit of the new design would be a great idea, even if I have to hit it every time I visit :) Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Advice needed for maxweight turning restriction
On 14 October 2013 13:24, Robert Whittaker (OSM lists) robert.whittaker+...@gmail.com wrote: The note is great for humans, but won't be able to be interpreted by routing algorithms. Using the Conditional Restrictions from http://wiki.openstreetmap.org/wiki/Conditional_restrictions , I'd suggest adding using the following tags: oneway = yes oneway:bicycle = no oneway:conditional = no @ height13'13 The makes the road one-way, unless you're riding a bike or higher than 13'13. I'd leave the note=* bit in to clarify the unusual situation in human-readable language for other mappers. Similar case: http://www.openstreetmap.org/browse/way/22974367 (streetview: http://goo.gl/maps/JjNKR and http://goo.gl/maps/x8Z0S) One-way for vehicles with MGW3t, two-way for bicycles, no access for other vehicles. That uses bicycle:backward=yes, rather than oneway:bicycle=no Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-gb-midanglia] Guided Busway Cycleway
On 16 September 2013 11:49, David Earl da...@frankieandshadow.com wrote: On 16/09/2013 10:08, Oliver Jowett wrote: It does render differently (I know, don't tag for the renderer, but it seems reasonable for a renderer to infer the primary use from the highway tag) Indeed, but it's a rather subjective approach. The usual rule is map what you see, not what you think, and in this case it is signed as a bridleway (and is also designated as such). A good rendering would take note of the surface tag when displaying cycle specific information. Well, it does already have designation=public_bridleway too. I'll try to ride the length of the path some time checking what exactly is signposted. I wonder if cyclestreets assigns different costs to highway=bridleway vs highway=cycleway? It does show them differently in the resulting directions, at least. Oliver ___ Talk-gb-midanglia mailing list Talk-gb-midanglia@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-midanglia
Re: [Talk-GB] Phone numbers in little England
On Thu, Aug 22, 2013 at 8:35 AM, OpenStreetmap HADW osmh...@gmail.comwrote: - no delimiter (+442079460676) - misplaced delimiter (+44 207 946 0676) Aren't these unambiguous already? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Phone numbers in little England
On Thu, Aug 22, 2013 at 9:01 AM, OpenStreetmap HADW osmh...@gmail.comwrote: On 22 August 2013 08:43, Oliver Jowett oliver.jow...@gmail.com wrote: - no delimiter (+442079460676) - misplaced delimiter (+44 207 946 0676) Aren't these unambiguous already? They breach the existing guidelines, which call for the (UK usage) area code to be delimited. In particular, in London, you can dial this number as 00442079460676, 02079460676 or 79460676. On the other hand, dialing it as 9460676 will fail. (Always assuming it weren't a bogus number for drama use.) In any case, about 90% of people who used international format seemed to agree that +44 20 7946 0676 was the right grouping, even if some of them added the (0). My point is that in this case, it's unambiguous what the fully-qualified number means, regardless of where the spaces fall, so the edit is not actually adding anything other than a particular display format. Isn't that a policy to impose in the frontend that presents the data, not in the data itself? In the case of numbers such as 79460676, they suffer from ambiguity as you need to know some extra information (country code, area code, etc) to be able to produce a globally-unique number - so fixing those is a good plan. Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Usage of lanes / turn restrictions versus multiple ways when road is not divided
I did something similar to this junction: http://osm.org/go/0EQSYTukM-- / http://binged.it/16jtNsx (note that the most detailed aerial photo is quite old and predates the guided busway - zoom out for more recent imagery) primarily to get routing right. The current version reflects some combination of physical traffic islands (definitely necessary to get cycle / pedestrian routing correct) and paint islands. If there's a better way to represent this while keeping enough information to be able to route sensibly, how should it be done? Oliver On Thu, May 9, 2013 at 1:06 PM, David Earl da...@frankieandshadow.comwrote: On 09/05/2013 12:56, Jason Cunningham wrote: UK legislation is fairly clear that Traffic Islands (with or without hatched markings before are after) are not considered to create two carriagways. We're not mapping legislation, but nethertheless I wouldnt create two carriageways for a traffic island in a stretch of road... What do people think of this: http://osm.org/go/0EQSJEoZT-- (aerial: http://binged.it/10kuDNm ) and this: http://osm.org/go/eu6_VCkLp-- (aerial: http://binged.it/16js1Ye ) I was dubious when I first saw what someone (not me) had done in these two locations. On the other hand, it is hard to represent properly how pedestrians are intended navigate a junction if you don't represent the islands, so I have warmed to it a bit. It does make rendering a street map a mess, often with lots of apparently superfluous one way arrows and a bulge, except at a very large scale. David __**_ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-gbhttp://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Usage of lanes / turn restrictions versus multiple ways when road is not divided
On Thu, May 9, 2013 at 1:40 PM, David Earl da...@frankieandshadow.comwrote: On 09/05/2013 13:30, Oliver Jowett wrote: If there's a better way to represent this while keeping enough information to be able to route sensibly, how should it be done? You can set up turn restrictions with relations where necessary. Right, I have turn restrictions in the current junction. It's been a while since I did it, but IIRC I actually needed to split up the junction to be able to express the turn restrictions correctly. Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Usage of lanes / turn restrictions versus multiple ways when road is not divided
On Thu, May 9, 2013 at 2:19 PM, SomeoneElse li...@mail.atownsend.org.ukwrote: First of all - thanks for all the replies. I've added a link to this thread to the map note. David Earl wrote: What do people think of this: http://osm.org/go/0EQSJEoZT-- (aerial: http://binged.it/10kuDNm ) It's a couple of months since I was there, but my recollection is that that one (Cambridge) is a fair representation of reality. There is stuff on the (very narrow) strip in the middle of the road isn't there? A westbound ambulance wanting to do a U-turn would have to go as far as the former garage (where the white structure at the top of the Bing imagery is) to turn back I think. The centre strips are raised islands with a kerb, and most of them have barriers too. Having cycled through that junction regularly in the past, I can vouch for it being as complicated as it looks! Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 10 fascinating facts about OSM OSGB
On Thu, Apr 18, 2013 at 3:02 PM, Chris Hill o...@raggedred.net wrote: On 18/04/13 14:14, Shaun McDonald wrote: On 18 Apr 2013, at 13:01, Dave F. dave...@madasafish.com wrote: On 18/04/2013 12:52, Shaun McDonald wrote: Updates are a lot harder to do as you have to deal with differences When you say differences, do you mean within the tags? Does it need to do that, could it not do a simpler find replace? If someone has modified the item in OSM and in NaPTAN then it needs manual intervention as to which is more correct - the one in OSM or the one in NaPTAN. Shaun There are various errors in NaPTAN data. The data was created by different means in different local authorities and to varying standards of quality. The position is not always very accurate, but sometimes the accompanying information can be poor too. Some data are very good, but until you survey it you just don't know. As someone who has manually validated every stop in in a city (~1300) and about a third (~900) of the stops in a large Unitary Authority I can vouch for the differences and the wide variation in quality. It became clear that in the city the quality varied from area to area. I suspect that some areas were surveyed or recorded or checked more diligently than others possibly because a more diligent or competent person did the work there. Can I ask what type of changes you made to the NaPTAN data when manually validating the stops? I've been meaning to look at exactly this - updating the NaPTAN imported data - for a little while now as it's needed before the TNDS data (which has route / timetable info) can be usefully used. My rough plan was to assume that all tags under the naptan: namespace were fair game for updating to match the current NaPTAN import. Whether that's practical will depend on if there have been widespread manual changes to the naptan: data or not. Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 10 fascinating facts about OSM OSGB
On Thu, Apr 18, 2013 at 4:57 PM, Chris Hill o...@raggedred.net wrote: I followed the guidelines in the wiki [1] That seems to boil down to don't modify naptan: tags except naptan:verified, so hopefully we won't have to worry about conflicts between import updates and manual changes there. Not sure what to with naptan:verified=yes when updating a stop, setting it to no and leaving it unchanged both seem unsatisfactory. and use the NOVAM viewer [2] That's a nice viewer! Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 10 fascinating facts about OSM OSGB
On Thu, Apr 18, 2013 at 7:15 PM, Chris Hill o...@raggedred.net wrote: On 18/04/13 18:12, Oliver Jowett wrote: On Thu, Apr 18, 2013 at 4:57 PM, Chris Hill o...@raggedred.net mailto: o...@raggedred.net wrote: I followed the guidelines in the wiki [1] That seems to boil down to don't modify naptan: tags except naptan:verified, so hopefully we won't have to worry about conflicts between import updates and manual changes there. There are many naptan:* tags that are not mentioned on the page. If you find any that are not consistent with what you find on the ground, change them. Examples are bearing, street, Atcocode, landmark, all of which I found often to be wrong. Various authorities include different levels of detail, so there may be more tags than this. All are open to change if you find an error. I'm a bit confused now. The wiki page says Tags that start with Naptan should not be edited until a system had been agreed on (except naptan:verified=*, see below). Have you been updating the naptan tags in-place as you find errors, or correcting the data elsewhere (e.g. by modifying name= as the wiki page suggests)? On the NOVAM example you linked, I see stops where there is a note saying that the NaPTAN Bearing is wrong and should be some other value, but the original value is still there in naptan:Bearing. (On another note, shouldn't source=naptan + survey be source=naptan_import; survey?) Not sure what to with naptan:verified=yes when updating a stop, setting it to no and leaving it unchanged both seem unsatisfactory. If a stop has been verified, delete the naptan:verified=*. Oh, right, I misread how that was used. However my point is that when merging updated data from NaPTAN to a stop that has been verified on the ground, we want some way to say this has been verified manually at some point in the past, but there have been subsequent imported changes that may need re-verification - how should we represent that? (naptan:verified=previous_import? naptan:unverified=CommonName;Bearing?) I should add that I sent all of the anomalies I found to my local councils. having said they were interested, both ignored my data, so OSM in my area is still more accurate that the NaPTAN data. Local authorities provide the data that ends up in NaPTAN. I would not, therefore, support updating OSM with another NaPTAN import in my local area. I'm working around Cambridge where there's been essentially no verification done, and there have been various route and stop changes since the import so the current TNDS data now references many stops that do not exist in OSM, and there are lots of dead stops. An update is definitely needed here! Since the original imports were done piecemeal I expect the same would happen with any updates, so at worst we can just not update areas with good coverage that we don't want to touch. Ideally, though, we'd take the best of both datasets. Certainly we would not want to clobber manual corrections with the old, wrong, import data, but if we get new NaPTAN data then it's probably worth at least flagging the changes for further inspection? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] 10 fascinating facts about OSM OSGB
On Thu, Apr 18, 2013 at 7:50 PM, Rob Nickerson rob.j.nicker...@gmail.comwrote: Or perhaps a comparison between the old and new NaPTAN data would be better? Do we have the old data around? (I'm not clear whether all the original imports were from one dataset, or several over time) Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Messed up buildings in Preston
On Wed, Mar 13, 2013 at 6:59 PM, Andy Allan gravityst...@gmail.com wrote: And does anyone know how widespread such Auto_OS_OpenData_StreetView damage is around the country? Taginfo suggests there's 45 598 cases - hopefully not all this bad? http://taginfo.openstreetmap.org/tags/source=Auto_OS_OpenData_StreetView Presumably this is output from http://wiki.openstreetmap.org/wiki/Mapseg(which has suitably big warnings about automated imports etc) Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] TNDS and NaPTAN data
Hi Has anyone looked at using TNDS (http://traveline.info/tnds.html) as a basis for importing bus routes into OSM? I've had a quick look at the data and it looks like it would be possible to extract at least the stop ordering for each route. In theory it can also have the road routes between stops, but the local routes I looked at (Stagecoach Cambridge) only have the stops, not the routes between them. Still, even the stop list would a good start. The background here is that while updating my local area and removing a bus route that no longer runs through there, I ended up rebuilding the whole route by hand from timetable information as the OSM route relation was quite out of date and had missing road sections/stops/etc. Looking at other routes in the area, they have similar errors. Transcribing routes by hand is quite a lot of work - just the one route I did took a couple of hours to get right. A related issue is that the stop information imported from NaPTAN is getting out of date. The TNDS data uses NaPTAN stop references and - at least around Cambridge - there are some new stops in the TNDS routes that don't exist at all in the current OSM data. Is there an existing mechanism to update the NaPTAN data? Or what would be the right way to add the missing stops? Oliver ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
