You are not logged in.

#1 2018-12-23 07:35:45

houtari
Member
From: Helsinki
Registered: 2017-02-15
Posts: 42

Import: HSL:n joukkoliikenteen pysäkkejä OSM:iin / HSL stops to OSM

Tervehdys! (English version below)

Aiemmin tällä foorumilla on jo ollut puhetta Liikenneviraston koordinoimasta OSM-Digiroad pysäkki-importista. HSL:ssä olemme suunnitelleet tämän jatkoksi Helsingin alueelle omaa pienempimuotoista pysäkki-importtia.

TAUSTA

HSL:n (Helsingin seudun liikenne) alueen pysäkeille on annettu nimien lisäksi ns. lyhyttunnus joka on pysäkin kunnittain yksilöivä nelinumeroinen tunnus. Tämä lyhyttunnus on nähtävissä asiakkaille reittioppaassa, pysäkkikilvissä ja osassa pysäkki- ja reittikarttoja. Muilla kaupungeilla/kunnilla lyhyttunnusta on jo pitkään edeltänyt ns. kuntatunnus. Kuntatunnus koostuu 1-2 kirjaimesta, jotka kuvaavat ko. kuntaa (esim. E,Ka,Ke,Ki,Si,So,Tu & V). Helsingissä tätä kuntatunnusta ei ole kuitenkaan aiemmin käytetty. Syy tähän on siinä että tämä lyhyttunnus-käytäntö kehitettiin alunperin vain Helsingin kaupungin liikennelaitoksen (HKL) pysäkeille, jolloin ei kuntatunnukselle ollut tarvetta. Myöhemmin se kuitenkin levisi laajempaan käyttöön ja sitä kautta kuntatunnuskin jouduttiin ottamaan käyttöön.

Nyt tuota kuntatunnusta ollaan yhtenäisyyden vuoksi ottamassa käyttöön Helsingissäkin. Se on jo otettu käyttöön pysäkkikilvissä ja pysäkkijulistekartoissa - sitä mukaa kun niitä on uusittu. Reittioppaassa tätä kuntatunnusta (käytännössä siis H-kirjainta) ei vielä pysäkkien lyhyttunnuksessa näy, mutta valmiuudet sen käyttöönottoon on kuitenkin jo olemassa. Reittiopas yhdistää HSL:n pysäkkidataa mainitun lyhyttunnuksen avulla OpenStreetMapin pysäkkidataan (ref-tagi) ja jotta tämä yhdistäminen Helsingin alueella onnistuisi jatkossakin niin vaaditaan että nämä Helsingin kuntatunnukset (käytännössä siis H-kirjaimet) näkyvät OSM:n ref-tunnuksissa. Mistä ne tällä hetkellä muutamaa yksittäistä poikkeusta lukuunottamatta puuttuvat kokonaan.

RATKAISUN KUVAUS

HSL:ssä asia on ajateltu hoitaa kertaimporttina. OpenStreetMapin importteja sitoo erilaiset periatteet joita on noudatettava... https://wiki.openstreetmap.org/wiki/Import/Guidelines

Nämä periaatteet sisältävät paljon byrokraattisia toimenpiteitä (työn dokumentointia, palautekierroksia ja luvan kysymistä jne.). Onkin todettu että kaiken tämän suorittaminen pelkästään yhden H-kirjaimen lisäämisen vuoksi ei ole mielekästä vaan samalla voisi rikastaa OSM-dataa laajemminkin. Pysäkkien nimet (name, name:fi & name:sv) ja katostieto (shelter) ovatkin tietoja joita on myös tarkoitus tässä yhteydessä lisätä OSM:iin (niiden puuttuessa).

Geometriaan ei ole tarkoitus koskea ja kuten Liikenneviraston koordinoimassa Digiroad-importissakin niin tässäkin importissa OSM-aineistoa on ajatus kohdella master-aineistona, eli OSM:ssa jo olevia ominaisuustietoja ei muuteta prosessissa. Ristiriidat toki lokitetaan ja käydään jälkeenpäin käsin läpi, jotta mahdolliset virheet saadaan korjattua.

Veikkaan että ensimmäinen kysymys joka tästä herää koskee näitä kahta erillistä importtia - ja kuulu näin "Miksei näitä importteja yhdistetä?". Alla perustelut...

Miksei tätä hoideta Liikennevirasto Digiroad-importin yhteydessä? No, koska...
- HSL haluaa tuoda OSM:iin sellaisia tietoja (esim. ruotsinkieliset pysäkkinimet) joita ei Digiroad-importin piiriin kuulu
- HSL:n import koskee myös muita kulkumuotoja kuin pelkästään bussi (esim. metro, juna, raitiovaunu ja lautta). Pysäkkinoodien lisäksi huomioimme asemalaiturit,
terminaalit, relaatiot jne.

Voisiko tämä korvata Liikennevirasto Digiroad-importin Helsingin alueella? Ei koska...
- Digiroad on varsinainen valtakunnallisen pysäkkidatan masterdatalähde ja se (ja Digiroad-import) sisältää jotain sellaisia tietoja joita ei HSL:n järjestelmistä löydy (esim. suunta & pyöräpysäköintioptio) tai jotka eivät ole HSL:n järjestelmissä välttämättä ajan tasalla (esim. digiroadin valtakunnallinen pysäkkitunnus).

