> 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)
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
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.
In reply to this post by Great Britain mailing list
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.
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
Silent Spike wrote:
> 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).
The application I wrote and use is available on github and has some (perhaps now a bit dated) notes on use available there:
https://github.com/EdLoach/CheckPublicTransportRelations/tree/develop The develop branch (above link) is what I'm currently using - I've not created a recent release to incorporate bug fixes, so should probably do so when I get a moment. I think there might be a current bug relating to adding new areas that aren't added in the default locations file on first run, so should probably fix that first.
I've avoided the recent tagging discussions emails. The app is written to validate against the adopted PT v2 schema as documented in the wiki, with additions to handle tagging noted in either the wiki or on this list dating from the time of the previous naptan stop import, and that I completely don't care about public_transport=stop_position. E.g. I have a "surveyed" property based on the various tags discussed previously: physically_present, flag, kerb, timetable_case and shelter (which I've taken as signs the imported stop has been physically surveyed, though typing this now I wonder if I should exclude shelter like I do layby as it can possibly be determined from aerial imagery - I just know I haven't locally):
https://github.com/EdLoach/CheckPublicTransportRelations/blob/master/CheckPublicTransportRelations/MainForm.cs#L365 (this is in the method that takes the OSM XML and converts it into one of by BusStop objects).
Basically it compares the OSM data with the Opendata and I try and fix discrepancies manually, either tweaking the route relations that have changed or by adding new route variants if required. I have occasionally been rate limited by overpass since I added a hyperlink column to zoom to a stop, rather than doing click on naptancode cell, ctrl-c, switch to JOSM, ctrl-f, ctrl-v, enter, check whether more than one node has been selected (as for example 1500IM111 might match all these without adding extra bits after ctrl-v: 1500IM111, 1500IM1110, 1500IM1111, 1500IM1112, 1500IM1112Y, 1500IM1114, 1500IM1114Y, 1500IM1115, 1500IM1116, 1500IM1117, 1500IM1117Y, 1500IM1117YB, 1500IM1117YC, 1500IM1119) - if I get limited I just take a break for a while.
The application isn't clever enough to know when a particular route variant runs, so if you run it at an unfortunate time you might find you add all the current route variants and all the ones that replace them starting soon so are also in the file, and next time you run the application have to delete half of what you added the previous time. A recent route change did give me forewarning of when a new roundabout on the A120 was about to open when a new route variant appeared, changing from the old route as it passed through a village near the new roundabout, to head northwest towards the roundabout instead of north to the gap in the dual carriageway that was due to close when the roundabout opened.