Talk:Digiroad/Digiroad bus stop import
Tags on the stops
First off, source on every single stop is not needed. It's a waste of space in the DB and causes unnecessary processing. This is especially true when adding 94k objects. It's sufficient to add it to the changeset's tags.
If timetable=yes, that's what one would expect, so it would be sufficient to add timetable=no for the exceptions.
Same goes for bench and shelter in reverse. No real need to add them when they aren't present.
Most stops won't have passenger_information_display, so it may be better to only add those where they exist.
____
Hi,
Thank you for your comments and the good advice! Digiroad source tag was added partly because of the licensing and partly to ease the recognition of stops, that were imported in this project. In the test import, we only import 232 stops, thus we can evaluate if use of the source tag can be avoided in the main import.
Unfortunately, we are unable add timetable=yes tags to most of the stops, due the fact that in rural areas of Finland there are lot of stops without timetables. We also considered, that shelter=no and bench=no can be important information for the elder passengers and people with difficulties in moving.
Passenger information displays are mainly used in larger cities and in most of the 53 000 stops in this import, the value is NULL, so the amount of actual tags will be low. We apologise, that the test set data does not bring this fact up very well. Here we also thought, that “no” can serve the needs of public transport companies and the municipalities, who plan how to develop their services.
We will address these issues in mapahton next week and possible also in the webinar before the main import.
Displace stops, so they move off the road axis
You have the compass bearing in which the bus will leave from this stop. If you add 90 degrees to that, you can displace the stop nodes about 10m, so it becomes apparent on which side of the street they are located and thus for which direction of travel they serve.
___
This was our first plan also in Digiroad operating service, but after discussions with developers from Digitransit and the local OSM community contacts, we concluded together that the manual moving of the stops is probably the only way to ensure good enough quality for the needs of the pedestrian routing, which is an important application for this data. That’s also why we have mapathon for the test set coming up so we can test our plan.
- Manually moving them to where they actually are will still be needed. But my take on this is that this is a lot easier if it's already clear on which side of the street the stop was meant to be, hence the suggestion to move them off the centerline of the road. Seeing a bearing in degrees is not very clear for most people, myself included. Using software to give them a nudge of about 8-10m is trivial to do with software.--Polyglot (talk) 08:50, 30 October 2018 (UTC)
____ The point about difficulty to understand the degrees is good and this can also be discussed in our up coming events to get the feedback from mappers! Thank you for you comment.
- I figured out a way to cope with it: a brand new MapCSS style dedicated to the import: https://josm.openstreetmap.de/wiki/Styles/DigiRoadBusStops
- In JOSM go to Map Paint Styles and select it from the list. Each bus stop now has an arrow pointing in the direction of travel.--Polyglot (talk) 14:12, 1 November 2018 (UTC)
_____
Yes it seems! This is a really good feature and works also in basic browser editor.
ref and ref:findr
Why are two identifiers necessary? Do you have a picture of a stop? Is one of these id's visible to the public?
____
Two ID:s here are both used in the different applications so we consider both important. Also OSM stops may have either one so we need both for identifying duplicates.
route_ref
If you have GTFS data, you could calculate which lines will serve this stop and add the line identifiers as a semicolon separated list. I think this is interesting information to have when creating route relations. They can be used to select a subset of stops based on a regular expression.
_____
Thank you for the good idea. The aim of this import is mainly to provide the missing bus stop data to the OSM community for further development and application purposes. Actual routing data is not stored in the Digiroad database, but this is definitely one aspect that can be considered while planning further development of the original Digiroad data in the OSM.
crowd source the import
You could make the stops available in blocks of 50-100, maybe on a tasking manager. Or an interface where mappers can download them for the lines they want to work on.
This way, a mapper/importer can add them to JOSM's todo list and move them to where they see them on the aerial imagery. At the same time, the mappers can then draw shelters and bus bays for them. This would tremendously increase the quality of the import. Unfortunately that way of working is not "compatible" with the expectation of using separate import accounts, so maybe a two step process would still be necessary.
My take on this is that it would be better to do it this way, there is no need to exclude pre-existing stops from the workflow then, as the mapper can simply merge them.
________
Adding data as a smaller sets to the tasking manager is a good idea and we will consider this for the main import.
note
Having notes on the imported nodes doesn't convey useful information.
LISATIEDOT:Lasi, roska-astia -> bin=yes (or drop it, as not really important)
LISATIEDOT:Ei käytössä -> simply leave empty if there is no additional information LISATIEDOT:Ei merkkiä -> no characters? -> drop
_____
It's true, that the note tag is a bit problematic in the test set, but in the full data set there is also more important information. There is no clear formatting for the note tag in the full data, so we are basically unable to parse strings to tags like you suggested. The information is written by local officials and was wished to be added by the local OSM community representatives. Note tag can be checked in the mapathons and also deleted if it does not contain anything useful. We are organizing a webinar before the main import so we can consider this issue there again with some samples from the full data. “LISATIEDOT:Ei merkkiä” and "LISATIEDOT:Ei käytössä" can be both bit hard to translate. “LISATIEDOT:Ei merkkiä” translates more accurately as “no sign” or “no pole” and could be changed to tag pole=no in the mapathon event.
- Did you know that JOSM automatically discards certain tags before uploading? (odbl, created_by, etc). I use this often to show data to mappers that isn't very useful to upload.--Polyglot (talk) 08:52, 30 October 2018 (UTC)
_____ Thank you for the comment! We will look into this.
test set import
We imported a small test set around city of Jyväskylä and it's ready for mapathon next week (5/11/2018)!
In overpass turbo, zoom to jyvaskyla (Central Finland) and use command to see the imported stops, that have not been moved yet:
Add these lines under (rows 8-10) the "node":
[highway=bus_stop] [source="Digiroad.fi"] [note=""]
- Hi, I created a screencast video on how I would proceed using JOSM + PT_Assistant plugin to process these stops. I would not put a source tag on each and every node. In fact I'm actively removing source tags on objects, the really belong on the changeset.
- In JOSM, this Overpass query is very useful:
[out:xml][timeout:325][bbox:{{bbox}}];
(
(
node["highway"="bus_stop"];
node["public_transport"="platform"]["train"!="yes"]["ferry"!="yes"];
node["public_transport"="stop_position"]["train"!="yes"]["ferry"!="yes"];
);
._;<;
way["highway"="platform"];
way["amenity"="shelter"];
node["amenity"="shelter"];
relation["route"="bus"];
._<<;
);
(._;>;);
out meta;
- And to find the stops to process you can still use search (Ctrl-f):
highway=bus_stop type:node direction- I'm removing the direction tag when the stop is processed. The red arrow disappears, so it serves well as a 'flag'. --Polyglot (talk) 15:12, 2 November 2018 (UTC)
__
- Thank you for this! We were planning to keep the direction tags because they can be used in software development and tag was specifically asked by the developers.
____
Yeah, sure! we'll get back to this.