Toki nämä erilliset importit on keskenään synkronoitava/huomioitava, mutta muuten niiden keskinäinen työnjako on varsin selkeä. Digiroad-import lisää myös geometriaa kun taas HSL-import lisää pelkästään ominaisuustietoja. Tästä syystä toivommekin HSL:n toimesta että Digiroad-importointi on alueella jo suoritettu ennenkuin HSL-import tehdään.

Importista on laadittu alustava wiki-sivusto ... https://wiki.openstreetmap.org/wiki/Fin … top_import
Lupa tuoda HSL-dataa OSM:iin on myös kunnossa ... https://wiki.openstreetmap.org/w/images … ission.pdf

Miltä suunnitelmat kuulostaa?

Lisätietoja
markku.huotari@hsl.fi
Puh: +358 9 4766 4064



- - - - - - - - - - - - - - - - - - - - - - - - - - - -



Hello!

Earlier on this forum there were some discussions about the OSM digiroad stop import conducted by the Finnish Transport Agency (FTA). We at Helsinki Region Transport -authority (HSL) have planned yet another small scale stop-import in the Helsinki area.

BACKGROUND

The stops in the HSL-area are besides names provided with a short_id that identifies each stop within it's own municipality. These short_id's are visible to customers in our journey planner, on stop plates and some public transport maps. Within other municipalities this short_id is preceded by a so called municipality identifier. This identifier consists of 1-2 letters that symbolize the municipality in question (eg. E,Ka,Ke,Ki,Si,So,Tu & V). In Helsinki this identifier hasn't been used until now.

Now this identifier will however be implemented in Helsinki as well. It's already been introduced on stop plates and stop poster maps. In the journey planner this municipality identifier (letter H) is still missing for Helsinki stops, but in principle the system is ready to handle them whenever they come available. The journey planner combines stop data from HSL to OSM stop data with the help of the described short_id, which in OSM is located in the ref-tag. In order to make it possible to combine these two data sets in the future it's required that the municipal identifier (letter H) will be included in Helsinki stops ref-tag in OSM as well. At the moment these are all (with the exception for a couple of stops) missing.

SOLUTION

At HSL we've got plans to sort this thing out with an one-time import. OpenStreetMap imports have to follow certain guidelines ...
https://wiki.openstreetmap.org/wiki/Import/Guidelines

These guidelines include a lot of bureaucracy (community buy-in, documentation, review & approval process etc.). Going through all this trouble for just one H-letter  wouldn't be reasonable so we've decided to enrich OSM with some further information. Stop names (name, name:fi & name:sv) and shelter data (shelter) are information we've decided to add as well - whenever these are missing.

The object geometries will be left untouched and just as the Digiroad import this import will also consider OSM-data as master data. This meaning that attribute data allready present in OSM will be left untouched as well. Conflicts will be logged and later on manually investigated, in order to get possible existing errors fixed.

I guess the first probable question that arises from these plans considers these two imports - and why they should be conducted separately. Arguments are presented here below...

Why aren't these operations performed within the Digiroad import? Well, because...
- HSL wants to import such attributes (eg. swedish stop names) that aren't part of the Digiroad import.
- The HSL import involves also other means of transport than just bus (eg. subway, train, tram and ferry). Besides stop nodes we pay attention to station platforms, terminals and relations etc. as well.

Could this import replace the Digiroad import in the Helsinki area? No, because...
- Digiroad is the true national stop master dataset and it (and the Digiroad import) contains attribute data that can't be found in HSL datasets (eg. direction and bicycle parking option) or attribute data that isn't necessary up-to-date in HSL datasets (eg. Digiroad stop ID).

Naturally these two separate imports have to be synchronized. They have clearly two different roles. The digiroad import also add geometry data where as the HSL import only adds attribute data (tags). Due to this fact it's reccomended that the Digiroad import will be performed before the HSL import in the HSL area.

Wiki page for the project ... https://wiki.openstreetmap.org/wiki/Fin … top_import
The permission to incorporate HSL data into OSM is already taken care of ... https://wiki.openstreetmap.org/w/images … ission.pdf

How does our plan sound like?

Further information
markku.huotari@hsl.fi
Puh: +358 9 4766 4064

Offline

#2 2019-02-28 14:19:16

keimo
Member
Registered: 2013-07-11
Posts: 29

Re: Import: HSL:n joukkoliikenteen pysäkkejä OSM:iin / HSL stops to OSM

Hyvä että HSL:n dataa on tuossa lisää OSM:ään. Kertaimportit ovat toki hyviä, mutta pidemmällä aikavälillä OSM-datan säännöllinen vertailu master-aineistoon (eli reittiopas tai HSL:n GTFS) on tarpeen. Vapaasti editoitavassa kartassa data kun voi muuttua jos jostain syystä, ja pysäkkejä poistuu käytöstä ja tulee lisää koko ajan.

HSL:n reittiaineiston osalta olen päivittänyt vertailua OSM wikiin (https://wiki.openstreetmap.org/wiki/Fin … kenne/HSL/) silloin tällöin. Pysäkkidatan vertailu sopisi tietenkin tuohon jatkoksi oikein hyvin. Pysäkkivertailun lisääminen vertailun tekevään skriptiin on ollutkin TODO-listalla pidemmän aikaa. Ongelmana on, että sillä listalla on aika monta muutakin asiaa smile

Offline

Board footer

Powered by FluxBB