Re: [Talk-GB] Importing NaPTAN Data
4 lip 2019, 19:28 od talk-gb@openstreetmap.org: > On 04/07/2019 16:39, Martin Wynne wrote: > >> On 04/07/2019 16:11, Dave F via Talk-GB wrote: >> >>> >>> In OSM we map *physical* objects only. >>> >> >> In rural areas there are many places where buses are timetabled to stop but >> where there is nothing physical -- no signpost or shelter. >> > > These are still 'physical' in the sense that they exist in the timetable & > Naptan documents. (Think also boundaries which don't have dashed lines > painted across fields) > In that sense everything is physical, boundaries also have paper records and there are some markers. >> >> The wiki for highway says "Can be mapped more rigorously using >> public_transport=stop_position for the position where the vehicle stops and >> public_transport=platform for the place where passengers wait. >> > > It's disappointing to see, once again, the PT schema developers hi-jacking > wiki pages to enforce their schema. The comments column is meant to describe > how to use the tag not promote alternatives. This needs changing. > Yeah, there is nothing more rigorous in extremely verbose PTv2 tagging. > highway=bus_stop is perfectly adequate to locate the place where people wait > for a bus. 'platform' is redundant > > PTv2 is a complete mess. it needs rescinding. > I completely agree here.___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On Thu, Jul 04, 2019 at 06:49:10PM +0100, Dave F via Talk-GB wrote: > > > On 04/07/2019 16:59, Silent Spike wrote: > > > > My understanding is that `public_transport=platform` is any place where > > public transport can be accessed > > Same as bus_stop/tram_stop, you mean? > > > and should not literally be interpreted as > > a physical platform > > then why hi-jack the word 'platform' which has a clear, specific meaning? > Yet more confusion > > > If anything `highway=bus_stop` is redundant data, > > It's is a well established, popular tag far exceeding any PT tags > > > however it's necessary > > for render compatibility (violating the "don't tag for the renderer rule" > > I think your logic got a bit twisted around. bus_stop is the original & no > PT tag adds anything extra to improve the database. > > > and (in my opinion) should not impede mapping progress. > > Existing tags work, Changing for the sake of change is irrelevant. PTv2 > needs to be rescinded. +1 ael ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On 04/07/2019 18:51, Dave F via Talk-GB wrote: These are still 'physical' in the sense that they exist in the timetable & Naptan documents. (Think also boundaries which don't have dashed lines painted across fields) This strikes me as a strange definition of "physical" and could cover almost anything. My definition of "physical" is something I can take a photograph of. But I don't see any reason why OSM should be limited to such "physical" objects. Most maps show all sorts of non-physical data. cheers, Martin. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
In OSM we map *physical* objects only. What about border - especially lower administrative units and nature reserves? From a previous post: These are still 'physical' in the sense that they exist in the timetable & Naptan documents. (Think also boundaries which don't have dashed lines painted across fields) DaveF ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On 04/07/2019 16:59, Silent Spike wrote: My understanding is that `public_transport=platform` is any place where public transport can be accessed Same as bus_stop/tram_stop, you mean? and should not literally be interpreted as a physical platform then why hi-jack the word 'platform' which has a clear, specific meaning? Yet more confusion If anything `highway=bus_stop` is redundant data, It's is a well established, popular tag far exceeding any PT tags however it's necessary for render compatibility (violating the "don't tag for the renderer rule" I think your logic got a bit twisted around. bus_stop is the original & no PT tag adds anything extra to improve the database. and (in my opinion) should not impede mapping progress. Existing tags work, Changing for the sake of change is irrelevant. PTv2 needs to be rescinded. DaveF ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
This is getting a little bit off topic. I guess to bring things back on
track, would there be any objections to an import along these lines:
1. Import data specifically for the Aberdeen admin area (ATCO code 639)
2. Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
3. Import BCT stops of type MKD ("Marked (pole, shelter etc)")
4. Manually conflate and review the data before upload using JOSM
5. Split the edits up according to the "LocalityName" data field
(basically districts from what I can tell) [or is it better to be one
changeset for the whole area?]
6. Tag the stops using:
- `highway=bus_stop`
- `public_transport=platform`
- `bus=yes`
- `name=*` [Imported]
- `naptan:AtcoCode=*` [Imported]
- `naptan:NaptanCode=*` [Imported]
- `source=naptan`
- `naptan:verified=no`
___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On 04/07/2019 16:39, Martin Wynne wrote: On 04/07/2019 16:11, Dave F via Talk-GB wrote: In OSM we map *physical* objects only. In rural areas there are many places where buses are timetabled to stop but where there is nothing physical -- no signpost or shelter. These are still 'physical' in the sense that they exist in the timetable & Naptan documents. (Think also boundaries which don't have dashed lines painted across fields) Are these highway=bus_stop in OSM? As a guesstimate, if they came from the naptan import, then probably yes The wiki for highway says "Can be mapped more rigorously using public_transport=stop_position for the position where the vehicle stops and public_transport=platform for the place where passengers wait. It's disappointing to see, once again, the PT schema developers hi-jacking wiki pages to enforce their schema. The comments column is meant to describe how to use the tag not promote alternatives. This needs changing. "public_transport=stop_position for the position where the vehicle stops" But that's not happening, is it? it's being wastefully duplicated on the highway=bus_stop which is most often at the pole/sign location, not on the highway. highway=bus_stop is perfectly adequate to locate the place where people wait for a bus. 'platform' is redundant PTv2 is a complete mess. it needs rescinding. DaveF ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
4 lip 2019, 17:11 od talk-gb@openstreetmap.org: > > In OSM we map *physical* objects only. > What about border - especially lower administrative units and nature reserves?___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On 04/07/2019 16:39, Martin Wynne wrote: In rural areas there are many places where buses are timetabled to stop but where there is nothing physical -- no signpost or shelter. Are these highway=bus_stop in OSM? (following a previous discussion on this list) I've used "physically_present=no" on one of those - after verifying that buses actually stop there. Example: https://www.openstreetmap.org/node/502390265 Best Regards, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On Thu, Jul 4, 2019 at 4:40 PM Martin Wynne wrote: > In rural areas there are many places where buses are timetabled to stop > but where there is nothing physical -- no signpost or shelter. > > Are these highway=bus_stop in OSM? > > The wiki for highway says "Can be mapped more rigorously using > public_transport=stop_position for the position where the vehicle stops > and public_transport=platform for the place where passengers wait. > I believe such stops would just be mapped with stop positions. However, I don't intend to import them currently as I'd need to look into that more in-depth (and want to keep things simple for now). Just getting the physical stops imported seems like a good first step which would have the most significant improvement on available data in OSM. ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On Thu, Jul 4, 2019 at 4:10 PM Dave F via Talk-GB wrote: > > Please, please don't use public_transport=platform unless you're > actually mapping an actual, physical, raised object, similar to railway > platforms. > > It has now been regressed one stage further, being superfluously added > to highway=bus_stop nodes. So much of the PT schema is just duplicating > valid, existing data which leads to confusion & errors. It is a waste of > time & effort. > My understanding is that `public_transport=platform` is any place where public transport can be accessed and should not literally be interpreted as a physical platform (tags not literally matching what they are used to map seem to be very common in OSM). I think if you want to constructively change tagging practise you need to discuss it on the tagging list and that the import I would like to do should follow established tagging. If anything `highway=bus_stop` is redundant data, however it's necessary for render compatibility (violating the "don't tag for the renderer rule", but everyone does it because default render still doesn't support PTv2 scheme). Until the wider OSM community establishes better methods of tag creation and deprecation these issues will continually crop up and (in my opinion) should not impede mapping progress. > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On 04/07/2019 16:11, Dave F via Talk-GB wrote: In OSM we map *physical* objects only. In rural areas there are many places where buses are timetabled to stop but where there is nothing physical -- no signpost or shelter. Are these highway=bus_stop in OSM? The wiki for highway says "Can be mapped more rigorously using public_transport=stop_position for the position where the vehicle stops and public_transport=platform for the place where passengers wait. cheers, Martin. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
naptan:verified=no dates back to the original import in 2009 and was there to indicate the bus stop needed surveying to verify its position- when a survey was done the process was for this tag to be deleted. Might be good to adopt this process here too? Regards Brian On Thu, 4 Jul 2019 at 16:10, Dave F via Talk-GB wrote: > > Please, please don't use public_transport=platform unless you're > actually mapping an actual, physical, raised object, similar to railway > platforms. > > 'platform' has been misappropriated from the physical railway=platform > by those who developed the PT schema to mean an arbitrary area of > pavement that's somewhere, roughly near where a bus stops. In OSM we map > *physical* objects only. > > It has now been regressed one stage further, being superfluously added > to highway=bus_stop nodes. So much of the PT schema is just duplicating > valid, existing data which leads to confusion & errors. It is a waste of > time & effort. > > -- > > if you're adding the bus stop & your source is naptan how can > naptan:verified=no? > > DaveF > > > On 02/07/2019 11:06, Ed Loach wrote: > > David wrote: > > > >> Given that few people like maintenance work, if you can't map all > >> the > >> stops from first principles, it is very unlikely that imported ones will > >> get maintained. Retaining the NaPTAN tagging is important in > >> allowing > >> any later remerge of the updated NaPTAN data. > > I've been regularly updating local bus route relations (all now upgraded > to PT schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of > Essex. This involves more maintenance than just the bus stops (which for > Essex were imported some years ago). I've written a program to help me with > this, comparing the opendata with the OSM data so I can work out what needs > updating. > > > > Occasionally I encounter a bus stop used by a bus route which wasn't > imported previously. In these cases I add the stop from NaPTAN (based on > their latitude and longitude) and add the tags: > > highway=bus_stop > > public_transport=platform > > source=naptan > > naptan:verified=no > > name=(NaPTAN name) > > naptan:AtcoCode=(whatever) > > naptan:NaptanCode=(whatever) > > > > If the bus stop type is not MKD I add > > > > naptan:BusStopType=(bus stop type) > > > > and if the status is not "act" I add > > > > naptan:Status=(status) > > > > This last one is very rare as I think it is only once that I've found a > deleted bus stop still part of a bus route (the road had been diverted and > new stops installed - the old stop was on what is now a cycle path). > > > >> Another problem with NaPTAN stops, which applies to non-OSM > >> users as > >> well is that they have virtual stops in Hail and Ride areas. Routers > >> seem to only like people boarding at those place, so, in my case, can > >> take me about 7 minutes out of my way against the direction of > >> travel, > >> so tell me I have missed a bus that could be easily caught. > > I'll agree with this. I've been adding them at the NaPTAN location as > described above if they aren't already in, but these are occasionally up > cul-de-sacs (usually at the start or end of the route). > > > > Ed > > > > [1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes > > [2] > https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes > > > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > > > ___ > > Talk-GB mailing list > > Talk-GB@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-gb > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
Please, please don't use public_transport=platform unless you're actually mapping an actual, physical, raised object, similar to railway platforms. 'platform' has been misappropriated from the physical railway=platform by those who developed the PT schema to mean an arbitrary area of pavement that's somewhere, roughly near where a bus stops. In OSM we map *physical* objects only. It has now been regressed one stage further, being superfluously added to highway=bus_stop nodes. So much of the PT schema is just duplicating valid, existing data which leads to confusion & errors. It is a waste of time & effort. -- if you're adding the bus stop & your source is naptan how can naptan:verified=no? DaveF On 02/07/2019 11:06, Ed Loach wrote: David wrote: Given that few people like maintenance work, if you can't map all the stops from first principles, it is very unlikely that imported ones will get maintained. Retaining the NaPTAN tagging is important in allowing any later remerge of the updated NaPTAN data. I've been regularly updating local bus route relations (all now upgraded to PT schema v2) in Tendring [1], Colchester [1] and Maldon [2] areas of Essex. This involves more maintenance than just the bus stops (which for Essex were imported some years ago). I've written a program to help me with this, comparing the opendata with the OSM data so I can work out what needs updating. Occasionally I encounter a bus stop used by a bus route which wasn't imported previously. In these cases I add the stop from NaPTAN (based on their latitude and longitude) and add the tags: highway=bus_stop public_transport=platform source=naptan naptan:verified=no name=(NaPTAN name) naptan:AtcoCode=(whatever) naptan:NaptanCode=(whatever) If the bus stop type is not MKD I add naptan:BusStopType=(bus stop type) and if the status is not "act" I add naptan:Status=(status) This last one is very rare as I think it is only once that I've found a deleted bus stop still part of a bus route (the road had been diverted and new stops installed - the old stop was on what is now a cycle path). Another problem with NaPTAN stops, which applies to non-OSM users as well is that they have virtual stops in Hail and Ride areas. Routers seem to only like people boarding at those place, so, in my case, can take me about 7 minutes out of my way against the direction of travel, so tell me I have missed a bus that could be easily caught. I'll agree with this. I've been adding them at the NaPTAN location as described above if they aren't already in, but these are occasionally up cul-de-sacs (usually at the start or end of the route). Ed [1] https://wiki.openstreetmap.org/wiki/Tendring(Essex)/Bus_Routes [2] https://wiki.openstreetmap.org/wiki/Maldon(Essex_District)/Bus_Routes --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
It's also useful to add shelter=yes if there is one route_ref= x;y indicating bus route nos that stop there (if indicated on the stop) CUS stops are also useful to add but omitting the highway=bus-stop tag ( you can always add the public tranpsort stop_poisition as a node on the highway). They often become marked with pole over time There's also a relatively new tag to indicate if the bus stop allows the bus to pull in to a small layby off the main highway (but I've forgotten what it is) Your local bus authority might also be able to help (in the West Mids TfWM have been very helpful) Personally I've given up on bus route relations: they're a time sink in editing them in the first place and they're even more of a time sink to maintain. I think they're better off in a separate layer in dedicated journey planners maintained by public transport authorities. Regards Brian Regards Brian On Thu, 4 Jul 2019 at 14:54, Silent Spike wrote: > On Tue, Jul 2, 2019 at 11:07 AM Ed Loach wrote: > >> highway=bus_stop >> public_transport=platform >> source=naptan >> naptan:verified=no >> name=(NaPTAN name) >> naptan:AtcoCode=(whatever) >> naptan:NaptanCode=(whatever) >> >> If the bus stop type is not MKD I add >> >> naptan:BusStopType=(bus stop type) >> >> and if the status is not "act" I add >> >> naptan:Status=(status) >> > > These tags all seem reasonable to import to me. Would be curious to learn > more about your route maintenance process. I have a list of local bus route > relations I've been meaning to update, but it's hard to do so without all > of the stops mapped (hence my desire to import the available data). > > >> ___ >> Talk-GB mailing list >> Talk-GB@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-gb >> > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Importing NaPTAN Data
On Tue, Jul 2, 2019 at 11:07 AM Ed Loach wrote: > highway=bus_stop > public_transport=platform > source=naptan > naptan:verified=no > name=(NaPTAN name) > naptan:AtcoCode=(whatever) > naptan:NaptanCode=(whatever) > > If the bus stop type is not MKD I add > > naptan:BusStopType=(bus stop type) > > and if the status is not "act" I add > > naptan:Status=(status) > These tags all seem reasonable to import to me. Would be curious to learn more about your route maintenance process. I have a list of local bus route relations I've been meaning to update, but it's hard to do so without all of the stops mapped (hence my desire to import the available data). > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Mapillary geoJSON data
My first thought is recycling points. My second is (related to the quarterly project) solar panels. On Thu, Jul 4, 2019 at 10:39 AM Gareth L wrote: > Mapillary imagery is readily available in the iD editor and also the > traffic sign detections data that they derive from it. Their computer > vision efforts also detect a plethora of other items, to varying levels of > accuracy on detection and triangulation. > > They recently wrote a blog post about how they allow access to the data > sets derived from the imagery, which is free for non-commercial direct to > OSM use, although they charge it out to other companies. > > > > The blog post is > https://blog.mapillary.com/update/2019/05/23/map-features-in-openstreetmap.html > which also explains how to access it in GeoJSON form or using pic4review. > > And the item detections that they support are listed here: > https://www.mapillary.com/developer/api-documentation/#points > > > > As mapillary’s content gets older, i believe it’s possible to request the > results from only imagery in a specified time period, hopefully eliminating > stale results. > > > > The blog post does say that they’re trialling parts of the data with > certain osm communities before making it more widely available for OSM > contributors. At the moment, specific geoJSON data needs to be requested > through an organization account. > > > > I personally found the pic4review task which helped refine tags for > benches having a backrest very satisfying. > > > > What specific use cases can you think of for this? > > > > Gareth > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Mapillary geoJSON data
Mapillary imagery is readily available in the iD editor and also the traffic sign detections data that they derive from it. Their computer vision efforts also detect a plethora of other items, to varying levels of accuracy on detection and triangulation. They recently wrote a blog post about how they allow access to the data sets derived from the imagery, which is free for non-commercial direct to OSM use, although they charge it out to other companies. The blog post is https://blog.mapillary.com/update/2019/05/23/map-features-in-openstreetmap.html which also explains how to access it in GeoJSON form or using pic4review. And the item detections that they support are listed here: https://www.mapillary.com/developer/api-documentation/#points As mapillary’s content gets older, i believe it’s possible to request the results from only imagery in a specified time period, hopefully eliminating stale results. The blog post does say that they’re trialling parts of the data with certain osm communities before making it more widely available for OSM contributors. At the moment, specific geoJSON data needs to be requested through an organization account. I personally found the pic4review task which helped refine tags for benches having a backrest very satisfying. What specific use cases can you think of for this? Gareth ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
