[Talk-dk] Adresser på nye veje - og andet godt nyt

Fre Maj 14 05:11:36 BST 2010

Hej,

Jeg er nu skiftet over til at opdatere alle ændringer med
osmChange-dataformatet:
http://wiki.openstreetmap.org/wiki/OsmChange
<http://wiki.openstreetmap.org/wiki/OsmChange>Egentligt var det bare for at
finde en let måde at kunne slette noder (nu hvor DELETE-metoden drillede),
men det gav samtidigt en række andre fordele. Det betyder:

- Programmet kan nu slette nodes
- Den samlede opdatering er langt hurtigere end før; alle ændringer sendes
samlet og bliver behandlet på et par sekunder, i stedet for at hver rettelse
skal sendes for sig
- Ændringerne er atomiske. Var der knas med OSM-serveren undervejs, ville
man før have risikeret at nogle nodes ikke blev opdateret. Nu er det alt
eller intet i rettesættet, som opdateres.

Her er et eksempel på et changeset (med én samlet opdatering), som både
rummer nye nodes, opdaterede nodes og slettede nodes.
http://www.openstreetmap.org/browse/changeset/4692134

Hvis det ikke lige var for det med kommunalreformen, så var der intet i
vejen for at alle kunne bruge værktøjet nu...

En opdatering, jeg arbejder på nu, er at man kan markere et område på et
kort. Mit program vil så hente alle adresser i det område og ud fra
adresse-data udtrække en liste med (kendte) vejkoder, og den vej igennem
vise hvilke veje, som har fleste uopdaterede nodes. Det burde gøre det langt
hurtigere at komme i gang med et område, i stedet for manuelt at skulle
taste vejnavne. Det skal nok blive godt!

- Peter Brodersen

2010/5/12 Peter Brodersen <peter at ter.dk>

