Re: [Talk-transit] SotM: tram network of Milano
Hello everybody, the code is public available as part of the Overpass API repository and has always been. A pointer to the main file is: https://github.com/drolbr/Overpass-API/blob/minor_issues/src/pt_diagrams/topographic.cc I'm sorry for the confusion. "not publicly announced" shall mean that there is no documentation because the code never got production ready. Line separation works, colour selection works good enough, label placement doesn't work and is a hard problem. This includes line numbers. I'm happy to answer questions to get that code to productive use. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] stop_position proposal
Dear all, as a follow-up a statistic about whether highway=bus_stop is rather used on-street or off-street. The vast majority is (now) mapping bus stops off the street. The numbers vary, 99% of all bus stops in United Kingdom are mapped off street, about 80%-90% in France, Italy, and Germany. But also only 65% in Poland. The request is per country, here "United Kingdom" as an example. Please change the country to your country of interest: https://overpass-turbo.eu/s/xXp The runtime can vary, and for Germany it is several minutes. The important data points are the first entries on the "Data" tab. The results visiable on the map indicate which stops the query could not sort as either on-the-road or off-the-road (including being on a footway or similar) because it could not classify the highway value as footway or vehicle related. highway=pedestrian is classified as vehicle way, because in all the examples I have checked it has been used that way: https://overpass-turbo.eu/s/xXq Maybe we should, rather than blurring the line between on-street and off-street use, make off-street the officially preferred way of mapping. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] stop_position proposal
Dear all, there is another proposal, distinct from Polyglot's proposal that is in RFC since some days: https://wiki.openstreetmap.org/wiki/Proposed_features/Drop_stop_positions_and_platforms Before I tell a personal opinion, I would like to present some related facts. The basic idea is to look how the tags are actually used. Taginfo tells us http://taginfo.openstreetmap.org/keys/public_transport that there are more platform tags than stop_position tags and both are so many that you cannot reasonably view them all on a map. About two thirds of elements with public_transport=platform bear also highway=bus_stop https://taginfo.openstreetmap.org/tags/public_transport=platform#combinations but there are at least more than 100'000 nodes (not ways, not relations, hence not fully mapped platforms) that are public_transport=platform but not highway=bus_stop. These are still too many to reasonably show them on a map (and to not talk what should happen about them). For you convenience, I have added a bbox limited request for those that you need to move to your area of interest: https://overpass-turbo.eu/s/xWI From my fist impression, most of them are simply not tagged with highway=bus_stop. However, the first hit in Rome is a tram stop that for a good reason is not tagged as highway=bus_stop. It is much less compelling to retag public_transport=stop_position as highway=bus_stop. Less than one third of them is tagged as https://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations And here, many belong to railways. Again, a bbox bounded query: https://overpass-turbo.eu/s/xWM Another matter are definitely wrong public_transport=stop_position, because they are off any highway, railway, or ferry. There is a surprsingly large number of them. I have made an area related request because we need the statistics in a moment: https://overpass-turbo.eu/s/xWF Running this request for Germany, France, Belgium, the Netherlands, Austria, and Switzerland shows that more than half of all global uses of stop_position are in these six countries (go to "Data", read the first entry). This is not an arbitrary selection - all these six countries have about 1000 to 2000 stop_positions per million inhabitants, but for comparision UK has only 150 stop_positions per inhabitant. However, the number of failures are significant, between 5% and 10% (with the exception of Belgium). The uneven distribution suggest that these relates to specific users, but the total number of users is more than 500, suggesting that there is a problem to explain the difference between stop_position and platform. All in all, I do agree that there is definitely room for the improvement of public transport mapping. But making the tagging of 500'000 nodes deprecated and neglecting both problems with that and the more presseing problems is probably not a good way to go forward. Given that Ilya refuses for unknown reasons to read this mailing list, please discuss the matter on the discussion page if he wiki page. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
Hi Polyglot, https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes I do agree that it would be easier for everyone to have one and only one member on the line relation per actual stop. However, trains and sometimes also trams can have a significant length. Walking the full length of a train can take as long as 7 or 8 minutes. There are applications that send people before stepping on the train to the right section to have a shortest possible walk after getting off (search for e.g. "london tube exit routing", no link here to not advertise a specific one). We render OSM useless for such applications if we force people towards adding fictitious nodes for trains. Please note that an easy approach like adding a node at the front position of the train does not bail out us because there are platforms that are called at in both directions of travel. In such cases, also the middle position of a train may vary. Therefore I suggest to drop the node requirement and keep up the requirement to have only one object per stop. A second thing for simplication: I suggest to require always a "name" tag on the member object or multiple "name:XX" tags if there is no preferred name in a multilingual setting. This way we could safely ignore relations for stop related objects. When writing both a plugin for JOSM and the display tool https://overpass-api.de/public_transport.html it was the most frustrating part to go on a quest to find the appplicable name if people had hidden it in some special relation, including scores of new possible kinds of error if one has no or multiple names from multiple stop_area relations and so on. This was the main reason to discontinue the development. I consider to write a proposal for the "name" requirement. Would it make more sense for you to instead include that in your proposal, i.e. add the requirement for the member object to have a "name" or multiple "name:XX" tags? Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
Hi all, 1. A general public transport service (e.g. No. 38): In OSM: "route_master" in GTFS: "route" For me that is a line. It has a line number. (which sometimes is not simply numeric, so it's more of a symbol, but OK) 2. A theoretical tour a bus takes, but without schedule information, it represents one each for different direction, but also if one is shorter than the other In OSM: "route"; in GTFS: /not existent/ I would call those itinerary. If OSM had started out with that term, we wouldn't have the ambiguity today. But route is used for foot/bicycle/horse and PT itineraries. For PT I resorted to call them route variations, but they are 'represented' by route relations in OSM. 3. An actual tour a bus takes, on a certain time In OSM" not existen; in GTFS: "trip" [..] If we could figure out a way to represent it anyway, I think it would be a plus. But I won't be holding my breath. I fully support that wording. But I would like to point you to another problem that has kept and is keeping OSM PT painful: There are two very distinct underlying data models in use by the transit agencies. The metropolitan (line based) model looks like subway lines usually look: The full schedule is essentially modeled by the itineraries plus the list of departure times per itinerary. This works because all trips have the same set of stops and approximately the same travel time. If there are many trips per itinerary then there might not even be a fixed list of departure times but just a defined departure frequency, like 05h48 06h00 then every 2 to 5 Minutes 19h00 19h13 19h28 ... That is all you need to know. Frequencies depend on the hardware (signalling limits, number of vehicles for the line). Thus they usually persist for years or decades. First and last times depends on the habits of the local users and therefore also persist usually for years. It would make sense to have that information in OSM. The rural model, also often used for long distance service, looks like school buses: Different trips may vary wildly, and times fluctuate quite often. A useful data model would have to capture not only an itinerary for each single trip, but also the operating dates. This is out of scope for OSM, because it is ephemeral. Nonetheless, trips have a line number that is displayed. Operations based on the metropolitan model tend to be attractive for passengers from the general public. Operations based on the rural model tend to be cheap for the agency. This is why it is a political issue to tell a local community that their public transport network is too rural for OSM. Long story cut short: I would suggest that you keep a structure for unassigned trips in your intermediate data structure, even if that is not filled from OSM. If you want to fight for timetable data according to the metropolitan model in OSM, then you have my support. But a lot of people have tried that years ago and each eventually resigned. There is quite a vocal part of the community concerned with more rural-style services, and they have defeated so far all apporaches to metropolitan style information to OSM. Best regards, Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
I'm sorry if I was unclear. I didn't mean that one person should just blindly dump every GTFS feed into OSM and leave it to others to clean up. I was thinking of something that an individual mapper could use to import the feed(s) in their particular area and resolve conflicts or errors before uploading, e.g. in JOSM. Thank you for the clarification. Yes, I would agree to that. I could image to let a JOSM plugin produce a layer of coordinates from the GTFS stop data. There could as well be a feature to do routing along the sequence of stops that are provided with GTFS data. Perhaps it's different in Rightpondia, but here in Leftpondia, it's common to see major (sometimes network-wide) changes to routes and schedules every 3-6 months. Thank you. This is indeed an important disctinction. Here, bus services are stable always at least a year, usually five to ten years and sometimes for decades. Services on rails are usually even more stable. For example, my ancient home town Wuppertal introduced a new bus network in 1994 and is mostly offering the same service right now. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
Hi, OTOH, this doesn't seem like a huge problem if we're importing the data from elsewhere using automated tools and only tweaking by hand where it's wrong--and ideally, there should be some sort of feedback mechanism to get the source corrected so even that's a short-term problem. Well, that's explicitly deprecated in OSM. Please look in the wiki about mechanical edits. If you have useful and free data then the better approach is to mix them up with OSM data outside OSM and give the OSM mappers a tool such that each mapper can pick what he/she deems useful in OSM. Also, like it or not, Google Maps (and hence GTFS) has set a bar for what users expect from online maps. I'd certainly like OSM to be better, of course, but the current situation is that OSM is generally far, far worse. I think this is where local differences matter. In large parts of Europe, the transit agencies themselves have already good information, OSM is more or less on par with that, and Google lags significantly behind. And: how to tell apart services that run a few times per day from those that have a headway of a few minutes? That's starting down a slippery slope to including full schedule data. Once again, please note that this is a huge difference in local culture. All around the world, if there is a metro then people usually go there without looking on a timetable and it as granted that the headway is a few minutes. Next to nobody consults a timetable first, and some systems don't even public precise timetables. Believe it or not, there are quite a number of bus service mimicking this concept: https://fr.wikipedia.org/wiki/Bus_%C3%A0_haut_niveau_de_service This is in contrast to a number of service that run once a day on schooldays. In between, there are a lot of services that have a fixed headway all over the day: https://fr.wikipedia.org/wiki/Horaire_cadenc%C3%A9 In practice here in Europe, reducing complexity would mean to send a potential passenger to the next stop of a high frenquency service or clock-face scheduled service and to ignore once-a-day services altogether. And the right solution for this is not to delete these services from OSM but to mark them as low-frequency service. If you would like to improve relevance of OSM, discriminating between these three levels of service would be a prime concern. - Where to start/end routing of vehicles? Sorry for the misunderstanding. I'm talking about getting a vehicle from stop to stop. While the overall level of detail is often good enough for routing, this doesn't hold always. To find and resolve the mapping issues it makes sense to check whether you can route from stop to stop. If not, this is always a strong hint that there are mapping issues. I do notice as a benefit from this discussion that not all transit agencies (Tulsa, Portland) care whether their routes can be lawfully driven in reality. That's different here in, at least in Western Europe, maybe all Europe. - How to obtain a name of a station? Please start trying to work with the data. Names can come from the pole, the platform, the stop_position, a connecting stop area. Or a combination of that, including contradicting information. Factor in "local_name", "loc_name", "official_name", probably others, and in countries like Switzerland and Belgium names in multiple languages. To make things more fun, some stations have different names for some of their stops within the station. And add abbreviations to the equation or the repetition of the municipality name in the name tag. I would like to see a set of rules that answer questions like: - Does a "name:en" tag on the pole override a "name" tag on the stop_position, or vice versa? What about a "name:en" tag on a stop_position versus "name" on a platform? - Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)" to "(Westfalen)"? - Have the tracks in the station "Vaugirard" this name or the name "Montparnasse"? Paul has already mentioned that, to the contrary of these observations, at some places the stops don't have explicit names and get their names from nearby street features. To sum up: if you set up a consolidation service to mix up GTFS data with OSM data outside OSM, a lot of people would be grateful. If you push somehow converted GTFS data into OSM then most mapppers will treat this as more harm than good. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Tagging of railway station
Hi, 1. Position of tag railway=station There are currently two approaches [1]: (i) on a node within the main concourse area (ii) on an area encompassing the land used for passenger services (including any concourse, platforms and associated tracks) I strongly opt for (i). As you have mentioned, for both the exact placment is subjective. But the single node is far easier to understand and handle for mappers. For example, you could tell a mapper that the node is the location where label is placed. By contrast, to start a mapper's introduction with a lengthy explanation of the computation of a centroid is not practical. If you want a really precise station description, I would go towards indoor mapping, see http://wiki.osm.org/wiki/Indoor_Mapping In-station navigation could be a strength of OSM if enough stations are mapped. N.B. A third approach is presented on the wiki [2]: tagging the building. This approach seems not appropriate, since the bulding(s) often doesn't cover the whole station surface (e.g. platform area). Maybe it could be removed frome the wiki ? Yes, remove it from the wiki. A lot of stations even don't have a building. 2. Use of public_transport=station This is a much debated point: [...] (ii) public_transport=station should be added to the one object that is tagged railway=station, since these tags are synonymous [...] Same question: is there one of these four approaches that should be favoured ? Clearly (ii) is the best choice. Even the public transport proposal states that the tags should be used alongside the existing tags. In general, a mapper and also a tool would usually just left aside unknown tags, so (ii) keeps tools working regarless on what tagging they depend. Having two distinct objects would be difficult to understand, because which object you get will then depend on the tools syntax (either one of them or both), and nobody expects a second difficult-to-find shadow object to exist. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] maintenance is very time consuming on public transport routes
First of all, it's great to see that the list comes back to life again. I hope we can use the enthusiasm to solve some of the problems that have hade public transport mapping so tedious. One of the core issues is that there are very different concepts of what makes up a bus service. In the cities, bus routes almost always have fixed routes and run every few minutes: An example is the bus route 26 in London: http://en.wikipedia.org/wiki/London_Buses_route_26 These services aims to be easy-to-use for tourists and other strangers. In the countryside and some small towns, bus services are merely a collection of school services. These services often aren't useful to anybody else than the pupils using it. Other types may exist as well. Think for example of shuttle services to ferries or to airports. They may run far fewer than a busy bus service in London, but they are straightforward useful to all ferry or airport passengers. The urban services also tend to be long-term stable, line 26 for example since more than 20 years. A first step would be to clearly distinguish these different types of bus services, and the best I can offer so far would be the subjective criteria if I would suggest a stranger to use that service without knowing the time table: I would encourage to use line 26 instead of a car, but discourage to use an arbitrary school service instead of a car. I also claim that mapping these urban services is much more useful than mapping school services, hence tools should make at least adding these urban services as simple as possible. There is unfortunately less value in adding school services to OSM, because the general public cannot replace their car use by them anyway, regardless if they change frequently or not. The state of affairs is that at least the JOSM relation editor handles such relations well, including splitting ways with multiple relations on it (I've just tested with 35 bus services on a way, and it worked without notable delay). We should keep in mind that urban model simply works and do break things here. Other editors have better chances to get to the same level of comfort if the data model is simple. And the simplest form is indeed: one relation per route and direction, stops and ways added in the order of service. Does it make sense for me to elaborate on this and invest time into an actual proposal? Actually no. None of the above listed problems would be solved by yet another proposal. Proposals help if and only if there are already mulitple conflicting usage patterns around and the proposal process would offer the forum to bring proponents of all sides to an agreement. They don't help if the problem is to choose a data model and to implement it in software. To make a good data model choice the best way is to collect as much examples as possible to check whether proposed data models does cover them and to implement them in software. This helps to understand whether a data model is really simple or just simple-looking. The sub-relation proposal is an example for simple-looking: The code to figure out whether a given relation is a bus route and how to order it for the line diagram generator http://overpass-api.de/public_transport.html is already more than 2000 lines long. Adding support for sub-relations and doing something sensible in all the various error cases will add some hundreds or thousands of lines, precisely because there is plenty of opportunity to create maybe-errorneous route relations with a more complex data model that you have to deal with a a software developer. Requiring a routing capability is even worse: Implementing an A* algorithm that does the core routing is not the hard part. The hard part is to choose which kinds of way to take (sometimes buses may pass through pedestrian areas, sometimes not, sometimes against one-way routes, sometimes not), because you have a good chance to get several kilometers of bogus deviations if you wrongly exclude a way that's actually allowed, and tagging practices do subtlely differ between different local communities. So I'm happy about the initiative, but yet another pile of prose text doesn't make a tool for mappers. By contrast, I would love rather an approach that has a chance to work: Let us collect a structured set of examples and then write code that can handle all these examples. This gives at least the chance that mappers, software developers and data users all have a chance to adopt the data model. Best regards, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS compatibility
But we are still in the thinking-about-this stage, haven't made any decisions, and are looking for suggestions and comments (hence this posting). Let me make a suggestion: instead of producing duplicates and leaving mappers with the frustrating task of tiding up, you could use JOSM to do a semi- automatic import. JOSM will offer quite powerful and versatile editing capabilities to solve conflicts immediately. I've extended the Public Transport Plug-In to offer an experimental GTFS import (for stops only at the moment). The aim of this software is to avoid cluttering the database with duplicates and to maintain the data model as consistent as possible. At the moment, the stops as treated as bus stops, because I can't find a stop type in the GTFS specification. Installation instructions: - download JOSM: http://josm.openstreetmap.org - Run with java -jar josm-tested.jar - Open Edit Preferences Plugins and select public_transport - Restart JOSM I suggest the following workflow: - Download an area to work on into JOSM - Import the respective GTFS file (stops.txt) with the plug-in - The plugin will pre-sort on load - work through the nodes that remain pending: mark a line in the dialogue, press Enable to add the node, the Show and Mark to center on the node. If you want to join it with an existing node, this What happens on load of stops.txt: - Every stop that is outside the bounding box of the currently loaded area in JOSM will be set to state outside - Every other stop that is more than 1000m away from any existing bus stop (recognized as highway=bus_stop) will be added to the map (state: added) - Every stop nearby existing bus stops is set to state pending. What you can do within the plugin: - The button Enable adds all stops currently marked as lines in the dialogue as nodes with highway=bus_stop stop_id=[stop_id] name=[stop_name] to the map. - The button Disable removes the stops marked as lines from the map. - The button Catch drags an existing, marked node on the map to the position of the imported stop and tags it as explained above. An existing name is preserved. - The button Join does the same as Catch, but the node remains at the position of the existing node. - The buttons Mark and Show mark resp. show a stop (must be enabled) from the dialogue on the map. The button Find marks lines the dialogue that correspond to marked nodes in the map. Possible extensions or modifications to make life easier: - Use remote control and a server application to only detect those areas where conflicts exist. - Reuse existing stop_ids to match imported stops there. This would greatly simplify later updates. - Use other attributes from stops.txt - Make the workflow smoother, e.g. use key shortcuts for sequences like Enable, Show, Mark. - do something with agency.txt. and of course any idea you might have. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
those two would meet in point A, from which the branch line sets off/rejoins the core line. So a hypothetical future route-finding algorithm would follow different_route to its end, upon meeting core line it would continue along. It just doesn't work. Having an unordered relation or even mapping both directions within the same relation leads to ambiguities. Just two examples: http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B000FTF Bus service 618 southbound comes on the Gennebrecker Str. from the north, loops into Agnes-Miegel-Straße and then proceeds on the Gennebrecker Str. to the south, always. 618 northbound passes on the Gennebrecker Str. from south to north only. Oxmoa suggests two relations rel tag k=ref v=618/ tag direction=southbound/ ... member ref=northern Gennebrecker Str./ member ref=Agnes-Miegel-Straße/ member ref=southern Gennebrecker Str./ ... /rel rel tag k=ref v=618/ tag direction=northbound/ ... member ref=southern Gennebrecker Str./ member ref=northern Gennebrecker Str./ ... /rel Now I would like to see how you discriminate this case from the case where 618 passes through the loop in both directions (so does line 624) if you don't have an ordered relation. In Oxmoa it is very simple: you map what the bus does. Second example http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. In Oxmoa, it is again simple and intuitive: rel tag k=ref v=643/ tag direction=eastbound/ ... member ref=Morianstraße/ member ref=platform 5/ member ref=Islandufer/ ... /rel rel tag k=ref v=643/ tag direction=westbound/ ... member ref=Morianstraße/ member ref=platform 4/ member ref=Islandufer/ ... /rel Also, there is at present no provision for implementing the time of bus lines, so at present one could be advised to take a night line at daytime. See http://wiki.openstreetmap.org/wiki/Opening_hours (the server is currently down): just add something like Mo-Fr 5:00-21:00 to indicate when the service is operational. Nonetheless, there are still things that Oxmoa leaves open. For example, there is no specification how to store approximate journey time. But the usage of ordered relations and the separation of directions is one of the strengths of Oxmoa, not a weakness. Concerning Potlatch ... It's just not open. You can easily contribute to JOSM by writing a plug-in or even submitting a patch. Potlatch makes the life for the programmer much more difficult; it has no defined interface for extensions. By the way, it doesn't work in a densely populated area at all. The reason why I have written the plug-in for JOSM is that I wanted an easy way to map bus lines, not a personal preference of JOSM. I'd suggest that we use the discussion page http://wiki.openstreetmap.org/wiki/Public_Transport of the wiki once the server is back again to write a consistent, easy-to-use and easy-to-implement standard. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Bus stops in North America from GTFS data
You may want to follow British/German standard. There is a tag that identifies stops uniquely, sorry can't recall at the moment. The last time I saw it was Siegburg/Bonn train station. Do you mean the ref tag as on node 160621? I'd strongly advice not to follow that way. The ref has also been used to list the lines stopping there and should not be used for something else. I've never seen any item that identifies bus stops uniquely in Germany or Britain and is visible to the ordinary passenger. It is also not needed - all bus stops with the same name in the same town are usually very close together (just stops for different directions). But being unique would be never stated as a formal constraint. Buses sometimes stop at two nearby stops with the same name. Thus there is nothing comparable to the stop_code here in Germany. John, I would advice you to just set name to the stop_code if this is the thing displayed on the bus stops. It is very different from the northern European system. But passenger (or traveller) information is the primary goal of the OSM data. Thus a useful information in the tag that is expected to be crucial (name) is probably the best solution for Ottawa. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Annoucement: Plugin for JOSM enhanced
Hello everybody, the Public Transport plug-in for JOSM has been enhanced to simplify the mapping of stops and stations. You can now convert a GPX file semi- automatically to (bus) stops in the map, just with a few keystrokes. The reworked documentation is available at http://wiki.openstreetmap.org/wiki/JOSM/Plugins/public_transport in particular http://wiki.openstreetmap.org/wiki/JOSM/Plugins/public_transport#Examples_how_to_Use You can install the plug-in by the JOSM plug-in manager and access the new capabilities in the menu Create Stops from GPX. You are welcome to make comments, suggestions, ask questions or report bugs. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Sketch-line] suggestion of improvement
Suggestion of improvement Sketch-line from an example : http://78.46.81.38/api/sketch-line?network=Ginkoref=7correspondences=100 The ways forward and backward are not on the same streets for the line 7 in Besançon. The Scheme * relation:line ** relation:route ** relation:route is very powerfull in this case So I have drawn from the SVG above what could be an improvement of the rendering. (i'm not very skilfull with Inkscape) http://frvipofm.net/osm/sketch-line/7+.svg First of all, thank you for the suggestions. I'll try to implement as much as possible. To the details: Splitting the line bar in two directions is possible. Also stopname printed below the line bar, but this excludes with printing correspondences below the line bar. Thus it will become an option. But the problem is that the generator doesn't use any way data so far, just the names and positions of the stops. So it will take a larger rework of the data model to make this possible. I'm thinking about this but I have not yet a good idea how to do. The line 27 has different length. Compare the relation 154149 532894. The queue, could be drawn dashed. But i'm unable to write code for that. I can only have ideas of improvement... What do you mean exactly? Relation 532894 has only two stops, but the itinerary looks a lot longer. Is this intended? So, should the longer section of the line be dashed from De Vigny to Funiculaire? Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Line diagrams
Hello everybody, to encourage mapping public transport, Tiziano and I have developed a line diagram generator that displays nice diagrams from (sufficiently properly mapped) bus routes. A showroom example is http://78.46.81.38/misc/showroom.svg generated by the URL http://78.46.81.38/api/sketch- line?network=APS%20Mobilit%C3%A0ref=22style=paduamax-cors- below=12correspondences=100 (takes about a minute) The tool is documented at http://78.46.81.38/public_transport.html Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] RFC on interchanging data
Hello everybody, What is the consensus on how to map interchange data? I would like connect two (or more) bus stops and/or railway stations to indicate that you can preferably change vehicles there (e.g. the bus stop(s) that is/are intended to change into a nearby train station). This is often indicated by sharing the same name, but not always. I haven't found anything useful about this neither on http://wiki.openstreetmap.org/wiki/Public_Transport and its connected pages nor on http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema and I want to know which data model (or models) I hard-code into my software and use for the data I map. I think that membership within a relation public_transport=stop_area fits best for this purpose but I'm not sure whether I can interpret all existing stop areas in this way. Thus, I would be grateful for any comments. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Help: Bus Stop Data Extraction for Bus Routing Service
Dear Grace, We would like to extract public transport data for public transit routing service in Sweden. This will be a difficult, maybe impossible task at the moment. Public transport data are a complicated matter. Most important for you might be that there is no timetable information in the OSM database. Thus, without a data source for the timetable information, it is not useful for public transport *routing*. Buses running only a few times a week or only on school days can't be discriminated from regular services running every few minutes. Also, there is not even a standard for a public transport data model for bus services in OSM. The best possible approach known to me is http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema But there might be a quasi-standard for Sweden differing from this one, depending on your local community. Please provide some IDs of example relations of the data. I'll try to answer to you based on the data model commonly used in Germany (e.g. Wuppertal) or France (e.g. Grenoble). What is the difference between the stop nodes within a relation and the nodes tagged as “bus_stop” in highways which are also contained in a relation? [...] Do the stop nodes within a relation merely refer to the passenger waiting point, whereas, stops in highway contained in a relation represent the vehicle stopping points? In general, the node tagged as highway=bus_stop indicates the position of the road sign or shelter and is off the street. If I find such nodes on the street, I move them to their proper position. For the vehicle stop, the node on the street might be tagged as public_transport=stop_position but they rarely exist (almost 500,000 bus stops in the database versus 9000 stop positions) or aren't even defined (stop positions in my area depend on the vehicle design, not the served line). The stop areas are introduced to group all the bus stops having the same name. A relation can carry one or all directions of a bus line. In the former case, I recommend to keep both the itinerary (the way the bus physically takes) and the bus stops, usually nodes of type highway=bus_stop, in the order in which they are served. In the latter case, you often find a big mess on both the itinerary and the bus stops which are left from former times (API 0.5) when there was no defined order on the elements of relations. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] JOSM Plugin
Hello, thank you for trying the plugin. Cool. So far I've seen a new menu item Public transport having appearing in my main menu. Anything else to discover? No, that's all so far. At the moment, the plugin facilitates to build bus services when the underlying streets and bus stops already exist. This wizard can be accessed via the menu item in this menu. A second wizard should simplify adding bus stops such that one can map them by just going by a particular bus line with a gps logger in the pocket plus some mouse clicks. But I think, I should rather complete the first wizard, then start the second. If you were asking for a wishlist: Double-click routes or stops should actually select the relation/node and center the editor's view on the latter. Do you mean Double-click on stops on the map should center the stop in the editor window. Or double click in the editor should center the map to the item? How are routes (i.e. relations) visible in the map (I have not found them?) What's the Tags-tab used for? It's empty when I loaded my Leipzig public transport data. I'm sorry, the tags tab is not yet implemented. I'll do this next, but one has to use the standard relation editor as a replacement for the moment. I haven't discovered yet how the Suggest stops feature works. The idea behind this is that adding an itinerary and adding the bus stops for a certain service means to do essentially twice the same thing. Generating the bus stops automatically from a given itinerary is easier than the other way round. Thus, this is implemented so far. The algorithm takes the given itinerary (this is a long sequence of line segments) and adds all bus stops that are closer to one of these line segments than the threshold Maximum distance from routes and one side. As bus stops usually appear in both directions but buses have doors only on one side, all stops in the correct direction must be either on the right hand side or all on the left hand side. To illustrate http://78.46.81.38/misc/suggest_stops.png For the sake of simplicity, the suggest stops replaces all previous stops and assigns no role to the bus stops. But this behaviour can be changed if otherwise useful. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM / OPNV-Karte to Excel/SVG
Am Mittwoch, 20. Januar 2010 00:16:18 schrieb Tiziano D'Angelo: Hello to everyone! As another bonus to the work done, I'd love to export the data of each route relation first to some excel/text/CSV file or database where I can see lat/long + name of the stop in the correct forward/backward order for each line (so I can send the updated data to the author of Metro ( http://nanika.net/Metro) Do you want something like these? http://78.46.81.38/api/nodes-csv?380861all http://78.46.81.38/api/nodes-csv?380861forward http://78.46.81.38/api/nodes-csv?380861backward The first parameter is the id of the relation. then, I'd like to export the data to SVG files to do graphs for each route of the network (both as topological maps http://en.wikipedia.org/wiki/File:Bakerloo_line_Topological_map.svg and as this graph: http://en.wikipedia.org/wiki/File:Bakerloo_Line.svg) and also of the entire network, just leaving on it the lines and names of the stops, and as a further development, create a map similar to the Paris/London metro network. Could anybody explain me how to do any of these things? Well, it depends on your exact needs. A simple SVG can be created straightforward because it is just Markup. Feel free to ask for sample code. I'm interested in a more advanced tool to produce full blowd grid maps in this style but this will take a lot of work. If you can spend some days or hourls on programming, I'd like to do this in joint work. I'm currently ordering the stops so they show up in OPNVKarte in the proper order. I'm currently writing a JOSM plugin to make this easier. But it may take some more weeks until it gets completed. I'll post a intermediate version as soon as possible. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] bus route/relations done right
Can I suggest we define some terms. A Line is all the journeys made using a particular reference (4, X13, Citi1 etc). [...] A Line Variant (also know as a Service Variant) is a unique stopping pattern for a bunch of Journeys within a Line. (ie inbound, outbound, inbound via the school, outbound but stopping at the station and not going to the end of the route etc). [...] I strongly suggest we don't add this data to OSM - it is too complex and not needed for mapping and should be kept in the schedules service. I strongly refuse that point of view. From the preceding discussion, I conclude that the paradigm of bus services varies very much between different countries. I don't know the situation in Great Britain, so I'm referring to the situation in Germany (in particular: Düsseldorf, Münster, Wuppertal), Switzerland, The Netherlands, Belgium and maybe other countries. In these places, most bus services have very few variants (in general two, one forth and one back) and timetables are very stable. For example, in Wuppertal more than 90 percent of all services have not changed even their timetable in the last 15 years. Thus, the timetable information has a similar complexity than the information about lines. The paradigm can be found under the name Integraler Taktfahrplan in German or Horaire cadencé in French. I have not found an English translation. Roughly, it would be Integrated fixed-interval timetables. On the other hand, there is no free timetable service in Germany or France. Thus, having the essential information (Where exist direct services? Which connections a designated and thus reliable for changing trains?) in OSM would be a great help. So I would suggest to encourage mappers to add timetable information whenever an integrated fixed-interval timetables exists. This might not apply to Great Britain, but I think we shouldn't take this as a reason to map Public Transport elsewhere worse than possible. Cheers, Roland ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
