Möjligheter kring att skapa osm-filerna på län-nivå istället för kommun-nivå.

[isakengstrom]

Hej! Förstår om det här i grund och botten inte är rätt plats att fråga, men jag gör ett försök ändå!

Bakgrund

Jag håller på att undersöka olika möjligheter kring att konvertera NVDB-data för ett län (specifikt Stockholms län) till en enda osm-fil för hela länet. Målet är att kunna göra det i en automatiserad pipeline. osm-filen kommer dock inte laddas upp till OpenStreetMap, istället kommer nätverket användas för ruttning, där endast vägar för fordon (cykelvägar exkluderat) är relevanta.

Strategi 1

Jag har testat att hacka ihop en lösning via split_nvdb_data.py-skriptet, där jag gjort några småjusteringar för att få ut de olika gpkg-lagren för län istället för kommuner. För att se ändringarna i skriptet, kan man kika på min fork av repot. Resultatet är att jag exempelvis kan köra skriptet med följande argument, med senaste datat från Lastkajen:

-d --lanskod_filter 10 ../lastkajen_data/Blekinge_län_GeoPackage.zip ../lastkajen_data

och få en output zip-fil för Blekinge. Sen är planen att kunna använda en sådan zip-fil på län-nivå som input till det omodifierade nvdb2osm.py-skriptet, för att få ut en osm-fil på län-nivå.

Strategin fungerar utmärkt när jag testar med Blekinge, men när jag provar med Stockholms län får jag följande exception när jag kör nvdb2osm.py-skriptet:

Traceback (most recent call last):
  File "C:\Users\myUserName\AppData\Local\Programs\PyCharm Professional\plugins\python\helpers\pydev\pydevd.py", line 1551, in _exec
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "C:\Users\myUserName\AppData\Local\Programs\PyCharm Professional\plugins\python\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\nvdb2osm.py", line 480, in <module>
    main()
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\nvdb2osm.py", line 353, in main
    insert_rlid_elements(way_db, ways, name, debug_ways=debug_ways)
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\nvdb2osm.py", line 179, in insert_rlid_elements
    way_db.insert_rlid_way(way, data_src_name, debug_ways)
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\waydb.py", line 766, in insert_rlid_way
    _, ways = self._adapt_way_into_reference_geometry(way, data_src_name)
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\waydb.py", line 943, in _adapt_way_into_reference_geometry
    self._fix_after_failed_adapt_geometry_way_insert()
  File "C:\Users\myUserName\projects\labs\forks\nvdb2osm\waydb.py", line 1102, in _fix_after_failed_adapt_geometry_way_insert
    if seg.way[seg_idx].dist != ref_way.way[ref_idx].dist:
IndexError: list index out of range

Här är alla debug logs från exekveringen: debug_log.txt

Här är också en screenshot från variablernas state i samband med exception:et. seg.way har 26 items. ref_way har 14 items, vilket leder till list index out of range när seg_idxär 14.

split_nvdb_data.py params setup:

-d --lanskod_filter 1 ../lastkajen_data/Stockholms_län_GeoPackage.zip ../lastkajen_data

nvdb2osm.py params setup:

-d --skip_self_test --railway_file=../lastkajen_data/Järnvägsnät_grundegenskaper2_0_GeoPackage.zip ../lastkajen_data/stockholms_lan.zip ../lastkajen_data/stockholms_lan.osm

Jag har testat att köra med senaste datat från Lastkajen med original-skripten. Dvs, skapat upp osm-filer för varje kommun, och det går bra. Istället är det något med det modifierade split_nvdb_data-skriptet. Antingen om jag orsakat någon bugg, eller om filerna på län-nivå leder till att data är strukturerat på ett sätt som orsakar en bugg i nvdb2osm-skriptet. Därav tänkte jag höra om någon med mer domän-kunskap än jag vet vad som går snett, eller kanske till och med vet hur jag kan lösa problemet?

Strategi 2

Den andra strategin är att låta skripten fungera som vanligt, dvs skapa upp osm-filer för varje kommun. Därefter använda ett cli-merge-verktyg för att kombinera kommunfilerna till en enda stor län-fil. Den här strategin är verifierad att funka, men då tillsammans med JOSMs merge-verktyg, som verkar detektera de överlappande delarna i kommunernas nätverk och merge:a på så sätt.