> Hej,
>
> Allerførst: Yep, der bør wiki'es en del, specielt nu hvor der er en del
> forskellige opdaterings-projekter kørende. Det kommer også til at ske.
>
> Dernæst: Jeg har fået kodet lidt videre på projektet og opdateret en god
> del adresser. Her er et screenshot af systemet, som en lille forsmag:
> http://osm.ter.dk/streetupdate.png
> Systemet fortæller altså, hvad den har tænkt sig at gøre med de enkelte
> adresser (markeret med grønt, gult eller rødt) - eller hvorfor, den vil
> undlade at gøre noget ved en adresse (markeret med blåt).
>
> De gode nyheder:
> - Jeg har fundet en stabil XAPI-tjeneste. Jeg kan ikke både søge på
> kommunekode+vejkode, så jeg nøjes med at søge på vejkode (de er typisk på
> fire cifre, så den samme vejkode optræder for mange forskellige veje i
> forskellige kommuner) - dvs. værdien for kms:street_no - og så i det store
> output filtrerer jeg bare indholdet på min side. Langt fra optimalt, men det
> tager stadigvæk kun et par sekunder.
> - Det nye dataudtræk har fået processen til at virke :-) Ved at sammenholde
> OSAK-data med OSM-data er det let at se hvilke adresse-noder, som skal
> tilføjes, rettes, slettes eller ignoreres.
> - Performance er generelt ret god. Det tager en 5-10 sekunder at hente de
> to datasæt (OSAK og OSM), og hver node-opdatering i OSM tager ca. et sekund
> (dvs. et minut eller to for en stor vej). Jeg har overvejet at kigge på
> osmChange for at lave én samlet opdatering; det burde gå endnu hurtigere.
> - Opdateringer skriver nu navnet på den behandlede vej på i
> changeset-kommentaren.
> - Programmet kan også rette postnummer+by til, hvis de er skiftet i
> mellemtiden. Det er fx tilfældet her for en lang række nodes her, der er
> skiftet fra 2860 Søborg til 2870 Dyssegård:
> http://www.openstreetmap.org/browse/changeset/4674155
> Den ændring er faktisk noget, mit enkelt-node-opdaterings-program (
> http://osm.ter.dk/address_insert.php ) ikke foretager, men det burde den
> også. Det er ikke noget, jeg har tænkt på før jeg faldt over et sådan
> tilfælde her i nat.
> - Der er allerede opdateret ca. 200 veje ved hjælp af programmet -
> inklusive en del nye adresser på de veje.
>
> De dårlige nyheder:
> - Noget af en showstopper: Grundet kommunalreformen har en god del adresser
> skiftet vejkode og kommunekode! Det er den største forklaring på, at
> værktøjet endnu ikke er online, idet man kan skabe en del problemer med det.
> Mere om det længere nede.
> - Programmet kan ikke slette nodes endnu. Indtil videre bliver de bare
> ignoreret, når en vejs indhold skal opdateres. Jeg kan ikke lige lure,
> hvordan man med PHP og cURL kan lave et DELETE-request *med* XML-indhold.
> Jeg må spørge lidt rundt omkring.
> - XAPI-fortegnelsen er lidt forsinket. Det betyder, at hvis man går ind på
> en vej, man lige har opdateret, kan man hente forældet data. Det gør ikke så
> meget for adresser, der bare skal opdateres (de bliver bare overskrevet med
> den samme data) eller sletninger (noden er allerede slettet, så endnu en
> sletning gør ingen forskel), men nyoprettelser kan ske igen, idet der ikke
> er noget node-id at forholde sig til her. Er der egentligt ikke noget med at
> OSM brokker sig, hvis en ny node bliver oprettet på samme position som en
> eksisterende?
>
> Det største problem er det med kommune/vejkoderne. Det er så et rimeligt
> stort problem, idet den gamle kommunalkode+vejkode for en vej ikke stemmer
> overens med det nye sæt.
>
> Det betyder, at man kan søge og finde en vej og få koordinater fra OSAK med
> en kommune+vejkode, som der ikke findes noget på i forvejen i OSM. Her vil
> mit program så foreslå, at den opretter samtlige adresser. Søger man derimod
> på de gamle koder (som ikke længere findes i OSAK), vil mit program foreslå
> at slette alle de gamle adresser.
>
> Gør man begge dele, er der måske som sådan ikke noget problem, men det er
> stadigvæk lidt noget rod - specielt fordi der ikke er nogen automatisk måde
> at gøre det må.
>
> Problemet er altså, at der ikke er en garanteret måde, jeg kan få det
> korrekte datasæt fra OSM. Jeg har overvejet nogle alternativer, men de er
> ikke rigtigt gode. Det vil ikke virke at hente/filtrere/sammenligne på
> vejnavn og postnummer, idet en vej kan spænde over flere postnumre, plus at
> adresser i nogle tilfælde har skiftet postnummer i mellemtiden (men bevaret
> kommune/vejkode). Det er fx tilfældet med førnævnte nodes, som skiftede fra
> 2860 Søborg til 2870 Dyssegård. I det tilfælde var mit
> sammenligningsgrundlag således kun kommunekode+vejkode+husnummer for at
> konkludere, at der var tale om de samme adresser i de to sæt.
>
> Det holder heller ikke at sætte en spærring ind, hvis programmet kun vil
> oprette nye adresser. Flere nye veje er netop tilføjet på den måde, som set
> på:
>
> http://www.openstreetmap.org/browse/changeset/4655604
> Det er netop også en ret effektiv måde at få et overblik over omfanget af
> en ny vej, man endnu ikke har mappet.
>
> Jeg har ikke selv en vildt god løsning på problemet i baghovedet. Mit
> script er endnu ikke frit tilgængeligt, idet det er let at komme til at
> slette en masse adresser eller oprette en række dubletter i de kommuner, som
> skiftede kommunekode i forbindelse med kommunalreformen. Er du alligevel
> interesseret, så spring på IRC og hiv fat i mig (brugernavn: pbro):
> irc://irc.oftc.net/osm-dk
> For mange byer er værktøjet sikkert nok at bruge. Det er mere, hvis noget
> mod forventning skulle gå galt, eller du vil hjælpe med udviklingsarbejdet.
>
> - Peter Brodersen
>
>
> 2010/5/10 Peter Brodersen <peter at ter.dk>
>
> Hej,
>>
>> Lige et par gode nyheder herfra på mit arbejde med at opdatere
>> adresse-koordinater.
>>
>>
>> 0. Forklaring af forkortelser
>> 1. Opdatering af hele veje
>> 2. "AWS request error" gennemskuet
>> 3. Ændring i opdateringskøen
>>
>>
>> 0. Forklaring af forkortelser
>>
>> OSM: OpenStreetMap (-data)
>> KMS: Kort- og Matrikelstyrelsen. I denne sammenhæng henviser KMS til det
>> datasæt med millioner af danske adresse-koordinater, der blev frigivet
>> omkring 2002 og som er lagt ind i OSM.
>> OSAK: Officielle standardadresser og koordinater. Henviser til de
>> standardiserede og løbende opdaterede adressedata, vi er interesseret i
>> :-)
>> AWS: Address Web Services. En SOAP-baseret webtjeneste, der giver mulighed
>> for at forespørge om data. Metoderne er offentligt tilgængelige, gratis at
>> anvende og der er ikke restriktioner på den videre anvendelse af output.
>>
>> KMS og OSAK er altså adressesæt fra det offentlige. AWS er metoden,
>> anmoder om adressedata på.
>>
>>
>> 1. Opdatering af hele veje
>>
>> For det første er jeg ved at teste nye funktioner til at opdatere hele
>> veje i stedet for blot enkelte koordinater. Fordelen er, at vi får et
>> hurtigere udtræk (mange koordinater på én gang), og at vi får et udtømmende
>> udtræk for en vej. På den måde kan vi både oprette nye adresser og opdatere
>> eksisterende i samme omgang, hvilket er en klar forbedring for den nuværende
>> opdaterings-metode, hvor vi kun tjekker eksisterende adresser (fra det
>> oprindelige KMS-input).
>>
>> Jeg testede lidt i nat med Jonas (rasher). Et par af opdateringerne kan
>> ses her:
>> http://www.openstreetmap.org/browse/changeset/4655604
>> http://www.openstreetmap.org/browse/changeset/4655607
>> http://www.openstreetmap.org/browse/changeset/4655731
>>
>> Programmet er endnu ikke i fri drift (grundet de problemer, jeg nævner
>> længere nede), men det virker på følgende måde:
>> 1. Man indtaster et vejnavn og ud fra en liste af veje i Danmark med det
>> navn (hentet via AWS) vælger man den ønskede vej, man vil have opdateret
>> 2. Programmet bruger den valgte vejs kommunekode+vejkode til at anmode om
>> en liste af OSAK-data via AWS
>> 3. Programmet henter en tilsvarende liste fra OSM over eksisterende veje
>> 4. Programmet sammenligner de to lister (OSAK og OSM), og foretager
>> følgende handlinger i OSM:
>> 4.1. Findes adressen kun i OSAK, bliver den oprettet med alle addr:-felter
>> og OSAK-data (id, kommune+vejkode, revision)
>> 4.2. Findes adressen både i OSAK og i OSM, bliver den opdateret med
>> koordinater og OSAK-data (id og revision)
>> 4.3. Findes adressen kun i OSM, bliver den slettet.
>>
>> Den nuværende ulempe er, at det er svært at trække data ud af OSM! Jeg
>> ville gerne bruge XAPI til adresse-prædikater, fx:
>>
>> http://www.informationfreeway.org/api/0.6/node[kms:municipality_no=615][kms:street_no=1938]
>> Men dette giver problemer, idet den ene XAPI-tjeneste kun giver mulighed
>> for at begrænse sit opslag til ét tag-prædikat (og et bbox-prædikat). Den
>> anden tjeneste giver fin mulighed for at begrænse på flere tags, men virkede
>> ret ustabil i nat. Før der er fundet en løsning på dette, kan programmet kun
>> oprette nye adresser - hvilket kun er brugbart på veje uden nogen som helst
>> eksisterende adresser.
>>
>> Jeg overvejer en alternativ løsning med en lokal database af
>> adressepunkter. Jeg henter alligevel et dagligt udtræk. Men det ville være
>> rart, hvis tjenesten kunne spørge op imod den rigtige database med det
>> reelle indhold. Ellers risikerer at programmet flere gange prøver at oprette
>> nye vejpunkter, fordi den ikke kan se, at punkterne er blevet oprettet.
>>
>> En let metode mod dette er at logge lokalt, hvilke veje, som er blevet
>> opdateret, men netop fordi der løbende kan komme opdateringer til (nye
>> adresser, nedlagte adresser, mere præcise adresser), skulle folk helst kunne
>> have mulighed for at opdatere den samme vej flere gange over tid.
>>
>> Der er en del mere, som skal finpudses på programmet. Den overholder
>> allerede de sædvanlige regler - primært at hvis en node er blevet
>> modificeret siden KMS-importen, holder den snitterne væk. Et alternativ til
>> at slette et modificeret punkt (fx hvis der er tilføjet en butik til
>> adressepunktet), som ikke er i OSAK, kunne være bare at fjerne alle
>> adresse-tags og bevare den tilføjede information. Således bliver et
>> adressepunkt med en butik og navn tilføjet blot reduseret til butikken og
>> navnet, og ingen adresse-data.
>>
>> Slutteligt skal der gøres en del ved overskueligheden, så man lettere kan
>> se, hvad scriptet har tænkt sig at gøre, før man trykker OK.
>>
>> Kender I til veje, hvor der ikke er nogen som helst adressepunkter, så giv
>> endelig lyd - dem kan jeg snildt tilføje.
>>
>>
>> 2. "AWS request error" gennemskuet
>>
>> Der har tidligere været problemer med adresser, som gav problemer i AWS.
>> Det er dem, som fremstår som "AWS request error" på kø-oversigten:
>> http://osm.ter.dk/address_insert.php
>> I første omgang var det blot en kategori for ethvert AWS-opslag, som gav
>> en eller anden form for fejl.
>>
>> Nogle af dem har været forståelige nok, som når AWS brokker sig over
>> adresser som denne:
>> http://www.openstreetmap.org/browse/node/340946635
>> .. på adressen "Hillerødvej 902, 0000 Uoplyst" :-)
>>
>> I adskillige andre tilfælde var der blot tale om at mit script kun havde
>> tålmodighed til at vente 60 sekunder på et svar. Denne timeout-værdi er nu
>> hævet godt deropad. Nogle opslag har taget op til 15 minutter - og det altså
>> bare for en enkelt adresse!
>>
>> AWS-fejl-adresserne blev smidt til gentest kort efter jeg hævede
>> timeout-indstillingen, og de ca. 20.000-adresser, som tog lang tid at slå
>> op, er nu smidt i kø til gentest. Det virker således som adresser, som
>> AWS-systemet bruger lang tid at slå op, så der går nok lidt tid, før den del
>> af køen er tygget igennem
>>
>>
>> 3. Ændring i opdateringskøen
>>
>> I samme omgang har jeg ryddet lidt op i køen, blandt andet så
>> adressepunkter ikke kan optræde flere gange i køen. Oprindeligt var tanken
>> at man kunne sætte punkter til gentest, hvis der fx var AWS-problemer,
>> OSM-problemer eller at jeg tweakede på andre ting. Men det skabte blot lidt
>> forvirring over hvor mange forskellige punkter, der var blevet behandlet. Nu
>> indsætter køen kun node-id's, hvis de ikke findes i tabellen i forvejen.
>>
>>
>> - Peter Brodersen
>>
>>
>
-------------- næste del --------------
En HTML-vedhæftning blev fjernet...
URL: <http://lists.openstreetmap.org/pipermail/talk-dk/attachments/20100514/d50bc231/attachment.html>