cli-baserade merge-verktyg (så som Osmium) verkar dock inte fungera på samma sätt som JOSM, utan merge:ar istället nätverken m.h.a. id:n i osm-filerna. Eftersom nvdb2osm.py-skriptet inte skapar id:n som är unika mellan kommunfilerna fungerar inte en sådan merge rakt av. Även här har jag för lite domän-kunskap för att eventuellt lösa så att id:na blir unika. En tanke är om det går att använda sig av RLID för att sätta id:na i osm-filerna, men jag kan inte avgöra till fullo hur RLIDs fungerar utifrån readme-filen. Finns det någon kompletterande dokumentation att ta del av?

Strategi 3

Den sista strategin jag halvt har undersökt är att använda andra verktyg, så som org2osm, för att konvertera Lastkajens nvdb-filer direkt till osm-filer. Men som jag förstår det skulle inte ett sådant verktyg kunna översätta NVDBs taggar till rätt osm-taggar?

Sammanfattning

Som sagt, jag förstår helt om detta är out-of-scope för projektet, men är tacksam för all hjälp jag kan få! :)

[marsip]

Jag förstår inte syftet med detta förslag. Det finns ju redan script och rutiner för att generera osm-filer. Visserligen för per kommun, men varför skulle man generera per län? Att uppdaterar per kommun är ett stor jobb, att uppdatera per län, kan inte jag se att det är praktiskt möjligt med den arbetsmetod som nu används. Dvs. manuellt uppdatera varje "way" med funktionen Replace-geometry.

Så förklara varför nuvarande metod inte är ok, eller varför du vill generera osm-filer per län. Och i så fall hur dessa läns-osm-filer ska används.

[isakengstrom]

Tja! Jag skrev ner detaljer kring detta under bakgrundsrubriken, men jag kan göra en recap! Mitt issue är inte ett förslag på att lägga till ny funktionalitet i den nuvarande lösningen. Mitt slutmål är att kunna skapa rutter över NVDBs vägnät, specifikt för ett län. I och med att det finns väletablerade ruttningsmotorer som läser in osm-data så kändes denna väg som ett intressant alternativ att undersöka! Så den fork jag skapade tänkte jag kunde leva kvar som ett separat use-case, ifall fler skulle vara intresserade av att göra något liknande.

[marsip]

Ok. Slarvigt av mig. Jag läste aldrig så långt som till "...nätverket användas för ruttning,"

Angående rutter har jag ingen kunskap om sådant. Annars finns ju flera olika ruttmotorer redan, man kanske uppfyller dessa inte dina önskemål?

[atorger]

NVDB-geometrin från Trafikverket innehåller en hel massa konstigheter, saker som inte sitter ihop ordentligt och lager som inte riktigt passar ihop mm, så nvdb2osm-skriptet gör en massa geometri-magi för att lyckas knyta ihop alltihopa, och den koden är lite bräcklig.

Jag skulle inte alls bli förvånad om man kör skriptet på ett helt län att något av den koden ballar ur pga av en bugg, men det är ganska så besvärligt att debugga och fixa. Jag ägnar inte mycket tid åt det här nu, men om det dyker upp buggar som stör den "officiella" pipelinen som tuggar kommun per kommun brukar jag försöka fixa.

I det här fallet så får jag nog säga att "you are on your own" :-)

I princip ska det inte vara något i skriptet som ska hindra det på att köra på större enheter än kommuner, men som sagt det är inte testat och med tanke på kodens bräcklighet är det troligt att man kommer stöta på problem.

[isakengstrom]

@marsip - Jag ska kolla igenom de andra alternativen och se ifall jag kan hitta en alternativ lösning.

@atorger - Ändå skönt att höra att nvdb2osm.py-skriptet inte är hårt begränsat till kommuner! Jag ska grotta ner mig i NVDBs dokumentation och i lösningen för att se ifall jag kan samla på mig tillräckligt med domänkunskap för att felsöka.

Stort tack för era svar!